On 12.02.2014 16:57, Arno Wagner wrote: > On Wed, Feb 12, 2014 at 16:04:08 CET, Matthias Schniedermeyer wrote: > > 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. DRAM is in effect a little capacitor, it takes a little time for the charge to fade. There was an article a few years back that said that modern DRAM actually got better at holding that charge. And that (or a separate) article further said that the time gets extended when a specific cell holds a particular charge for a long time. > Have a citation? Unfortunatly no. > > 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. The basic "attack vector" is getting ahold of the memory contents. With cold boot you try to do that "inline" (RAM still plugged in). In the "rip out" case it's "out-of-line" (RAM in another device). So i personally see little difference, both require protection against physical access to the computer. Only what an attacker can do if s/he gets ahold of the physical computer is slightly different and they ce be tried in order (cold-boot, then "rip out"). > > 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. The theory is that after the CPU is reset (Cold-boot) or switched off (rip-out) you have no way of getting ahold of the cache contents. DRAM is easy, they have a standard connector (assuming a standard PC) and building a device where you connect the DRAM and that then copies the contents is relativly easy. At least for a qualified attacker. Building a device that dumps the contents of a CPU should be quite difficult and as an "active" component the CPU can't be simply read. You have to create the all interfaces a CPU needs to start/run and then you have to write a program that the CPU needs to execute that does the dumping. And then it may still not be possible. I'm guessing CPUs mark valid cache-contents and i would further guess that marker/flag get's reset upon a reset of the CPU. Same goes for the cold-boot-case, at least the theory is that you can't get to the cache-contents after a reset, or that the memory usage while booting is enough to evict the complete cache. Altough i would go with the theory that CPUs don't have any cache-contents marked valid after the CPU got a reset signal. -- Matthias _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
