[FDE] Data at Rest, Data in Transit, and Data in Use

[Patrick Cahalan]

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.