I burned the midnight oil this evening. I wrote a Java program that decrypts an Orthrus volume given images of the two cards. It should be no surprise that this is possible to do - the whole security of Orthrus is based around the idea that you're going to keep the cards separate so that no one has a chance to get both images (unless they're supposed to).

I then paired two cards with a real Orthrus and zeroed out a goodly chunk of blocks. I then read in images of the two cards and ran them through the Java program, expecting to get all zero bytes out. Of course, there were some bugs to find, but at the end of that effort, I did, indeed, get the expected result.

Most of the bugs were in my translation of the BouncyCastle AES implementation used in the first prototype, so they (in principle) won't have any impact on the next prototype (which will do AES natively in hardware), but there were one or two in the actual logic of Orthrus, so it's good that they were found. And while AES ECB is hardware accelerated, CMAC is still done in software, so it's important to validate that it interoperates as well.

I've checked in the java code in question into the GitHub repository. It's useful in that the Java code is MUCH simpler and easier to read. It should be fairly straightforward for (almost) anyone to understand what it's doing. And you can test the hardware yourself by pairing two cards, writing a filesystem on them, then reading in the encrypted images and running them through the java code.