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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
