Bug 439434

I want to add to this from my home account.

I think that the application and the kernel would have to have a secure method
of keeping the password secure.  The password would have to be tied to the
application and the kernel module couldn't decrypt it for a different application.

Something like PGP but at a kernel level.  When an application starts, it could
generate a private/public key based on the some different random variables.  A
second token could be created when the application requires the use of the
password.  These then could be used to communicate between the kernel and
application.  Hopefully something could be done so no memory dump could point to
the specific tokens used for the password.

Some ideas for tokens that wouldn't need to be in ram but tied to the machine.  

Application serial number.  Could be in a config file or user file.
Processor information.
User name.
Number of users in the password file on the system at the time of start.  
Number of characters in the password file as the time of application/system
start or user login.
Data in some random inode.

The more I think about this, the harder it gets to figure a way around the problem.

The method would have to overwrite the ram after using the password or
calculating anything to do with the password.

Thats a more kernel/distribution related bug though, so i'm reassigning it to
the proper component so it gets the right attention.

Thanks,

Read ya, Phil

I'd like to see some proof that this actually is successful at finding passwords
on a Fedora system before spending too much effort on this.  It sounds scary on
paper, but until I see something concrete involving a Fedora system and not just
some unnamed "Linux" I think it's a bit premature to act.  Also, given how many
different applications store passwords differently this likely will end up being
an application by application fix, not something that can be done globally
(except for maybe the things that use gnome-keyring).  I wouldn't be surprised
if Firefox/Thunderbird hit on Linux, given that they hit on Windows.

If you can find proof that this actually happens on a modern day Fedora system,
please re-open the bug and point out said proof.

I understand your concern.

I found the link for the full paper.

http://citp.princeton.edu/pub/coldboot.pdf


I have copied and pasted the two important parts in regards to Linux.  TrueCrypt
and dm-crypt.

As I understand it, both of these programs work at a kernel level so they would
be cross system unless Fedora actually changed the kernel.  But the procedures
are provided in detail.

The paper does provide some ideas to make it harder to carry out the one attack
without any changes.  (RAM check on reboot and bios passwords for access and boot.)

From the paper, Microsoft does provide some information on how to make BitLocker
better.


A test for Linux is provided here.  It requires physically crashing the system
to test.

http://citp.princeton.edu/memory/exp/


I will see if I can find out more information.

I still feel that this is important.


----------------Copy and paste.

7.3    TrueCrypt
TrueCrypt is a popular open-source disk encryption product for Windows, Mac OS,
and Linux platforms.  It supports a variety of ciphers, including AES, Serpent,
and Twofish. In version 4, all ciphers used LRW mode; in the current version,
version 5, they use XTS mode (see Section 5.3). TrueCrypt stores a cipher key
and a tweak key in the volume header for each disk, which is then encrypted with
a separate key derived from a user-entered password.

     We tested TrueCrypt versions 4.3a and 5.0a running on a Linux system. We
mounted a volume encrypted with a 256-bit AES key, then briefly cut power to the
system and used our memory imaging tools to record an image of the retained
memory data. In both cases, our keyfind program was able to identify the 256-bit
AES encryption key, which did not contain any bit errors. For TrueCrypt 5.0a,
keyfind was also able to recover the 256-bit AES XTS tweak key without errors.

     To decrypt TrueCrypt 4 disks, we also need the LRW tweak key. We observed
that TrueCrypt 4 stores the LRW key in the four words immediately preceding the
AES key schedule. In our test memory image, the LRW key did not contain any bit
errors. (Had errors occurred, we could have recovered the correct key by
applying the techniques we developed in Section 5.3.)


7.4    dm-crypt
Linux kernels starting with 2.6 include built-in support for dm-crypt, an
on-the-fly disk encryption subsystem. The dm-crypt subsystem handles a variety of
ciphers and modes, but defaults to 128-bit AES in CBC mode with non-keyed IVs.

     We tested a dm-crypt volume created and mounted using the LUKS (Linux
Unified Key Setup) branch of the cryptsetup utility and kernel version 2.6.20.
The volume used the default AES-CBC format. We briefly powered down the system
and captured a memory image with our PXE kernel. Our keyfind program identified
the correct 128-bit AES key, which did not contain any bit errors. After
recovering this key, an attacker could decrypt and mount the dm-crypt volume by
modifying the cryptsetup program to allow the raw key to be input.

This is quite likely exploitable on any modern system, Fedora included.  Without
dedicated tamper-proof hardware, it is always going to be possible to retrieve
keys from RAM.  It's the nature of the system.

If you feel you have ideas that would not be vulnerable to this attack, you
would be better off writing some demo code proving your ideas, and why they
don't suffer from this problem (nothing I've seen in this bug so far would be
free from RAM snooping).  The solution for the truly paranoid is to get a
dedicated tamper-proof hardware encryption device.  The rest of us will have to
rely on powering our machines off (for now).

If you want to further fuel your paranoia, I suggest you look over these papers:
http://www.google.com/search?q=data+remanence+volatile+semiconductor+memory

This is not a new problem.  What is new is that someone found an easy way to
acquire the contents of memory.


The real world implications of this are not quite what they appear to be though.
 A successful attack of this nature will need to be very targeted.  If you are a
person who handles very sensitive data, and you need maximum security, I suggest
you keep your sensitive information on something like a flash drive, and only
mount the drive when you actually need the data on it.

I would love to write some code but at this time, I am just getting back to
doing "Hello World" in C again.  To many years since the last time I wrote any
code.  :)  I finally have to write some code so back to the tutorials for my
aging mind.

I have some ideas but putting them into words that others can use to run with
will take some time and investigation.  Also some more time to understand how
some of this can be controlled.

Some of my thoughts have already fallen through in my own mind, especially after
reading about the different tools that can read RAM.

As for sensitive material, with the increased government intrusion into private
lives, the need may become higher for standard individuals.  Also criminals whom
love to steal your credit and bank info would love to be able to grab your
credit card/bank details using a simple hack.