Remember that cold boot encryption attack we talked about last week? Looks like someone went out and released a public tool that replicates part of the functionality of the Princeton tool. I thought it would take a little longer; guess I was wrong. Does this change my advice? Not really- your best bet is still to maintain physical control of your laptop, and the odds are still pretty low you’ll have to deal with this in the real world. But keep asking your vendors how you need to configure your encryption product to limit the attack. Still, I’m always impressed with how quickly those Internets are able to recreate this stuff; talk about the end of security by obscurity. It’s almost as if there are an infinite number of really smart monkeys out there with computer science degrees.Thanks to Hack A Day for the link…
Reader interactions
4 Replies to “Heads Up: Cold Boot Encryption Attack In The Wild”
Thanks, you’‘re absolutely right. TCT’s is called findkey. Here’s what I wrote on the comments of my own blog, where you asked the same question. Pasted it here since more people read and can benefit from Rich’s blog than mine, I imagine 🙂 :
I haven’‘t been able to do a lot with key extraction, since this is only a side-project for me, and I don’‘t have any of the commercial encryption products to test with. I have done some experimentation with dm_crypt, with some information that I found in this paper:
http://events.ccc.de/camp/2007/Fahrplan/attachments/1300-Cryptokey_forensics_A.pdf
The technique in that paper tries to find the key by looking for characterisics of the struct that it’s in. I got so far as getting the code from that to compile, however it did not manage to find the key. Either something that I did to get it to compile managed to foul things up, or possibly newer versions of the kernel have a different struct. The next step would be to dive into the kernel source, see what the struct actually looks like, and perhaps encrypt a volume with a known key just to verify. I haven’‘t gotten around to this yet, but I may soon. Feel free to pick up there if you’‘d like, though 🙂
I thought that also. The tool on the Coroner’s Toolkit is called findkey, and the tool in the video us called keyfind.
have you been able to get the key yet from ram?
Jesse James
Hey guys, glad you enjoyed reading about the tool!
I’‘d say there isn’‘t a hard part of this attack when it comes right down to it. As Rich states, the RAM dumping definitely isn’‘t the hard part (it /was/ a weekend project away, and now it’s accessible to anyone). As far as the encryption key is concerned, if nothing else you could simply try everything. Slide a 256/128 bit window 8 bits at a time through the memory you’‘ve dumped, and you’‘ve reduced the number of keys you need to try to something on the order of the number of bytes you have in memory.
>>> 2**32
4294967296L
versus
>>> 2**128
340282366920938463463374607431768211456L
And that’s doing it as “dumb” as possible. I believe Princeton’s “bitunlocker.sh” at least in-part uses “keyfind” from The Coroner’s Toolkit to make things a bit easier. At least intuitively it seems you can narrow this down by a measure of the entropy of the possible keys you’‘re looking at.
Just wanted to point out a bit of a paradox, “your best bet is still to maintain physical control of your laptop”. Isn’‘t the main purpose of full-disk encryption to prevent data disclosure when people *don’‘t* maintain physical control of their laptop? If people maintained physical control wouldn’‘t that negate the reason to have full-disk encryption in the first place? 🙂
To the point of the tool though, this tool is only a USB image that dumps the RAM contents and I’‘d argue that’s really the easy part. The hard part (or harder part) will be to determine where on that dump are the 256 or 128 bits of the key. If I remember right that was really the secret sauce of the Princeton folks. But it is just a secret algorithm and it’s just a matter of time before the threat is realized and the risk is real.