Today eight colleagues and I are releasing a significant new research result. We show that disk encryption, the standard approach to protecting sensitive data on laptops, can be defeated by relatively simple methods. We demonstrate our methods by using them to defeat three popular disk encryption products: BitLocker, which comes with Windows Vista; FileVault, which comes with MacOS X; and dm-crypt, which is used with Linux. The research team includes J. Alex Halderman, Seth D. Schoen, Nadia Heninger, William Clarkson, William Paul, Joseph A. Calandrino, Ariel J. Feldman, Jacob Appelbaum, and Edward W. Felten.
Our site has links to the paper, an explanatory video, and other materials.
The root of the problem lies in an unexpected property of today’s DRAM memories. DRAMs are the main memory chips used to store data while the system is running. Virtually everybody, including experts, will tell you that DRAM contents are lost when you turn off the power. But this isn’t so. Our research shows that data in DRAM actually fades out gradually over a period of seconds to minutes, enabling an attacker to read the full contents of memory by cutting power and then rebooting into a malicious operating system.
Interestingly, if you cool the DRAM chips, for example by spraying inverted cans of “canned air” dusting spray on them, the chips will retain their contents for much longer. At these temperatures (around -50 °C) you can remove the chips from the computer and let them sit on the table for ten minutes or more, without appreciable loss of data. Cool the chips in liquid nitrogen (-196 °C) and they hold their state for hours at least, without any power. Just put the chips back into a machine and you can read out their contents.
This is deadly for disk encryption products because they rely on keeping master decryption keys in DRAM. This was thought to be safe because the operating system would keep any malicious programs from accessing the keys in memory, and there was no way to get rid of the operating system without cutting power to the machine, which “everybody knew” would cause the keys to be erased.
Our results show that an attacker can cut power to the computer, then power it back up and boot a malicious operating system (from, say, a thumb drive) that copies the contents of memory. Having done that, the attacker can search through the captured memory contents, find any crypto keys that might be there, and use them to start decrypting hard disk contents. We show very effective methods for finding and extracting keys from memory, even if the contents of memory have faded somewhat (i.e., even if some bits of memory were flipped during the power-off interval). If the attacker is worried that memory will fade too quickly, he can chill the DRAM chips before cutting power.
There seems to be no easy fix for these problems. Fundamentally, disk encryption programs now have nowhere safe to store their keys. Today’s Trusted Computing hardware does not seem to help; for example, we can defeat BitLocker despite its use of a Trusted Platform Module.
For more details, see the paper site.
What about the fix suggested above, not to clear the key on screen-saver lock, but to clear the key on sleep (plus hibernate and shutdown of course)? Surely the great majority of computer thefts are laptops, and the great majority of laptop thefts would find the system in a suspended state. You’re going to want to ask for the password again anyway on resume from any of these states. Isn’t this an easy fix that addresses 90% of the problem? used compound bows
Are stationary PC’s & servers subject to this attack? I mean, it would be impossible to open the casing in a normal situation, esp. on servers mounted in a rack or fulltower with keylock for the case.
Agrees on that you should overwrite key on screen saver, and by that removing this hole. (if you leave it w/o screen saver you’re still fucked, whatever security you got)
After reading your reading the article on encrption code crackers and the cold air thieves, I am totally confused. Please unscramble my brain. I thought that everything that is downlowded on the internet or written/saved on the computer can be found by professionals. The FBI and Police departments take computers everyday for the purpose of retrieving evidence. I do understand encrypting message on phones and email messages, yet I am confused how taking a memory card and blowing it with cold air with make a difference, except that you can save the informationa nd transport it from place A to B. Is the article about holding on to memory or how to encrypt.
Thank you
It describes an attack on how to get an encryption key, without the use of brute forcing it. It is about cooling the RAM, so that any data in it will not fade (like an unencrypted disc, if you so will), and then dumping it on a medium that WILL NOT fade. Most encryption software relyes on the belief that the RAM is secure, and impossible to read. This is true, if you don’t cool the memory.
Therefore, the cooling of active RAM makes it possible to dump it and analyse it in an other computer.
Anonymous Cryptographic Technician:
One solution I had designed for a client a few years back would have defeated this attack. A relay was attached to a burglar alarm and the computer was placed in a small and specialized room. The room had a magnetic sensor on the door and a passive infrared detector to detect unauthorized access. If anyone tripped the alarm by breaking in a relay would cut the power. The PC case had a high quality lock to slow down an attacker and was also placed in a metal enclosure to prevent theft and tampering. FIPS 140-2 seals were also used on the case to make it tamper evident. While this solution isn’t exactly mobile it defends from this attack through layered security and conservative design. In fact, I had never planned for this sort of attack and my physical countermeasures would have been sufficient. I contacted the previous client and made him aware of the hypothetical threat and he was thrilled his system was protected even from this emerging threat. Good Work.
Guess the best thing to do is remove all sensitive info from the laptop and place on a micro sd like thing disguised as an hearing aid and non-metalic so it won’t set off metal detctors in airports.
Write over all deleted data 1000 times on the hard drive.
Put the sd device info which is basically letters and numbers in some code based on a language you invent and then encrypt that so even if the could break in they could never figure out the code………
whats the brand of external hdd used in video ? 🙂
Pardon me if I missed this but at first glance it seem that all the testing was done on encrypted disks. Not sure I understand if this would impact a TrueCrypt volume that was created from a file residing on an internal disk, a partition or external USB disk that had not been mounted or had been un-mounted prior to shutting down the computer or un-mounted prior to going in to hibernate mode. My understanding from TrueCrypt that the key is never kept in memory under these circumstances and therefore would not be vulnerable. Your kind response would be greatly appreciated.
IMO this attack only works where the key is located in the RAM = DURING MOUNT.
Dismount, then you’re safe.
Has anyone here been able to get the usbdumper program to work for them? I can successfully retrieve the contents of RAM with the USB scraper utility, but when I go to dump it using the usbdump utility, I get the following error: bad checksum on dump map (0 != 71dce719), aborting
Can someone please tell me what i’m doing wrong. I’ve tried this on various computers using various usb drives and continue to get the same results. Any help would be much appreciated. Thank you.
ZZZZZZZZZZZZZZZZZZZZZZZZZZ http://www.monsterpapers.com time to wake up
I think some of this can be fixed with software, in this way:
– Take a hash of computer-specific variables, such as the MAC address of first ethernet card, CPU ID, hard drive serial numbers, region of DVD-ROM (if any), etc., along with a “counter” function and a random salt. Use this to “encrypt” the keys stored in memory.
– Build a variable-length hash algorithm that takes the normal hash result and applies it to the input, where another hash is made, and added to the end of the hash, until the hash size is the same as the key size.
– XOR the hash against the key that is stored in memory in the decrypt code.
– In the “encrypt” code, increment the counter, and in high-security mode, re-randomize the salt, then recompute the hash, and store the encrypted key, as well as 63 (in normal mode) to 255 (in high security mode) other keys, also stored in different locations in memory. Part of the key encryption algorithm would include which of the 64 to 256 keys was the real one.
This would completely defeat the technique defined here, as removing the memory chip from one computer and putting it in another, and then running a ram dump, would get you randomized data, but not the unlock keys, unless you knew the counter, which order the hardware IDs were in in the original hash, how big the actual key is, and the random data that was used to salt the hash.
Rebooting the same computer into a different operating system will get you a long way to getting the correct key, but you’d still have to know the random data and the counter in order to get at it. Since all the factors are hashed, there’s no way to know you’re correct until you are. With the extra variables that “look like” encrypted keys also in memory, you’d have to apply the same brute force hacking attempt to each of the 64 to 256 keys in memory, then try each one, to possibly get at the key which may unlock the drive.
This algorithm could be implemented today with hardware and software already in existence. I may build a patch for dm-crypt for my own use to test this out.
A future application would involve a patch to VirtualBox OSE, qemu, or other source-available emulation packages where all the memory in the guest OS was stored encrypted in the host OS. The guest hard drive would exist on an encrypted partition on the host computer for added security, and the swap space on the same host computer would be encrypted with a randomized key on boot. All sensitive operations would be done on the guest OS, which may not be aware (or care about) any encryption.
Just a few thoughts on the matter. Still, this paper really got me thinking, and I enjoyed the mental exercises 🙂
I thinked about cold bolt method and have one idea.
Cold bold method based on dumping ram mamory and searching for “crypt signature” then dumping keys.
What if defragment ram with special programs (there is a lot of it, like Hare, Ramboost etc. … not reclam) before using cold bolt method. Defragment memory will clean up unused memory paths (i am not specialist) but how i think it will make using cold bolt method useless.
I was interested to know how well the findkey program performed. Was it really pratical?
And ?
please can anyone feed me where can i find the modified PXE memory imaging Program that was used in the expirement !!! i need to use it in the same expirement for a senior project am preparing !!!! can any one help me plzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
Wow, this is GREAT work! I’ve always relied on disk encryption for my laptops and Sony UX micro PC (on which I have 3 levels of password “protection”); now I know better. Thanks a billion for your tremendous contribution to the security scene!!! I look forward to you guys’ future work.
please can anyone feed me where can i find the modified PXE memory imaging Program that was used in the expirement !!! i need to use it in the same expirement for a senior project am preparing !!!! can any one help me plzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
Oh I almost forgot
and I have known a few very paranoid hackers in my time
almost always we prefer to encrypt our disks and then just to be safe
remove the disk and take it with us
a computer can be rebuilt quite easily by any idiot with a screwdriver
laptops included.
and keeping all internal and external disks upon your person in a bag or just with you
means
your data is very safe
of course
the individual who wants to steal it could
shoot you and take the disks anyway so avoid places with guns
only install a disk if you are sure you need it always remove it afterwards
and don’t litter the world with disks you no longer feel capable of running because they are low spec, keep them all
a good idea is also not to leave a laptop unattended in a public place like almost half of the employees of the British Civil Service recently
another thing to note about notebooks and laptops I know of someone who accidently dropped one from a third floor window onto a spanish sidestreet
and there was no way that the information on his hard disk was ever going to be recovered by anyone even if his DRAM retained the encryption keys, so hope for a clumsy thief.
The First Hurdle – Reality
The DRAM attack described by the Princeton requires a well prepared attacker who is able to time the theft or access of a specific laptop to 35 seconds or less of the laptop being powered down or DRAM contents and encryption keys will not be recoverable. The authors themselves note that in some cases, this period of vulnerability is as low as 2.5 seconds.2 During this time period of 2.5 to 35 seconds, the attacker must steal the computer, open it, access the DRAM and cool it using an air spray or other methods which may include transplanting the DRAM into liquid nitrogen. The attacker must perform these actions while the owner of the PC or laptop must remain unaware of the attack or risk the owner preventing the attack via physically restricting access. Since the DRAM data recovery or cooling must occur immediately after power off and the power off sequence is extremely likely to be initiated by the owner of the laptop, the computer owner is likely to be in the immediate vicinity if the attack involves the actual theft of the computer. In a realistic scenario, a random attacker stealing a laptop is far more likely to spend the first 35 seconds of the theft running away than disassembling a laptop to apply liquid nitrogen. This type of attack would be more plausible in cases where the owner of the laptop or PC poses no risk of interference, such as in rapid government seizure or robbery at the point of a gun. However, in such a scenario, the attacker would most likely be able to use the same physical means of taking possession of the computer while the power remains on, thus eliminate the necessity of breaking the decryption.
As a result, this attack cannot be used in a casual theft or on a laptop mistakenly left behind at the airport. A much higher risk, is an unattended laptop left in the workplace while in standby (S3) mode. Computers in this state could be hacked very effectively with this technique. This is unquestionably a risk. In such cases, more needs to be done to eliminate standby mode and raise user awareness rather than directly confront the DRAM attack.3 Regardless, there are weaker links in the chain and it is easier by far to steal someone’s credentials than a more elaborate heist, but the DRAM attack warrants a detailed examination and brings significant issues to the forefront regarding software-based Full Disk Encryption.
Can the attacker steal the encryption key if the laptop is stolen during power on or suspended mode?
This is misleading. Full Disk Encryption products provide Data-at-Rest protection and are designed to provide power-off protection to PCs or laptops. By definition, such products allow complete access to the encrypted contents of a drive or partition that has been authenticated to while the drive is mounted and the power is on. As such, the assertion that the encryption keys can be stolen in this context is not a valid security flaw. If the laptop is stolen while powered on, there is simply no reason to bother breaking the disk encryption when the data can be easily accessed in any case.
SECUDE strongly recommends shutting down computers with sensitive data and never leaving such a computer unattended and on. No amount of encryption can protect data that is left unlocked and unattended. We also strongly recommend enforcing computer shutdown by utilizing two factor authentication methods in highly sensitive areas with a multi-use smartcard. Requiring the same smartcard for computer access and to enter or leave the area will force users to remove the smartcard and subsequently shut down the computer before leaving. In the case of suspend mode, most computers are vulnerable to attack in this state for a number of reasons, including the possibility that sensitive data may remain in unencrypted form in memory during this time. For this reason, most security companies recommend configuring computers at risk to employ hibernate mode instead. This is a sound precaution and the authors rightly point out this vulnerability, although it is well known for other reasons. We strongly recommend employing hibernate mode on laptops which may contain sensitive data.
Is this attack new?
No. Several papers have been published on this subject6 and even Wikipedia has references which apply.7 The authors of the paper also note that the issue of memory retention has been known since the 1970s.8 However, this paper does focus more attention on the subject, which is welcome and may provide sufficient motivation for hardware vendors to focus more security efforts on all forms of RAM.
What is the window of opportunity for attackers?
The authors note that the window of opportunity can be as low as 2.5 seconds before complete memory loss and the slowest memory averages at 35 seconds.9 The authors also note that, machines using newer memory technologies tend to exhibit a shorter time to total decay than machines using older memory technologies.â€10 The attacker has this brief period of time to radically drop the temperature of the DRAM which will allow the attacker to read the contents of the memory. This time must include stealing the laptop, opening it, and applying the coolant without being interrupted.
Defenses for Software-Based Full Disk Encryption
Several possibilities for securing against this type of attack are possible and have been suggested, but most fail to address the underlying problem and ignore the general unfeasibility of the attack on practical grounds suggested above. However, some are worthy of consideration and will have bearing on the subsequent discussion of hardware-based encryption.
Change the Location of Keys during Runtime
This has no bearing on this issue since the DRAM is literally frozen at the time of the attack. Mounting this attack via a key search algorithm such as the one suggested by the authors renders the location of the keys and whether or not they are periodically moved irrelevant. This is an attempt at obfuscation. Encryption can be combined with obfuscation, but in a theoretical case such as a DRAM attack, obfuscation is not a valid response. SECUDE does not recommend relying on obfuscation as a data protection method.
Fragment Keys into Discontinuous Pieces to Increase Obfuscation
Similar to changing the location of the keys, this suggestion has virtually no effect on key recovery. While in use, the encryption key must be unified and careful study of the encryption software prior to the attack will remove any difficulty the attacker might face. The purpose of encryption is to ensure that obfuscation such as this is unnecessary. While this may delay an attack, it will not prevent one. In addition, this method would slow down decryption during regular system use. As performance reduction is generally regarded as the number one complaint for software software-based encryption users, implementing this obfuscation technique represents a large tradeoff of performance for dubious security improvements. We do not recommend relying on obfuscation as a data protection method.
Use Multiple Keys for Different Parts of the Disk
This suggestion prevents the entire contents of the disk from being exposed at one time during a single attack. However, multiple encryption keys require additional authentication if they are to avoid exposure in the same attack instance. Although this suggestion is valid and is implemented in many FDE solutions there is no reasonable presumption that the most sensitive data is not on the exposed partition. As such, the suggestion does not truly address the attack.
We recommend using an additional layer of encryption for top secret data and requiring additional multi-factor authentication. This additional encryption can take the form of additional partitions such as described above or file / folder encryption and authentication should be at least two factors.
Multiple Keys Used in Sequence to Decrypt the Disk
This suggestion might delay an attack by adding an additional layer of complexity, but the DRAM attack would ensure that all keys are available to the attacker. Since the search algorithms employed by the author do not rely on decrypting plaintext to check for key integrity, the attacker will simply have a variety of keys to check in order to decrypt the data correctly. This may inconvenience an attacker and slow the process, but it will by no means stop an attacker as sophisticated as the authors. Although technically encryption, this really is just an additional layer of complexity which either is either equivalent to obfuscation, or could just as easily be accomplished with longer encryption keys.
We strongly recommend employing the largest available keys lengths and uses AES 256 algorithms for encrypting the Data Encryption and Key Encryption Key
Use Longer Encryption Keys
As the contents of DRAM decay, more and more key data is lost. The more key data that is lost, the larger the searchable key space is and the less likely that an attacker can reconstruct the correct key required for decryption. Utilizing a longer decryption key means a larger searchable key space and makes it statistically more likely that a sufficient degradation of the key will take place during the same period of time that a shorter key might still be recoverable. Although it goes without saying that longer keys mean more security, this suggestion ultimately does not eliminate a potential DRAM attack since DRAM decay has a steep acceleration curve and most decay occurs in a relatively brief period of time. Therefore a longer key does result in some extra protection, but it is not a significant barrier to attack.
We strongly recommend employing the largest available keys lengths and uses AES 256 algorithms for encrypting the Data Encryption and Key Encryption Key
Erase DRAM Free Space Periodically During System Run
This suggestion does not offer any real solution. The encryption keys must be available during normal use, and wiping DRAM does nothing if the keys are immediately replaced or moved to a location with similar vulnerabilities. There is also no guarantee that DRAM space happens to be wiped immediately prior to the theft and shutdown of the notebook.
Force a Complete Erasure of DRAM during Shutdown, Hibernate, or Standby
This suggestion is valid in theory, but impractical in reality. Wiping out DRAM during standby is unfeasible because recovering from standby would be impossible. As noted previously, standby mode should never be employed by users serious about data security. SECUDE strongly recommends employing hibernate mode on laptops which may contain sensitive data. In the case of shutdown or hibernate mode, erasure of DRAM is advisable, but still does not eliminate the basic attack proposed by the authors. There is no guarantee that an attacker cannot completely cut power and prevent any erasure before it takes place. Without modification of the underlying computer hardware to contain such an automatic erasure with an independent power supply, this suggestion only covers certain scenarios where the owner of the laptop has control over the shutdown of the computer. The assumption of the authors is that the attacker can control the method of shutdown and force the complete and abrupt termination of power. However, as noted previously, in this scenario the attacker already has complete access to an unlocked and powered on computer. Therefore this scenario of obtaining the encryption keys is unnecessary, the data is already exposed. In the scenario that the computer owner is in control of the shutdown enough so that an automatic DRAM wipe can be implemented, the drive owner is in sufficient position to prevent the DRAM from being frozen by an attacker within the 2.5 seconds that it will take to decay in today’s advanced DRAM. Even if the owner chooses to allow an attacker to attempt this feat, 2.5 seconds is insufficient time to remove a laptop from a case, let alone open the casing and freeze the DRAM.
Leave Fake Keys in DRAM Which Will Erase the Disk if Implemented
This suggestion is an inconvenience at best. An attacker using this attack method is not attempting to decrypt the contents of the drive via the Full Disk Encryption program. Therefore there is no way for the computer to recognize and execute any command indicated by the fake key. At best, this suggestion is obfuscation again and will slightly delay the attacker by forcing him to attempt decryption with more than one key. We do not recommend relying on obfuscation as a data protection method.
Take Steps to Make Boot Code Disassembly Difficult
Aside from open-source implementations, all encryption software vendors take steps to ensure their software is difficult to disassemble in order to preserve their competitive advantage. However, an attacker implementing this attack should be presumed to have the foresight and preparation time to obtain and sufficiently examine a copy of the drive owner’s software.15 The purpose of encryption is that data should be secure regardless of the amount of preparation or the length of time available for an attack.
Use a Trusted Platform Module (TPM) in conjunction with Full Disk Encryption (FDE)
As pointed out by the authors, the use of a TPM chip in conjunction with FDE does nothing to eliminate the possibility of a DRAM attack since the TPM chip does not perform the drive decryption and the key must be copied into memory in order for decryption to take place.
Clear Memory at Boot Time
Some computers can be configured to require that RAM be cleared at startup before loading any operating system. This suggestion would prevent an attacker from using the stolen laptop to perform the DRAM attack, but an attacker could still move the DRAM to a separate computer. We recommend configuring laptops to clear RAM at power up regardless.
Block Accessible Ports
Eliminating the possibility of booting from separable media eliminates the possibility of using the stolen laptop to perform the DRAM attack (as above), but suffers from the same weakness. TheDRAM can be moved to a separate computer or the hard drive can be entirely replaced during the DRAM attack. We recommend using port blocking software such as DevicePro by Cynapspro.
Summary of Software-Based FDE Defenses
Although the likelihood of an attacker being able to successfully steal a laptop and implement an attack before the DRAM decays is low at best, software-based FDE is theoretically vulnerable to this attack. Potential fixes by software vendors cannot eliminate the possibility entirely, although they can certainly make the attack more difficult. Hardware fixes on the motherboard including making the DRAM more tamper resistant or adding additional hardware to erase the DRAM even after sudden power-off cannot be implemented by software vendors, but pose an intriguing possibility for hardware manufacturers. However, for those extremely security conscious individuals or enterprises, newer hardware encryption technology exists which eliminates many of the difficulties posed by this attack in a robust manner.
Eliminate DRAM Attacks with Hardware-Based Full Disk Encryption
Recently, hard drive vendors such as Hitachi and Seagate have released products which implement hardware-based Full Disk Encryption in their hard disk drives. Intel has also announced the implementation of a Trusted Platform Module (TPM) as well as Full Disk Encryption in their new chip set to be released in the third quarter of 2008. These newer technologies share a distinct advantage over software-based encryption in terms of DRAM attacks – the data encryption keys never enter into computer memory and are thus not vulnerable to this sort of attack.
Location of the Data Encryption Key
In hardware-based encryption, the keys used to encrypt sensitive data are kept in a self contained computing environment and never enter into DRAM. Therefore, this attack is not feasible, at least not in the sense that the DRAM itself could be attacked. Although there is a separate key known as the Key Encryption Key (KEK) which may be used to access and decrypt the Data Encryption Key (DEK), this key is encrypted with a hash of the username/password or certificate (in the case of smartcard use) prior to authentication. The KEK is only decrypted and used momentarily during the initial unlocking of the disk drive and the KEK is not available in DRAM subsequent to the drive unlock. Therefore an attacker would have to be able to shut down power to the drive, not while it is unlocked, but at a precise instant immediately after the drive is unlocked, but before the KEK is wiped from memory. This remarkable feat of timing is not only unrealistic, but would have to be done within milliseconds after software authentication with the computer owner present and willing. Again, if the attacker has access to a computer owner willing to unlock the drive, there is no need for such a complicated attack.
Physical Challenges
Of course, the attack could be modified to direct itself against the Data Encryption Key directly on the HDD or chipset. However, this presents an additional level of physical complexity since accessing the chipset or hard disk drive requires significantly more time to access. In addition, there have been no known successful attempts to reproduce this form of attack on hardware-based FDE.
At the very least, removing chipset based FDE and submerging the chips in liquid nitrogen presents the attacker with the considerable challenge of either detaching the chipset, or carrying around a significant quantity of liquid nitrogen sufficient to submerse the entire motherboard or computer.
Similarly, disassembling an FDE hard drive is impractical in a short period of time and submerging the entire hard drive in liquid nitrogen is likely to damage the data beyond repair. While a DRAM attack of software-based Full Disk Encryption is unrealistic at best, the same attack on hardware-based Full Disk Encryption is almost inconceivable.
Summary
While the paper published by Princeton brings a valid argument against the current security measures used to protect DRAM, this vulnerability does not present a significant threat or challenge to existing software-based Full Disk Encryption due to the physical challenges of implementing the attack in a real life scenario. The proposed attack is performed in laboratory conditions and some assumptions required to implement such an attack allow the attacker unfettered access to the computer while it is powered. This assumption often eliminates the necessity of mounting an attack in the first place since the data can be easily accessed while the drive is unlocked and the power is on.
Current Full Disk Encryption users have little reason to implement immediate changes. However, highly security sensitive individuals and enterprises should consider gradually migrating to hardware-based FDE for additional security and other performance benefits such as better CPU performance.17
FinallySecureâ„¢ is a hybrid hardware- or software-based Full Disk Encryption solution which functions in conjunction with hardware-based technologies such as FDE hard drives or independently with software-based encryption. This solution allows Enterprises the flexibility to protect their existing legacy systems immediately while migrating to hardware-based encryption which offers additional security and productivity benefits.
This product is available from SECUDE AG – a Swiss Information security company that recommends the used of hardware-based encryption technologies in conjunction with their product FinallySecure™.
Jagan Vaman CISA
It _IS_ quite simple to add a few lines of code in truecrypt 5.1 so that when the encrypted data gets unmounted the precomputed keys are overwritten several times with some random data.
That’s the only measure necessary to avoid such attacks, and of course good programming practice will allocate this small part of memory in a non swappable segment avoiding problems with the swapfile.
If the authors had invested 10% of their efforts to imagine these counter measures the hype of their publication would have gone before it appeared on the net :p
And of course, by “clear memory containing the unencrypted key”, I mean “overwrite it with garbage enough times to prevent it from being recovered by the means described by Felten”.
“Several posts have suggested clearing the key from memory when the computer is screen-saver locked but still powered up.
This is not possible, as the operating system and processes keep running while the computer is locked.”
Use two partitions. An unencrypted partition for the OS and non-sensitive data (like stock programs) and an encrypted partition for all custom data. The key for the encrypted partition has to be kept on the unencrypted partition, but the key can itself be encrypted on disk by a strong cipher which can’t be broken without the manually entered password. This means that the *unencrypted* variant of the key is only present in DRAM memory. This key can easily be wiped before shutdown by synchronizing and unmounting the data partition before wiping the key from memory, then wiping the key, then shutting down the rest of the machine.
Linux is pretty well set up to enable this sort of structure. Encrypt /home; ask at the console for a password before mounting /home; clear memory containing the unencrypted key after unmounting /home and before shutting down.
Simple, really. I guess the crucial point is that you can’t encrypt *everything*, you need an unencrypted partition to contain early boot and late shutdown data. Which is all stock information and shouldn’t be considered secret in any case.
I was interested to know how well the findkey program performed. Was it really pratical?
I’m glad to see, that you uploaded the full-size WMV of the full video. Great! 🙂
Mr. Richard L. Unison: First, thank you for noticing our efforts. Our comment to your statement is no; no developer involved in writing nokVAULT File Encryption software code had ever accessed the mentioned patent or any other such patent. nokVAULT super security is based on a creative software architecture which was development as original and proprietary work of a group of very smart and creative engineers over a period of many years. Knowing that you are so involved in security, having filed a patent on the subject, we are more than pleased to make you acquainted with our work and we invite you to take a closer look at our product(s). We are all very excited at the release of our most recent super file encryption software solution and we welcome support from experts. To answer your question, our engineers are well aware of cold boot attacks – not at all a new idea in hacking.
two things to think about,
1 this kind of attack could be prevented quite easily if
the user reboots the machine into a thin client linux distribution on a purpose built ram disk thus overwriting the information stored in ram with a load of virtual operating system information, and if the virtual OS is compiled without disk mounting software ie a cut down kernel and without hal support, any malicious os that attempts to take advantage of the flaw could be presented with only useless information stored in the ram of course the user would then have to re shut down the laptop or pc afterwards so that the virtual os without any encryption passwords is stored in the ram thus effictively removing any encryption from the last hard disk boot.
2 a heavy duty linux/unix live dvd/cd with write to ram only instructions ie like live freebsd could also be useful against this sort of attack because it can be booted directly into ram storage thus wiping and overwriting any data that may be stored in the dram chips and chip buffers. thus any attacker who then hijacks the chips can only access information from the last operating system booted and if the last os booted was a static ram only os without information about data stored on hard disks, the attacker has attacked for nothing.
3 the only other way would be to hack the bios of the motherboard of the said laptop or pc, writing in an overwrite ram option (warning only do this if you know what you are doing and don’t tell the motherboard manufacturer because they may prosecute, which is a shame), change the boot structure so that on shutdown the pc/laptop etc reboots into the bios, run the ram/dram cleaning option and add a bios shutdown command so that the bios then shuts down the machine to effect any changes made as any bios would do normally. Only one problem, most bios’s are going out of fashion, operating systems themselves are trying to do without them, but in cases like this they could become exceptionally usefull, and thus should be ressurected.
@ Ed Felten
Many thanks. So I will wait for the upload. 🙂
Are you releasing any information or software to Law Enforcement Agencies? I work at the Louisiana Department of Justice, in the High Tech Crime Unit. We work ICAC (Internet Crimes Against Children), and there could potentially be a situation where this information could help protect a child from danger.
“This problem cannot be solved in software, people”
Please. What about simply wiping the key (i.e., unmounting the encrypted volume) when the machine is about to get screen-locked/put to sleep/hibernate? The user will have to re-enter the passphrase, to be sure.
I’m greatly surprised to learn that all these disk encryption suites don’t do this already.
Hi all! I saw that the tool used for dumping the RAM to USB hasn’t been released, so I took it upon myself as a small weekend project to write one myself:
http://mcgrewsecurity.com/projects/msramdmp/
Hope this helps someone out who wants to play with this sort of thing.
I think I might have mis-spoken a bit in my previous post about the meaning of Cold Boot Attack, but the point remains: there are states in which a laptop can be found in which one cannot decrypt the hard disk without knowing or discovering the key.
Max,
We’ll try to generate and upload it. If possible, it’ll appear on our video/image page at http://citp.princeton.edu/memory/media/
Could you upload the Full-size WMV for the full video “a brief, accessible
introduction to our results”??? Would be great! Thx!
Toby: to expand upon Seth Schoen’s response to your post, do you understand what Cold Boot Attack means? It means the attacker has access to your PC after it is turned off. Of course he has access to your PC, and your hard disk with the encrypted data on it; otherwise, what good is the key going to do for him? But do you understand that encrypted data is useless without the key? If you read it, it would look like gibberish. If you try decrypting it with the wrong key, it would still look like gibberish. That’s the whole point of encrypting data. If you didn’t know that, why are you using encryption at all?
nokVAULT: looks like your company has rediscovered several of the features of my invention (see my earlier post for the patent number). But did you really analyze all possible hacks and come up with your solution, or did you just read my expired patent and implement it? Well, what can I say, it’s expired so you’re free to do that. But it’s hardly original. Granted, there were no laptops (or anything like today’s desktops, just some toy computers like Timex Sinclair 1000), and there was no World Wide Web, at the time it was filed. We had in mind protecting data on mainframes. But the principle still applies, as so many of the posters in this discussion have, to reuse that word again, rediscovered.
In the case of an attacker booting one’s hardware to recover keys, we can thwart the attack by placing the key in a physical page that will be overwritten during boot. For instance, the BIOS on x86 architectures will always load 512 bytes of boot sector in a predictable physical location. A kernel that uses this location to store a master key will not be vulnerable to your attack. All other attacks require the attacker to open the case, which, apparently, should trigger a small explosion if one’s data is at all sensitive.
Google: Motorola EEPROM RAM POWER FAILURE
Old concept…. to the guy who says he has a disk encryption product that is secure with physical access…… are you a betting man?
If I was hired to obtain information from you or your company you wouldn’t know who I was but i’de be so close to you ide see or hear everything you did anyway.
Susan: the MacBook Air might be relatively safe if it could be configured not to boot from “untrusted” devices, but it is not really clear yet that this is possible. If we can get it to boot from the network or a USB device or if we can temporary replace the internal hard drive, we can carry out the attack without needing to physically remove the RAM. RAM soldered to a motherboard could be a part of a mitigation strategy, but can’t be considered a complete mitigation by itself.
Toby: your machine might be vulnerable if you ever leave it unattended under some circumstances after you’ve entered the TrueCrypt password but without turning it all the way off — for example, if it’s screen-locked, sleeping, or hibernating, or if you haven’t logged into any account.
I don’t understand this.
I use TrueCrypt. My PC starts, TC runs, I enter my password.
Now, I understand from this attack that the key derived from my password lingers in memory, and that if an attacker has physical access to that memory, he can get my key.
I’m clear about that.
But if the attacker has physical access to my memory, he’s going to have physical access to my PC – which is sitting there, *with the TC encrypted volume already mounted and fully accessable*.
Why does he even care to look at my memory chips? he’s got access to my encrypted data via my mouse and GUI already!
Though it might be harder to protect on mobile devices (e.g pdas, thumbdrives, laptops), physical security is a very important aspect of overall security for a system, which seems to be beyond the scope of this research! One more reason to store the most sensitive information on tamperproof locked down appliance box or in Aaron’s safe 🙂
Nevertheless a very interesting paper!
Cheers
I’ve often wondered about a slightly different approach to the same purpose: a hot-pluggable expansion card that uses DMA to copy all of main RAM to an external device. PCMCIA is by design hot-pluggable and I wouldn’t be suprised if through careful design it weren’t possible to make a device that could be gently powered up on a standard PCI bus without crashing the CPU. Whether it’s possible to get the DMA controller and other mobo hardware to allow unfettered DMA access without OS cooperation is beyond my hardware knowledge, but it wouldn’t suprise me.
Susan,
Sorry, the MacBook Air is not automatically immune to these attacks. The attack can often be done without removing chips from the computer. See, for example, the attack we show in our video, which doesn’t remove chips.
How hard would it be to construct a microprocessor which encrypts all main memory accesses using a key that’s generated randomly on system startup and is never stored externally? That would require an encryption engine that could run at main memory speed, but I would think that with pipelining techniques such a thing might be feasible.
You’re safe with a MacBook Air, the SDRAM is soldered onto the logic board rendering this attack impossible.
A scrubber can be anything that is require to dump the charge from all the bits. It is not necessarily something that writes 0 to everything. You might be able to power this using the very charge itself.
Yes, this attack vector attacks the keys. Improving key management would not stop this and your software Full Disk Encryption is very vulnerable. Don’t lay down the gauntlet Brian you could pay dearly for foolishness.
For example this attack also works for retrieving the login hash of whatever network authentication scheme, no matter what the OS. You could within minutes impersonate that user on the network from another machine. This wouldn’t be easy and the implementation is dependent on what you want, but it’s very possible. Easyier still would be stealing someone hash and writing just enough code to impersonate and change (not reset) the user password. You now have a window of opertunity to retrieve data, install backdoors, rootkits, or whatever and all undetectable by virus software.
This attack vector seems like bad Key handling implementations. IN every example in the paper the key defense mechanism was known and was weak – SHA-1 in one example. This seems to speak much more to poor quality implementations of cryptography then a wholesale dunking of Full Disk Encryption.
We would welcome the Princeton team to examine our Full Disk Encryption implementation, and would be very sure that such an attack would be mathematically implausible – even with 0% key degradation.
So, if I was faced with this as a challenge, I would set out looking for a way to supply voltage to the ram when the system is in power off state or just a capacitor to power the flashing of specific mem addr to eeprom…. such as constructing my own stick of ram to insert with a self contained power supply. (e-mail for quotes, motorola has a paper out somewhere) [That negates the “scrubber” feature(which is ridiculous)]…. that way I could just come back a week or two later to get it, or whenever I feel like it. Physical access is a ridiculous reiteration of new ways to cook chicken.
Or since these programs probably use the same memory address every time to store the key, why not install a blue tooth device either internal usb or external to access the memory, or code a lil app to dump it via wireless. or omg…. use your video phone to record the keyboard,trj via e-mail, key loggers, social engineering, cooling the ram with liquid nitrogen is hardly pratical, and compressed air leaves all kinds of evidence, including wonderfully vibrant fingerprints. But its is great fun to find a new use for compressed air.
What amazes me is that it took someone this long to find this and then decide to publish it.
This is really nothing new… this ability (to varying degrees) has existed since RAM (core, static, dynamic) were invented.
All DRAM manufacturers have to do is put scrubbers on chips to wipe them on power fail. Yes they know how to do this because they know this phenomenon exists. Though some manufacturers probably didn’t have the imagination to consider this.
Now I can call up that IT admin who’s account use to get hacked on regular basis 6 years ago and send him here.
If to freeze preserve, to warm can destroy, could be? With not warm the RAM just fell seconds after shut down the notebook? May be, it can speederst to cleaner processe of the memory.
Store the keys in the TPM chip and not the DRAM?
I have a possible workaround for the problem. But I’m not sure how consistent it is. Tell me if it is wrong.
Here is the possibility I thought of: http://andreas.woodpecker.ch/item/2008/02/workaround-for-cold-boot-attacks-on-disk-encryption
(encrypt the key with the normal user password as long as the user is absent)
Probably someone already thought of this possibility…
Unmentioned is the radio signals eminated from your keyboard and other internal parts of your computer.
It’s been a while since I read anything about this, I think it is called Tempest. But there are methods of encasing one’s keyboard and computer in signal dampening material to prevent the transmission of what you type.
So, you have an unsecured laptop of top secret information and you open it in the local coffee shop sitting next to the guy with the receiving equipment tucked under his coat and he grabs all of your keystrokes and can can find your password within them.
And he doesn’t have to be sitting next to you, just within the range of the radio signals, assuming radio signals to be a correct descriptive term.
Of course every Trekkie knows all you need is a TriCorder which can tell you everything about the computer.
Hard Drive Encryption Vulnerability…
Why not reserve one or more of these registers to hold an encryption key? If using a register would be too expensive, surely it would not be too expensive to use some of the plenteous cache that modern processors possess….
This is indeed very interesting research of an old phenomenon. Thank you Ed for sharing the paper. I would qualify your research as equivalent to publishing vulnerability of WEP (wired equivalent privacy) that led into new WLAN security standards that we all know about.
If we analyze the actual problem, the transmission of the key from the entry point (keyboard) to the encryption software, we could propose another solution to mitigate the vulnerability of DRAM. Why not proposing challenge -response solution so that the key is different for each disk decryption session, just like in the most of e-banking solutions?
Ed,
how about if the de/encryption keys are actually not held in DRAM but on an USB tolen such as the Aladdin eToken Pro? Any tests done in this scenario?
Tom
Dennis,
We discuss this issue in our paper. (Follow the link from http://citp.princeton.edu/memory) The paper discusses some very efficient algorithms for identifying AES, DES, and RSA keys in memory, even in the presence of memory errors.
Assuming you are able to examine the DRAM image of a machine (say 1 Gb.) which may have encryption keys embedded in that image… what procedure would you use to identify those keys in the memory image???
Cold boot attack is one of many ways that disk encryption can be hacked by getting the encryption keys. There is not much that you can do about it, BUT, there is a company that analyzed all possible encryption hacking issues and created an UNHACKABLE SOLUTION. This simple and powerful solution that CANNOT be circumvented by anything or anyone is nokVAULT! It was released to the market in final BETA only a month ago. I have used most encryption software on the market to date and if you truly want to protect your data you can only do it one way: encrypt your information outside your OS.
I’m confused as to how this is new knowledge.
There was already software in the “old” days which used to search ram for documents after a system had crashed, or in the usual case, when word had crashed. I’ve probably still got some around. That dates back to the windows 3.1 era. You could reboot the computer with a reset switch, boot into the software and tell it to examine ram.
This is essentially the same thing, with the exception that you are assisting in the length of recovery by using lower temperatures to extend the time available.
Not new, just rediscovered.
Congratulations to all of you who rediscovered the concept of hardware protection of crypto keys. This is only one aspect of my invention, US Patent # 4,262,329, filed 30 years ago. My “co-inventor”, Herb Bright, passed away about 20 years ago; he admitted that he was listed as an inventor because he was my boss and he ordered me to invent it; and that he was listed first because he was first alphabetically. The patent was assigned to the company, which expired around the same time as the patent did, namely 10 years ago.
By the way, Bright and I were speakers in the same session of NCC ’76 in New York as Whitfield Diffe, when he announced and described his invention: public key encryption.
The patent, of course, is still viewable at the U.S. Patent Office’s website, http://patft.uspto.gov
Howard Israel Says: “1. The major implication that I can think of initially is that you just changed the way Computer Forensics work will be done, e.g., on a drug raid.”
I don’t think that it will in the near term. In the longer term, this potential exploit will be fixed. First, there are not a lot of raid teams that include a qualified examiner. Second, unless a machine is running, or you’re certain that it just shut down, this precedure is irrelevant. In a drug raid, or most law enforcment operations, you won’t know the state of the machine in advance, absent a great deal of pre-raid intelligence that exceeds most agency’s capabilities.
If a machine is running, and you can get to the desktop (privileges aside for the moment), there are plenty of tools that can aqcuire memory or image the logical, decrypted volume. There also is a device through which you can take a running machine back to your lab, without killing the power. For now, I’ll leave my bottle of liquid nitrogen at home.
One thing I have not seen mentioned here is that lots of people leave their computers on 24-7, especially people who run p2p applications. While this attack is not the only threat such people face, it is a significant one of these folks. Who needs keylogger and such rot. Stroll into their house when they are not at home, read the keys off the memory, decrypt the drive, get the data you want, reboot the machine and leave again. If you did it right, the person would never even know their machine was compromised. Yes, this doesn’t work for top secret installations but the amount of data on a home computer that an identity their would want is huge.
One way to overcome this problem is using a biometric as the encryption key, where an enrolled biometric is stored in a secure way – similar in principle to the hash of a password. The “secure biometric” does not reveal any information about the enrolled biometric data, i.e., it is not be easily reversed. Also, the bits that are stored enable on-the-fly recovery of the enrolled biometric (encryption key) only when a genuine user provides a second reading of the biometric.
Here are a few links to some related techniques in the literature:
http://www.merl.com/projects/secure-biometrics/
http://www.rsa.com/rsalabs/node.asp?id=2061
http://isis.poly.edu/projects/biomet
http://biometrics.cse.msu.edu/
Here’s a thought –
What if the hardware key was stored on a USB dongle, which was then read directly by a specialized HDD controller? It would seem that you could work it out so that the key was never actually stored in main memory.
a) Always ensure that your computer is not cd/usb/externaldrive boot enabled. this ensures that your machines always boots from the native hard-drive.
What if you use keyfiles? Wouldnt you be safe then, since they are not loaded into the RAM but read directly from the source.
what about zeroizing the keys from the memory if the box is attempted to be open to retrieve the memory chips.
The solution has to be in the hardware. Encryption keys must be stored in memory to access encrypted data. No way around it.
I would suspect that the technology already exist in military gear. The details are just kept classified to make it harder for hostiles to get at data on a captured laptop.
Any number of fixes are possible. A special chip that has it’s own battery inside the package could auto erase data in response to a number of tampering attempts.
The market would need to demand this level of security in order for secure chips to become affordable however.
Fascinating paper and amazing work. Hopefully, you won’t release any POCs w/ deep instructional information for carrying out this attack. Anyway, I’m wondering what your thoughts are on mitigating this attack in the longer run (I understand the short-run mitigations, like eschewing standby mode). Given the location of the weakness (hardware), I’m thinking the solution will also be in the hardware.
So, do you foresee “secure RAM” chips? Or, maybe a separate, lower-capacity chip that’s used solely to store sensitive info? Or something else?
Ummm, isn’t this why you set the Windows registry key to wipe the swap file on shutdown? The time window to get the memory contents for hard memory is very small.
Hive: HKEY_LOCAL_MACHINE
Key: SYSTEMCurrentControlSetControlSessionManagerMemory Management
Name: ClearPageFileAtShutdown
Type: REG_DWORD
Value: 1
The attack may be plausible, but not practicle. Good work never the less.
Thought I would add one last question to the list that I don’t expect to be answered. Would Via’s Padlock technology on their C7 chips mitigate this risk at all?
Anyone who uses fixed disk based encryption keys are asking for trouble. Since 10/05 I have been booting my laptop from a 1GB USB key. This key contains abbreviated Ubuntu, login info and drivers for a USB fingerprint scanner. Without that USB key my laptop is a readily replaceable brick. To make the world class TSA airport security people happy I have since made the laptop boot to the “C:” prompt when turned on. On windows machines I have made it a habit to disable both the Hibernate and system restore functions. For Linux machines all data is kept external on encrypted USB keys. This just slows determined folks down, I know. Excellent work to all of you!
As an “old” technogeek, your paper is fascinating! The impact of your research will likely provide substantial advances to file encryption and computer security in the coming years. Thank you for this.
However, with my years of experience, I always apply this test to new research/technology: What implications does this have in the real world? In this regard, the real question is: What percentage of computers/laptops are stolen/accessed by an intruder while still running? My guess is a very, very small number.
As one example, from prior conversations with airline terminal security, the indications are traveler’s laptops are stolen while in their travel state, either in checked luggage or more likely in a laptop case being personally transported, in which case they are all turned off to prevent damage to the hard drive. I assume this is a similar situation for road travelers as well.
In the case of a business environment, while the computer/laptop may be kept running for long periods of time, including while the owner/operator is absent, the probability of an intruder gaining access to the unit is very limited. Particularly an intrusion that could remove the unit from the premises.
And for the home/home office user, the chance for computer intrusion becomes even more remote while the unit is operating, unless the owner is in a habit of leaving it running 24/7 or possibly turning it on in the morning and off in the evening when finished for the day. This likelihood is becoming more and more unlikely from two perspectives: First, from an environmental and economic perspective, the extended running of appliances is becoming taboo, and saving energy includes turning off computers when not using them. Second, with the laptop become more pervasive, users keep them on battery while roaming around the house, then plug them in again after the battery dies, which has conveniently shut down the system (hopefully not suspending it!). And the vast majority of these home owners don’t even use encryption software in the first place!
Sum and substance, I believe the real world implications for this today are extremely limited. But the long term implications for computer technology, business, and national security are relevant, and particularly for our law enforcement agencies such as the Department of Homeland Security, who I understand was involved in helping to fund this project.
Sorry, one correction — I was looking through /dev/mem, not /dev/kmem.
Also, it may be that I am wrong about the key and the encryption, it may be that you do not need the passphrase once you have the key schedule, I am not clear on that… but that is really just a side point, dont get distracted from the main points 🙂
Not sure if this has been mentioned. Lots of comments and I only read about half.
The original post is written in terms of a hacker-type getting control of an encrypted hard drive and then defeating the encryption via the OP’s method.
Does this not provide attacks on other things such as DRM. The key has to be in memory to decode the video so it seems someone could use this to attack their own machine for other uses than hard drive decryption. Or am I missing something?
Thanks
I’d like to see more broad tests run that bring out some of the
potential and pragmatic counter-measures based on failures that emerge
from the analysis. I’m surprised that certain variables that could
dramatically affect results were either intentionally omitted from
this paper, or were not experimentally tested.
I see on page 5 of this paper a *small* selection of RAM types tested,
but the RAM parameters used fail to account for different experimental
variables that could dramatically influence the results: specifically
ECC vs. non-ECC memory, registered memory vs. non-registered? Do other
memory variables that seem like they would have no influence on the
results (such as CAS latency, speed, etc.) have any affects at all?
The paper does mention the effects of ECC memory, but provides no data
(cf. section 3.4 BIOS footprints and memory wiping). The decay curves
with the RAM tested did seem to exhibit dramatically different
results, in one case decay was an average of 2.5 seconds at normal
room temperature, and others were 35 seconds. Its likely that testing
for these different experimental variables would produce the same
decay curve shape, but in terms of pragmatic counter-measures, the
shape isn’t as important if the rate of decay is so dramatic to make
effective attacks much more difficult.
My own tests failed to replicate this research[0] when using my laptop
(SODIMM) and a desktop machine with plain old PC100/PC133 DIMMs. I
also couldn’t replicate it on machines with ECC memory. Is this
because my attacks were not sophisticated enough (I do not have the
tools to experimentally reproduce these tests, I did not use
compressed air and my liquid nitrogen was at the shop), or are these
attacks significantly (and if so by how much) more easily undertaken
on particular memory types? If so, what are those memory types? This
is significantly important information, in my mind. These tests only
worked with 4 manufacturer’s memory modules and included data that was
irrelevant to the tests (Make/Model of the the computer that the
memory comes from doesn’t really matter). Where is the data for other
important memory factors?
You may point out here that the cooling tests brought the rate of
decay down significantly, so that with the RAM types tested, up to 60
seconds resulted in 99.9% bit recovery, so probably these other
factors do not matter. That’s fine, but I’d like to see the data to
support “probably”. Also, keep your eyes on the prize here: if I need
to make choices of RAM based on the rate of decay at room temperature,
then I will. No, its not total protection, but it raises the bar and
now I require someone to open my case, cool my memory chips (which in
some of my machines cannot by sprayed with a can of compressed air
without removing certain things in the way that require you to power
down the machine) and then remove them and image them within 60
seconds. Raising the bar does work to remove a certain class of
attackers.
Additionally, these tests were run with *known* data bits. I’d like to
see a demonstration whereby extraction of memory (even at 99.9%
accuracy) was able to get my loop-aes key (which you do not know) and
then use that to actually decrypt my drive. Correct me if I am wrong,
but you get the key, you don’t get the passphrase that unlocks that
key. So you will need to then attack that key in order to get at the
actual data. Common wisdom is that if you have my private key (either
pgp, or loop-aes key) then your encryption is effectively foiled,
however lets not be so flippant… its not that easy and discounting
this gives a false sense of insecurity (however, as opposed to a false
sense of security, a false sense of insecurity is often better when it
comes to security).
Lets also not forget that if you do manage to dig out of my memory
image the actual key (and remember, you don’t know what the key looks
like), and you have .01% error rate on that key… how successful is
an attack on that key going to be? Under the extreme cooling test, you
measured “only[sic] 14,000 bit errors within a 1MB test region”. I
have two questions about this: 1. If I have an encryption key that
you’ve extracted and 14,000 bits are screwed up, how likely are you
going to attack my passphrase? You talk about Reconstructing AES keys
in section 5.2, but I’d like some correlation with the previous
information about 14,000 bit errors, if my key was in that bit range
and there were 14,000 bit errors, can you reconstruct the key if you
*do not know what the key is*? Section 6 of the paper seems to
indicate that you developed techniques for locating keys in memory
even with bit errors. However the description about how you do this is
unsatisfying, the interesting part, that I’d like to see expanded more
was, “A threshold parameter controls how many bit errors will be
tolerated in candidate key schedules”. I’d like to know more about how
these bit errors come into play in relation to the 14,000 bit errors you measured. For example, at what point are the bit errors too high
to recover anything useful? 2. Did you measure much higher bit errors
in other test regions? Why did you only point out the 14,000 bit
errors, was that the lowest one you measured? If the other regions
exhibited higher bit errors, I would like to know this and how these
higher bit errors related to #2. If you did omit the other test region
bit error amounts in order to strengthen your point, I would much
rather see the raw data, rather it not even be mentioned. Omissions
like this only serve to lead me along to your conclusions which I can
hardly argue with because I don’t have all the data.
So what are the pragmatic counter-measure here? Choice of memory that
has high room-temperature decay, combined with case design that
requires power to be removed before you can get at the RAM, or ram
which is epoxied or enclosed in a case which cannot be easily
penetrated. As pointed out above, maybe other memory variables, such
as ECC may play a significant role here and without a more complete
suite of tests, we can’t really say. BIOS protection, destructive POST
that cannot be disabled, disable booting from external USB/firewire,
along with recommendations made in section 8, physical counter
measures…
This is a great paper, and I think the data is pretty clear here, I am
not arguing against what are clear conclusions, I’m simply saying that
if you are going to go through the trouble to submerge things in
liquid nitrogen and write a specialized boot-loader memory-imaging
programs, why not test against legitimate variables (and if you did,
why don’t you include the data?) to produce more complete test results
that account for more variables, and *provide all the data*? I find
more valuable where your tests *fail* to work, and am somewhat
surprised (you weren’t wont for space) to find that this information
was omitted.
Also, people keep asking about loop-aes, if this attack would work against it. I’ve seen responses to this that say that it just needs to be done,
and would be just as easy as the rest of the encryption methods
tested. If its so easy, lets do it, I’d like to see it. Its not that I
doubt that its possible, its that I would like to see if its harder
and if so how much harder. If loop-aes key extraction from a
rapidly-decaying memory type where the memory chips are physically
difficult to reach is much harder than dm-crypt, then I want to know
that! Every variable which throws a roadblock in the way makes the
attack harder to pull off… and with an attack like this, you only
have *one chance*. If you fubar it, you don’t get a second chance by
sticking the chip back in the machine (although you can come back a
few days later after I’ve re-mounted my encrypted filesystem and try
again 🙂
Micah
0. I filled all my available memory with a string and then rebooted my
machine and attempted to grep /dev/kmem for that string, and failed.
If running in windows as host and Linux as guest in virtual machine with disk encryption(e.g. dm-crypt), what will be the result? What’s the difference?
Is that safe to doing that?
There are ways in whcih to store the keys in memory and not only eliminate the risk but mitigate the hack.
Superdave,
We discuss the TPM issue near the end of our paper. The bottom line is that today’s TPMs don’t seem to help, because the encryption key must be put in memory, and once it’s in memory it’s vulnerable.
Btw., I do hope my dm-crypt encryption keys will NEVER be purged when I lock the screen. The programs I will normally have running may still need disk access.
I’ve never programmed OS software, but just a quick idea: I’m not sure if this is still so, but during the boot process, if I remember correctly, the BIOS loads the boot sector into a fixed memory location – I think it was real mode segment 07C00h. After the OS loads the rest of its files into memory and jumps to the next stage of loading, would it not be possible to reclaim this region of memory and store the memory-resident decryption keys here, hedging bets with some of the other techniques described?
Say this module was removed, but somehow placed into another system that had a similar DIMM bank configuration which then mapped the module to the same memory addresses, wouldn’t that machine then automatically overwrite those decrypted keys with the boot sector?
To what extent do TPM (Trusted Platform Module) equipped systems mitigate this potential vulnerability (if at all)? As I understand, BitLocker can use, but does not require a TPM chip. Is the vulnerability attacking this chip too or just the DRAM? TIA!
Mike Says: “When using FDE, one uses the system BIOS to interact with the disk entering the authentication password. Password is passed to specilized components on disk, hashed, combined with other keys, and then moved to encryption engine.†Correct.
“Do the specialized encryption components contain memory?†Yes, on chip, hidden memory, but the keys are erased even from there in a few ms, after they are transferred to the encryption engine. A similar chilled-RAM attack is not feasible: there is no memory (only protected registers) holding keys.
So, to sum up: You get an access to already mounted encrypted file system and you have to power it off to extract the keys. Wouldn’t just coping file system off contents be simpler?:P
As an “old” technogeek, your paper is fascinating! The impact of your research will likely provide substantial advances to file encryption and computer security in the coming years. Thank you for this.
However, with my years of experience, I always apply this test to new research/technology: What implications does this have in the real world? In this regard, the real question is: What percentage of computers/laptops are stolen/accessed by an intruder while still running? My guess is a very, very small number.
As one example, from prior conversations with airline terminal security, the indications are traveler’s laptops are stolen while in their travel state, either in checked luggage or more likely in a laptop case being personally transported, in which case they are all turned off to prevent damage to the hard drive. I assume this is a similar situation for road travelers as well.
In the case of a business environment, while the computer/laptop may be kept running for long periods of time, including while the owner/operator is absent, the probability of an intruder gaining access to the unit is very limited. Particularly an intrusion that could remove the unit from the premises.
And for the home/home office user, the chance for computer intrusion becomes even more remote while the unit is operating, unless the owner is in a habit of leaving it running 24/7 or possibly turning it on in the morning and off in the evening when finished for the day. This likelihood is becoming more and more unlikely from two perspectives: First, from an environmental and economic perspective, the extended running of appliances is becoming taboo, and saving energy includes turning off computers when not using them. Second, with the laptop become more pervasive, users keep them on battery while roaming around the house, then plug them in again after the battery dies, which has conveniently shut down the system (hopefully not suspending it!). And the vast majority of these home owners don’t even use encryption software in the first place!
Sum and substance, I believe the real world implications for this today are extremely limited. But the long term implications for computer technology, business, and national security are relevant, and particularly for our law enforcement agencies such as the Department of Homeland Security, who I understand was involved in helping to fund this project.
[Note that machines are vulnerable while in “sleeping” or (usually) “hibernation” states. Most laptops are in these states when the user is traveling. — Ed]
Kudo!
What a great piece of work you gents have done.
I am simply floored by the work and the simplicity of how one could recover data, given your scenarios.
I hope you don’t mind but I blogged a little about this today and made reference to your blog, the groups site and the Times article. Congratulations on your work. With your permission, I’d like to add Freedom to Tinker to my blog role.
Best regards
Mark Reichenbach
On the Mark
Not news to anyone who workd on BitLocker.
http://peternbiddle.wordpress.com/2008/02/22/attack-isnt-news-and-there-are-mitigations/
Mr. Hars,
When using FDE, one uses the system BIOS to interact with the disk entering the authentication password. Password is passed to specilized components on disk, hashed, combined with other keys, and then moved to encryption engine. Correct?
Do the specialized encryption components contain memory?, or is it passed on character at a time?
In reference to Tony Lauck’s mentioning FIPS 140-2. Did any of the testing use disk encryption configured to use FIPS 140-2 validated cryptographic modules? I don’t know if zeroisation is done automatically in the compliant cryptographic module or if it is an option that is done by the programmer implementing the cryptographic module. Anyone know?
paul Says: “FDE hardware, even assuming it has no back door, just moves the locus of the attack. If you’re decrypting the data as if comes of the disk, you’ve got those key bits somewhere…â€. Yes. The key bits are computed from the password and from some secrets stored in protected registers, and then moved to the encryption engine, securely erased from RAM. It means, you need to protect a few bytes only, (it is a standard crypto requirement to lose information at the loss of power), and easier than protecting the whole RAM. The registers involved are buried in complex chips, soldered in and protected from tampering (by physical sensors). There is no comparison of the complexity of attacking specialized crypto HW to taking removable RAM modules or rebooting a still warm laptop.
I’m no expert but it seems that with the manufacturers of encryption software having been alerted to the problem, they could implement into their programs a feature in which, immediately after one types a password and hits the enter key, the data representing the password would self-delete or self-corrupt in RAM, irregardless of the state of the RAM, i.e., sleep mode, full shutdown, cooled chip or not cooled, bypass-volume bootups, etc.
This is why I got myself a Data Locker Secure drive.
Some processor architectures, like the SPARC architecture for example, provide general registers that are not saved onto the stack (e.g. %g1 to %g7 in case of SPARC) and support multiple register sets, including one exclusively for the operating system. On these architectures it would be feasible to keep the key permantly in registers which would never be copied into memory.
This is by FAR the most interesting news I have read in the past year. You folks should be very proud of your work.
BTW, if you decide on the C4 implementation, I would STRONGLY advise against purchasing your case tamper microswitches from Radio Shack ! 🙂
One of the important things to consider for some of the proposed countermeasures is the degree to which they could contribute to a denial-of-service attack. Anything that requires a separable dongle or that wipes your RAM at the first sign of trouble could be exploited to destroy the very data you were trying to protect. (In some cases, that risk is preferable to a higher risk of having the data copied, but you have to do the analysis to be sure.)
And of course FDE hardware, even assuming it has no back door, just moves the locus of the attack. If you’re decrypting the data as if comes of the disk, you’ve got those key bits somewhere…
@Hal: In my mention of sleep state (question 3) I misspoke. I intended to say “system shutdown/hibernation” as I had said in question 2. You are right that trying to overwrite memory of a system in a sleep state makes no sense. I probably should have qualified the states with the correct ACPI state (G0-3, S1-4). That and double checked what I wrote.
I’d also point out that a system in sleep state (S1-S3) is simply a powered on system in a power saving mode. This means that in a practical sense the cold boot attack isn’t applicable as the system can be more easily compromised by alternate attacks. If those attacks aren’t effective the cold boot attack could still be used. So the compromise/theft of a system in a sleep mode is the worst of all possible scenarios.
My purpose here is to determine what the real risk profile of this attack is. There may be policy changes that help alleviate the problem in the short term and I would like to determine what those are. I was thinking one of them would be to disallow sleep modes S1-S3 in system configuration as a first step. Or requiring users to by powered down for 5 minutes before removing a laptop from the office. Longer term technical solutions are probably the best solution. But IT security isn’t locked inside the computer case.
@Aaron: I really hope you are kidding when you say, “For instance, when i leave the house I remove my ram, and hard drives and place them within a high-end safe attached to the ground. Oh the safe is also rigged to blow with C4 in the event of tampering…”
I guess you’re hardware is secure but now your house may blow up. So your risk profile in terms of confidentiality is increased but you’ve got some pretty serious availability and integrity issues. Anyone interested in denying you access to your data just has to tamper with your safe.
Have you guys tried this against a full disk encryption software such as PointSec?
There are a few issues here. One is allowing the legitimate owner of the data to control the data, and the other is how to make the data vault absolutely secure.
All the hardware solutions that have been mentioned aim for the later. That, I believe misses the points. The equation given physical access, time, tools and ability, nothing is absolutely secure.
One point I believe is that the tools need to allow the legitimate owner of the data to attempt to do the right thing. If shutdown, power off and wait X number of minutes are required to do that, then that should some with the instructions. One problem here is there is no reliable length of time mentioned to know when it IS safe. If the encryption tool can reliably wipe the RAM based keys at shutdown so that a waiting period after power off isn’t required, then great.
The real point here is that one shouldn’t walk around with data the needs to be secured.
There are as some have mentioned, implications beyond the data on the hard drive. There are the contents of main memory. Many have mentioned that the unexcypted data in memory is at risks to the same technical. This means that just leaving the data on a server and accessing it locally isn’t 100% secure either. If I access a personnel database on a server, I could have conceivable large pieces of that database cached in memory on my laptop.
Also no one has mentioned graphics card memory! OUCH! While there may not be tons of useful data there, it is conceivable that a illegitimate user could cull the image(s) of recent used documents.
Granted hardware solutions covering normal power down do not protect data when memory is ripped out while the system has power. However such solutions allow a responsible user to reasonably protect her/his data. With many of the mentioned hardware solutions, the end user would know that once the computer successful completed a power down that the data were reasonably secure. And even then the responsible user would still place high value on physical protection of the system.
Aaron Says: “It has long been assumed that if an attacker has physical access to a machine it is only a matter of time until you are compromisedâ€. Well, a trillion years of key search on a trillion processor machine performing trillion instructions a second is a “matter of time†for some, foolproof security for others. There is no known faster attacks on FDE (encrypting) disk drives, because the key is not stored anywhere.
“the safe is also rigged to blow with C4 in the event of tampering…†I don’t want to be near your house in case of an earthquake, hurricane or just a minor fire. It is the wrong form of physical security, dangerous and inferior to crypto.
Donald McFarlane Says: “neither the government nor anyone else is supposed to employ torture against the citizenryâ€. We were speaking about criminals, trying to deprive your secrets. They have never been concerned about human rights. At gunpoint I would not hesitate for a second to tell my password or key, would you?
Tom Says: “Seagate’s data recovery division told me they didn’t need a passphrase to recover data from any of their drives or many of their competitors’.†This is not true. What they could have said concerned the ATA password functionality, which was replaced by full disk encryption. They cannot recover a single bit of information from their own drives, without knowing one of the possible several passwords. Please don’t disseminate out-of-date or false information.
This research is clearly food for thought. Yet, the limits of this vulnerability do not end at Whole Disk Encryption. In fact, any security service that leaves a memory cache of its keys is vulnerable to this type of attack.
With the methods of this vulnerability clearly presented, users can now evaluate whether they believe that this type of attack is an actual concern to their active security, or if the risk presented needs to be addressed by the modification of policy or practice. Likewise, I am certain that many of the vendors of this type of technology will be evaluating methods to reinforce their solutions by zeroing the key cache on volume dismount (effective for vulnerability after shut/power down) or through the addition of a hardware based key component.
Should a hardware based key component be added, the liability of attack would then be the responsibility of the user for not removing the hardware based key component, whether it be a USB ROM, or Flash, based device, or other removable key technology.
Donald McFarlane may want to google “waterboarding” some time. And “rendition”, and a few other things (including where the US quietly changed things to allow itself to send anyone, even US citizens, to Gitmo or black sites).
Canada’s a better place to be by far these days. Even then, some other country’s black ops can nab you.
If you keep secrets that are that interesting to governments, you need more extreme security measures, such as hollow teeth with cyanide capsules. (And if you are a terrorist plotting to blow up some famous landmark or something, you should not only have one, but employ it pre-emptively, immediately. :))
Structuring how you do things so that you don’t *need* to keep secrets is another interesting possibility…
I saw something similar to this presented at Black Hat DC last year. Except they were semantically rebuilding the memory image to extract the TrueCrypt keys.
http://www.blackhat.com/presentations/bh-dc-07/Walters/Paper/bh-dc-07-Walters-WP.pdf
Regarding hard drives with built-in encryption, Seagate’s data recovery division told me they didn’t need a passphrase to recover data from any of their drives or many of their competitors’. Someone previously relying on a published implementation (PGP, TrueCrypt, dm-crypt) or even a vendor’s claim of security (BitLocker) may not be comfortable relying on a system with an acknowledged back door.
First off, great work. My congrats to your team.
A few observations/thoughts:
1. The major implication that I can think of initially is that you just changed the way Computer Forensics work will be done, e.g., on a drug raid.
2. Reliance on “secure hardware” is critical. Some very advanced hardware encryption schemes (not to be named) from many (20+) yrs ago had taken into account the potential for a hardware based attack (such as yours). The method used to protect the keys involved a form of tamper proofing the hardware via physical methods (e.g., “this tape will self destruct in 5 seconds”.) Not exactly a commercially available technology (to my knowledge), or at least commonly available.
3. There is a somewhat well known cartoon (from many years ago) of a broken robot, that is being repaired by another robot behind it, that is also being repaired by another robot, that is being repaired by an actual person. Analogy relevance – for any encryption scheme that protects data, the challenge is now reduced to ‘How to protect the keys”. While certainly a smaller problem then say an entire HD, it is non-trivial. So, what is the best method to protect the keys? Well, most would say: Encryption of course. So you protect the keys with encryption, and now how do you protect the keys to that?? So, per the robot analogy, sooner or later something needs to be in clear text, somewhere — and that, of course, is the most vulnerable aspect of any scheme.
4. One possible counter-protection – data (i.e., key) obfustication within the memory. i.e., clear text keys would be reconstructed on the fly via an obfustication algorithm. Clearly, this would impact decryption times. So now the challenge would be to decode the obfustication scheme. (Remember the Robot analogy in 3, above?). Sooner or later…something must be in clear text.
“‘Secure’ is NOT a binary state — it is a continuum.”
—Howard Israel
My approach to address this:
– the framebuffer for the display is usually at a certain address
– on boot, shift this address by a few bytes and have the data show from there
– use the (now unused) bytes for keys, they’ll be overwritten for sure on next boot when the display is initialized
– display RAM isn’t DRAM anymore – most of the time anyway
little effort, doable on every operating system, gains security
this of course doesn’t apply to hardware implementations of disk encryption
Lazlo says “If an attacker is able to rip off your RAM from your machine while you are watching, he could just force you to tell the key. ”
Well, I don’t know what country you are in, Lazlo, but if it’s the US I would remind you that neither the government nor anyone else is supposed to employ torture against the citizenry. And compelling delivery of keys by refrigerating the brain and transferring it to a different reader is still some ways away, as I understand it 😉
In which case, it would be nice to know that your machine is not going to betray you, and although it is easy to assert that this hack is nothing new (and granted, it isn’t) — it is still the case that the publicity which it now has will bring it sufficiently to the minds and to the capabilities of the average investigator that it is now more of a practical risk for an individual defending his data than previously. I’m not decrying the research, quite the opposite in fact, but again I think this calls for an easy means of kicking off a memory clearing routine at a moment’s notice (see my previous comments about the Big Red Button).
Three important notes:
1- This also is a problem because somebody can retrieve your sensitive
files and information from RAM (e.g. cached files), not only encryption keys.
So maybe it’s not necessary to find the encryption key, maybe the attacker
already has the sensitive file cached or loaded in some form in RAM, no need
to decrypt the disk in that case.
2- At the present time this seems a sophisticated attack, but public bootable
CD’s that does all the work will appear for sure, so the skills needed to find
files & encryption keys on the RAM will drop to zero. So this is really a big
issue, maybe already known, but his paper is popularizing it.
3- Please stop commenting “If you don’t have physical security, you are
already compromised”. The point here is that with laptops the best you
can have is _temporary_ physical security (the laptop is with you). Always
somebody can stole it or use it when you are not near.
I am truly impressed. very nice work and thanks for publishing !
Also probably worth mentioning that I used to use this technique 10 to 15 years ago to rip audio samples out of games on my Amiga.
Not sure if this has been posited already, but a viable solutions to this threat would be to create “self-erasing RAM modules” that, for example, contain a capacitor with enough charge to power the RAM past a power-cut for long enough that it can self-erase. Then you could harden this mechanism using some kind of epoxy resin (similar to the way they do with HDCP enabled hardware). The attack would then become much more difficult, but the RAM would also be more expensive.
Thank you for your intriguingly interesting article. While it may worry a lot of people, it just made a nice read for me this morning.
I generally power my laptop off when I’m not using it. Unless someone can grab it right after I switch it off, I think it should be pretty safe.
Where can I get a copy of that unlocking software so I can test it out?
It is a bit like the DMA access through firewire, only a lot better.
For now I will not ever use sleep mode again while my laptop is out of my sight…
hi guys,
thanks for this interresting results.
If I would have phy access to a laptop (like in your video) I would try to
read out the memory WHILE its running think about that… maybe
there ll also be a JTAG connector on board etc…
research this!
Hi,
I thought it was a known problem, but what about write new value on the DRAM section containing the key ?
thks,
James Navarro: yes, we actually first confirmed this phenomenon on my laptop under Ubuntu. Generally, there is nothing about any particular operating system that would prevent memory images from being captured this way. In fact, most of the attack software works without knowing what operating system it’s attacking.
I’ve read all the comments and I’ve seen everything from gluing your ram into your mobo to having special photosensitive ram developed, yet not one post mentioning the fact that physical security of your machine is and always has been one of the most critical aspects of an overall security setup. It has long been assumed that if an attacker has physical access to a machine it is only a matter of time until you are compromised. The headlines of fortune 500 companies loosing data and this paper change nothing about that. Ninety percent of physically compromised laptops were never cunningly stolen, rather careless owners leave them out of sight or unsecured. Physical security is one of the easiest to implement but one of the most often neglected. For instance, when i leave the house I remove my ram, and hard drives and place them within a high-end safe attached to the ground. Oh the safe is also rigged to blow with C4 in the event of tampering… thats security you can bet your bits on.
What if I’m using Ubuntu? Will your memory forensic scientists able to extract anything from my RAM?
Chase Venters Says: “If you are using an encrypted disk, and that disk is mounted (opened), the operating system will have the decrypted key in memory.†It is not the case with FDE (encrypting disk drives)! The key is never in the memory. It is in the disk drive electronics. Mounting the drive needs a password (or some more complicated authentication method), but the password need not be stored in memory, either: just transferred to the drive one character at a time.
psilo Says: “With the machine running, yank the memory…You are now holding the encryption keys IN YOUR HAND.†This is your key, you knew already. If an attacker is able to rip off your RAM from your machine while you are watching, he could just force you to tell the key. Why bother with the RAM? On the other hand, if you leave your running machine unattended, you deserve losing your secrets. Even if the PC is locked, the attacker can still reboot it to DOS, and read the memory, which never lost power.
Jamie Craig Says: “Unfortunately the decryption key for your disk is held in memoryâ€. Not in the case of encrypting disk drives.
Use HW encryption (FDE drives), so no key can be lost! FDE drives cost about the same as dumb drives, so you have high security almost for free, and right now. No need for changing the BIOS, the OS, the crypto SW, the memory bus, the memory chips, the processor, the enclosure…
Pseudonymous Says: ‘it is slanderous to call this a “flaw in encryption softwareâ€. This has nothing to do with disk encryption software’. It is a flaw. The encryption software could and should wipe out the keys from memory when the PC is being shut down or hibernated, so a user need not babysit his laptop for minutes after power down.
Tom Says: “I don’t trust Microsoftâ€. The problem is you must trust somebody. Open source is a nice idea, but it is easy to hide malicious functions in sufficiently complex C code, so I don’t trust open source, either. And how about compilers? Do you trust them not to include backdoor access, masqueraded as debug info.
As far as I know PGP suite unmounts the encrypted partitions when you lock/log off/switch user/sleep your laptop. As for PCs there is a time-based option to do the same thing.
For most devices, the keys should be stored in a proximity memory key, employing a well-encrypted link. That memory should be mapped into the address space. The device could keep a copy of the keys in RAM, but immediately clears the private key when the proximity link is broken.
When you move away from your device, proximity is lost, so the device encrypts memory as necessary (using the public key) and locks its I/O; later, it can hibernate itself using the public key to encrypt.
Proximity can be determined by the round-trip time from the device to the key and back. Passphrases can be entered on the key using squeezes. I should think a simple piezo device could serve to receive the squeezes. And the squeezes could be done in a pocket, thus out of sight of most prying eyes. And IR and UV filters lining the pocket would take care of hidden prying eyes.
This would not solve *all* physical data theft. But it would eliminate a lot of it.
A couple of points on recent comments. When a laptop suspends, there are a few different ways it can go. One is a full shutdown to power off. Another is so-called “hibernation” where the system state is written to the disk and then it is powered off. The third is “sleep” where power is shut off to some parts of the computer, generally including the disks and CPU, but power remains on to the memory. Sleep provides the fastest wakeup time, almost instantaneous. Hibernate takes usually about 15-30 seconds to wake up and load the saved state. Power on from shutdown takes the longest as the system goes through a full boot cycle.
The hibernate and shutdown states are not generally at risk from this attack because the system will have been turned off for a while by the time someone gets access. (There may be a short window of vulnerability for a minute or so after shutdown, but that’s it.) The main risk in terms of a closed laptop is sleep state. In this state the memory retains power and the keys are still there.
Proposals to wipe memory on going to sleep state will not work because the definition of the state depends on memory being intact. That’s why the computer is able to resume instantly. If you write memory to disk, that is hibernation, and as mentioned it is basically immune to the attack but is much slower to resume.
Discussion of threat scenarios is useful but again you need to distinguish between powered-on systems, sleeping systems, and hibernated/shutdown systems. The latter class is immune. Powered-on systems may be vulnerable in people’s offices or homes to attackers who can get physical access. Sleeping laptop systems are probably the biggest class which is vulnerable to this threat. People often travel with laptops in sleep state and they get lost or stolen like this.
It may well be that an acceptable short-term workaround for travelers is to set their laptops to hibernate rather than sleep, and accept the slightly longer delay in getting the computer ready to work when it is opened. This should provide reasonable security against loss or theft of laptops which hold sensitive data on encrypted disks.
I think it has a good side to it.
In current day scenario, if an HDD on a PC crash all data is lost. How about a utility that monitors physical integrity of the disk and when it reaches the threshold the important files get dumped into memory and the memory gets cooled.
Now if the security key is also scrambled leaving another code (following a different Algorithm), stealing data from that memory will not be very easy. We can take this memory and put it into a unscrambling device.
This way we can save some files(very last minute data) from a PC even if the HDD crashes.
I would think that one way to *partially* mitigate the problem would be to store the key in fragments spread across the memory. That would at least prevent the attacker from using the brute-force method of trying every 128-bit section of memory as the key. It still may be possible to retrieve all the pointers that point to the key parts, but it’s at least much harder (especially if there are errors).
Another way I can think of is to “encrypt” the key in memory by xor-ing it serval times with lots of data, hoping that there’d be enough bit corruption in the xor data to make the key not retrievable. To use the key, you would just load it to registers, use it, then discard it.
Ideally, there should be a small amount on SRAM directly on the CPU that should be available to store sensitive data like keys and that would never be written to main memory. I wonder whether there’d be a way to tweak an OS to use a part of the cache for that purpose…
“Today eight colleagues and I are releasing a significant new research”
Oh please. Thats far more than enough self-promotion. While the demonstration is interesting this is NOT a surprising new phenomenon.
http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html (search for random-access). At least Gutmann was cited, although the paper erroneously claims that Gutmann did not anticipate their results, although his paper quite clearly points out that cooling memory will prolong its cell-storage.
The Linux loop-aes file system has long implemented key scrubbing to try to avoid this attack. Here again the paper gets it wrong claiming “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.” But protecting keys in memory is exactly what loop-aes attempts to do.. It’s probably completely ineffective against a cold-recovery depending on the capacitive behavior of DRAM, but it should have been measured.
> This is deadly for disk encryption products because they rely on
> keeping master decryption keys in DRAM. This was thought to be safe
> because the operating system would keep any malicious programs from
> accessing the keys in memory, and there was no way to get rid of the
> operating system without cutting power to the machine, which “everybody
> knew” would cause the keys to be erased.
Is that so ? Superusers (root in most *nixes) could already peek at all
memory locations without a segmentation violation (the OS check
mentioned above).
When we write code, we generally take a hash of the key and keep that in
memory. When we need to compare a user input, we take a hash of that as
well and compare that with the hash we already have. Hence the key is
never ‘en clair’ in memory. disk or CPU registers. Well, I lie a bit,
the user input key is in clear in some buffers for a short time until
the hash operation is performed.
This is how *nix passwords have operated since I have known them (more
than 15 years). The disadvantage is that if you forget the key, there is
no way of getting it back. You have to reset it to a new one.
What about: Linux, Loop-AES and Smartcard Based Disk Encryption?
The idea was proposed by some guys from TuxOnIce:
http://wiki.tuxonice.net/EncryptedSwapAndRoot
A possible solution for safer Suspend-To-Disk and swap space is to encrypt your swap partition using a key that is stored in a external device (token/smartcard). You still need a PIN to unlock this key. After that, when you hibernate the computer the contents from memory that were saved to your swap partition are encrypted using Loop-AES and the only way to decrypt the swapped image or accessing (that contains the key for your TrueCrypt device) is having the smartcard that contains the key and typing the PIN at boot.
I have not tested this method yet, but it seems to solve one of the problems. I have a notebook with a embedded smartcard reader and i will be testing the method and posting the results here.
The method of saving the keys for the encrypted device (Truecrypt, Bitlocker etc.) in a token/smartcard would be safe enough? Any of these solutions alredy have support for tokens?
I think the main question for the whole idea to work is: The libs, APIs and drivers for smartcards are “safe” enough to avoid recovering the PIN used to have access to the keys inside the smartcard at boot? Do the PIN stays in memory for a while? It remains there?
What about programming the kernel to wipe the memory before powering off? This doesn’t protect against hitting the reset button, but it would be something.
This is stunning research and will certainly change the way people think about securing laptops. I can feel Karen Evans writing an addendum to OMB M06-16 as we speak.
I have a few practical questions that I would love to hear more on and then some rambling observations:
1. In a room temperature configuration how long will it take before the memory/configuration with the slowest decay be unable to facilitate key recovery?
2. Could an application (as in kernel mode driver) be used to overwrite memory immediately prior to system shutdown/hibernation?
3. Could BIOS be used to overwrite memory as it is sent into a sleep state?
4. Would either of these be effective countermeasures to this threat?
5. On systems other than BitLocker how effective is the use of a TPM module? Do the keys still get written to main memory and become recoverable by your software?
When I first saw the video and read the paper it seemed like disk encryption was dead. But then I considered the use cases associated with disk encryption. Here are the ones I thought best described the possibilities:
a. Laptop is stolen in an a fully powered on state by someone interested in stealing data on the disk. The cold boot attack isn’t applicable because a competent attacker can bypass system security before shutdown the disk encryption locks them out.
b. Laptop is stolen in a powered up or powered down state by a person with the intent of reselling the hardware and no interest in accessing the data. If it’s powered up it will likely power down long before they resell. Cold boot attack isn’t applicable because the disk will be encrypted and the memory decayed long enough to make recovery impractical by the time it is resold.
c. Laptop is stolen in a powered down state by a person interested in anything of value on the system, physical or memory. Assuming technical competency and the eventual access to programs designed to exploit the flaw you present he will have to steal the system and reach a safe environment before attempting to crack the system. Let’s say that this takes at least 15 minutes, will the memory have decayed enough to make recovery impractical? This is the rationale for question 1.
d. Laptop is stolen in a powered down state by a person interested in the data on the computer specifically. The person would have to be prepared to take advantage of the cold boot attack by knowing how to implement it, having canned air handy and have planned for a way to access the system quickly and unobtrusively before hand. The person will have to get the system, get to a safe environment, crack the case and freeze the memory sticks within ~6 minutes to maintain a 50% decay. (Please feel free to correct me if I am wrong about that time frame)
I don’t know much about laptop theft statistics but I suspect that use cases a, b and c are the most likely scenarios. I would think that a thief would need to be motivated, technically skilled and have foreknowledge of valuable data presence to make the effort worthwhile. How often this happens in laptop thefts is an open question. Does anyone have reliable statistics on this?
That said, I am just thinking out loud. This is a threat that needs to be dealt with and taken seriously. I hope a solution can be found to reduce the risk to laptop’s disk encryption quickly.
I like Gene’s comments, and certainly extensive precautions to mitigate data remanence in DRAM have been commonplace on the government side for decades. Nonetheless, it is interesting to be reminded just how easy it can be to circumvent things.
I am pleased to note that, running Vista with Bitlocker in advanced mode and always hibernating not sleeping, I appear to be in reasonably good shape. I always had regarded it as folly to leave my laptop in its bag “asleep” with keys in memory, not because I had really thought about the lack of complexity of this attack, but just because I recognized it would be possible. Although I would still caution against leaving laptops or PCs unattended, since it is way too easy just to insert a hardware monitoring device, e.g. keylogger. Someone else asserted herein that Mr Felten’s team’s attacks do not lend themselves to a typical office environment: I beg to disagree entirely, they seem to me to be perfect lunchtime or meeting time or fire drill or (whatever) attacks, when people tend to lock the screen and leave.
The two overriding thoughts which I am left with are these:
first, I was interested to note that there is apparently a wide variance in remanence for different chip fabrications, and wonder how long it will be before the market brings (low current drain, preferably) solutions to bear here to reduce or at least to properly specify in the product data sheets the remanence time when powered off, and less trivially but possibly to compensate, or perhaps I should say insulate ;-), somewhat against the vagaries of temperature; and
secondly, this seems to call for a new low level BIOS feature a la Ctrl-Alt-Del or soft power button that acts to immediately run a clearing routine (FFFF,000,random,wash,repeat) against one’s volatile memory. It would be much more convenient to hit one non-maskable hardwired button when nefarious persons start to approach you than to have to hope that Windows is being responsive at that point in time, and kick off the software routine that would require to run, in memory, against itself. This should be a call to arms for the manufacturers to insert just such a “big red button”, and possibly make this a standard and early step in both the hard and soft power off / reset cycles.
Chase:
You’re right, some common platforms use a hardware assist to look in the page tables. IA-64 can turn off hardware assistance, so that a TLB miss raises an exception rather than turning to the page table-handling hardware, but the vanilla IA-32 needs its page tables loaded in memory, and as you point out, the TLB isn’t designed for recovering values stored in it.
Of course, if we’re talking about IA-64 or x86_64, we’ve got a lot of registers available to us, we might be able to hold four of them aside with a modified compiler, but that also assumes you can ensure these registers won’t get pushed to the stack on an interrupt request, or cleared by a context change.
OK, registers, TLB, cache. Is there anywhere else a person can find 256 bits of volatile storage on the die of a modern CPU? Hardware performance counters? You can read those, but I don’t know if you can write them, or turn off their updating.
I read the paper today and was rather depressed that this seems to be all bad news for us folks who value our privacy in that it makes our encryption more vulnerable. Then I saw the bright side: It makes *everyones* encryption more vulnerable including DRM schemes. So even if they do lock us out using DRM you can cool the RAM and get it out of the machine (or just clip on and read it out after power-off of the host system) and read out the encryption keys used by the DRM.
Overall I think this may be a very worthwhile trade. The chances of someone actually performing this attack on my physical hardware while the encryption key for my encrypted volume is in RAM are slim. I keep it unmounted when it is not needed. And they need to have physical access which means they are either feds or really determined crooks.
But my chances of being able to benefit from cracked DRM via this method are great. It only takes one person to do it and millions of people will have access to the hardware.
The old Amiga 500 docs used to tell you to wait at least 30 seconds between powering the machine down and up again for the RAM to clear. Otherwise you risked random Guru Meditation errors.
Considering Schneier’s recent post about seizing computers without powering them down, solving this problem is almost moot…
Christopher:
What architecture are you referring to? I’m pretty sure that at least on x86 (and probably most if not all others), the TLB is filled transparently by the processor itself.
The operating system is responsible for setting the *page tables* from which the TLB obtains its address mappings. That doesn’t help, because the only place to store the page tables is in RAM.
The only direct control you have over the TLB is that you can flush it. On x86, you can only flush the whole thing (which is triggered by writing the page table pointer AFAIK) at a time. Other arches let you nuke individual entries if I’m not mistaken.
OK, let’s say one uses 128-bit encryption keys, maybe having a dozen of them active at once. We need 256 bits of guaranteed volatile memory (128 bits to hold a common XOR key against all of the encoded keys in main memory, and 128 more bits to hold the currently active decoded key).
Is there a way in the OS to set aside a cache line on one CPU, ensure that it is not synced up with L2 or main memory, but can still be read and written to when required?
How about keeping the data in the TLB? The operating system is responsible for filling the TLB, so hold a few aside to store these two 128 bit quantities, and just make sure never to overwrite them. Can the OS retrieve values from the TLB?
You sacrifice cache lines and/or TLB entries, but if either of these techniques is possible, you can do it without modifying the hardware, and I don’t expect that this attack will work against data sitting within one of the CPUs.
Here’s a concern. Microsoft has the ability to ‘push’ updates to laptops in its biweekly update cycle. I’ve observed my Vista computer and it seems that the updates are pushed at night while the laptop is in hibernate state.
If the laptop turns on to contact Microsoft for updates then why couldn’t msft also grab what’s in ram at the same time. Now, substitute the fbi, cia or some agency and you get the idea. The gov’t now scans virtually everything going over the net so it could see the connection to msft and the source ip so this isn’t total paranoia.
I don’t trust Microsoft. I worked in data security for many years and was told by police agencies that the security in Word and Excel etc is easily compromised because Microsoft provides a work-around access key to authorized agencies by phone that works in seconds to read enctypted Office files. I wouldn’t doubt that they have arrangements with security agencies too.
Also, it is slanderous to call this a “flaw in encryption software”. This has nothing to do with disk encryption software in specific, and telling people to “check with the maker of your disk encryption software to find out how to protect yourself” as is done at the end of the video, is sort of like telling people to call Toyota to complain about potholes.
It smells like someone needed to prove they’re worthy of their grant, or is fishing for new ones. Would have expected better from mr. Felten.
Their suggested solution works for the really important files – encrypt them independently with PGP or something. I do this because of the size and slowness of my encrypted data – a 2TB disk takes a long time to back up or defrag so I have to leave the machine powered up for extended periods (24 hours+) while defrags run. So I have a separate password hoarding program, an encrypted “all my software registration keys” file and so on.
What I get out of that is that it’s difficult to get a copy of my files without me noticing, and even if you do it’s unlikely you’ll manage to grab the moz-impersonation data that I really care about. Of course, were I stupid enough to carry that disk (or any of the backups) into the US or UK I could be required to decrypt it all for them, but that’s a different attack altogether.
This is an interesting result, but in practical circumstances it is irrelevant.
Even before this attack it was true that physical access + time = full access, via hadware based attacks which can be as simple as a camera which records the user’s unlock or crypto password.
What this research teaches us is to stick around for a few minutes after you power down your machines, which is something that happens anyway in most cases. And even this is only necessary if you fear three letter law enforcement. Ofcourse it will not work against them anyway, since they can ship you to gitmo if they please, no questions asked.
Oh, and ofcourse, don’t use suspend-to-ram, but this was a silly feature to begin with.
Ed, Alex, et al – compelling work as always.
I’m interested to know if a computer with non-removable RAM and has been set to only boot to the internal drive, such as a MacBook Air with firmware password set running FileVault, would be susceptible to this vulnerability. It seems that if you can’t remove the RAM and can’t boot off another device you shouldn’t be able to get at the key, correct?
Fun read, even if some of the facts are already known about recovering raw data from RAM after powering down. The discussion about finding and reconstructing the keys was very interesting to me.
I’m much more concerned with this type of attack being used on organic computers, such as myself. I am reasonably sure that the application of enough Dust-B-Gone can allow my memory to be removed from its case and installed into a suitable device, such as the frozen head of Walt Disney. From there, extracting keys and other assorted data would be (Donald) duck soup.
I’m considering the proposed solutions, but as usual, they come with other costs and impacts to overall security.
Any method that zeros the ram on shutdown or power loss to the MB wont work because they attacker can just chill the ram and then rip it out without turning off the power.
If you were to put capacitors on the ram chips and use their power to wipe the ram when it loses signal from the mother board, it might help. But it it is possible that the attacker could just rip off the capacitors before they rip out the ram.
My solution is to use the inner layers of a multi layer PCB as a capacitor bank to get power to blank the ram. Cell phones have up to 14 layer PCBs these days, and presumably a ram chip only needs 1-4 layers. This would give you ten inner PCB layers you could use a flat plate capacitors. Just place alternating charges on each layer. Since all the charges are equal, it should not interfere with the ram too much.
Of course the response to this would be to drill a hole in the RAM PCB while it was still running and short the capacitor layers together. So you would have to detect shorts while the ram is still in the MB and use MB power to blank the ram in that case.
If you had a way to mechanically remove the ram chips while the power was on, then you would have to move the capictor into the chip itself, and i don’t see that as being practical.
The DS-5000 by Dallas Semiconductor featured an encrypted memory bus; that particular implementation was weak because the processor needed to be able to read and write bytes individually. Since today’s larger microprocessors have no such requirement, it might be practical to implement a block cipher in hardware between the cache and main memory. Some means would still be required to secure the cache, but adding fail-secure circuitry to that would probably be easier than adding such circuitry to all of memory.
Incidentally, I don’t know about today’s static RAM chips, but some of those of decades past could hold most of their data for a few seconds at room temperature (there was quite a bit of variation).
Marty,
Unfortunately the decryption key for your disk is held in memory too, so potentially *all* of the data on the disk is compromised, not only the information already decrypted in memory.
I only read about half of the 57 comments here, but I got sick of watching 99% of you miss the point entirely. With the machine running, yank the memory; it is probably necessary to disconnect the power connector from the motherboard first, not sure. You are now holding the encryption keys IN YOUR HAND. This problem cannot be fixed in software, people.
Marty:
If you are using an encrypted disk, and that disk is mounted (opened), the operating system will have the decrypted key in memory. So assuming an attacker was skillful and able, they could indeed steal the complete contents of your drive.
Just a thought:
Say I have my laptop operating with whole disk encryption. I use both a very long passphrase and key files. (irrelevant to the discussion, but even so.)
Now, said laptop is seized by a hostile party AND they are able to cool down the memory thus preserving the data in RAM.
The amount of data exposed to the hostile party is still limited. They can only see what was in RAM at the time of the seizure. Say I have my companies full database of customer information, with SSN, addresses, credit card numbers, etc. Unless that data was being used in RAM this attack, while exposing my company and myself to some damage, is LIMITED.
I may not be happy with the result, but using whole disk encryption has limited my exposure and that of my client significantly.
Just my 0.02 worth. 🙂
Ed
Bruce Schneier wrote about the fact that the contents of RAM can be recovered once a PC has been shut down within his book which is entitled; ‘Secrets And Lies : Digital Security In A Networked World’ although I cannot remember the exact page he wrote it on.
It has been known that it’s possible to do so for many years. I have been overwriting the contents of my RAM via a utility for some time.
http://www.schneier.com/book-sandl.html
Another angle of vulnerability: “hot-swap BIOS”. I have a friend that has claimed to successfuly reflash a fubared BIOS chip by hot swapping it into a running board. So in theory, even if you configured your system to clear the RAM during POST, someone could swap in a BIOS chip that would do their bidding instead.
If the encryption system came with a hardware dongle or a random code written to a thumb drive, then only half of the key would be left in RAM. A code written to a thumb drive would probably be better because it can be modified or rewritten on another thumb drive if the first one became lost. Put the thumb drive on a cord around your neck and whenever the laptop is separated from you the thumb drive component of the encryption would be missing. Can’t have one without the other. Best of all, no hardware changes to the computer. It would require all the encryption schemes to add an option on their next version of their software. Downside is that you loose the use of one USB port.
I freely admit to not having read all the 50 comments before me, but one simple solution is to have a independant battery powered circuit attached to the memory modules. When the memory cover is lifted off, a photo detector notes this and a resistor heats up the modules and in seconds the memory wiped. This is easy to bypass when you want to upgrade.
A simpler solution is to glue the memory modules to the motherboard, alternatively glue the memory cover to the case.
Another practical application for acquiring RAM after rebooting was mentioned at ForensicZone.com. The “Guillotine Method†runs on the following idea. Instead of pulling the power cord from the back of the machine, pull the power cord from the back of the hard drive running the OS, thereby stopping all writes to the drive. Then (fast as possible) reboot the machine into your favorite flavor of Knoppix (Command Line Mode) and dd the RAM Memory to USB. This attack can work against a Vista System (running Bitlocker) even at the Log-In Screen allowing the possible capture of SAM and SYSTEM Files.
(sorry Hal, didn’t realize you were talking about flushing the key and not all RAM)
What about being more judicious with the use of encryption? For example, I use AES-encrypted disk images on the Mac and only open them when I need access… obviously, this isn’t much of a solution for people that need to encrypt lots of stuff.
Hal: I think clearing RAM on sleep would defeat the notion of sleep (you could write it to disk, but then sleep isn’t as snappy as it has been and you’re writing the key in the clear to disk). Plus, what you’d really want is essentially “instantly-degrading RAM” that would reset the second power is off (and not be susceptible to temp. effects)
very very cool. Bravo!
Further note —
The “key stored in CPU” used to encrypt RAM, or used to encrypt the disk key stored in RAM, need be nothing more than some randomized values in a few registers that are then preserved. All access to the encrypted data would then make use of the randomized values.
The randomized memory encryption key stored in the CPU can be recreated on every boot of the system–there is no need to preserve it over time. Its purpose is simply to make memory unreadable.
Plainly the DRAM threat goes beyond just disk encryption. Presumably you encrypt your data because it is sensitive, and presumably you have a use of that data so it is sometimes loaded into RAM. For example, you might view a sensitive document–at that point, it too is in RAM.
Even were the disk encryption key problem resolved somehow the attacker could still use this technique to recover data the user had thought was secure. Recovering the key simply allows the attacker to recover ALL the data, rather than only the data in RAM.
In that light even using a hard-drive with built-in encryption would not help, because your sensitive materials would still be in RAM.
I think what is needed is, in addition to disk encryption, RAM encryption. The OS should be able to mark a sensitive document as sensitive, and all accesses to that segment of memory should be encrypted. This would obviously slow down the memory accesses, but such may be the price of security.
The key used to encrypt RAM is tricky but I guess this would have to be stored in the CPU.
An aside–if a long key is needed to decrypt data, even without the above scheme, a short key could be stored in the CPU, and the short key could be used to decrypt the long key. Thus the long key data would reside in RAM but would be encrypted there–accessing it would require use of the short key stored in CPU memory.
If you can resolve that problem, though, you might as well extend the solution and have all sensitive data encrypted in RAM in the same manner.
I think Justin Wells was onto something by suggesting encrypting both the RAM and HDD data. However, you could store the key used to decipher the RAM in virtual memory which is already encrypted on the HDD. This ensures that both keys are encrypted by each other, and interdependent. That way there is no chance of a key being compromised by any method other than a cryptanalysis attack, which is exactly the kind of attack that these methods are meant to avoid. Perhaps, there is some logical reason that you can not encrypt both keys at the same time, but if not, then this would seem to be the simplest and most effecting way of mitigating a cold boot attack. It would also work on existing hardware. The only consideration is in getting the two encryption functions to work in tandem so that neither key is accidentally lost or corrupted. Passing the keys to the CPU caches at specific intervals could safeguard against this. However, that opens up the possibility of SRAM remanence, but it would be hit or miss for an attacker wishing to utilize it. This would, at the very least, increase security ever so slightly; which is a good thing. Another option might be to store a key used only to decrypt the key used for decrypting the DRAM on the CPU. Because the DRAM key resides on an encrypted volume, it would be virtually impossible to find the key to decrypt even if you had the key to decrypt it with; especially given the nature of virtual memory. You could even load the system with false positive keys that would only decrypt certain files & the operating system, which gives an attacker a false success. These methods would obviously impose a performance hit, but in situations where secrecy is crucial, it might be worth it.
What about soldering all RAM onto main board and forcing BIOS to to full memory test on every boot-up?
I agree that I don’t feel any more vulnerable to attack as a result of this.
Isn’t the most compelling use of this technique in defeating attempts to lock your own computer against you (I’m talking about DRM measures)?
Just asking.
I wonder if the effort to impose security on boot up aren’t approaching the problem from the wrong end–what about having some over-writing occur on power down?
Of course, I assume that the attacker wouldn’t necessarily power down the system through the OS, but unplug-it.
This would require some special hardware, I would think that would be able to execute code upon detection of power down.
You wouldn’t necessarily have to complete zero the contents–a certain amount of scrambling would do enough damage to the data, right?
Joshua, if you read the full article, you’ll see that the RAM does not need to be booted in your system. Someone could theoretically walk in, detain you, open your PC case, chill your RAM, pull it out and boot it in some specialized hardware they may have available. Not that something like this happening is common place, but still very possible.
Unintended retention of cryptographic materials has long been a threat known by intelligence agencies. They have a term for removing this information: “Zerosation”
See http://en.wikipedia.org/wiki/Zeroisation
FIPS Pub-140 places requirements on encryption devices used in providing various levels of protection. This document specifies when zeroisation must be used.
See http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
I suggest that you update the paper to cite FIPS 140.
What about the fix suggested above, not to clear the key on screen-saver lock, but to clear the key on sleep (plus hibernate and shutdown of course)? Surely the great majority of computer thefts are laptops, and the great majority of laptop thefts would find the system in a suspended state. You’re going to want to ask for the password again anyway on resume from any of these states. Isn’t this an easy fix that addresses 90% of the problem?
Joshua,
Actually, that countermeasure isn’t enough. An attacker could still remove the DRAM and transplant it into another computer that has a friendlier BIOS.
A simple way to deter these sort of attacks would be to not accept USB boots and lock the bios.
Jeff Tyrrill Says: “…clearing the key from memory when the computer is screen-saver locked but still powered up… This is not possible, as the operating system and processes keep running while the computer is locked.†The disk encryption key can be erased, if the screen saver, log-on process, etc. run in memory. Preventing disk accesses there is not a trivial change to the OS, though.
as Ed Felton said…Dram remanence has been known about for a long while…. SRAM remanence is harder but it exists… I’ve heard SRAM may also be induced to have power-on preferences through extended V and T.
The real issue revealed by the paper is not weaknesses in disk encryption software, but a cheap way to go around DRM, and code privacy. You run the protected code, like a DVD player or a game in one PC, freeze and move the RAM to another machine (can be the same one rebooted to DOS), where you can analyze the memory at your leisure. You can disassemble protected code, find media keys, etc. It is simpler and cheaper than using high speed, logic analyzers on memory lines.
Seth,
Assuming SRAM state can be retained, I doubt an invalidated cache is any more secure – a valid or invalid cache line is simply indicated with another SRAM bit, and not necessarily by destroying the actual contents of the cache.
I’m going to +1 Laszlo here. Any claims of security should be, by nature, understood to have limitations and caveats. On-disk encryption protects against certain attacks, in particular someone getting access to the disk — the surface, or via the disk heads. In this attack, someone must gain physical access to the device, be able to either disassemble it or act on it within minutes, or bring the appropriate pieces to near cryogenic temperatures within those minutes in order to prolong the retention, then be sufficiently technically sophisticated to extract the keys and then read the disk.
It would seem the conditional probability of success over this chain of events is pretty small; thus the actual risk would be relatively small.
Should this be considered for TOP SECRET or SECRET? Sure, there the hazard is large. For common data, where the actual hazard is tens or hundreds of thousands of dollars? not so clear.
I’m not an EE, but I wonder if it would be easy / cheap to develop ‘secure DIMMs’ that would open the RAS/CAS wide and drain all the capacitors to some load the moment power loss occurs? The solutions that rely on motherboard / power supply capacitance to give the CPU a chance to clear the keys ignore the possibility that someone simply yanks the DIMMs out of a running system.
Several posts have suggested clearing the key from memory when the computer is screen-saver locked but still powered up.
This is not possible, as the operating system and processes keep running while the computer is locked.
Brad,
We’ve heard these rumors too, but we couldn’t find anything in the published literature. Our study goes into considerable depth in evaluating the usefulness of these methods today, and in considering countermeasures.
Dan Bodoh: check out the paper by Skorobogatov cited in our paper; it reports retention in SRAMs at room temperature. An electrical engineer has explained the physical basis of this to me, although I do not entirely understand the explanation (it is somewhat more intuitive to understand for DRAM retention). If you have an SRAM somewhere outside of your CPU cache, you may be able to reproduce Skorobogatov’s result. 🙂
There are probably retention effects in CPU caches, but whether they can be exploited for anything does seem to depend crucially on whether the CPU (or firmware?) invalidates the cache before attack software could potentially read those caches.
Sorry, Ed, I’ve been hearing about this technique since the 90s. It’s not new. Rumour is that spooks have been using it for some time.
Here’s an old message board threat a quick google search found…
http://www.madisonlinux.org/pipermail/madlug/2003-October/007264.html
A solution touched on by “xxx” would be to overwrite the memory containing the decryption key whenever the computer is locked/suspended/slept. The user is (or should be) required to re-enter their password when accessing the computer again, which would unlock the disk at the same time without undue burden on the user.
This seems trivially easy to implement for the OS-integrated protection such as BitLocker and FileVault. The only circumstances under which the disk would still be vulnerable is power removal when still logged in, but at that point an attacker has full access to the system anyway.
Bart van Deenen – Just what I was thinking! In fact, since power supply filter caps store enough energy for a few milliseconds operation, the power-down IRQ could potentially be generated as soon as the system senses the power switch or loses the AC line connection. This would require mods to the PC hardware and BIOS though, so it’s no immediate solution.
Dan Bodoh – SRAM retains some data through a power cycle as well. I can remember an old machine I had that used SRAM for video memory. If I cycled power on it, the previous contents of the screen would still be there before the thing cleared it during the subsequent reboot. This effect could be observed even hours later.
Basically all these suggestions are interesting but don’t work on current hardware, which I think was Ed’s point.
Nick and Dan: Need some SRAM? Check your video card, if it is one that has its own video frame buffer space. Some of them use SRAM for higher speed.
Nice results, although not quite as surprising as it seems. For instance, the effect of cold on memory has been known for a while as a vulnerability for keys in DRAM (cf. the papers on the IBM 4758 secure co-processor, for example). There are also hardware methods of reading the memory if you can get to the board without shutting down the system.
The key is also vulnerable to root kits, trojan software with privileges to read memory, and other software attacks.
People who think that encryption is equivalent to security are always surprised by results like this. They should go (re)read Thompson’s “Reflections…” piece. 🙂
I don’t see how this chilled-RAM attack increases risks under normal circumstances. If the user is at the PC, the attacker cannot access the RAM unnoticed. When the user leaves, the attacker has a few seconds to run to the PC left alone, to boot into a malicious OS (from CD or external disk) and search for a key left in RAM. It can be a problem in public computers (library), but there you should never expose any secrets. In workplaces this attack is unrealistic. Maybe at unattended servers, where the attacker can get a memory dump this way? But he does not have to cold boot: just reboot from CD. The RAM content stays intact. The only danger is when you switch off your PC and immediately walk away. This is bad practice, anyway, because the PC sometimes hangs during shut down, so you always have to make sure that the PC is completely powered down.
However, it has been recommended for ages that encryption keys are never stored in RAM. They have to stay in a locked part of the processor cache. It was not because of the chilled-RAM effects, but because of virtual memory (swap file), or hibernation. The OS might write any info from RAM to disk, where an attacker can find it later. It is surprising that BitLocker does not follow this practice. TrueCrypt is known to be weak both in the choice of algorithms and their implementation (an example is their recent choice to implement the IEEE P1619 encryption standard meant for completely different type of applications).
billb says: “These products should scrub their keys when the machine is asleep, hibernated, or locked.”
I would add: … or when it is being powered down. This simple precaution would have prevented breaking these SW disk encryption products. Still, encrypting disk drives are safer: accessing their key store requires much more work: disassembling the drives, freezing the controller chip, shaving off its cover, inserting micro-probes or ion-implanted contacts, etc., which requires multi-million dollar investment.
“This is deadly for disk encryption products because they rely on keeping master decryption keys in DRAM.”
It would seems simple to insert malicious code into an exploitable kernel to extract the keys.
Tomas, the technical term is, ASS-U-MEing, I believe. Everybody assumed the
memory would clear on powerdown. Well, turns out it just doesn’t fade quickly
enough. Whoops.
Thinking about it for two seconds; implement quick encryption of the cpumemory bus for at least a “safe” storage for such things, possibly
anything that doesn’t need to be written to disk, and keep the key only in the cpu.
That requires cpu support and extra logic on its memory bus, so it’s not an easy fix. But once implemented in the cpu, it’s a drop-in replacement in hardware, then add software support.
I will do the easier thing first and venture to read the paper. 🙂
As an imperfect solution, an OS could provide a service that carved out a small portion of the CPU cache or elsewhere on the CPU for a “master key” and provide an API where programs that needed to store encryption keys in RAM could have them encrypted by the master session key before storage and decrypted on-demand. Even better if the OS could guarantee that the clear-text keys never resided in RAM for more than a fraction of a second, if at all. On computers where there is on-CPU storage that is not “forced” back to RAM without an OS-veto, this can be done today.
No big surprise. I’ve read multiple articles before about being able to actually recover even previous generations of RAM data with special equipment. So it’s not terribly surprising that the current data set lives longer than people expect. Also, ages ago on my old PC/XT, I was typing a paper when we were hit with a 3-4 second power outage. When the power came back on I was quite surprised that the computer resumed right where it left off! I figured it was just capacitance in the power supply supplying just enough power to keep the RAM alive (even though the drive spun down).
Would something like memtest86 do for RAM what shred etc. does for physical drives? I.e. if one would reboot into memtest wouldn’t the contents of the RAM chips be overwritten multiple times with fairly random data?
Alan, Ed:
SRAM is a fundamentally different circuit than DRAM, so it’s unlikely that this will work. A DRAM bit is a capacitor, which, by its nature, stores charge without requiring a power source. However, because the capacitor is leaky, it must be refreshed often.
An SRAM bit is a two inverters feeding each other. Without power, there’s no storage of data. I suppose that there might be some parasitic capacitances in the bit, but they’d be much smaller than the purpose-designed DRAM capacitor.
@dave-O: “Another strike against suspend-to-RAM”
No. Nothing prevents encryption code from clearing the passphrase from memory on suspend. Indeed, it *should*, just as the desktop will require re-login from screensaver and keychain will forget its keys.
wow interesting read
still not yet sure i can believe it
but if this is true, how comes the design has such an apparent weakness?
i mean, people readily care about destroying data on hdd but i cant recall anyone bothering about the ram at all…
Don’t a lot of brownout/reset chips generate an interrupt when the power goes off? In that case, grab the irq (preferably an nmi), and wipe the relevant bytes. Should be quite doable in its last remaining gasps of activity.
Ed, I don’t see how that addresses what I wrote. There’s a difference between getting physical access while the computer is on and getting that access by stealing a powered off machine (say while it’s turned off in your bag). If you’re regularly leaving your drive-encrypted laptop lying about powered up and unattended, that’s irresponsible. If the disk encryption folks don’t let you automatically lock the drive (and scrub the key from RAM) when you lock the screen-saver, that’s bad, too.
I personally don’t keep my laptop iced down, so this only seems to be a worry for attackers who can get access to a powered up and unlocked machine.
BTW, I enjoyed the paper and think it’s good work, but I don’t think the circumstances are as dire as you suggest in your blog post (the paper itself seems less dire). Clearly one should lock one’s encrypted drive when one locks one screen-saver. If these products don’t make that easy, good on you for calling them out on it. But to say that there’s no easy fix seems to over state the case to me. There’s no reason to keep the encrypted drive unlocked and mounted when not in use by the user. These products should scrub their keys when the machine is asleep, hibernated, or locked. If these simple precautions are taken, I don’t see what concerns remain.
For a fact seems that online offers are very often the right choice.
Any case to itself you know, but selling software systems might do the job with a strong machine and server which will be protected from attacks and backup for data at rest. Well protection on device is necessary.
This sounds like computer needs a battery-backed chip that erases memory after power is cut off.
Full Disk Encrypting (FDE) hard drives perform the encryption in hardware directly on the hard drive, using a key that never leaves the drive. Such FDE drives are protected against this attack on off-drive encryption.
Another strike against suspend-to-RAM, I suppose. One way to protect against this method is to power down the laptop prior to allowing it to leave your personal possession. At operating temps, the values in the RAM would be gone by the time an attacker had the chance to read them. A laptop is suspend mode, however, will provide the attacker plenty of time to cool the chips prior to cutting power and attempting to read them.
Nick,
I don’t know for sure. I would guess the CPU marks cache lines as invalid on boot, which would prevent a problem. But only experiment, or careful datasheet reading, can give a sure answer.
The moral of the story: for maximum protection, shut down the computer when you are not present.
Perhaps during shutdown, a small resident memory-eating program could be executed after the disk is unmounted, to overwrite memory prior to power-off.
Does a similar attack work for SRAM cache memory in the CPU?
I should have guessed as much. Rats.
Well, I shall have to read the paper carefully. I’m glad you and your colleagues chose to publish it online, freely available.
Avi,
As we explain in our paper, even that isn’t enough. An adversary can remove the chips from the target computer and transplant them into another computer that doesn’t overwrite RAM on startup.
Well, that’s rather…unsettling.
Question: if the system firmware were reprogrammed so that it overwrote RAM with zeroes on startup, before booting an operating system, could this hole be closed? Or is that infeasible? Would it even work?
Are there solutions for this that wouldn’t impose a possibly-unworkable burden on the user, say some kind of two-level scheme where a less-sensitive working set is available through a key that does persist in RAM, and the rest of the disk is encrypted with a volatile key?
Obviously persisting keys could be protected by some kind of security-through-obscurity mechanism (e.g. by having part of the key on a removable dongle) but ultimately that would get you only so far. Nice work.
Billb,
The whole point of disk encryption is to protect file contents if an adversary gets physical access to the computer. Our results show that most file encryption systems don’t actually provide such protection, even if the adversary has no advance information (e.g., no knowledge of the user’s password).
If the attacker has physical access to the system when it’s powered up, I’ve always assumed all bets are off. Given that the attacker may have already captured the user’s login password, they can certainly bypass the screen-saver lock, so they could easily have access to the mounted encrypted drive via that mechanism. If these products don’t ditch the keys when the screen is locked, perhaps they’ll start doing that in the future. If someone manages to access an unlocked, unattended machine, shame on whoever walked away from it. Presumably these encrypted partitions are never made accessible over the network (i.e. as a share), so they don’t need to be accessible when the user isn’t there. If the user has to re-type their disk password when they unlock the screen-saver, I suppose that’s the price we need to pay for this level of security.
Cheers, I guess sharepoint java can get us some Freedom at the Disk Encryption with Microsoft’s packs.
I don’t like cold boots at the summer despite all 😉