Author: Nick P
Date: January 8, 2010 11:05 PM
Link: http://www.schneier.com/blog/archives/2010/01/fips_140-2_leve.html#c406341

If one is building hardware, then it will likely be an inline media encryptor. Here's a start for someone looking to design one:

1. Enforce red-black separation. The plaintext must NEVER touch any resource shared with ciphertext side. The crypto component usually bridges the two sides & uses periods processing (data scrubbing) & partitioning of memory to ensure this.

2. Keep the interface simple on the plaintext side. THe implementation should be layered to allow for verification, possibly formal.

3. Use tried and true methods. Keep the protocol as simple as possible.

4. The device includes a TRNG and generates all keys itself, while having self-test features.

5. The device should use two factor authentication if possible.

6. The device MUST have a "trusted path." This is a way to ensure user input is ONLY sent to the cryptoprocessor. In my designs, I usually have a miniature keyboard or something, similar to SafeNet's, that connects directly to the encryptor. Even a PIN pad is decent & an LCD for status or requests is better, if possible. External hard drives are idea for this kind of stuff, as they are expected to be a bit bigger than USB.

7. In my designs, I create the encryption key using a combination of a user-supplied password & onboard (or USB-stored) key, mixed with SHA-2 over a number of iterations.

8. If intentional data destruction is a must, like for classified info, then a Erase button or command should be included & the master key should be in a predictable location. Erase should first overwrite master key several times, then any plaintext (Red) buffers, & then try to burn random data into flash memory that contains user-specific key. If time is left, further sanitize RAM & storage. If a strong password is used and Red data is overwritten, then ciphertext is unrecoverable (assuming good crypto). If password is weak, then user-specific key must be wiped as well. All of this can happen in seconds. My strategy is just press the button and throw it as high as you can. It will be clear by the time enemy grabs it. ;)

9. Covert channel analysis. It's quite easy, although tedious, to design a system without covert storage channels if one uses the MILS architecture & a separation kernel. Many out there. Timing channels are trickier & require clocking inputs and outputs & preventing discrepencies in timing. Formal methods should also be used to catch them at the logic level. Some can be eliminated, but many can only be measured. Don't discount the importance of these: real-world "side" channel attacks are based on exploiting covert channels. If high robustness is needed, then so is covert channel analysis.

10. EMSEC. If your device is to be considered high assurance, rather than medium, then you will also need Emanation Security. The design should meet at least TEMPEST Level 2 standards and protect against both passive and active electromagnetic emanations. Many think TEMPEST is impractical. WRONG! It's been used against US many times and a recent attack by (Cambrige?) researchers used active emanations to drop a RNG's entropy from 32 bits to like 8. High assurance drive encryption requires TEMPEST protection.

Pretty tired tonight so may have left out something. Hope this helps you guys looking to design secure drive encryption. Most important parts are: red/black; design for verification; tried and true beats neat and new; crypto key = onboard-generated key (preferably stored off device) + user password; trusted path. That last feature is essential for secure distributed systems and would have prevented this attack. Have at it!