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

[Matthias Schniedermeyer <ms@citd.de>]

On 12.02.2014 15:19, Arno Wagner wrote:
> Hi,
> 
> > 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.

No.

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 
mitigation technique.




-- 

Matthias