TRESOR

TRESOR (

CPU registers rather than random-access memory (RAM). It is one of two proposed solutions for general-purpose computers. The other, called "frozen cache" uses the CPU cache instead.^[1] It was developed from its predecessor AESSE, presented at EuroSec 2010 and presented at USENIX Security 2011.^[2]

The authors state that it allows RAM to be treated as untrusted from a security viewpoint without hindering the system.

Motivation

In

encrypted data on a computer. Modern encryption algorithms, correctly implemented and with strong passwords

, are often unbreakable with current technology, so emphasis has moved to techniques that bypass this requirement, by exploiting aspects of data security where the encryption can be "broken" with much less effort, or else bypassed completely.

A

forensic or evidentiary

purposes.

Since this is a physical property of the hardware itself, and based on physical properties of memory devices, it cannot be defeated easily by pure software techniques, since all software running in memory at the point of intervention becomes accessible. As a result, any encryption software whose keys could be accessed this way is vulnerable to such attacks. Usually a cold boot attack involves cooling memory chips or quickly restarting the computer, and exploiting the fact that data is not immediately lost (or not lost if power is very quickly restored) and the data that was held at the point of intervention will be left accessible to examination.

Cold boot attacks can therefore be a means of unauthorized data theft, loss or access. Such attacks can be nullified if the encryption keys are not accessible at a hardware level to an intruder–i.e., the devices in which the keys are stored when in use are not amenable to cold boot attacks–but this is not the usual case.

TRESOR's approach

TRESOR is a software approach that seeks to resolve this insecurity by storing and manipulating encryption keys almost exclusively on the

atomicity, and blocking of usual ptrace

access to the debug registers for security.

TRESOR was foreshadowed by a 2010 thesis by Tilo Muller which analyzed the cold boot attack issue. He concluded that modern x86 processors had two register areas where CPU-based kernel encryption was realistic: the SSE registers which could in effect be made privileged by disabling all SSE instructions (and necessarily, any programs relying on them), and the debug registers which were much smaller but had no such issues. He left the latter for others to examine, and developed a proof of concept distribution called Paranoix based on the SSE register method.^[3]

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",^[4] and run slightly faster than standard encryption despite the need for key recalculation, a result which initially surprised the authors as well.^[2]

Potential 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 virtual memory (/dev/kmem
) and physical memory (/dev/mem), 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.

TRESOR is resistant to
AMD Bulldozer, and certain VIA PadLock
processors.

In 2012 a paper called TRESOR-HUNT showed how a
ring 0 (the highest privilege level), bypassing the "lockout" imposed by TRESOR, which would allow it to read the keys from the debug registers and transfer them to usual memory. The paper also proposed ways to mitigate such attacks.^[6]

References and notes

^ Erik Tews (December 2010). "Crypto Talk at 27C3: FrozenCache – Mitigating cold-boot attacks for Full-Disk-Encryption software, Day 3, 23:00, Saal 2". 27th Chaos Communication Congress.
^ ^a ^b Müller, Tilo; Freiling, Felix C.; Dewald, Andreas (2011). "TRESOR Runs Encryption Securely Outside RAM" (PDF). Preprint.
^ Müller, Tilo (May 2010). "Cold-Boot Resistant Implementation of AES in the Linux Kernel" (PDF). Thesis.
^ "TRESOR Runs Encryption Securely Outside RAM".
^ 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."
^ Blass, Erik-Oliver; Robertson, William. "TRESOR-HUNT: Attacking CPU-Bound Encryption" (PDF). ACSAC 2012.

External links

TRESOR home page

[1] Erik Tews (December 2010). "Crypto Talk at 27C3: FrozenCache – Mitigating cold-boot attacks for Full-Disk-Encryption software, Day 3, 23:00, Saal 2". 27th Chaos Communication Congress.

[tresor-usenix-2] Müller, Tilo; Freiling, Felix C.; Dewald, Andreas (2011). "TRESOR Runs Encryption Securely Outside RAM" (PDF). Preprint.

[3] Müller, Tilo (May 2010). "Cold-Boot Resistant Implementation of AES in the Linux Kernel" (PDF). Thesis.

[4] "TRESOR Runs Encryption Securely Outside RAM".

[5] 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."

[TRESORHUNT-6] Blass, Erik-Oliver; Robertson, William. "TRESOR-HUNT: Attacking CPU-Bound Encryption" (PDF). ACSAC 2012.

[1]

[2]

[3]

[4]

Motivation

TRESOR's approach

Potential vulnerabilities

See also

References and notes

External links