Re: [dm-crypt] Some questions about cryptsetup 1.6.x

[Arno Wagner <arno@wagner.name>]

Hi,

On Wed, Feb 12, 2014 at 10:49:54 CET, Cpp wrote:
> Greetings.
> 
> I have a few questions about the use of cryptsetup and its security.
> First I'd like to know something about the command line options. I've
> seen people specify the digest (hash) in two different places in
> cryptsetup. Consider the following line:
> 
> # cryptsetup -c aes-xts-plain64:sha512 -h sha512 -s 512 -y -i 5000
> --use-random -y -v luksFormat /dev/sda1
> 
> What is the difference between specifying the hash in the -c parameter
> i.e. aes-xts-plain64:sha512 or by using the -h parameter? Do they both
> do the same thing meaning that the following two are equivalent?

-h is the hash that the plain-text password is put through
to turn it into a binary value of certain defined length.
-c specifies the hash that goes into pbkdf2 for the hash
iteration.

Probably not too clear in the man-page, come to think of it.
"cryptsetup --help" is clearer.

> # cryptsetup -c aes-xts-plain64:sha512 -s 512 -y -i 5000 --use-random
> -y -v luksFormat /dev/sda1
> # cryptsetup -c aes-xts-plain64 -h sha512 -s 512 -y -i 5000
> --use-random -y -v luksFormat /dev/sda1
> 
> 
> Next I'd like to ask about the memory management of the master key.
> Suppose I mounted a volume using luksOpen (or --type luks open). What
> happens when I invoke luksClose (close) on that container? Does the
> master key get securely erased from memory (several overwrites with
> random data) or is it simply blanked out (single overwrite with
> zeros)?

That makes no difference for memory. For DRAM, it is refreshed to
its actual setting periodically anyways, something like 10x...100x per
second. For SRAM (caches, maybe small embedded use), overwriting with
the same value has no effect.

You are confusing this with techniques to delete magnetic storage.

> How is the master key stored in memory? I read somewhere that having
> the same data in the exact same location in RAM for an extended period
> of time (like a 24/7 server) can "burn in" the data into the RAM
> module, which can be later recovered. Is this of any concern with
> current cryptsetup i.e. for attacks like cold boot?

It is a concern for SRAM, but not/less for DRAM. And for SRAM, it 
becomes a concern if the same value is in the same place for years. 
What happens then is that the chip changes slowly and makes it more 
likely that it goes to the previous state on power-up.

Look for example at references [22],[23] and [40] here:
https://www.usenix.org/legacy/events/sec08/tech/full_papers/halderman/halderman_html/
[40] deals only with SRAM. While [22] and [23] deal with DRAM 
also, it is more a suspicion for DRAM, but not a really strong 
threat. While I believe this attack has been demonstrated for 
SRAM, I am not aware of it having ever been done succcessfully 
for DRAM.

There are several factors that make this less relevant for DRAM:

- DRAM cells are much smaller than SRAM cells and there is 
  less room for change before the cell starts to break.

- In a DRAM cell there is less that can change. A DRAM 
  cell is one capactiro and one transistor and ythe transistor
  is unpowered most of the time. In an SRAM cell, there are the 
  two transistors of the Flip-Flop, and one of them is powered all
  the time, according to the cell state.

- DRAM always comes up empty when it was unpowered for a while
  so reading such changes is difficult, while SRAM always
  comes up in a random state with ideally both states of
  the same probability. Now, if a SRAM cell is just 0.01% 
  more likely to come up with one state than the other, that
  is simple to test: Power it up 1 million times, and 
  you see it. It is not that simple for DRAM. There, you
  likely have to mess with the read amplifiers on the chip 
  and do other things that are difficult and expensive.
  It might not work at all, either.  

In addition, the attack in general is not too relevant.
Chip structures have gotten a lot smaller and significant
changes in chip elements are a lot more likely to break the 
chip and hence have to be limited much more strongly then
when Gutman looked at it. 

Also take note that in order to extract a key this way, 
the attacker needs to find the location the key is in as 
well. If you have a perfect memory dump (such as a hot-boot 
attack or a freeze-and-remove attack gets you), you can 
just try every location in decryption. However if there 
is just one changed bit, this fails.  

That said, for tokens storing keys in SRAM in an exactly
known location for years and years, these attacks are a 
concern.  

And finally, zeroing a key-storage location several times
does exactly nothing to help with the problem. What secure
tokens do is flip all bits periodically to prevent the
SRAM cells from changing in a specific way. 

> Finally I'm interested to know about removing all the keyslots.
> Suppose I mounted a container and erased every available keyslot
> (please don't ask why). I know this would in theory make the data
> irrecoverble, but the container is still mounted for the time being.
> Assuming that the power doesn't disappear, is there a way to
> reintroduce a new key slot into the LUKS container after all slots
> have been erased, provided that the container is mounted and I can
> read the master key from memory?

Yes. See FAQ item 6.10. 

Arno
 
> 
> Best regards!
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -  Plato