Re: the cold-boot attack - a paper tiger?

[Matthias Schniedermeyer <ms@xxxxxxx>]

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/