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@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
