Source-linked AI summary
Security Through Amnesia: A Software-Based Solution to the Cold Boot Attack on Disk Encryption
Patrick Simmons
TL;DR
Cold-boot attacks can recover disk-encryption keys from RAM, challenging protection against physical access. Loop-Amnesia keeps key material in CPU registers and reports theoretical and practical resistance, with a measured disk I/O slowdown of about 2x.
Problem
Cold-boot attacks can recover disk-encryption keys retained in RAM, and the paper identifies a lack of software countermeasures supporting multiple keys.
Source: §1 · p. 2Method
Loop-Amnesia stores encryption keys in CPU registers and avoids storing key-related data in RAM during AES operations.
Source: §1 · p. 2Results
2.04x average slowdown relative to Loop-AES and 2.23x relative to an unencrypted disk; the implementation is described as theoretically immune to cold-boot attacks given its structure.
Source: §6.1 · p. 5, §7.1 · p. 7Takeaways & Limitations
The authors consider the measured overhead acceptable given the protection benefit and report no appreciable decline in interactive desktop use during their own use.
Source: §7.2 · p. 7Key material transmitted through a UNIX pipe may remain in its buffer because the kernel does not currently zero the pipe after use.
Source: §8.3 · p. 9
Abstract
from arXiv · showhide
Disk encryption has become an important security measure for a multitude of clients, including governments, corporations, activists, security-conscious professionals, and privacy-conscious individuals. Unfortunately, recent research has discovered an effective side channel attack against any disk mounted by a running machine\cite{princetonattack}. This attack, known as the cold boot attack, is effective against any mounted volume using state-of-the-art disk encryption, is relatively simple to perform for an attacker with even rudimentary technical knowledge and training, and is applicable to exactly the scenario against which disk encryption is primarily supposed to defend: an adversary with physical access. To our knowledge, no effective software-based countermeasure to this attack supporting multiple encryption keys has yet been articulated in the literature. Moreover, since no proposed solution has been implemented in publicly available software, all general-purpose machines using disk encryption remain vulnerable. We present Loop-Amnesia, a kernel-based disk encryption mechanism implementing a novel technique to eliminate vulnerability to the cold boot attack. We offer theoretical justification of Loop-Amnesia's invulnerability to the attack, verify that our implementation is not vulnerable in practice, and present measurements showing our impact on I/O accesses to the encrypted disk is limited to a slowdown of approximately 2x. Loop-Amnesia is written for x86-64, but our technique is applicable to other register-based architectures. We base our work on loop-AES, a state-of-the-art open source disk encryption package for Linux.
1 Introduction
Cold-boot attacks can recover encryption keys from RAM after power is cut, undermining disk encryption against physical access. Loop-Amnesia addresses this with a kernel-based design intended to keep key data out of RAM while supporting multiple encryption keys.
1 Introduction
- Disk encryption stores a filesystem in encrypted form and is widely used as a security measure across operating systems and third-party tools.The introduction describes it as effective against adversaries seeking to defeat its protection before the cold-boot attack was identified.Source: §1 · p. 1
- Cold-boot attacks recover disk-encryption keys from RAM after power is cut, and are broadly applicable to existing disk-encryption packages.The attack dumps RAM contents for key searching or tries key-length strings found in memory.Source: §1 · pp. 1–2
- Disk encryption is intended to protect data from adversaries with physical access, the same setting targeted by cold-boot attacks.The paper notes that lost or stolen machines can expose data despite disk encryption.Source: §1 · p. 2
- Loop-Amnesia contributes a kernel-based disk-encryption approach that keeps encryption keys in CPU registers rather than RAM and supports masking multiple keys.Its design also avoids leaking key-related data to RAM during AES operations.Source: §1 · p. 2
2 Attack Model
The attack model assumes an adversary with physical access, while the background explains why keys in RAM make existing disk encryption vulnerable. AES key schedules and loop-AES’s key storage provide the relevant context for the design.
2 Attack Model
- The attacker is assumed to have full physical access and equipment for reading RAM removed from the target machine.The model also considers an attacker with an account but excludes gaining keys through operating-system vulnerabilities.Source: §2 · p. 2
3.1 Aspects of AES Relevant to Loop-Amnesia
- AES is an efficient block cipher, and the paper focuses on its 128-bit form, which uses 10 rounds.Each round applies the encryption algorithm to the current plaintext or ciphertext state.Source: §3.1 · p. 2, §3.1.1 · p. 2
3.1.2 Key Schedule
- AES uses a different round key for each round, and conventional implementations precompute and store the keys in RAM.With unmodified loop-AES or similar software, 20 related 128-bit quantities from which the original key can be derived reside in RAM.Source: §3.1.2 · p. 2
3.2 Organization of loop-AES
- Loop-AES is a Linux kernel plugin that provides an encrypted loopback device for a disk partition or file.Data written through the device is encrypted before being stored on its backing device.Source: §3.2 · pp. 2–3
- Loop-AES confines encryption, decryption, and key-setting work to three routines, but its key-setting routine stores keys in memory, leaving it vulnerable to cold-boot attacks.Other disk-encryption operations are handled independently of those routines.Source: §3.2 · p. 3
4 The Design of Loop-Amnesia
Loop-Amnesia uses CPU model-specific registers as key storage so cold-boot attackers cannot read key data from RAM. The design repurposes performance-counter registers, encrypts volume keys under a master key, and trades away hardware-assisted profiling.
4 The Design of Loop-Amnesia
- Repurposed model-specific registers (MSRs) store key data inside the CPU rather than RAM, making it unreadable to a cold-boot attacker.Finding suitable registers requires weighing their intended system uses against the storage need.Source: §4 · p. 3
- On x86-64, disabled performance counting permits performance-counter registers to hold one 128-bit AES key; the authors also identify potentially repurposable performance-counter MSRs on PowerPC.The PowerPC assessment is based on the CPU system programming manual.Source: §4 · p. 3
- Repurposing hardware performance counters forecloses hardware-assisted performance profilers, which the authors do not consider a serious deficiency for production machines.Source: §4 · p. 3
- To support multiple mounted volumes, Loop-Amnesia stores a randomly generated master key in MSRs and uses it to encrypt each volume key.The design requires an RNG whose later internal state cannot reveal previously output random numbers.Source: §4 · p. 3
5 Implementation
The implementation avoids RAM storage for key data by tightly controlling register use and computing AES key schedules on the fly. Its prototype has a single-core constraint, while a TPM-based alternative is rejected and the AES routines operate within x86-64’s register limits.
5.1 Constraints
- Loop-Amnesia uses x86-64 assembly to control register allocation and prevent key-containing registers from spilling into RAM.Because the repurposed MSR space cannot hold a full AES key schedule, the implementation computes the schedule on the fly.Source: §5.1 · p. 3
- The prototype is limited to one CPU or core because MSRs are per-CPU and the implementation compiles the kernel in single-CPU mode.The design itself does not require this limit; a production implementation could distribute the master key to CPUs and then scrub it from RAM.Source: §5.1 · p. 4
The TPM Alternative
- The current TPM standard supports public-key RSA rather than the symmetric encryption needed to perform disk encryption directly.A TPM alternative could decrypt volume keys, but would expose them unencrypted over the TPM-CPU bus and incur processor and bus latency costs.Source: The TPM Alternative · pp. 4–5
5.2 Implementation Outline
- The AES routines decrypt a volume key from the context structure, process the input buffer, and write the resulting ciphertext or plaintext to an output buffer.The implementation assigns data and round-key work across the available x86-64 registers; every general-purpose integer register is in use.Source: §5.2 · p. 5
- The implementation initializes the AES context with first and last round keys encrypted under the master key.Source: §5.2 · p. 5
6 Verification of Cold-Boot Immunity
Loop-Amnesia’s design aims to prevent key data from reaching RAM during normal operation, and its code review and RAM inspection support that claim. Correctness testing found no master or volume key in RAM, while non-maskable interrupts remain a stated caveat.
6.1 Justification
- Code review found no master, volume, or round-key data stored to RAM, and the authors argue that disabling interrupts until key-bearing registers are zeroed makes cold-boot vulnerability theoretically impossible.This reasoning concerns normal operation; the stated immunity criterion excludes directly after key input.Source: §6.1 · p. 5
- Loop-Amnesia also keeps only fully encrypted ciphertext or fully decrypted plaintext in RAM, avoiding storage of partially processed data that could aid cryptanalysis.The authors identify this as desirable even if it is not strictly necessary for cold-boot immunity.Source: §6.1 · p. 5
6.2 Correctness Testing
- RAM inspection found neither the master nor volume key when Loop-Amnesia was used, although the encrypted volume key was present as expected.The same inspection methodology extracted the secret key from loop-AES.Source: §6.2 · p. 5
- Non-maskable interrupts cannot be disabled by software, so key data could theoretically leak to RAM if such interrupts are considered.The authors identify this as a limitation to their theoretical immunity claim.Source: §6.2 · p. 5
7 Performance
Benchmarks compare Loop-Amnesia with Loop-AES, Xornesia, and an unencrypted baseline. Loop-Amnesia averages a roughly twofold slowdown against the baselines, with overhead attributed to extra cryptographic work and on-the-fly round-key generation.
7.1 Benchmarking
- On benchmarks using a single-core 1.8GHz Intel Celeron 540 laptop with 1GB RAM, Loop-Amnesia introduced average slowdowns of approximately 2.04x versus Loop-AES and 2.23x versus an unencrypted disk.Source: §7.1 · p. 7
- The CPU-only test found a 3.77x theoretical worst-case slowdown for Loop-Amnesia relative to Loop-AES.The test measured 10 million encryption and decryption operations and was intended to model performance when disk access is free.Source: §7.1 · p. 7
7.2 Analysis
- The authors report no appreciable decline in interactive desktop performance after using Loop-Amnesia for several months on two machines.They note that disk access speed does not play a major role in overall performance for many applications.Source: §7.2 · p. 7
- Loop-Amnesia’s overhead comes from decrypting the device key before each requested operation and generating round keys on-the-fly rather than pregenerating them.Xornesia removes the device-key decryption overhead by XOR-masking device keys, while retaining the on-the-fly key schedule.Source: §7.2 · pp. 7–8
- Xornesia’s lower overhead comes with weaker security: an attacker able to choose a device key could use a cold-boot attack to derive the master key.The authors also note possible cryptanalysis of first and last round keys in RAM, with a proposed mitigation of storing only the last round key.Source: §7.2 · p. 8
8 Limitations
Loop-Amnesia has constraints in architecture and functionality, and several paths may still expose key or decrypted data. The authors identify specific practical boundaries, including unsupported RAM suspension and residual risks from userspace buffers, cached data, JTAG, and non-maskable interrupts.
8.1 Architecture Dependence
- The assembly-language approach is architecture-dependent, limited to kernel-mode encryption, and requires an implementation for each CPU-architecture and encryption-algorithm combination.The authors expect it to be applicable to a wide variety of uses because encryption algorithms are small and self-contained.Source: §8.1 · p. 8
8.2 Functionality Limitations
- Suspension to RAM is unsupported because it clears the CPU registers, including the MSRs, where the key is held.Copying the master key to RAM before suspension would expose it to a cold-boot attack.Source: §8.2 · p. 8
8.3 Potential Effectiveness Issues
- Userspace key material may remain in a UNIX pipe buffer after transmission because the kernel does not currently zero the pipe after use.The loop-AES userspace components reportedly overwrite their key material after sending it to the kernel.Source: §8.3 · p. 9
- The approach does not protect decrypted data cached in RAM, though periodically clearing Linux's disk cache could mitigate this at a performance cost if freed pages are cleared.The authors had not checked whether Linux clears freed pages.Source: §8.3 · p. 9
- An attacker with JTAG access may read the master key from the CPU's MSRs, while a hardware fault causing an NMI during key residency could expose the key saved to RAM.The authors note JTAG is rarely wired out on x86 and consider the NMI attack unlikely; modifying the interrupt handler to scrub registers from RAM would suffice against the latter.Source: §8.3 · p. 9
9 Related Work
Prior cold-boot mitigations include hardware changes, register-based schemes, cache use, and leakage-resistant ciphers, but the described approaches have limits in coverage, performance, or practicality. The discussion argues that partial key leakage defenses and the TCG reset specification do not fully address the attack.
9.1 Lest We Remember: Cold-Boot Attacks on Encryption Keys
- Halderman et al.'s mitigations include deleting keys on unmount, obfuscation, and hardware modifications, but they do not present a full solution for general-purpose hardware.Hardware modifications may add cost or be unavailable, and the authors doubt obfuscation because the attacker obtains RAM including the encryption program text.Source: §9.1 · p. 9
9.2 AESSE
- AESSE stores one encryption key in MMX registers but supports no multiple disk-encryption keys, incurs approximately 6x algorithmic slowdown, and restricts userland MMX use.The MMX restriction also causes compatibility problems and can slow userland software that would otherwise use MMX.Source: §9.2 · p. 9
9.3 Braving the Cold Black Hat Talk
- A Black Hat proposal would store a key as the hash of a large bit block, but recalculating that hash for each key access would likely cause severe performance problems.The talk also suggested MMX-register caching without explaining how it would work.Source: §9.3 · p. 10
9.4 Frozen Cache
- Pabel's L1-cache key-schedule approach would disable the cache's normal role, causing an estimated 200x slowdown for all software.The authors argue their design avoids those system-wide performance side effects.Source: §9.4 · p. 10
9.5 Linux-Crypto Mailing List Brainstorming
- Linux-Crypto discussion raised keeping key information in CPU registers, but the ideas were too vague to specify an implementation and appear not to have been pursued.Source: §9.5 · p. 10
9.6 Leakage-Resistant Algorithms
- Partial-key-leakage defenses are insufficient because a cold-boot attack can leave over 99.9% of memory uncorrupted a minute after power loss, requiring countermeasures to account for full key leakage.Prior leakage-resistant work mainly focused on designing ciphers that mitigate partial key leakage.Source: §9.6 · p. 10
9.7 TCG Platform Reset Attack Mitigation Specification
- The TCG reset specification's BIOS RAM-zeroing requirement is insufficient because an attacker can move the RAM and boot it using a noncompliant BIOS.The specification prevents the attack only when using the victim's computer.Source: §9.7 · p. 10
A Framework for Live Forensics
Cold-boot attacks can expose sensitive RAM contents beyond disk keys, including session keys for active network connections. Loop-Amnesia protects the encrypted disk but does not ensure those network sessions remain safe.
A Framework for Live Forensics
- Cold-boot access to RAM may expose session keys that let an attacker impersonate the victim to connected websites, SSH servers, or other systems.Source: A Framework for Live Forensics · p. 10
- Loop-Amnesia can protect the encrypted disk against a Forenscope-using attacker because the tool uses the same key-recovery strategy as Halderman et al.Source: A Framework for Live Forensics · p. 10
- SSH and SSL session keys may remain in RAM, so a Forenscope attacker could still recover them and potentially impersonate the victim on active connections.Source: A Framework for Live Forensics · p. 10
10 Future Work
The authors identify extending Loop-Amnesia beyond AES and examining its use against Forenscope as future work. They also point to compiler control over register allocation as a language limitation relevant to their implementation.
10 Future Work
- The approach's applicability outside AES remains to be analyzed, especially for algorithms with key-dependent S-boxes such as Blowfish.The authors expect it to work for algorithms without key-dependent S-boxes and with inexpensive key schedules.Source: §10 · p. 11
- The authors propose examining whether Loop-Amnesia could help neutralize Forenscope's other capabilities by encrypting kernel TCP-stack data so network sessions expire before an attacker can analyze recovered session keys.Source: §10 · p. 11
- Current system programming languages cannot require compilers to keep particular values from being spilled to RAM, a control the authors suggest could benefit security and performance.Source: §10 · p. 11
11 Conclusion
Loop-Amnesia is presented as the first practical cold-boot defense for general-purpose hardware, with likely moderate performance cost under most workloads. Its design strategy applies to operating-system-based disk encryption, and an open-source implementation validates the design.
11 Conclusion
- Loop-Amnesia provides the first practical cold-boot solution for general-purpose hardware, protecting against an attack affecting previous state-of-the-art disk encryption systems.The authors describe the performance cost as likely very moderate under most workloads.Source: §11 · p. 11
- The design strategy applies to operating-system-based disk encryption systems, and a usable open-source implementation validates the design.Source: §11 · p. 11
- The authors intend to work with the Linux kernel community on integrating their approach, and possibly code, into the standard Linux kernel distribution.Source: §11 · p. 11