CPU-bound Encryption (TRESOR, TreVisor, ARMORED)

TRESOR Runs Encryption Securely Outside RAM

TRESOR is a secure implementation of AES which is resistant against cold boot attacks. 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 only little performance penalty compared to a generic implementation of AES. 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, we recommend to use TRESOR in combination with one of Intel’s new Core-i processors supporting AES-NI (e.g., Core-i5 or Core-i7).

Kernel patch:
[tresor-patch-3.18.5_aesni] (Core-i series with AES-NI support; 64-bit)
[tresor-patch-3.18.5_i686] (other x86 CPUs with at least SSE2; 32-bit)
[tresor-patch-3.6.2_aesni] (Core-i series with AES-NI support; 64-bit)
[tresor-patch-3.6.2_i686] (other x86 CPUs with at least SSE2; 32-bit)
Contributors to Kernel versions 3.14+: Ido Rosen, Claire Farron, Andes Ho, and Seth Dickson.

[tresor_sysfs.c] (userland prompt to write tresor keys securely via sysfs)

Information / Papers:
README (installation instructions)
TRESOR Runs Encryption Securely Outside RAM, USENIX Security 2011
AESSE — A Cold-Boot Resistant Implementation of AES, EuroSec 2010

Alternative: A similar project to TRESOR is Loop-Amnesia (AES-128 for 64-bit CPUs without AES-NI support).


TreVisor – The TRESOR Hypervisor

TreVisor adds the encryption facilities of TRESOR to BitVisor, i. e., we move TRESOR one layer below the operating system into the hypervisor such that secure disk encryption runs transparently for the guest OS.

Paper: [http://www1.cs.fau.de/filepool/projects/trevisor/trevisor.pdf]
BitVisor-1.2 patch: [http://www1.cs.fau.de/filepool/projects/trevisor/trevisor-1.2-patch]
BitVisor-1.3 patch: [http://www1.cs.fau.de/filepool/projects/trevisor/trevisor-1.3-patch]
BitVisor-1.3 patch with XTS: [http://www1.cs.fau.de/filepool/projects/trevisor/trevisor-1.3-patch-xts]
README: [http://www1.cs.fau.de/filepool/projects/trevisor/README.txt]

(The original publication is available at Springer.)


ARMORED – CPU-bound Encryption for Android-driven ARM Devices

As recently shown by attacks against Android-driven smartphones, ARM devices are vulnerable to cold boot attacks. At the end of 2012, the data recovery tool FROST was released which exploits the remanence effect of RAM to recover user data from a smartphone, at worst its disk encryption key. Disk encryption is supported in Android since version 4.0 and is today available on many smartphones. With ARMORED, we demonstrate that Android’s disk encryption feature can be improved to withstand cold boot attacks by performing AES entirely without RAM on ARM CPUs.

[tresor-3.2.0_arm-pregen.patch] (one atomic section per 16 blocks)
[tresor-3.2.0_arm.patch] (one atomic section per block)
[readdbgregs.tar.bz2] (kernel module to read debug regs)
[armored.paper.pdf] (The 8th ARES Conference (ARES 2013), Regensburg)
[armored.slides.pdf] (The 8th ARES Conference (ARES 2013), Regensburg)

(The research paper is published at the 8th ARES conference.)

3rd Party Development:
[tresor-3.14.0_arm_am335x-omap-xts128.patch] (README) by Cameron Moree