cold boot attacks on disk encryption
Ed Felten blogs on his latest research: http://www.freedom-to-tinker.com/?p=1257 Excerpt: 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. More info: http://citp.princeton.edu/memory Paper: http://citp.princeton.edu.nyud.net/pub/coldboot.pdf -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
interesting paper. but i fail to see how this could be "deadly" (as the author puts it) to the disk encryption products. This methods requires the computer to be "recently" turned-on and unlocked. So the only way it would work is that the victim unlocks the disks i.e. enter their preboot password and turn off the computer and "immediately" handover (conveniently) the computer to the attacker so that the attacker remove the DRAM chip and store in nitrogen. And the attacker has to do all this in less then 2 seconds :) If the attacker is standing right next to the victim, why even let the victim turn-off the unlocked computer Or am I missing something? -- Saqib Ali, http://www.full-disk-encryption.net On 2/21/08, Perry E. Metzger <[EMAIL PROTECTED]> wrote: > > Ed Felten blogs on his latest research: > > http://www.freedom-to-tinker.com/?p=1257 > > Excerpt: > > 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. > > More info: http://citp.princeton.edu/memory > > Paper: http://citp.princeton.edu.nyud.net/pub/coldboot.pdf > > > > -- > Perry E. Metzger[EMAIL PROTECTED] > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] > - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
"Ali, Saqib" <[EMAIL PROTECTED]> writes: > This methods requires the computer to be "recently" turned-on and unlocked. No, it just requires that the computer was recently turned on. It need not have been "unlocked" -- it jut needed to have keying material in RAM. > So the only way it would work is that the victim unlocks the disks > i.e. enter their preboot password and turn off the computer and > "immediately" handover (conveniently) the computer to the attacker so > that the attacker remove the DRAM chip and store in nitrogen. LN2 is pretty trivial to get your hands on, and will remain happy and liquid in an ordinary thermos for quite some hours or longer. However, the authors point out that canned air works fine, too. > And the attacker has to do all this in less then 2 seconds :) No, they may even have minutes depending on the RAM you have. > Or am I missing something? People readily assume that rebooting or turning off a computer wipes RAM. It doesn't. This is just more evidence that it is bad to assume that the contents of RAM are gone even if you turn off the machine. Perry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
On Thu, Feb 21, 2008 at 12:10:33PM -0500, Perry E. Metzger wrote: > > Ed Felten blogs on his latest research: > > http://www.freedom-to-tinker.com/?p=1257 > > Excerpt: > > 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. While they did have some success with recovering an entire AES key schedule uncorrupted, it seems important to note that the simplistic nature of the AES and DES key schedules allowed them to recover the entire original key even after the state had been somewhat degraded with only moderate amounts of work. A cipher with a better key schedule (Blowfish or Serpent, for instance) would seem to offer some defense here. Jack - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
After thinking about this a bit, i have changed my views on this attack. i think it is quite easy to perform this attack. i myself have been in similar situations, where my personal computer could have been easily compromised by this attack However, the hardware based encryption solutions like (Seagate FDE) would easily deter this type of attacks, because in a Seagate FDE drive the decryption key never gets to the DRAM. The keys always remain in the Trusted ASIC on the drive. On Thu, Feb 21, 2008 at 11:51 AM, Perry E. Metzger <[EMAIL PROTECTED]> wrote: > > "Ali, Saqib" <[EMAIL PROTECTED]> writes: > > This methods requires the computer to be "recently" turned-on and unlocked. > > No, it just requires that the computer was recently turned on. It need > not have been "unlocked" -- it jut needed to have keying material in RAM. > > > > So the only way it would work is that the victim unlocks the disks > > i.e. enter their preboot password and turn off the computer and > > "immediately" handover (conveniently) the computer to the attacker so > > that the attacker remove the DRAM chip and store in nitrogen. > > LN2 is pretty trivial to get your hands on, and will remain happy and > liquid in an ordinary thermos for quite some hours or longer. However, > the authors point out that canned air works fine, too. > > > > And the attacker has to do all this in less then 2 seconds :) > > No, they may even have minutes depending on the RAM you have. > > > > Or am I missing something? > > People readily assume that rebooting or turning off a computer wipes > RAM. It doesn't. This is just more evidence that it is bad > to assume that the contents of RAM are gone even if you turn off the > machine. > > Perry > -- Saqib Ali, CISSP, ISSAP http://www.full-disk-encryption.net - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
On Thu, 21 Feb 2008, Perry E. Metzger wrote: > > "Ali, Saqib" <[EMAIL PROTECTED]> writes: > > This methods requires the computer to be "recently" turned-on and unlocked. > > No, it just requires that the computer was recently turned on. It need > not have been "unlocked" -- it jut needed to have keying material in RAM. Indeed. Given the recent discussions of border searches of laptops, I wouldn't be surprised to see this technique used against locked laptops in suspended mode. The idea that data in RAM doesn't automatically disappear the instant the computer is powered off isn't the really interesting thing in this paper, though, at least for me. I'm more intrigued by the error-correction techniques they use to apparently recover AES keys that have degraded by up to 10% of their bits. It would be nice if the authors released their tools so that other researchers can build on this. --Len. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
"Ali, Saqib" <[EMAIL PROTECTED]> writes: > However, the hardware based encryption solutions like (Seagate FDE) > would easily deter this type of attacks, because in a Seagate FDE > drive the decryption key never gets to the DRAM. The keys always > remain in the Trusted ASIC on the drive. I'm sure that the same sort of attacks used to get keying material out of other ASICs and out of smart cards could be applied to the ASICs on the drive controller board. No one has tried yet, of course, but I see no reason they wouldn't succeed. Perry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
Hi, I'm one of the coauthors of the paper and I'd love to chime in. Perry E. Metzger wrote: > "Ali, Saqib" <[EMAIL PROTECTED]> writes: >> This methods requires the computer to be "recently" turned-on and unlocked. > > No, it just requires that the computer was recently turned on. It need > not have been "unlocked" -- it jut needed to have keying material in RAM. > This is correct. >> So the only way it would work is that the victim unlocks the disks >> i.e. enter their preboot password and turn off the computer and >> "immediately" handover (conveniently) the computer to the attacker so >> that the attacker remove the DRAM chip and store in nitrogen. > > LN2 is pretty trivial to get your hands on, and will remain happy and > liquid in an ordinary thermos for quite some hours or longer. However, > the authors point out that canned air works fine, too. > Yes, this is also correct. Canned air is often found in server rooms. An attacker might not even need to bring anything with them to leverage this attack. >> And the attacker has to do all this in less then 2 seconds :) > > No, they may even have minutes depending on the RAM you have. > This is an important point. Without cooling, it's not merely a matter of a second or less. This is a common misconception that even in light of new evidence is difficult to believe. I think reading our paper and understanding our graphs should help with this. >> Or am I missing something? > > People readily assume that rebooting or turning off a computer wipes > RAM. It doesn't. This is just more evidence that it is bad > to assume that the contents of RAM are gone even if you turn off the > machine. Yes. General purpose memory isn't a safe place to store keying material and software countermeasures are a step behind. Even with obfuscated key schedules or strange byte ordering, the physical properties of the memory chips are going to be difficult to overcome. As our paper states: "There is no easy solution to this problem." I'm happy to field questions if this is the proper forum. Best, Jacob Appelbaum - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
[EMAIL PROTECTED] (Perry E. Metzger) on Thursday, February 21, 2008 wrote: > >Ed Felten blogs on his latest research: > >http://www.freedom-to-tinker.com/?p=1257 > >Excerpt: > >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. > >More info: http://citp.princeton.edu/memory > >Paper: http://citp.princeton.edu.nyud.net/pub/coldboot.pdf Their key recovery technique gets a lot of mileage from using the computed key schedule for each round of AES or DES to provide redundant copies of the bits of the key. If the computer cleared the key schedule storage, while keeping the key itself when the system is in sleep mode, or when the screen-saver password mode kicks in, this attack would be less possible. If, in addition, the key was kept XORed with the secure hash of a large block of random memory, as suggested in their countermeasures section, their attacks would be considerably more difficult. These seem to be simple, low overhead countermeasures that provide value for machines like laptops in transit. Cheers - Bill - Bill Frantz| The first thing you need when | Periwinkle (408)356-8506 | using a perimeter defense is a | 16345 Englewood Ave www.pwpconsult.com | perimeter. | Los Gatos, CA 95032 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
On Feb 21, 2008, at 12:14 PM, Ali, Saqib wrote: However, the hardware based encryption solutions like (Seagate FDE) would easily deter this type of attacks, because in a Seagate FDE drive the decryption key never gets to the DRAM. The keys always remain in the Trusted ASIC on the drive. Umm, pardon my bluntness, but what do you think the FDE stores the key in, if not DRAM? The encrypting device controller is a computer system with a CPU and memory. I can easily imagine what you'd need to build to do this to a disk drive. This attack works on anything that has RAM. Jon - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
Ali, Saqib wrote: > After thinking about this a bit, i have changed my views on this > attack. i think it is quite easy to perform this attack. i myself have > been in similar situations, where my personal computer could have been > easily compromised by this attack Usually when doing a demo of this attack, people change their minds quickly. I'm pleased to hear that in actual use cases you acknowledge an actual problem. > > However, the hardware based encryption solutions like (Seagate FDE) > would easily deter this type of attacks, because in a Seagate FDE > drive the decryption key never gets to the DRAM. The keys always > remain in the Trusted ASIC on the drive. > While riding the BART this morning, I ran into Nate Lawson (from Cryptography Research). He mentioned that he felt people would reply with such endorsements. I'd like to take the time to disagree with endorsing hardware products as a solution. Hardware solutions are going to be hard to attack in some circumstances. But they may in fact be worse without fully viewable (or Free) source software (for the firmware, the FPGA or the layout of the ASIC, etc. A great example of some so called "unbreakable" hardware disk crypto is this snakeoil: http://it.slashdot.org/article.pl?sid=08/02/19/0213237 http://www.heise-online.co.uk/security/Enclosed-but-not-encrypted--/features/110136 "A new generation of inexpensive disk drive enclosures using hardware encryption and RFID keys do not fulfil the promises of their publicity. The adverts claim 128-bit AES hardware encryption, but they don't tell us how it is used." Without transparency, I'd rather stick with software. It has issues, we now know about another one. Regards, Jacob Appelbaum - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
"Ali, Saqib" <[EMAIL PROTECTED]> writes: > How about TPM? Would this type of attack work on a tamper-resistant ver1.2 > TPM? The phrase is "tamper resistant", not "tamper proof". Depending on how determined your attackers are, pretty much anything depending on tamper resistant hardware will fall. As always, the question is whether what you are protecting is worth more than the attackers would have to spend on the attack. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
wrt Cold Boot Attacks on Disk Encryption
From:David Farber <[EMAIL PROTECTED]> Subject: [IP] Cold Boot Attacks on Disk Encryption -- report on To: "ip" <[EMAIL PROTECTED]> Date:Thu, 21 Feb 2008 16:25:43 -0500 Begin forwarded message: From: Declan McCullagh <[EMAIL PROTECTED]> Date: February 21, 2008 3:57:43 PM EST To: [EMAIL PROTECTED] Cc: Jacob Appelbaum <[EMAIL PROTECTED]> Subject: Re: [IP] Cold Boot Attacks on Disk Encryption Dave, The paper published today makes some pretty strong claims about the vulnerabilities of Microsoft's BitLocker, Apple's FileVault, TrueCrypt, Linux's dm-crypt subsystem, and similar products. So I put the folks behind it to a test. I gave them my MacBook laptop with FileVault turned on, powered up, encrypted swap enabled, and the screen saver locked. They were in fact able to extract the 128-bit AES key; I've put screen snapshots of their FileVault bypass process here: http://www.news.com/2300-1029_3-6230933-1.html And my article with responses from Microsoft, Apple, and PGP is here: http://www.news.com/8301-13578_3-9876060-38.html Bottom line? This is a very nicely done attack. It's going to make us rethink how we handle laptops in sleep mode and servers that use encrypted filesystems (a mail server, for instance). - -Declan Jacob Appelbaum wrote: > With all of the discussions that take place daily about laptop > seizures, > data breech laws and how crypto can often come to the rescue, I > thought > the readers of IP might be interested in a research project that was > released today. We've been working on this for quite some time and are > quite proud of the results. > Ed Felten wrote about it on Freedom To Tinker this morning: > http://www.freedom-to-tinker.com/?p=1257 - --- Archives: http://www.listbox.com/member/archive/247/=now RSS Feed: http://www.listbox.com/member/archive/rss/247/ Powered by Listbox: http://www.listbox.com -- - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
i think in most cases tamper-resistant is sufficient - provided the device that can detect an attempt of tampering, and erase itself. DRAM chips referred to in this attack are not tamper-resistant. http://www.linkedin.com/in/encryption On Thu, Feb 21, 2008 at 2:59 PM, Perry E. Metzger <[EMAIL PROTECTED]> wrote: > > "Ali, Saqib" <[EMAIL PROTECTED]> writes: > > > How about TPM? Would this type of attack work on a tamper-resistant ver1.2 > > TPM? > > The phrase is "tamper resistant", not "tamper proof". Depending on how > determined your attackers are, pretty much anything depending on > tamper resistant hardware will fall. As always, the question is > whether what you are protecting is worth more than the attackers would > have to spend on the attack. > > -- > > > Perry E. Metzger[EMAIL PROTECTED] > -- Saqib Ali, CISSP, ISSAP http://www.full-disk-encryption.net - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
"Ali, Saqib" <[EMAIL PROTECTED]> writes: > i think in most cases tamper-resistant is sufficient - provided the > device that can detect an attempt of tampering, and erase itself. Clearly, if the anti-tamper mechanisms work, the device will not be compromised. The problem is, such mechanisms don't always work. There is lots of stuff in the literature about various kinds of attacks on such devices. Again, I will point out the following from my original comment: >> As always, the question is whether what you are protecting is >> worth more than the attackers would have to spend on the attack. Perry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
As soon as I heard about this research I had to try it out. My laptop (Thinkpad) has an encrypted Truecrypt partition. I quickly made a modified bootable DSL usb memory dumper, powered the machine down, waited a minute, dumped memory, and found that I could recover passwords from multiple prior reboots. I was able to recover my Truecrypt password even if the volume was not mapped at the time of reboot, as well as GPG passwords, SSH passwords, etc etc. It was really easy. During physical pentests, when I grab an encrypted laptop from an office, my clients usually respond that the laptop was "encrypted" and the data was therefore safe. That's not necessarily true, of course, but we don't have the time during these engagements to test out the security of the encryption products/implementation, and neither do most attackers. Now attackers (or customs) just have to grab a live laptop, plug in a USB memory dumper and power cycle the system in order to obtain a dictionary of likely passwords and potentially recover encryption keys. Presumably tools to to accomplish this will soon be found in the wild and will become accessible to attackers with even low levels of technical skill. I imagine this will eventually have a big impact on the way organizations respond to stolen mobile device incidents. With the current technology, if a laptop or mobile device is on when it's stolen, companies will need to assume that the data is gone, regardless of whether or not encryption products have been deployed. Anyone familar with the laws in the arena? Are there regulations which require reporting only if data on a stolen device is not encrypted? Sherri Ali, Saqib wrote: interesting paper. but i fail to see how this could be "deadly" (as the author puts it) to the disk encryption products. This methods requires the computer to be "recently" turned-on and unlocked. So the only way it would work is that the victim unlocks the disks i.e. enter their preboot password and turn off the computer and "immediately" handover (conveniently) the computer to the attacker so that the attacker remove the DRAM chip and store in nitrogen. And the attacker has to do all this in less then 2 seconds :) If the attacker is standing right next to the victim, why even let the victim turn-off the unlocked computer Or am I missing something? - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
> Umm, pardon my bluntness, but what do you think the FDE stores the key > in, if not DRAM? The encrypting device controller is a computer system > with a CPU and memory. I can easily imagine what you'd need to build > to do this to a disk drive. This attack works on anything that has RAM. How about TPM? Would this type of attack work on a tamper-resistant ver1.2 TPM? - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
On Feb 21, 2008, at 6:40 PM, Ali, Saqib wrote: i think in most cases tamper-resistant is sufficient Er, what do TPMs have to do with this at all? TPMs are not tamper- proof hardware FDE devices. They're somewhat tamper-proof (in practice, I wouldn't depend on it) non-volatile storage for small amounts of sensitive data, such as encryption keys. But as long as it's software that's driving your FD encryption, you need to have your keys in RAM. So, either: * The TPM is used in 'basic' mode, where its only purpose is to provide a measure of tamper-resistance to the boot path, and as long as no boot-time tampering is detected, the FDE key will be loaded into RAM automatically, or, * The TPM requires explicit authentication (e.g. by password or smart card) before releasing the key, in which case a successful authentication will load the FDE key in RAM. If the machine is running and the FDE in use -- which is the entire premise behind this attack -- both TPM use cases are just as vulnerable. TPMs are a red herring in this discussion, unless the FDE was actually offloading the crypto operations to it. This is not a supported mode of operation for any widely-deployed FDE system that I'm familiar with. So, is anyone else as amused as I am that Apple can release an EFI firmware update to zeroize MacBook Air memory at boot-time, turning the heretofore widely-decried inability to upgrade that laptop's RAM -- due to the chips being soldered to the motherboard -- into an advantage, and making the Air the laptop of choice for discriminating, fashion-aware, security-conscious professionals the world over? -- Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
So, is anyone else as amused as I am that Apple can release an EFI firmware update to zeroize MacBook Air memory at boot-time, turning the heretofore widely-decried inability to upgrade that laptop's RAM -- due to the chips being soldered to the motherboard -- into an advantage, and making the Air the laptop of choice for discriminating, fashion-aware, security-conscious professionals the world over? No. Apple (or anyone doing EFI boot, for example, someone doing WDE for OS X) can easily modify the EFI boot to zero memory. It isn't just the Air, it's any Intel Mac, but remember those are just Intel EFI systems. Note, however, that this does not completely solve the attack. If someone hits the reset button or yanks power, then you don't get to erase. Jon - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
| ...I imagine this will eventually have a big impact on the way organizations | respond to stolen mobile device incidents. With the current technology, if a | laptop or mobile device is on when it's stolen, companies will need to assume | that the data is gone, regardless of whether or not encryption products have | been deployed. | | Anyone familar with the laws in the arena? Are there regulations which require | reporting only if data on a stolen device is not encrypted? I believe something like this has been written into law. The reporting laws are all state laws, so of course vary. The Federal laws often have "safe harbor" provisions for encrypted data. Regardless of the law, the broad public perception is that "encrypted" means "safe". After one too many embarrasments, corporations (and governments) have learned that "Oh, yes, 150,000 credit card numbers were stolen but there's no evidence anyone is using them" no longer works as damage control; but "Oh, yes, 150,000 credit card numbers were stolen but that's OK - they were encrypted" works fine. (Note that these announcements don't even bother to discuss what the encryption mechanism might be - ROT13, anyone?) Unfortunately, the technical nature of these results - combined with the "We told you to encrypt everything to make it safe; now we tell you encryption isn't safe" nature of the debate, is unlikely to produce anything positive in the general public sphere. People will probably just shrug their shoulders, figure nothing can be done, and move on. -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
| Their key recovery technique gets a lot of mileage from using the | computed key schedule for each round of AES or DES to provide | redundant copies of the bits of the key. If the computer cleared | the key schedule storage, while keeping the key itself when the | system is in sleep mode, or when the screen-saver password mode | kicks in, this attack would be less possible. We've viewed "screen locked" and "sleep mode" (with forced screen lock on wake) as equivalent to "off". Clearly that's no longer a tenable position. Sensitive data in memory must be cleared or encrypted, with decryption requiring externally-entered information, whenever the screen is locked or sleep mode initiated. This would actually make them *safer* than the "off" state, since at least you know your software can gain control while entering those states! | If, in addition, the key was kept XORed with the secure hash of a | large block of random memory, as suggested in their countermeasures | section, their attacks would be considerably more difficult. | | These seem to be simple, low overhead countermeasures that provide | value for machines like laptops in transit. I suspect GPS chip sets will become a standard part of laptops in the future. One can imagine some interesting techniques based on them. Even now, most laptops have motion sensors (used to "safe" the disks), which could be used. I seem to recall some (IBM?) research in which you wore a ring with an RFID-like chip in it. Move away from your machine for more than some preset time and it locks. I'm sure we'll see many similar ideas come into use. -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
Jon Callas wrote: > > On Feb 21, 2008, at 12:14 PM, Ali, Saqib wrote: > >> However, the hardware based encryption solutions like (Seagate FDE) >> would easily deter this type of attacks, because in a Seagate FDE >> drive the decryption key never gets to the DRAM. The keys always >> remain in the Trusted ASIC on the drive. > > Umm, pardon my bluntness, but what do you think the FDE stores the key > in, if not DRAM? The encrypting device controller is a computer system > with a CPU and memory. I can easily imagine what you'd need to build to > do this to a disk drive. This attack works on anything that has RAM. > Actually, I hear that some companies store the keys on the platters of the disk. Again this is if they're actually using crypto and not just selling XOR'ed blocks of data. To project the keys, they limit standard read commands to not enter those areas of the disk. Of course the vendor provides a method to read those areas of disk, it's just a matter of finding them. Regards, Jacob Appelbaum - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
"Leichter, Jerry" <[EMAIL PROTECTED]> writes: >I seem to recall some (IBM?) research in which you wore a ring with an RFID- >like chip in it. Move away from your machine for more than some preset time >and it locks. I'm sure we'll see many similar ideas come into use. There were commercial products that did this available some years ago, they hooked into the Windows auth using a custom GINA DLL (GINA = the Windows extensible login/authentication mechanism, think PAM for Windows) and locked the machine when you moved away from it. They failed in the marketplace, there was no interest in them from users (or at least several of them failed, some may still be around). I was given a bunch of the tags some years ago when one vendor discontinued them, but from memory the drivers were from the NT4 era and there was no chance they were going to be updated further so I never did anything with them. I wasn't able to find out any more details about their failure in the marketplace beyond "no-one bought them". There have even been DIY articles on this published, e.g. http://www.extremetech.com/article2/0,1697,1944631,00.asp from ExtremeTech. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
On Thu, 21 Feb 2008 13:37:20 -0800 "Ali, Saqib" <[EMAIL PROTECTED]> wrote: > > Umm, pardon my bluntness, but what do you think the FDE stores the > > key in, if not DRAM? The encrypting device controller is a computer > > system with a CPU and memory. I can easily imagine what you'd need > > to build to do this to a disk drive. This attack works on anything > > that has RAM. > > How about TPM? Would this type of attack work on a tamper-resistant > ver1.2 TPM? See http://technet2.microsoft.com/windowsserver2008/en/library/d2ff5c4e-4a68-4fd3-81d1-665e95a59dd91033.mspx?mfr=true Briefly, there's a bit in the TPM that means "there are keys present; zero RAM when booting". This does nothing against the guy with the Dewar flask of liquid nitrogen, of course. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
On Sat, Feb 23, 2008 at 05:09:29AM +1300, Peter Gutmann wrote:
> There were commercial products that did this available some years
> ago, they hooked into the Windows auth using a custom GINA DLL
> (GINA = the Windows extensible login/authentication mechanism,
> think PAM for Windows) and locked the machine when you moved away
> from it. They failed in the marketplace, there was no interest in
> them from users (or at least several of them failed, some may
> still be around).
[...]
Saw an interesting free software example of this the other day (not
for Windows, of course) using loss of signal from a particular
bluetooth device (mobile phone, et cetera) to lock your machine or
run other designated commands:
http://sourceforge.net/projects/blueproximity/
It also supports *unlocking* on approach, but that's a bad idea
unless they can start providing a client to run on the "token"
device (maybe using asymmetric key crypto to sign and verify a
challenge string instead of just looking for the device's BT
address).
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: wrt Cold Boot Attacks on Disk Encryption
A lot of people seem to agree with what Declan McCullagh writes here: > It's going to make us rethink how we handle laptops in sleep mode and servers > that use > encrypted filesystems (a mail server, for instance). What I'd like to know is why people weren't already rethinking this when people like Maximillian Dornseif (http://md.hudora.de/presentations/firewire/2005-firewire-cansecwest.pdf) and later Adam Boileau (http://www.security-assessment.com/files/presentations/ab_firewire_rux2k6-final.pdf) showed you can read arbitrary RAM from a machine just by plugging into a FireWire port, due to lack of security considerations in the IEEE 1394 standard? Adam Boileau demonstrated finding passwords, but of course we already know that it's easy to locate cryptographic keys in large volumes of data (Shamir, van Someren: http://citeseer.ist.psu.edu/265947.html). Reading cold DRAM may have some applications on its own -- if only because of the large number of devices that it effects -- but as far as walking up to a locked machine/hibernated laptop/whatever and stealing its RAM contents, the game may have been up some time ago. - Ken - - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: wrt Cold Boot Attacks on Disk Encryption
Ken Buchanan wrote: > A lot of people seem to agree with what Declan McCullagh writes here: > >> It's going to make us rethink how we handle laptops in sleep mode and >> servers that use >> encrypted filesystems (a mail server, for instance). > > What I'd like to know is why people weren't already rethinking this > when people like Maximillian Dornseif > (http://md.hudora.de/presentations/firewire/2005-firewire-cansecwest.pdf) > and later Adam Boileau > (http://www.security-assessment.com/files/presentations/ab_firewire_rux2k6-final.pdf) > showed you can read arbitrary RAM from a machine just by plugging into > a FireWire port, due to lack of security considerations in the IEEE > 1394 standard? > I think that it's clear that people were shocked when Max released his work. Many people may discount the work if they (say like many Thinkpads) do not have at IEEE 1394 port. This is of course not going to stop someone from inserting a cardbus card. Furthermore, I think Max didn't manage to demonstrate a contradiction to a commonly held thought. I'm sure it was no surprise to FreeBSD kernel developers that you could use Firewire to read kernel memory structures using DMA. > Adam Boileau demonstrated finding passwords, but of course we already > know that it's easy to locate cryptographic keys in large volumes of > data (Shamir, van Someren: http://citeseer.ist.psu.edu/265947.html). > > Reading cold DRAM may have some applications on its own -- if only > because of the large number of devices that it effects -- but as far > as walking up to a locked machine/hibernated laptop/whatever and > stealing its RAM contents, the game may have been up some time ago. > I think the most important aspect of this work is that by using redundant (all Hail Nadia Heninger) keying information in memory we can recover and make a pretty good confirmation. This means we don't have to do reverse engineering to find keys and we can correct for errors. Our keyfinder could be used with firewire and I think it stands on its own. Regards, Jacob Appelbaum - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: wrt Cold Boot Attacks on Disk Encryption
On Mon, 25 Feb 2008, Ken Buchanan wrote: > Adam Boileau demonstrated finding passwords, but of course we already > know that it's easy to locate cryptographic keys in large volumes of > data (Shamir, van Someren: http://citeseer.ist.psu.edu/265947.html). This was implemented (in part by some of my colleagues at Leuven as joint work with Utimaco) as long ago as 2000: "KeyGrab TOO The search for keys continues" Dirk Janssens, Ronny Bjones, Joris Claessens Citeseer seems to be offline at the moment, but if anyone's interested in reading the paper, I believe I can give you a copy. --Len. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
