It turns out that the method I'm using to derive the volume key is just AES-CMAC-PRF as described in RFC-4615. In other words, we're just calculating the AES-CMAC-PRF with the concatenation of the two card keys as the "key" and the volume ID as the "data."

On the other hand, counter mode isn't the best choice for the block encryption. If an adversary can force you to write a known plaintext to a disk block and then observe the encrypted result, they can discover the pre-ciphertext stream for that block. It is then possible for them to trivially recover any plaintext written to that block anytime after that. The only mitigation possible for this scenario is to use a mode that includes the plaintext in the cipher usage itself (rather than just XORing it as the last step). XEX mode is widely used in whole-disk encryption and has this property. The trouble with this for Orthrus is that it means that the pre-ciphertext can no longer be pre-computed in the background, so performance would suffer, possibly fatally (performance is already quite constrained compared to other microSD card readers).

So Orthrus will retain counter mode at least for the initial version. That means that Orthrus won't be resilient against more sophisticated attacks which assume an adversary can force various requests of his choosing.

An improved performance version of Orthrus would have high-speed USB and perhaps a native SDHC controller of some sort. There are more sophisticated microcontrollers that have these features, and they might have the horsepower to support XEX mode as well (and use AES-256 possibly), but they're 144 pin TQFP or BGA packages and at least double the price of the current device. Not out of the question, but not... today.