Lest We Remember Cold-Boot Attacks Against Disk Encryption J. Alex Halderman, Seth D. Schoen, Nadia Heninger, William Clarkson, William Paul, Joseph A. Calandrino, Ariel J. Feldman, Jacob Appelbaum, Edward W. Felten

How Safe is a Stolen Laptop? Unlocked Unencrypted No protection Locked Unencrypted Minimal protection Locked Encrypted Industry best practice

How Safe is a Stolen Laptop? Locked Encrypted Industry best practice In 2007: 119,000 encrypted laptops with sensitive data lost at major US airports Were they really protected?

Disk Encryption Defense File System Disk Drivers On-the-Fly Crypto Password: ********

“Sleep” Suspend-to-RAM “Hibernate” Suspend-to-Disk Screen Locked Attack Scenarios

Common Attack Scenario Security Assumptions The encryption is strong The OS protects the key in RAM …the attacker might reboot to circumvent the OS, but since RAM is volatile, the key will be lost… Right…?

Security Assumptions: Data fades almost instantaneously without refresh Any residual data is difficult to recover 0 Dynamic RAM Volatility 1 Write “1” 1 DRAM Cell (Capacitor) 0 Refresh (Read and rewrite) Refresh Interval ≈ 32 ms What if we don’t refresh?

Decay After Cutting Power 5 secs30 secs60 secs300 secs

DRAM Remanence Gradual Unidirectional Predictable DRAM data disappears almost instantaneously without refresh Decay After Cutting Power 5 secs30 secs60 secs300 secs

Capturing Residual Data Any residual data is difficult to recover Complication Booting full OS overwrites large areas of RAM Solution Boot a small low-level program to write out (dump) memory content PXE Dump (9 KB) EFI Dump (10 KB) USB Dump (22 KB) Implementations Residual data can be captured easily, with no special equipment

Delivering the Attack

Basic Cold-Boot Attack Dumping RAM… Screen-locked machine (if hibernating/sleeping, just wake it up!)

What if the BIOS clears RAM? BIOS: Clearing RAM… !!! Common in machines that support ECC RAM

Advanced Cold-Boot Attack Attacker’s Computer Dumping RAM… Victim’s Computer

Slowing Decay By Cooling -50°C < 0.2% decay after 1 minute

Even Cooler -196°C Liquid Nitrogen < 0.17% decay after 1 hour Not necessary in practice

Dealing with Bit Errors Some bit errors inevitable, especially without cooling (increasing with memory density) Given corrupted K’, find K: Brute-force search over low Hamming distance to K’ e.g. 256-bit key with 10% error: > 2 56 guesses (too slow!) Given corrupted K’, find K: Brute-force search over low Hamming distance to K’ e.g. 256-bit key with 10% error: > 2 56 guesses (too slow!) Naïve Approach Most programs store precomputed derivatives of K (e.g. key schedules) These derivatives contain redundancy; we can treat them as error correcting codes Most programs store precomputed derivatives of K (e.g. key schedules) These derivatives contain redundancy; we can treat them as error correcting codes Insight

Correcting Bit Errors in DES Key schedule contains ~14 redundant copies of each bit from the key ~20% error

AES Key Schedule   Round 0 key (K) Round 1 key Round 10 key … … Core 128-bit key K  10 more 128-bit keys for cipher rounds   Byte

Correcting Bit Errors in AES  Round 0 key (K) Round 1 key Core  Key schedule recovered from memory (contains errors) 1.Slices: 4 bytes in Round 0 determine 3 bytes in Round 1 2.Enumerate 2 32 possibilities for each 7 byte slice 3.Eliminate values unlikely to have decayed to observed bytes (excludes vast majority)

Correcting Bit Errors in AES  Round 0 key (K) Round 1 key Core  Key schedule recovered from memory (contains errors) 4.Repeat for each of the 4 slices 5.Combine possible slice values into candidate keys 6.Test candidates keys by expanding them into full key schedules – compare to recovered memory

Recovering Other Keys AES, DES (key schedules) LRW tweak keys (multiplication tables) RSA private keys (primes P and Q) Efficiency vs. Security

Finding Keys Previous Methods – Entropy methods But, most high entropy data isn’t key material – Looking for data structure But, need to know internal details about software Our Method –Focuses on key schedules Precise and fully automatic, even with decay Doesn’t require analysis of target program

Finding AES Key Schedules Iterate through each byte of memory – 1. Treat following region as an AES key schedule 2. For each word in the “schedule”: Calculate correct value, assuming other bytes correct Take Hamming distance to observed value 3. If total distance is low, output the key

Steps of Cold-Boot Attack 1.Extract memory 2.Locate keys in memory 3.Reconstruct decayed keys 4.Decrypt hard drive

Demonstrated Attacks Linux dm-crypt Linux LoopAES Windows BitLocker Mac OS FileVault TrueCrypt

“BitLocker, Meet BitUnlocker” Demonstration of fully automated attack: Connect USB drive, reboot, and browse files

Countermeasures No Magic Bullet Possible Mitigations – Encrypt key in memory when screen-locked – Avoid precomputation – Fully encrypted memory – Trusted Platform Module (TPM)

Encrypt Memory During Sleep When entering screen-lock/hibernate/sleep: – Encrypt RAM with user’s password When awakened: – Require user’s password to decrypt RAM Minor behavioral changes Zzzz….

Avoid Precomputation This makes recovery harder, but: – Hurts performance (Having key schedule speeds computation) – Attacker can reduce the incidence of errors – Alternative recovery schemes may perform well without this data

Encrypted Memory Memory encrypted with key – Randomly chosen at boot On cache read/write – Data encrypted/decrypted when written/read CPU reset clears key

TPM? Current TPMs may help attacker Windows BitLocker in Basic Mode – On boot, OS loads key from TPM into RAM (No Password) – Vulnerable to cold-boot attack (Even if completely off) Future TPMs may help – Need bulk encryption

Key Points Characterization of DRAM remanence Cold-boot attacks on encryption keys Automatic key finding and recovery Compromises of popular disk encryption tools Discussion of remedies and their limitations

Take Aways DRAM decays in seconds without refresh, not milliseconds This is slow enough to allow data recovery, given physical access Software has no safe place to store a key Mitigation requires compromises

J. Alex Halderman, Seth D. Schoen, Nadia Heninger, William Clarkson, William Paul, Joseph A. Calandrino, Ariel J. Feldman, Jacob Appelbaum, Edward W. Felten For videos and source code, visit j.alexhalderman.com Lest We Remember Cold-Boot Attacks Against Disk Encryption