[dm-crypt] Some questions about cryptsetup 1.6.x
ms at citd.de
Wed Feb 12 16:04:08 CET 2014
On 12.02.2014 15:19, Arno Wagner wrote:
> > 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.
The reports where that remanence (i'm using the term for magnetic
storage. Don't know/remember if there is/was a specific term for DRAM)
in DRAM is longer, the longer a specific value was in a specific cell.
That is for the attack:
- Switch of computer
- Rip out RAM (optionally cool them to extend the time further)
- Plug them into a device that dumps current memory contents
AFAIR the articles, the time varies between (milli-)seconds to minutes
for cooled/non-cooled memory and also for "long term" vs. "short term"
memory-contents. (So best-case is likely cooled & long term)
For e.g. loop-AES contains a mitigation for that. If you activate the
option it holds 2 sets of keys in RAM. One is the "actual" key, the
other one is (AFAIR) with it's bit inverted and then it bit-invertes and
switches the sets in regular intervals. So that none of the 2 locations
actually falls into the "long term" category. In the hope that when you
switch of power (to memory) the keys fade fast enough to not be
recoverable (or at least with sufficient severe loss of bits).
Cold-Boot is a slight variation of this, where you try to use the actual
computer itself for the dump. You can (try to) mitigate using the
computer for dumping the memory, so an attacker has to revert to "rip
out". But if unsucessful the memory can be dumped with only a neglient
amount of bit-loss. (You have to store & execute a programm in some way.
So you have to overwrite at least a little bit of memory)
IIRC there was a description of a mitigation technique that "pin"s the
key in L1 (and/or L2) cache without it being stored in RAM.
And an interesting question is, if AES-NI could be used as another
More information about the dm-crypt