Protect Linux from cold boot attacks with TRESOR

While reading an interesting Blog I discovered a new treasure: TRESOR, in short TRESOR is a secure implementation of AES which is resistant against cold boot attacks and other attacks on main memory.

If like me you wonder what a cold boot attack is, Princeton University can help us :

Contrary to popular assumption, DRAMs used in most modern computers retain their contents for seconds to minutes after power is lost, even at operating temperatures and even if removed from a motherboard. Although DRAMs become less reliable when they are not refreshed, they are not immediately erased, and their contents persist sufficiently for malicious (or forensic) acquisition of usable full-system memory images. This phenomenon limits the ability of an operating system to protect cryptographic key material from an attacker with physical access. We use cold reboots to mount attacks on popular disk encryption systems — BitLocker, FileVault, dm-crypt, and TrueCrypt — using no special devices or materials. We experimentally characterize the extent and predictability of memory remanence and report that remanence times can be increased dramatically with simple techniques.

And moving to their blog we can read some more useful information:

The root of the problem lies in an unexpected property of today’s DRAM memories. DRAMs are the main memory chips used to store data while the system is running. Virtually everybody, including experts, will tell you that DRAM contents are lost when you turn off the power. But this isn’t so. Our research shows that data in DRAM actually fades out gradually over a period of seconds to minutes, enabling an attacker to read the full contents of memory by cutting power and then rebooting into a malicious operating system.

Interestingly, if you cool the DRAM chips, for example by spraying inverted cans of “canned air” dusting spray on them, the chips will retain their contents for much longer. At these temperatures (around -50 °C) you can remove the chips from the computer and let them sit on the table for ten minutes or more, without appreciable loss of data. Cool the chips in liquid nitrogen (-196 °C) and they hold their state for hours at least, without any power. Just put the chips back into a machine and you can read out their contents.

This is deadly for disk encryption products because they rely on keeping master decryption keys in DRAM. This was thought to be safe because the operating system would keep any malicious programs from accessing the keys in memory, and there was no way to get rid of the operating system without cutting power to the machine, which “everybody knew” would cause the keys to be erased.

So we have seen now the problem, but what’s the cure ?

TRESOR

TRESOR implement a secure way to store the sensible information about encryption outside RAM, the basic idea behind this implementation is to store the secret key inside CPU registers rather than in RAM. All computations take place only on registers, no AES state is ever going to RAM. In particular, the x86 debug registers are misused as secure key storage.

Running TRESOR on a 64-bit CPU that supports AES-NI, there is no performance penalty compared to a generic implementation of AES and the supported key sizes are 128, 192 and 256 bits (full AES).

Running TRESOR on a plain old 32-bit CPU, supporting at least SSE2, is possible as well. But you get a performance penalty of about factor six compared to generic AES and the only supported key length is 128 bits.

Thus, it’s recommend to use TRESOR in combination with one of Intel’s new Core-i processors supporting AES-NI

Installation of TRESOR

TRESOR is a patch for the Linux Kernel, in this moment the patch is available for the Kernel 2.6.36 (32 and 64 bit) or 3.0.9 (64 bit).

In this example i’ll show how to install it on Ubuntu 11.10 at 64 bit, this is based on the guide done by Oliver

1) Install the requisites for building your own Kernel:

sudo apt-get install build-essential fakeroot kernel-package libncurses5-dev

2) Download the version 3.0.9 of the Linux Kernel, the default config for Ubuntu and TRESOR patch:

cd
wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.9.tar.bz2
wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.0.9-oneiric/linux-image-3.0.9-030009-generic_3.0.9-030009.201111111635_amd64.deb
wget http://www1.informatik.uni-erlangen.de/filepool/projects/tresor/tresor-patch-3.0.9_aesni

3) With these command you can extract the config file from the ubuntu package and store it in the directory kconfig

mkdir ubuconf
cd ubuconf
ar -x ../*.deb data.tar.bz2
tar xf data.tar.bz2 ./boot/config-3.0.9-030009-generic
cp ./boot/config-3.0.9-030009-generic ../kconfig
cd ..
rm -r ubuconf

4) Now unpack the kernel and apply the patch with:

cd /usr/src
sudo tar xf ~/linux-3.0.9.tar.bz2
sudo patch --directory /usr/src/linux-3.0.9/ -p1 < ~/tresor-patch-3.0.9_aesni

5) And now apply the config extracted from the ubuntu package:

cd linux-3.0.9
sudo cp ~/kconfig .config
sudo make menuconfig

The TRESOR patch has a corresponding configuration entry in (Cryptographic API -> AES cipher, coldboot resistant (SAFE)) is added, which you must activate. Once activated you can save the configuration and compile the kernel into a .deb package with:

sudo make-kpkg kernel_image --initrd --revision 1337

You can install it with

sudo dpkg -i ../linux-image-3.0.9_1337_amd64.deb

And to test this new kernel just issue a:

sudo reboot

On the Grub page choose the 3.0.9 Kernel, Next you see a TRESOR password prompt: >> TRESOR << Enter password > ******** Confirm key hash > 51 b7 fd e3 67 b3 89 64 14 ca 02 60 e5 d7 d2 6e f0 65 99 12 4a 60 27 6b 80 19 6a 43 ff c9 58 ac Correct (yes/no) > yes

Choose a secure password of 8 to 53 characters (special characters allowed). There is no possibility to change this password once the system is up. So make sure you have entered the correct password (otherwise you may have to reboot). A hash of the secret key helps you to verify that the password you entered is correct. The hash is not the key itself; it is save to be displayed and even to be written down.

Once the system is up and running, you can give ACPI suspend a try: echo mem > /sys/power/state. Upon wakeup you get a password prompt similar to the one shown above. But this time you can enter the correct password only, i.e., the password you have entered during boot. To check whether the password you entered is correct, the hash of the key is stored internally in RAM. Upon wakeup, you are only allowed to enter the correct password for two reasons: First of all, a wrong key immediately leads to data corruption if disk encryption is active. Secondly, your computer is safe against unauthorized access without the need to have an additional user password prompt.

Set up an encrypted partition with TRESOR:

To make a simple test you can use cryptsetup.

sudo apt-get install cryptsetup

And create a 256MB large container file. It serves as a substitute for a real partition.

dd if=/dev/zero bs=1M count=256 of=container

Once done the container file create a loop device mount.

sudo losetup /dev/loop0 container

Now you can encrypt the container or partition with a safe 256-bit keys. Remember that on 32-bit systems you can use only 128 bit key length. The passphrase can be an arbitrary string — it is just used to derive the Crypto-API dummy key, which has no effect in practice.

sudo cryptsetup create tresor /dev/loop0 --cipher tresor --key-size 256

Next make a filesystem on the recently encrypted partition by mkfs.ext2 /dev/mapper/tresor to setup EXT2, for example.

sudo mkfs.ext2 /dev/mapper/tresor
sudo mkdir -p /media/tresor
sudo mount /dev/mapper/tresor /media/tresor

You are done, you can now put your files in /media/tresor, they will be crypted and TRESOR used to store your keys.

If you will enter an incorrect password on boot, the mount will be acknowledged with an error, because it do not recognize the file system, since it can not be decrypted.

mount: you must specify the filesystem type

Conclusions

I hope to have shown some useful information on a real problem (cold boot attacks) and a possible solution (TRESOR), sadly as long as this is not included in a easily installable Kernel i think that it will not be so used. But also i think that the import is to be aware of the possible security risks of our computers and their solutions.

More About TRESOR

I suggest the excellent work by Tilo Muller, Felix C. Freiling and Andreas Dewald : TRESOR Runs Encryption Securely Outside RAM

Popular Posts:

None Found