"One of these days, I might build a little device that stores a private key and does on-board encryption using a microcontroller. I would do it just for fun, since it is pretty useless if the infrastructure to support it is not out there."
...while Thomas Shaddack gave us the first go round of a Requirements document (see below).
Sounds like a nice little project..."Cypherpunks(TM) DenyDrive". Surely this must exist somewhere, no? Shouldn't the feds have ben using such a thing forever? Maybe we could sell them a few...
-TD
The unit should be tamperproof, with more services than just a dumb mass storage device. The unit should contain a biometric sensor (eg, a fingerprint reader), a small keypad or other device to enter a PIN, and its own processor, for performing cryptographic operations.The device should support several operations for different PINs, and several PINs, which will allow several different private storage areas, different operations, and a special PIN for destruction of secure content and offering dummy content instead ("See officer? I told you there are no crypto keys there!"). The device should be able to keep audit log of operations. The device should store the data in encrypted form in the memory. The PIN could be part of the decryption key. The device should be able to handle the biometric reader output on its own, independently on the host computer. This architecture together with adherence to USB mass-storage standards would make us independent on any OS-specific drivers, making the device truly multiplatform. The device should be able to perform the encryption/decryption services on its own (hence the cryptographic CPU). Eg, you have an untrusted computer. You plug the device to its port, move a document from the untrusted machine to device's directory "Cleartext", authorize yourself to the device with fingerprint and PIN, select the "Encrypt" function (which can be done eg. by a suffix to the PIN). In few seconds, you should then find the encrypted document in the device's directory "Ciphertext". Similarly, the device should support write-only directory, to which you could write files freely but won't be able to retrieve them without authorization (this could allow using the device for data couriers who would be able to pick data but won't be able to read them along the way). Optionally, the unit could be usable for encryption/decryption of data streams, which would make it very useful for IP telephony. The key for crypto functions should never leave the unit. Attempt of physical compromising of the unit should result in self destruction of at least the part of the memory that keeps the keys (maybe keep them in battery-backed RAM, sealed in epoxide resin with both passive and active tamper-detection devices (including but not limited to thin wire mesh)? This way, even if the computer itself would get compromised, the only thing the adversary would be able to intercept would be the plaintexts used in the sessions with the compromised machine. Which they would be able to get using TEMPEST or a keylogger anyway. This design should be robust against hijacking of the key by eg. trojan horses.
_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus
