To clarify: My understanding of key scrubbing in loop-aes is it is designed to prevent burn in as described in the Guttmann paper, which has not yet been shown to be a practical threat at any rate. Unlike the so-called "cold boot" attack, which can be defeated if keys in memory are overwritten after use. So just quit X and run THC's smem utility (from their secure_delete sources) as root after umo8nting an encrypted partition. Poof, all of free memory gets overwritten. No more keys in memory to recover. If an attacker has physical access to your machine while an encrypted partition is mounted, well .., you're screwed anyway. --- Matthias Schniedermeyer <ms@xxxxxxx> wrote: > On 23.05.2008 11:51, Peter_22@xxxxxx wrote: > > Hello everyone! > > Warning in front. I'm not an encryption expert so > take what i say with a > grain of salt. > > > > Maybe you remember the cold-boot attack described > at > > http://citp.princeton.edu/memory/ > > claiming memory remanence to leak passwords used > in popular disk > > encryption software. For truecrypt and other > suites this might apply, > > but there was some thing called "key scrubbing" in > loop-aes. As a > > cold-boot attack comprises the passphrase recovery > even after a system > > reset it ought to be even easier to check memory > on a running system. > > So does a simple command listed at > > http://citp.princeton.edu/memory/exp/ > > Key-Scrubbing "helps" the DRAM-Modules to forget > it's content after the > power to the DRAM-Modules is cut. (Whatever the > reason for that) > > The theory behind that is that memory patterns can > "burn in" when it > doesn't change for a long time. > > So Key-Scrubing uses at least 2 memory-locations > each with a key-set and > inverts the bit-pattern of the currently unused > one(s). Then it more or > less rapitly switches between the memory-locations, > inverting the > bit-patterns as needed. > > This way if power is cut from the DRAM-Module it > should "forget" the > key-set very fast. > > But the key-word here is "cut power" the > reboot-attack doesn't cut > power, so the DRAM doesn't forget anything. > > > 'sudo strings /dev/mem | less' > > Since I know the passphrase I recently entered to > mount an encrypted > > volume, I can search for it in memory like this: > > 'sudo strings /dev/mem | grep *somepass*' > > The Pass(word/phrase) has nothing to do with the > actual set of > encryption keys. > > The input keys are hashed into a bit-pattern that > has absolutly no > resemblance with the original input-bit-pattern. > > So the actual problem is: Where in memory is the > bit-pattern stored? > > > Surprisingly nothing happens. A passphrase as > entered in cleartext is > > never returned. Most likely, a reboot won�t make a > change for the > > better. Maybe putting memory modules in cryo > stasis allows for > > recording some bit-patterns. As of now, this boot > attack reveals > > nothing helpful to my eyes. Or could you tell me > at what point I acted > > amiss? > > A Reboot has the property that Power to the > DRAM-Modules isn't cut and > that most BIOSes don't erase memory. So the next OS > that boots can read > pretty much anything that was stored in the > DRAM-Modules. (Except the > few bytes that were overwritten by the boot and > usage of the now running > OS) > > So the ONLY 2 problems the attacker has with the > reboot-attack: > - Can i get the computer to boot something i want > - Where in the upto to several GB of data is the > data i want. > > The only bigger problem is the first one, for the > last one you can > always dump the whole memory and look for the keys > later or "brute > force" the memory content. > > And last but now least you can yank out the > DRAM-Modules and put them in > a device that just dumpes it's contents somewhere > else. (Key-Scrubbing > is whay MAY help against this as the few seconds > where the DRAM-Modules > are without power MAY be enough for it to forget the > keys) > > > The biggest problem for YOU is: Once the attacker > has physical access to > your computer, a requirement for this whole type of > attack, you have > pretty much lost. As current or to be more precises > "byable for > reasonable amount of money"-computers can't easily > be protected against > physical tampering. > > > Btw. My personal favourite is firewire or ieee1394. > When your computers > has firewire and a firewire-drivers is loaded(*) you > can Remote-DMA the > whole memory WHILE IT IS RUNNING you don't even have > to reboot or yank > out the DRAM-Modules. > > > > > *: > When the Option in most recent Linux-Kernels (AFAIR > 2.6.24 or 2.6.25) to > enable Remote-DMA for debugging purposes showed up, > i asked the > mainainer if the firewire-controller has to be > initialized to enable > Remote-DMA and he answered that it has to. So a > firewire-controller > without drivers or disabled in BIOS (if onboard) MAY > be OK. > > > Bis denn > > -- > Real Programmers consider "what you see is what you > get" to be just as > bad a concept in Text Editors as it is in women. No, > the Real Programmer > wants a "you asked for it, you got it" text editor > -- complicated, > cryptic, powerful, unforgiving, dangerous. > > > - > Linux-crypto: cryptography in and on the Linux > system > Archive: > http://mail.nl.linux.org/linux-crypto/ > > - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
