Orthrus dramatically simplifies the problems of providing a securely encrypted data store. There are no passwords or key material to manage. The act of pairing two cards together automatically creates all of the key material necessary to secure the store without any human action (other than initiating the paring process by pressing and holding a single button). The security offered by Orthrus is simple to explain and trivial to use. It's simply that if you have both of the cards, you have the data. If you have only one of them, then it is cryptographically opaque.
The basis for Orthrus is an ATXMega32A4U. This is an AVR with a built-in full speed USB interface and hardware AES support. It also has 32K of program memory and 4K of RAM. It has other peripherals, but of chief interest for us is that it has hardware support for SPI and more than a few GPIO pins. At first glance, it would seem to be ridiculous overkill for what we want to achieve, but it's our choice because it's the minimum available chip that includes the AES accelerator, and being able to do AES at north of 1 MB/sec is worth it. Hardware AES not only runs at more than 100 times faster than my software implementation, it also can proceed in the background, leaving the CPU free for actual I/O.
To review, SPI works by sharing 3 lines among all of the peripherals - MOSI, MISO and SCK. In addition to that, each peripheral on the bus has a unique chip select line (usually active low, so !CS). For each cycle of the CLK line, one bit is shifted out from the master over MOSI to the slave, and at the same time a bit from the slave is shifted out to the master over MISO. There are four choices for configuration of the polarity and phase of the clock signal relative to the setup and sampling of the two data lines, but the SPI system in the controller will generally shift a byte at a time. Since the AVR SPI system is only single-buffered, there will be inter-byte gaps as the data from the peripheral is read and/or the next byte of data to be written is set up.
One way to alleviate those inter-byte gaps is to use USART0 in SPI master mode. When you do this, the transmit register is double-buffered, so you can write a new value to it while one is going out. There is a REMAP register for the port we're using for SPI which allows USART0 to be mapped to the same pins used by SPI. Unfortunately, the USART synchronous pin mapping swaps TXD (MOSI) and the clock pin relative to SPI. There's a bit in the REMAP register to accommodate that as well, but unfortunately Atmel in all their wisdom made this bit work backwards from what you'd expect. The SPI bit in the remap register changes the SPI port wiring to match the USART layout. What this effectively means is that the most versatile way to wire the SPI port is with MOSI and clock swapped and using the upper nibble of the port. If you want to use traditional SPI, you can turn on the SPI flag in REMAP and the SPI subsystem will line up properly. If you want USART in SPI master mode, you turn on the USART0 bit in REMAP and that subsystem is shifted into place with the pins correct.
The controller requires 3.3 volt power. Since that's also what the cards want, there's no need for level shifting and the entire system can run from a single supply. Two SD cards and a rather beefy controller are probably pushing things for an LDO, however, but a buck converter can be used with almost no extra boards space. It is a good idea to provide a mechanism for the controller to turn power to the cards on and off. This way, power can be applied only once the two cards have been inserted. If one card is removed, power to both can be dropped, insuring that both cards will cold-start once the second is installed. We can use a P channel MOSFET as a power switch, and an AP2331 current limiting switch will insure that any inrush from the cards won't impact the supply rail for the controller. Since most of the pins we use are only general purpose and we barely use...Read more »