[dm-crypt] Some questions about cryptsetup 1.6.x
arno at wagner.name
Wed Feb 12 16:57:08 CET 2014
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.
Yes, you do. Doing multiple overwrites has exactly no effect for DRAM
> 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
> 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 Wagner, Dr. sc. techn., Dipl. Inform., Email: arno at 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
More information about the dm-crypt