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/
