Re: [dm-crypt] Crack a dm-LUKS partition or harddisk

[Arno Wagner <arno@wagner.name>]

On Wed, Nov 04, 2009 at 05:51:59PM +0100, Si St wrote:
> Question:
>
> Say we have a dm/LUKS encrypted partition or harddisk. - Do we have a
> crack-password-delay-mechanism as a part of the encryption, or is this a
> feature of the software of the OS?
> 
> I have understood that with the very rapid crackingspeed (brute-force)
> we have nowadays, the new approach to this is to force in a delay for each
> password enter, as a tool of increased security. Is this feature a block
> independent software, or is it only a software program of the booted OS?
>
> If so, attacking the harddisk directly independent of the booted OS will
> pass this feature.
> 

I guess this is in response to a recent slashdot article pointing
to some people that have cracked a PGP encrupted zip file using
Amazon EC2. 

Forst, this is only relevant if you have low entropy in your
passphrase. An exapmple would ba an [a-z] 8 char passphrase, which
has (if it is random) about 37.6 bits of entropy. This is of course
far less than a 128 bit or 256 bit key and in a brute force attack
it may be beneficial to run though all possible passphrases instead of
through all possible keys.

LUKS uses PBKDF2, which is specifically designed to be resilient
in case such low-entropy passwords are used. The hash is SHA-1
(the recent discoverd weaknesses do not matter for this application)
and it determined by a benchmark system, which basically benchmarks
PBKDF2 and then uses the number of iterations that give a specific
checking time. As fas as I can tell, the LUKS spec does not give a 
default.

cryptsetup 1.0.6 (the version in Debian Stable) seems to use
a default value of 1 sec (line 28 in src/cryptsetup.c:
static int opt_iteration_time = 1000;). 

Incidentially this gives a cost > 10 Billion USD for 
Amazon EC2 if the key setup was done on reasonably fast
hardware. If you do it on a linux running in a bochs
emulator, e.g., the security may be a bit worse ;-)

The passphrase and the iterations are needed to derive the key 
that unlocks the master key. This means the delay feature is 
a cryptographic feature of the key-derivation mechanism and 
cannot be bypassed by anyone. It is not just a static delay,
it is a computation that has to be done since its result is 
needed.

What the OS can do, if it is corrupt, is to just store 
the key somewhere when you unlock your crypto-container. 
This requires an attacker to have access to your OS two 
times and yoy to open the container in between. It has 
recently gotten some limited fame as an "Evil Maid Attack".
However an easier attack installs a keyboard sniffer or a 
physical bug into your computer.

Arno

----

Reference for LUKS:
http://cryptsetup.googlecode.com/svn-history/r42/wiki/LUKS-standard/on-disk-format.pdf

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier