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