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

Hello everyone!

Before writing some fancy patch to re-encrypt/scramble key material, might it be possible to go the full
hog? I mean from a rather macroscopic point of view the whole DRAM-part turns out to be a leakage. Since at
least photorec is able to produce usable files from /dev/mem on a running system, this area becomes
unprotected to some extent. Once again I emphasize photorec is *not* limited to jpg headers! It looks for
some 80 kinds of file types, including text files. That was why I was asking for a distinct string appearing
in loop-aes related key material.

Key question is:
What happens at boot time when kernel is loaded form usb memory?
A part of the physical DRAM memory must be allocated for the uncompressed kernel. But what then? First
modules are loaded, an environment to enter the passphrase and finally mount the encrypted root
partition is needed. At the time when /dev/mem is created, would it be possible to set a random key and
encrypt the user-part of the system´s memory? Encrypting swap can already be handled in such a way, with
generic keys for single usage and no user interaction needed.

Of course, this would put memory throughput over the edge. Such a scenario is intended for rather strong PCs
with several megabytes of CPU cache and at least two cores to do some work beyond the de-/encrypting. In my
eyes embedded systems (routers, dsl modems and the like) aren´t that vulnerable to a cold-boot attack as
their memory is soldered & the cases bolted together,
Perhaps this approach is easier to implement than a code that assures key material is set up and erased
properly in otherwise unencrypted memory. Any countermeasure will show an impact on system performance
and this one here seems to provide highest protection at the cost of maximum processing power.

Hence, is it actually possible to encrypt all of DRAM memory? The code for this would have to reside in the CPU
cache. How far is this from being realistic? Can it be compared to some compression software used to extend
RAM size advertised in the early era of Windows 95? How about a RAM disk used as encrypted swap partition so
that no DRAM memory is free but swap space increases by that same size? The encrypted RAM disk could be
assigned with a higher priority. So, how sick sounds this idea?

Kind regards,
Peter

--

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

-
Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/