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.
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 half of the available pins, we have the luxury of picking pins mostly for convenience. Since the USB port is only in one spot, we place the chip so that those are close to the USB connector. The remaining available SPI pinning is convenient for the SD cards, fortunately, and the rest of the connections can be selected to be near the peripherals in question. That puts the card related lines on port C near the SPI, the LED, switch and card power on port A, and the random number generator on port D. We'll use the USART on port E as a diagnostic I/O for development. It will be put on the two unused pins of the 2x3 PDI programming interface.
All that would be enough to simply provide a RAID 0 double SD card reader, but for the cryptography we need to be able to generate keys. This means coming up with random numbers, and when they have to be cryptographic quality, that's always non-trivial. I've decided to add a hardware RNG. This is done with a transistor in an avalanche configuration as a noise generator. The noise is fed into a second transistor to amplify it, followed by a pair of AC coupled self-biased inverters to amplify it further, before it's fed into one of the controller's GPIO pins. The inconvenient part of this circuit is that it requires a (relatively) high voltage supply. An AP3012 boost converter is used to make around 20 volts.
The first block of each card is reserved as a key storage block. The size of the volume reported to the USB host is determined by taking the smaller of the two card sizes, subtracting one and doubling that. The first block on each card contains...Read more »