30
Lest We Remember: Cold Boot Attacks on Encryption Keys By J. Alex Halderman, Seth D. Schoen, Nadia Heninger, William Clarkson, William Paul, Joseph A. Calandrino, Ariel J. Feldman, Jacob Appelbaum, and Edward W. Felten Appears in the Proceedings of the 17th USENIX Security Symposium (Sec ‘08), San Jose, CA, July 2008 Presented By Peter Matthews

Lest We Remember: Cold Boot Attacks on Encryption Keys By J. Alex Halderman, Seth D. Schoen, Nadia Heninger, William Clarkson, William Paul, Joseph A

Embed Size (px)

Citation preview

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

Appears in the Proceedings of the 17th USENIX Security Symposium (Sec ‘08), San Jose, CA, July 2008

Presented By Peter Matthews

Outline

Disk Encryption The Attack in a Nutshell Memory Remanence

Experimental Results Cold Boot Attack

Physical Software Results

Countermeasures

Introduction to Disk Encryption Disk encryption is one solution to the growing

need to protect access to sensitive data Allows transparent read/write access to the

hard drive while protecting the information stored on it via high-strength encryption

Typically requires initial authentication before granting access Password Biometrics such as fingerprint scanners USB dongle

Example: Using disk encryption with a laptop HD to prevent data theft if the machine is lost or stolen

Disk Encryption - Writing

Disk Encryption - Reading

Popular Disk Encryption Software

BitLocker

(Vista)

TrueCrypt

(Win/Mac/

Linux)

FileVault

(OSX)

Disk Encryption

20% of companies reported encrypting laptops in 2007 Source: Ponemon Institute: 2008

Annual Study: U.S. Enterprise Encryption Trends

Software attempts to minimize impact on user experience To ensure high performance, the

keys are stored persistently in memory

Attack in a Nutshell

Paper presents attacks that can defeat these disk encryption packages if an attacker gains physical access to the computer Take only a few minutes Require no expensive/exotic equipment Most need computer to be on or in sleep mode

Some even work if computer is off Rather than trying to break encryption, attack

uses a little known property of RAM and looks for the stored key in memory after a forced reboot

Bottom line: If computer is stolen or is left unattended for short time, attacker can find the disk encryption keys and access the protected data

Memory Remanence

What happens to data stored in volatile memory (RAM) when the computer’s power is cut? Widespread belief: Data is erased

In fact, data fades away gradually over a period of seconds to minutes

The following video demonstrates this:

Video Source: http://citp.princeton.edu.nyud.net/memory-content/video/mona-5fps-half-title.wmv

Memory Remanence

A DRAM cell is essentially a capacitor Stores one bit by charging or not

charging one of the conductors Other conductor hard-wired to power or

ground depending on address Over time the charge will leak out of the

capacitor Cell returns to “ground state” – 1 or 0

depending on whether hard wired to power or ground

To prevent this, cell must be refreshed (re-charged) on a set schedule

Memory Remanence

Experiments show that the pattern to which the memory cells fade and the order in which they do so are highly predictable Cause: manufacturing variations

They also show that temperature has a very significant effect on the rate at which cells lose their state

Machine

Seconds w/out power

Error % at operating temp

Error % at -50º C

A 60 41 No errors

A 300 50 0.000095

B 360 50 No errors

C 600 50 0.000036

C 120 41 0.00105

C 360 42 0.00144

D 40 50 0.025

D 80 50 0.18Effect of Cooling on Error Rates

Even Colder…

Liquid nitrogen boils at -196 °C

Stored data in these memory modules, cooled them, removed them from the computer, and placed them in a container of liquid nitrogen for an hour

After returning them to the computer, found practically no information had been lost

Imaging Residual Memory

Warm-boot, configure BIOS to start tool No memory decay, but gives software chance to

wipe sensitive data Disconnect and reconnect power (cold-boot)

Little to no memory decay Transferring DRAM modules

Cool DRAM modules with “canned air”, physically remove from machine, and place into other machine

May be able to avoid BIOS overwriting portion of memory if placed in secondary slot

Little to no memory decay

Imaging Residual Memory

When the system boots, memory controller begins refreshing the memory cells and decay halts

Booting necessarily overwrites some memory Minimize: Use tiny special-purpose program to dump

contents to external medium or network address Start tool via:

Network boot Intel Preboot Execution Environment (PXE) Intel-Mac Extensible Firmware Interface (EFI)

USB flash drives / external hard drives iPod

Authors wrote software for and successfully used all of these

Key Reconstruction

Even a small amount of error complicates the process of extracting correct cryptographic keys

Naïve approach: Brute-force search over keys with a low Hamming distance from the one in memory -- The number of positions for which the

corresponding bits are different This quickly becomes computationally infeasible

Most encryption programs speed up computation by storing pre-computed data For block ciphers, this is a “key schedule” with

subkeys for each round of the algorithm

Key Reconstruction

This pre-computed data contains much more structure than the key itself Can use this structure to efficiently

reconstruct original key in presence of errors

Structure allows self-contained key validity proving No need to test decryption of ciphertext

May be thought of as an error correcting code for the key

Example – Reconstructing DES Keys DES – 56 bit key DES key schedule algorithm produces 16 subkeys

Each a permutation of a 48-bit subset of bits from the original 56 bit key

Every bit from the original key is repeated in about 14 of the 16 subkeys

Use the values of these 14 copies of a bit to make a decision about the most likely value of that bit Even with a 25% error, the probability that the key

can be decoded without brute force search is more than 98%

Trivially extends to 3DES

Finding Keys in Memory

Test every sequence of bytes to see if it decrypts known ciphertext Too expensive, only works if memory

portion is perfectly accurate Look for the key schedule rather than

the key itself Valid key schedule has certain

combinatorial properties Iterate through each appropriately sized

block of memory, treating as key schedule For each key schedule word calculate its

Hamming distance from the key schedule word that should be generated from the surrounding words

Results

Defeated Microsoft Bitlocker (Windows) Apple FileVault (OSX) TrueCrypt (Win/Mac/Linux) dm-crypt (built-in Linux disk encryption

system) Loop-AES (Linux)

Countermeasures

Scrubbing memory Proactively clear memory when keys no longer in

use Force clear memory at boot time via BIOS

Restrict booting from network / removable media Still possible to replace /add hard drives

Suspending a system safely Require password to reawaken machine, encrypt

memory with key derived from password Avoid pre-computation

High performance overhead

Countermeasures Continued… Store pre-computed key components in a

difficult to reconstruct format Hashing can make it more sensitive to bit

errors Physical defenses

Lock/Epoxy DRAM modules in place Overwrite memory if case opened or low

temperature detected Hardware defenses

Provide safe place to store keys Move encryption to disk controller

Conclusion – Paper Strengths Uses a little known property to craft a

novel and unforeseen attack Demonstrated to work against a number

of products in wide use Extends to further uses: were able to find

the OSX user login password stored in memory

Well written and presented Excellent companion website

Documented source code, Pictures, Video, etc.

Conclusion – Paper Weaknesses Certain probabilistic results seem to

imply that the authors already know which blocks’ ground states are 0 / 1 Is this realistic in an attack scenario?

Future Work

What else is stored in “untouchable” memory? Authors found OSX user login password

stored multiple place in local memory Possible to use memory addresses that

every BIOS has to overwrite due to X86 legacy?

Production of effective hardware defenses

A precise quantification of remanence effects on RAM of various types and from various makers

Questions?