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

[Arno Wagner <arno@wagner.name>]

On Wed, Feb 12, 2014 at 16:04:08 CET, Matthias Schniedermeyer wrote:
> 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.

Yes, you do. Doing multiple overwrites has exactly no effect for DRAM
or SRAM. 
 
> 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)

I believe that is inconsistent with the way DRAM works. It is true
for SRAM. Have a citation? 
 
> 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 

It actually is something completely different, as the RAM stays powered
and modern DRAM is self-refresing. You are confusing two different things
here.

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

That would be really bad. L1/L2 cache is SRAM and that does suffer
from changes when values are stored long-term.

> And an interesting question is, if AES-NI could be used as another 
> mitigation technique.

There is very likely nothing to mitigate here.

Arno
-- 
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