thumdrive integrity --Deniable Thumbdrive?

[Thomas Shaddack]

> WTF is the point of adding more biometric security to a device that
> cannot and does not support data integrity?  that flash memory held
> within the thumbdrive keeps your data in clear text...unless of course
> you store everything within some form of encrypted disk.  even then,
> the quick and dirty way to bypass the bio-security us to pull the card
> out of the usb enclosure and start poking at the contents.

DEFINITELY TRUE!

Thumbdrive products are a good step in the right direction, but by far not
long enough. Another approach is needed.

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.