TRESOR

TRESOR is a kernel patch which provides CPU-only based encryption to defend against cold boot attacks on computer systems by performing encryption outside usual RAM. It was developed from its predecessor AESSE, presented at EuroSec 2010 and presented at USENIX Security 2011.[1] The authors state that it allows RAM to be treated as untrusted from a security viewpoint without hindering the system.

Contents

Overview

In computer security, a cold boot attack is a means of defeating data encryption on a running system. It relies on data persistence, namely the fact that software encryption keys are plainly held in RAM and the contents of RAM can be made readable by a third party with physical access by cooling the memory chips or quickly restarting the computer. Since cold boot attacks are based on physical properties of memory devices, they cannot be defeated easily by pure software techniques, since all software running in memory at the point of intervention becomes accessible.

TRESOR

TRESOR is a system that stores and manipulates encryption keys almost exclusively on the CPU alone, and in registers accessible at ring 0 (the highest privilege level) only - the exception being the brief period of initial calculation at the start of a session. This ensures that encryption keys are almost never available via userland or following a cold boot attack. TRESOR is written as a kernel patch that stores encryption keys in the x86 debug registers, and uses on-the-fly round key generation, atomicity, and blocking of usual ptrace access to the debug registers for security.

Its developers state that "running TRESOR on a 64-bit CPU that supports AES-NI, there is no performance penalty compared to a generic implementation of AES",[2] and run slightly faster than standard encryption despite the need for key recalculation, a result which initially surprised the authors as well.[1]

Vulnerabilities

The authors' paper notes the following:

  • Although they cannot rule out CPU data leaking into RAM, they were unable to observe any case this happened during formal testing. Any such case is expected to be patchable.
  • Root access to the encryption keys via the kernel of a running system is possible using loadable kernel modules or /dev/kmem if compiled to support these, but otherwise appears not to be accessible in any known way on a standard running system.
  • ACPI sleep and low power states: - on real processors registers are reset to zero during ACPI S3 states (suspend to ram) and S4 (suspend to disk) states since the CPU is switched off for these.
  • Cold boot attacks on the CPU: - on real processors registers are cleared to zero on both hardware resets and software resets ("Ctrl-Alt-Delete"). However CPU registers are currently vulnerable on virtual machines, since they are reset during simulated hardware resets but not during software resets. The authors deem this an apparent flaw in many implementations of virtual machines, but note that virtual systems would be inherently vulnerable even if this were rectified, since all registers on a virtual machine are likely to be accessible using the host system.

References

  1. ^ a b TRESOR USENIX paper, 2011
  2. ^ TRESOR home page
  3. ^ The authors cite Intel: Shay Gueron, Intel Advanced Encryption Standard (AES) Instruction Set White Paper, Rev. 3.0: "Beyond improving performance, the AES instructions provide important security benefits. By running in data-independent time and not using tables, they help in eliminating the major timing and cache-based attacks that threaten table-based software implementations of AES."

See also