A> Second, I wanted to add three additional vectors that could A> be used to compromise almost any data in any state of A> being - rubber hose cryptography by thugs or economic A> criminals, threatened torture or death of a loved one, and A> finally the types of torture represented by extreme A> rendition, Abu Ghraib, and Guantanamo.
RJ> Allen, the threat of an AK47 PIN extraction tool cannot be RJ> overlooked, although thankfully it is not a serious threat RJ> for most people. In such an environment, unless some other RJ> mechanism is provided, the use of a "duress" PIN should be RJ> considered - one that would cause immediate zeroization of RJ> the keys. Given the proper user scenario, this can be workable. However, it is equivalent to giving the cyanide pill to your secret agent -> you're still relying upon the captured agent to decide (a) he's caught (b) escape is not feasible (c) irresistible torture is coming and therefore DEATH BEFORE DISHONOR. This method of resistance to rubber hose decryption requires someone to take the step of zeroing out the key, with all the probable consequences involved. "Oh, clever you. You destroyed your keys, and now we can't recover the data. Oh, well, I guess we don't need you anymore <sfx: gunshot>". I generally regard rubber hose decryption to be less likely than the Robert Hanssen approach; humans, as a class, can be suborned. If you're an attacker, and you can profile the sneakernet, you can identify the weak nodes and bribe them. In a very high security scenario, you need to limit the ability of the user to be a collaborator in an attack. You should design your key management process to cut down on the untrustworthiness of your human network. Having a two-factor authentication mechanism where one of the two factors can be revoked remotely is by far the most scalable solution here. Now, of course, you need to protect the revocation mechanism, as well, so that you're not vulnerable to someone seizing control of the revocation mechanism and disabling all the field agents' abilities to read their data. Thankfully, very few security scenarios require this labyrinthine approach. _______________________________________________ FDE mailing list [email protected] http://www.xml-dev.com/mailman/listinfo/fde
