- Feb 23, 2005
- 22,902
- 2,359
- 126
This is a VERY technical paper and not for the weak. Very long read also. The readers digest version is...Princeton in partnership with Electronic Frontier Foundation has found a way to expoit encrypted drives. With most modern encryption programs (Bit Locker, Truecrypt, Drivecrypt) the keys are stored temporarily in memory. It has been recently thought by restarting your PC memory is wiped clear. Apparently not.
This article makes me nervous for a couple of reasons. We've all read every 3 or 4 months of some government PC or laptop having been stolen and sensitive information being compromised., Second, there is a privacy issue. Let me state I when I hear "if you have nothing to hide you shouldnt worry" it frightens me to think we have become so numbed as to the invasion of our personal lives. Although that's true, it really doesnt matter. MY info is MINE alone. That said...I have full confidence that at least two products, Truecrypt and Drivecrypt, will respond soon. I've always believed open source attracts the most intelligent of poeple because it is just that-open. I dont subscribe to the belief our government is more powerful intellectually than the people. Thats a little offtrack though.
Anyway the paper is here in PDF format. A few highlights: (Im looking forward to feedback from Bsobel)
Contrary to popular assumption, DRAMs used in most modern computers retain their contents for
seconds to minutes after power is lost, even at room temperature and even if removed from a motherboard.
Although DRAMs become less reliable when they are not refreshed, they are not immediately
erased, and their contents persist sufficiently for malicious (or forensic) acquisition of usable full-system
memory images. We show that this phenomenon limits the ability of an operating system to protect cryptographic
key material from an attacker with physical access. We use cold reboots to mount successful
attacks on popular disk encryption systems using no special devices or materials. We experimentally
characterize the extent and predictability of memory remanence and report that remanence times can be
increased dramatically with simple techniques. We offer new algorithms for finding cryptographic keys
in memory images and for correcting errors caused by bit decay. Though we discuss several strategies
for partially mitigating these risks, we know of no simple remedy that would eliminate them.
Most experts assume that a computer?s memory is erased almost immediately when it loses power, or that
whatever data remains is difficult to retrieve without specialized equipment. We show that these assumptions
are incorrect. Ordinary DRAMs typically lose their contents gradually over a period of seconds, even at
standard operating temperatures and even if the chips are removed from the motherboard, and data will
persist for minutes or even hours if the chips are kept at low temperatures. Residual data can be recovered
using simple, nondestructive techniques that require only momentary physical access to the machine.
We present a suite of attacks that exploit DRAM remanence effects to recover cryptographic keys held
in memory. They pose a particular threat to laptop users who rely on disk encryption products, since an
adversary who steals a laptop while an encrypted disk is mounted could employ our attacks to access the
contents, even if the computer is screen-locked or suspended. We demonstrate this risk by defeating several
popular disk encryption systems, including BitLocker, TrueCrypt, and FileVault, and we expect many similar
products are also vulnerable.
While our principal focus is disk encryption, any sensitive data present in memory when an attacker
gains physical access to the system could be subject to attack. Many other security systems are probably vulnerable. For example, we found that Mac OS X leaves the user?s login passwords in memory, where we were able to recover it, and we have constructed attacks for extracting RSA private keys from Apache web
servers. As we discuss in Section 2, certain segments of the computer security and semiconductor physics communities
have been conscious of DRAM remanence effects for some time, though strikingly little about them
has been published. As a result, many who design, deploy, or rely on secure systems are unaware of these
phenomena or the ease with which they can be exploited. To our knowledge, ours is the first comprehensive
study of their security consequences.
Extracting encryption keys from memory images requires a mechanism for locating the target keys. A
simple approach is to test every sequence of bytes to see whether it correctly decrypts some known plaintext.
Applying this method to a 1 GB memory image known to contain a 128-bit symmetric key aligned to some
4-byte machine word implies at most 228 possible key values. However, this is only the case if the memory
image is perfectly accurate. If there are bit errors in the portion of memory containing the key, the search
quickly becomes intractable.
We have developed fully automatic techniques for locating symmetric encryption keys in memory images,
even in the presence of bit errors. Our approach is similar to the one we used to correct key bit errors
in Section 5. We target the key schedule instead of the key itself, searching for blocks of memory that satisfy
(or are close to satisfying) the combinatorial properties of a valid key schedule. Using these methods we
have been able to recover keys from closed-source encryption programs without having to disassemble them
and reconstruct their key data structures, and we have even recovered partial key schedules that had been
overwritten by another program when the memory was reallocated.
BitLocker: BitLocker differs from other disk encryption products mainly in the way that it protects the keys when
the disk is not mounted. In its default ?basic mode,? BitLocker protects the disk?s master key solely with
the Trusted Platform Module (TPM) found on many modern PCs. This configuration, which may be quite
widely used [20], is particularly vulnerable to our attack, because it allows the disk encryption keys to be
extracted with our attacks even if the computer is powered off for a long time. When the machine boots, the
keys will be loaded into RAM automatically (before the login screen) without the entry of any secrets.
Apple?s FileVault: We used our EFI memory imaging program to extract a memory image from an Intel-based Macintosh
system with a FileVault volume mounted. Our keyfind program automatically identified the FileVault AES key, which did not contain any bit errors in our tests.
In the process of testing FileVault, we discovered that Mac OS X 10.4 and 10.5 keep multiple copies of
the user?s login password in memory, where they are vulnerable to imaging attacks. Login passwords are
often used to protect the default keychain, which may protect passphrases for FileVault disk images.
Truecrypt: We tested TrueCrypt versions 4.3a and 5.0a running on a Linux system. We mounted a volume encrypted
with a 256-bit AES key, then briefly cut power to the system and used our memory imaging tools to record
an image of the retained memory data. In both cases, our keyfind program was able to identify the 256-bit
AES encryption key, which did not contain any bit errors. For TrueCrypt 5.0a, keyfind was also able to
recover the 256-bit AES XTS tweak key without errors.
dm-crypt: We tested a dm-crypt volume created and mounted using the LUKS (Linux Unified Key Setup) branch
of the cryptsetup utility and kernel version 2.6.20. The volume used the default AES-CBC format.
We briefly powered down the system and captured a memory image with our PXE kernel. Our keyfind
program identified the correct 128-bit AES key, which did not contain any bit errors. After recovering this
key, an attacker could decrypt and mount the dm-crypt volume by modifying the cryptsetup program to
allow the raw key to be input.
Countermeasures and their Limitations
Memory imaging attacks are difficult to defend against because cryptographic keys that are in active use
need to be stored somewhere. Our suggested countermeasures focus on discarding or obscuring encryption
keys before an adversary might gain physical access, preventing memory-dumping software from being
executed on the machine, physically protecting DRAM chips, and possibly making the contents of memory
decay more readily.
Scrubbing memory Countermeasures begin with efforts to avoid storing keys in memory. Software
should overwrite keys when they are no longer needed, and it should attempt to prevent keys from being
paged to disk. Runtime libraries and operating systems should clear memory proactively; Chow et al. show
that this precaution need not be expensive. Of course, these precautions cannot protect keys that must
be kept in memory because they are still in use, such as the keys used by encrypted disks or secure web
servers. Systems can also clear memory at boot time. Some PCs can be configured to clear RAM at startup via
a destructive Power-On Self-Test (POST) before they attempt to load an operating system. If the attacker
cannot bypass the POST, he cannot image the PC?s memory with locally-executing software, though he
could still physically move the memory chips to different computer with a more permissive BIOS.
With most disk encryption systems, users can protect themselves by powering off the machine completely
when it is not in use. (BitLocker in ?basic? TPM mode remains vulnerable, since the system will
automatically mount the disk when the machine is powered on.) Memory contents may be retained for a
short period after power-off, so the owner should keep an eye on the machine for a minute or so after removing
power. Though effective, this countermeasure is very inconvenient given the long boot time of current
machines.
Conclusions
Contrary to popular belief, DRAMs hold their values for surprisingly long intervals without power or refresh.
Our experiments show that this fact enables a variety of security attacks that can extract sensitive information
such as cryptographic keys from memory, despite the operating system?s best efforts to protect memory
contents. The attacks we describe are practical?for example, we have used them to defeat several popular
disk encryption systems.
Other types of software may be similarly vulnerable. DRM systems often rely on symmetric keys stored
in memory, which may be recoverable using the techniques outlined in our paper. As we have shown, SSLenabled
web servers are vulnerable, since they often keep in memory private keys needed to establish SSL
sessions. Furthermore, methods similar to our key-finder would likely be effective for locating passwords,
account numbers, or other sensitive data in memory.
There seems to be no easy remedy for these vulnerabilities. Simple software changes are likely to be
ineffective; hardware changes are possible but will require time and expense; and today?s Trusted Computing
technologies appear to be of little help because they cannot protect keys that are already in memory. The
risk seems highest for laptops, which are often taken out in public in states that are vulnerable to our attacks.
These risks imply that disk encryption on laptops may do less good than widely believed.
Ultimately, it might become necessary to treat DRAM as untrusted, and to avoid storing sensitive confidential
data there, but this will not be feasible until architectures are changed to give software a safe place
to keep its keys.
This article makes me nervous for a couple of reasons. We've all read every 3 or 4 months of some government PC or laptop having been stolen and sensitive information being compromised., Second, there is a privacy issue. Let me state I when I hear "if you have nothing to hide you shouldnt worry" it frightens me to think we have become so numbed as to the invasion of our personal lives. Although that's true, it really doesnt matter. MY info is MINE alone. That said...I have full confidence that at least two products, Truecrypt and Drivecrypt, will respond soon. I've always believed open source attracts the most intelligent of poeple because it is just that-open. I dont subscribe to the belief our government is more powerful intellectually than the people. Thats a little offtrack though.
Anyway the paper is here in PDF format. A few highlights: (Im looking forward to feedback from Bsobel)
Contrary to popular assumption, DRAMs used in most modern computers retain their contents for
seconds to minutes after power is lost, even at room temperature and even if removed from a motherboard.
Although DRAMs become less reliable when they are not refreshed, they are not immediately
erased, and their contents persist sufficiently for malicious (or forensic) acquisition of usable full-system
memory images. We show that this phenomenon limits the ability of an operating system to protect cryptographic
key material from an attacker with physical access. We use cold reboots to mount successful
attacks on popular disk encryption systems using no special devices or materials. We experimentally
characterize the extent and predictability of memory remanence and report that remanence times can be
increased dramatically with simple techniques. We offer new algorithms for finding cryptographic keys
in memory images and for correcting errors caused by bit decay. Though we discuss several strategies
for partially mitigating these risks, we know of no simple remedy that would eliminate them.
Most experts assume that a computer?s memory is erased almost immediately when it loses power, or that
whatever data remains is difficult to retrieve without specialized equipment. We show that these assumptions
are incorrect. Ordinary DRAMs typically lose their contents gradually over a period of seconds, even at
standard operating temperatures and even if the chips are removed from the motherboard, and data will
persist for minutes or even hours if the chips are kept at low temperatures. Residual data can be recovered
using simple, nondestructive techniques that require only momentary physical access to the machine.
We present a suite of attacks that exploit DRAM remanence effects to recover cryptographic keys held
in memory. They pose a particular threat to laptop users who rely on disk encryption products, since an
adversary who steals a laptop while an encrypted disk is mounted could employ our attacks to access the
contents, even if the computer is screen-locked or suspended. We demonstrate this risk by defeating several
popular disk encryption systems, including BitLocker, TrueCrypt, and FileVault, and we expect many similar
products are also vulnerable.
While our principal focus is disk encryption, any sensitive data present in memory when an attacker
gains physical access to the system could be subject to attack. Many other security systems are probably vulnerable. For example, we found that Mac OS X leaves the user?s login passwords in memory, where we were able to recover it, and we have constructed attacks for extracting RSA private keys from Apache web
servers. As we discuss in Section 2, certain segments of the computer security and semiconductor physics communities
have been conscious of DRAM remanence effects for some time, though strikingly little about them
has been published. As a result, many who design, deploy, or rely on secure systems are unaware of these
phenomena or the ease with which they can be exploited. To our knowledge, ours is the first comprehensive
study of their security consequences.
Extracting encryption keys from memory images requires a mechanism for locating the target keys. A
simple approach is to test every sequence of bytes to see whether it correctly decrypts some known plaintext.
Applying this method to a 1 GB memory image known to contain a 128-bit symmetric key aligned to some
4-byte machine word implies at most 228 possible key values. However, this is only the case if the memory
image is perfectly accurate. If there are bit errors in the portion of memory containing the key, the search
quickly becomes intractable.
We have developed fully automatic techniques for locating symmetric encryption keys in memory images,
even in the presence of bit errors. Our approach is similar to the one we used to correct key bit errors
in Section 5. We target the key schedule instead of the key itself, searching for blocks of memory that satisfy
(or are close to satisfying) the combinatorial properties of a valid key schedule. Using these methods we
have been able to recover keys from closed-source encryption programs without having to disassemble them
and reconstruct their key data structures, and we have even recovered partial key schedules that had been
overwritten by another program when the memory was reallocated.
BitLocker: BitLocker differs from other disk encryption products mainly in the way that it protects the keys when
the disk is not mounted. In its default ?basic mode,? BitLocker protects the disk?s master key solely with
the Trusted Platform Module (TPM) found on many modern PCs. This configuration, which may be quite
widely used [20], is particularly vulnerable to our attack, because it allows the disk encryption keys to be
extracted with our attacks even if the computer is powered off for a long time. When the machine boots, the
keys will be loaded into RAM automatically (before the login screen) without the entry of any secrets.
Apple?s FileVault: We used our EFI memory imaging program to extract a memory image from an Intel-based Macintosh
system with a FileVault volume mounted. Our keyfind program automatically identified the FileVault AES key, which did not contain any bit errors in our tests.
In the process of testing FileVault, we discovered that Mac OS X 10.4 and 10.5 keep multiple copies of
the user?s login password in memory, where they are vulnerable to imaging attacks. Login passwords are
often used to protect the default keychain, which may protect passphrases for FileVault disk images.
Truecrypt: We tested TrueCrypt versions 4.3a and 5.0a running on a Linux system. We mounted a volume encrypted
with a 256-bit AES key, then briefly cut power to the system and used our memory imaging tools to record
an image of the retained memory data. In both cases, our keyfind program was able to identify the 256-bit
AES encryption key, which did not contain any bit errors. For TrueCrypt 5.0a, keyfind was also able to
recover the 256-bit AES XTS tweak key without errors.
dm-crypt: We tested a dm-crypt volume created and mounted using the LUKS (Linux Unified Key Setup) branch
of the cryptsetup utility and kernel version 2.6.20. The volume used the default AES-CBC format.
We briefly powered down the system and captured a memory image with our PXE kernel. Our keyfind
program identified the correct 128-bit AES key, which did not contain any bit errors. After recovering this
key, an attacker could decrypt and mount the dm-crypt volume by modifying the cryptsetup program to
allow the raw key to be input.
Countermeasures and their Limitations
Memory imaging attacks are difficult to defend against because cryptographic keys that are in active use
need to be stored somewhere. Our suggested countermeasures focus on discarding or obscuring encryption
keys before an adversary might gain physical access, preventing memory-dumping software from being
executed on the machine, physically protecting DRAM chips, and possibly making the contents of memory
decay more readily.
Scrubbing memory Countermeasures begin with efforts to avoid storing keys in memory. Software
should overwrite keys when they are no longer needed, and it should attempt to prevent keys from being
paged to disk. Runtime libraries and operating systems should clear memory proactively; Chow et al. show
that this precaution need not be expensive. Of course, these precautions cannot protect keys that must
be kept in memory because they are still in use, such as the keys used by encrypted disks or secure web
servers. Systems can also clear memory at boot time. Some PCs can be configured to clear RAM at startup via
a destructive Power-On Self-Test (POST) before they attempt to load an operating system. If the attacker
cannot bypass the POST, he cannot image the PC?s memory with locally-executing software, though he
could still physically move the memory chips to different computer with a more permissive BIOS.
With most disk encryption systems, users can protect themselves by powering off the machine completely
when it is not in use. (BitLocker in ?basic? TPM mode remains vulnerable, since the system will
automatically mount the disk when the machine is powered on.) Memory contents may be retained for a
short period after power-off, so the owner should keep an eye on the machine for a minute or so after removing
power. Though effective, this countermeasure is very inconvenient given the long boot time of current
machines.
Conclusions
Contrary to popular belief, DRAMs hold their values for surprisingly long intervals without power or refresh.
Our experiments show that this fact enables a variety of security attacks that can extract sensitive information
such as cryptographic keys from memory, despite the operating system?s best efforts to protect memory
contents. The attacks we describe are practical?for example, we have used them to defeat several popular
disk encryption systems.
Other types of software may be similarly vulnerable. DRM systems often rely on symmetric keys stored
in memory, which may be recoverable using the techniques outlined in our paper. As we have shown, SSLenabled
web servers are vulnerable, since they often keep in memory private keys needed to establish SSL
sessions. Furthermore, methods similar to our key-finder would likely be effective for locating passwords,
account numbers, or other sensitive data in memory.
There seems to be no easy remedy for these vulnerabilities. Simple software changes are likely to be
ineffective; hardware changes are possible but will require time and expense; and today?s Trusted Computing
technologies appear to be of little help because they cannot protect keys that are already in memory. The
risk seems highest for laptops, which are often taken out in public in states that are vulnerable to our attacks.
These risks imply that disk encryption on laptops may do less good than widely believed.
Ultimately, it might become necessary to treat DRAM as untrusted, and to avoid storing sensitive confidential
data there, but this will not be feasible until architectures are changed to give software a safe place
to keep its keys.
Facebook
Twitter