Orthrus

I've updated the design to swap out the micro-B connector for a USB C receptacle. The only real change this requires is adding the CCx pull-down resistors. I've also added a ferrite bead on the power input to prevent noise getting sent back down the USB cable.

I made a video a while ago testing the idea of whether with only two seals applied to the case you could still slide the middle layers out to get to the board. It turns out, you couldn't because the button gets in the way.

In that video, I didn't have the captive nuts installed, and it turns out that those too would prevent a lot of movement without lifting the top layers up (which the seals would prevent).

But to make it even better, I believe I am now going to recommend gluing the top two layers of acrylic together for best security. The bottom two layers aren't necessary to glue because the knurled portion of the captive nuts extends through both of them. But turning the top two layers into a solid unit means that the only hope to get to the erase pin would be getting enough of a gap in the middle to fish a wire in. As long as the seals are applied tightly, that ought to be really difficult.

To raise the security bar just one more notch, I've checked in code (and released new firmware) that sets the bit in CCFG_SYSIO to disable the ERASE pin early in main(). What this means is that now you must short the ERASE pin at power-up for it to be effective. Once the firmware starts to run, the ERASE pin won't work.

This isn't a huge improvement. It just makes the Vulcan neck pinch just a tiny bit trickier to apply.

As of December 2019, no government agency of any kind has issued demands or requests of me concerning Orthrus, with the exception of the BIS in relation to my application for an export license. And since the final determination of that application, there has been no further interaction with the BIS.

Watch this project log for that date to be regularly incremented. If I haven't incremented it in a while, then feel free to request/remind me to do so. The only reason I would not increment it by request would be if the statement were no longer true.

After just short of a year, I heard back from my request for classification of Orthrus from the Department of Commerce.

Their response reads, for the most part...

THIS ENCRYPTION ITEM IS AUTHORIZED FOR LICENSE EXCEPTION ENC UNDER SECTION 740.17(A) OF THE EAR  AND IS DESCRIBED IN SECTION 740.17(B)(1).

In addition to that, they call it a 5A002.A item, which is more or less what I figured.

This page seems to say that as long as I have made a classification request, and that request has been answered that I am free to export (other than to places like North Korea or Iran) without any reporting requirements.

Huzzah!

I requested an opinion from the EFF about the situation we're in and they were very kind to give me some of their time to provide some analysis.

And that situation is, legally speaking, quite murky. No court has weighed in on the regulations in question at all, apparently, so the meaning of the regulations has been completely untested.

After careful consideration, the best conclusion we have is that all of the project documentation, the schematics and even the EAGLE files posted here as well as the source code on GitHub are unencumbered by export law. So I'm not in trouble for posting them. That's good. That means that anyone who wishes to can reproduce the product anywhere in the world. Of course, the project is open hardware and open source firmware, so anyone should feel welcome to do exactly that.

One thing I was considering was uploading the board file as a shared project at OSHPark. After consideration, I believe I cannot do that, nor can I sell bare boards in my Tindie store (other than to Canada). Exporting a physical item - even if it's non-functional by itself - skirts too close to the line. This also means that anyone outside of the US should not use a US fab to have their boards made, as the potential exists for your fab to wind up in trouble for it.

If anyone outside of the US wishes to make Orthrus available for sale, I'd be happy to link to you. But until I hear back from the Commerce Department, my ability to export Orthrus remains limited to Canada.

Thanks again to the EFF for their time and assistance.

It just occurred to me today another way Orthrus could be implemented.

Instead of using a RAID-0 style, where each block is written to only one card, you could do this:

For each incoming block, generate a block of random data (the SAMS70 has a true random number generator to facilitate that). Write the block of random data to one card (chosen at random) and then XOR that block with the incoming data block and write that to the other card.

To read, read the two blocks from each card and XOR them together.

There are a few big drawbacks with this approach:

1. Instead of doing a single card I/O operation per block, you now must perform one to each card. Since we have only one hardware channel, we can't interleave them, so this likely means cutting the performance in half.
2. It depends for security on the quality of the TRNG in the SAMS70 chip. The only word we have on that quality at the moment is Atmel/Microchip's marketing claims.
3. Instead of a volume twice the size of the smaller card, the volume is the same size as the smaller card. This isn't that big a deal, though, because you can get truly massive µSD cards nowadays.
4. There is no easy way to "nuke" a volume the way that overwriting the key block on an Orthrus card does today. You would instead have to overwrite one of the cards entirely.

Given that set of drawbacks, I think I'll stick with AES-XEX and the current key derivation scheme.

In going from AES-128 to AES-256 for the WDE in Orthrus, the key derivation sequence had to be revamped to result in twice as many bits of key. This was particularly complicated by the fact that the key size and cipher block size were no longer the same.

To recall, the new key derivation sequence is:

Each card has 256 bits of unique (private), random key seed material and 512 bits of common (public) key material. The two blocks of private material are shuffled together and an AES CMAC with a 256 bit zero key is performed on each half of the shuffled blocks. The two results are concatenated to form the intermediate key. The two halves of the public block are run through AES CMAC with the intermediate key to form the two halves of the final volume key.

In examining a cryptographic method, what you're looking for is any weak spots - any places where an input into a method unnaturally constrains a key to a smaller number of bits. If there are any such places, then that's where an adversary can gain foothold.

We start with the assumption that AES-CMAC is strong. We can prove that our implementation of AES-CMAC is interoperable, because there are test vectors available (and our code does produce matching results). I personally don't have the crypto chops to go into validating primitives like CMAC (or AES itself) and can only trust the lack of countervailing opinions in the literature.

We use AES-CMAC twice with 256 bits of random input to generate the intermediate key. Half of those bits come from each card, so the holder of one card must still search a 256 bit key space to obtain a 256 bit intermediate key. Even then, that intermediate key must also be run through another pair of CMAC operations before it can be tried on the encrypted material. That second set of CMAC operations require a 256 bit unknown key in addition to the 512 bits of public key information (256 bits each round).

So we can see that at every point, AES-CMAC is used with at least 256 bits of either random data or output from a previous CMAC for both the key and input (the one exception being the all-zero key for the first round). At no point is the CMAC performed on fewer than 256 bits - meaning there is no choke point where the strength is constrained.

The purpose for the second round is simply to further the diffusion of the key material for the first round, which makes it more difficult to be able to predict that a search for the missing key material in the first round has succeeded.

I've gotten a finalized case design teed up. Recall that the major reason for putting Orthrus in a case (beyond aesthetics and protection) is to isolate the ERASE pin of the controller. If you load the firmware in and set the security bit in the GPNVM register, there should be no way to compromise the firmware with access only to the available external interfaces (the button, the USB port and the two SD card slots). The only avenue is to short the ERASE jumper and load new firmware with SAM-BA (or the SWD port).

To effect this, the case itself has to have barriers in place behind or around any openings in the case to prevent someone trying to fish a wire in. The case as currently designed is in 3 1/8" layers and one 1/16th inch layer. The thinner layer is the layer where the board sits, and is exactly the same thickness as the board. The layer immediately above the board is equipped with "dams" around the button, USB and SD card receptacles. Unless an attacker could damage those features without it being visible (which would be incredibly difficult for acrylic), then the interior of the board should be virtually airtight as long as the layers remain securely stacked. This is because the interior walls will sit exactly between the surface of the board and the top layer.

To insure that, a pair of FIPS 140 holographic security seals will be placed on opposite corners wrapping from the top to bottom. As long as you know the serial numbers of the seals remain unchanged, you can be sure that no one has replaced the firmware.

Unfortunately, to make this all work, I've had to move a handful of components on the board, so another revision will have to be made to go along with the new case. The case will be made available on Tindie as soon as these new boards come back from the fab (likely late this week). The case will add $25 to the cost. To facilitate field firmware updates, replacement security seals will be available for $3 a pair.

One of the nice things we got for free with the SAMS70 upgrade was the ability to shift to AES-256. But I haven't done it before now because getting it to just work was a first priority, but also because I wasn't sure whether there would be any speed penalty.

Well, I sat down and did it, and there is no discernible penalty, so the code has been upgraded to use it.

The key generation steps had to change quite a bit because it's now no longer the case that the cipher block size and key length are the same. To make that work, the new volume key generation looks like this:

The volume ID is now 64 bytes. The two key blocks remain 32 bytes and the nonce blocks remain 16 bytes.

You take the two key blocks and shuffle them together into a new buffer alternating bytes (A first). Run AES CMAC (with a zero key) over each half of the shuffled buffer one after the other, concatenating the results. That is the 256 bit intermediate key.

Using that intermediate key, run CMAC over the two halves of the volume ID, again concatenating the results. That becomes the volume key.

I've validated that the code interoperates with the java decrypt program, and to avoid mishaps I've changed the volume magic value.

The system is NOT backwards-compatible, so you must insure that you preserve the content of any volumes before upgrading the firmware. Alternatively, you can dump any version 1 volumes and use the old java decrypter to obtain the plaintext image.