Allen, the threat of an AK47 PIN extraction tool cannot be overlooked, although thankfully it is not a serious threat for most people. In such an environment, unless some other mechanism is provided, the use of a "duress" PIN should be considered - one that would cause immediate zeroization of the keys.
This threat was a very real requirement for us in the development of the SPYRUS Hydra PC hardware file encryption device for military applications, and the solution to that problem also provides a very useful data containment feature that is applicable to a more benign civilian environment. The Hydra PC uses a patent-pending mechanism that involves a secret-sharing scheme that includes (among other factors) a Host Authorization Code plus the user's PIN. This scheme is used to rederive an AES-256 Master Key Encryption Key that is used to decrypt all of the rest of the keys and other sensitive information. The Host Authorization Code is stored in encrypted form in the Registry of the various authorized host computers, and only the system administrator or Site Security Officer has write access to it. The encryption is keyed to the individual machine, so copying and installing it on another machine won't work. And the Host Authorization Code is diversified to the particular token before it is used (during the key generation process, when the user's PIN is created), so that if it were compromised, only that particular token would be compromised - other tokens would not be. Finally, the Host Authorization Code, like the PIN and other Critical Security Parameters, is sent over an encrypted session between the host and the token, even though that connection is typically only a few inches in lengths. Since the user normally has only Limited User Account privileges, he or she will not have access to the Host Authorization Code, and no amount of coercion will be successful. This also means that even if the PIN is divulged, the attacker can use all manner of exotic tools including chemical etching to peel the chip, and electron microscopes and/or ion beams, etc., to try to read the data, it will all be to no avail. There simply nothing stored on the chip that will do the attacker any good at all, even if they can read it (which we very much doubt, based on analyses to date), assuming they cannot break AES-256. Aside from the military applications, this provides an excellent data containment mechanism for commercial and government agencies who need to protect information from disclosure by insiders, either because it is proprietary, or because of various regulatory constraints. Now, even if the user has possession of the device, knows the PIN, and has gigabytes of data recorded on the miniSD card within the Hydra PC, it does them no good at all - they cannot access the data anywhere except on an authorized computer. Even if they take it home and try to decrypt it on their home computer where they do have system administrator privileges, they still can't even log on to the token. In addition to this mechanism, the Hydra PC middleware supports a Hydra PC Sentry function. This mechanism, again under System Administrator control, locks down the system by blocking all reads and write of unencrypted data to or from all removable mass storage devices, including USB and Firewire hard drives and flash memory devices. This makes it unnecessary to try to solve the remote key zeroization problem, because Disgruntled Joe can't remove the data from the premises, assuming Joe is NOT the system administrator! That problem needs to be solved as well, but is beyond the scope of the current discussion. (I want to make it clear that although I have discussed possible military uses for the Hydra PC, it is NOT a classified device, and is commercially available and freely exportable throughout the world (except of course to the pariah countries.) Regards, Bob Allen <[EMAIL PROTECTED]> wrote: [snip] > Finally, remember, (e) for detachable media, including laptop hard > drives, the USER is considered the "node associated with the media", > so really, your data can't be considered secure, because the user is > the node, and the user has the key. (Unless, I suppose, you have the > ability to revoke the key remotely, preventing Disgruntled Joe from > taking a laptop out and then quitting with a copy of your code base > already in his possession). First, your definitions are great for the various states and requirements. Second, I wanted to add three additional vectors that could be used to compromise almost any data in any state of being - rubber hose cryptography by thugs or economic criminals, threatened torture or death of a loved one, and finally the types of torture represented by extreme rendition, Abu Ghraib, and Guantanamo. Very few of us would be able to withstand the kinds of torture that have been developed in the name of exporting and enforcing one or another dogma. So what can we do? Not a d%^& thing I suspect except help each other to come up with plausible deniability solutions and not putting ourselves and our families in harm's way. I've not seen much about plausible deniability in various discussions except with the TruCrypt people. Perhaps this is an area that needs thought on and possible solutions proposed. Best, Allen _______________________________________________ FDE mailing list [email protected] http://www.xml-dev.com/mailman/listinfo/fde
