Build a better lock and someone will make a tool to open it without the key. Or in this case they’ve made a tool to discover the key using a trip to through the deep freeze. The Forensic Recovery of Scrambled Telephones — or FROST — uses cold temperatures and a custom recovery image to crack Android encryption keys.
Cold boot hacks go way back. They leverage use of low temperatures to slow down the RAM in a device. In this case, the target phone must already be powered on. Booting a phone that uses the encryption offered by Android 4.0 and newer requires the owner’s pass code to decrypt the user partition. But it then remains usable until the next power cycle. By freezing the phone, then very quickly disconnecting and reconnecting the battery, researchers were able to flash their own recovery image without having the encryption key cleared from RAM. As you can see above, that recovery package can snoop for the key in several different ways.
[Thanks Rob]
What do you get when you sit on the ice for too long?
Polaroids…
Get it?
Impressive work
Oh I think I was the one to solder a jtag connector to that phone. The world is so small…
Glad to see a real hack on HAD, good job :)
It’s certainly many levels above “custom motd on your RPi!”
If ever there was a hack to be posted, this would be it. Very cool, i actually didnt know that freezing something would slow it down that much…
“On the downside, scrambled telephones are a a nightmare for IT forensics and law enforcement, because once the power of a scrambled device is cut any chance other than bruteforce is lost to recover data.”
That was a disturbing sentence from the article.
Disturbing? It is damn good news if you actually believe it to be true.
I don’t believe it though.
Why? So criminals can continue to get away with serious crimes? Sounds great to me!
You seem to have forgotten about personal privacy. Criminals are dumb enough to get caught through more obvious methods… I sure hope you were being sarcastic.
In Australia at least, the police aren’t going to be sending your mobile to an IT lab without good reason for suspecting you in a crime, and anyone willing to fork out the money to get information off your phone will have other ways of getting enough information anyway.
If your phone is being sent to a forensic IT lab, invasion of privacy should probably be one of your last concerns.
I could tell you a story about playing shadow run on irc, a freinds chat logs, his nosy sister and my interview with the police. In short be paranoid protect your privacy.
So Big Brother can’t read all of one’s data in a formerly Free society.
Read MORE history from last century and LESS Corporate “News”
http://xkcd.com/538/
Here’s what I don’t get: they’re pulling the battery to force it to reboot into recovery. However, most Android phones have a PMIC that monitors the power button for a long press, and affects a cold reset. The time between the reset and the DRAM init code is minimal, far less than replugging the battery, when reset is asserted, so the freezing should be unnecessary.
The real point of this exercise is to realize one of the reasons vendors lock bootloaders, and why SoCs with security fuses usually have a way to disable JTAG access.
Yet another reason to use the iPhone!
iPhone doesn’t even have encryption dude……
What the hell are you guys talking about? the iPhone has had AES encryption since the 3GS: http://www.google.com/search?q=iphone+encryption&oq=iphone+encryption&sourceid=chrome&ie=UTF-8
Indeed since that doesn’t need any freezing to bypass the lock, just a few swift motions.
+1 to this answer
Right, because an iPhone is so much more secure! It’s not like there are methods to bypass the lock screen or anything… Oh wait!
Also, there is no encryption on iPhones… So by default, Android is by FAR, more secure than any iOS device.
This is the take-away:
If you can’t risk anyone else obtaining a file, phone number, etc., then don’t leave it on a cell phone. To paraphrase Smokey the Bear, “Only you can prevent unsecure data.”
Sounds really practical…
That, and whenever you are being arrested just smash your phone on the ground to dislodge the battery and hard power it off…
That only works if the batter is removable. a lot of newer phones don’t have removable batteries anymore.
I agree: too many people getting caught for stupid things this way.
So it seems the trend towards non-user-serviceable batteries aids security in this regard. Interesting.
On the other side, if you wanted to have some fun with this, use a thermally activated power switch, forcing a hard reset of the handset (or detonating a small explosive charge) any time the handset reaches temperatures useful for this hack. Just don’t answer your phone outdoors in Alaska…
Isn’t this one of the same ways the PS3 TPU code was extracted? Using a cold spray?
I would have to think an upside down can of compressed air would do a much quicker job of cooling a phone down?
This method only work with a unlocked bootloader …
Memory controller designers really need to implement memory clear on boot procedures
thx for sharing it… now whoever first designs a lipo battery that works just like a regular battery but has a very unfortunate ;-) tendency to explode and send shrapnels when rapidly cooled… will make some serious $$$
Destructive-by-design instead of defective-by-design? :D
Seriously though, there’s an obvious way around this on ARM chips: Don’t store the key (directly) in RAM so even if the firmware has horrible data security, you can still prevent trivial reading of the key. For example, store a 32-bit XOR key in a register and then reserve it for reading/writing all encryption keys. Maybe have another one just for related data structures. This is trivial, machine cycles-wise, but would make a key search practically useless. If a (native, not Java) user program can access that key, well it’s already operating from a point of advantage to possible exploits like key-snarfing, anyways. It would at least then have to be an inside job. A larger key (say, 256 bits) would be more secure but not as practical.
Oh, big caveat: Known plaintext exploits
It’s why a per-boot key should not be reused for other secret information.
In the introduction:
>However, we show that cold boot attacks are more generic and allow to retrieve sensitive information, such as contact lists, visited web sites, and photos, directly from RAM, even though the bootloader is locked.
But then later
>For this command to work, the bootloader must be unlocked.
So where exactly do they show this working on locked devices?
The more personal the device the larger the risk…..
Use it for it’s function not as an attached limb.
But hey who really leaves incriminating information on a phone, except for the call logs and messages which should be vague if you really are into that sort of thing.
most days a phone call for me goes like this.
Mom:”hello”
me:”on my way”
Mom:”alright”
and if it’s a friend
Me:”yo”
friend:”location”
Me:”Work”
friend:”On my way”
mostly just keeps the bill minimal lol
Don’t store pictures you dont want others to see or data you wont want others to have…
Be paranoid.
P.S my mom uses her cell like it’s a walkie talkie as soon as she hears the information she wants from you expect that to be the end of the call if she called you.
Me:”yo”
friend:”location”
Me:”Work”
friend:”On my way”
and the guys listening to your phone calls are like “yup, he’s prolly buying drugs” :-D
Be very paranoid ;-)
lol you are probably right but if I was I wouldn’t be selling at work so they would get too many false positives and eventually give up on that…
Out of curiosity: doesn’t the cold slow the RAM access of the recovery image ?
Using frozen ram to probe it with an external device sounds doable to me.
But preventing it from dataloss and at the same time still be able to use the same RAM chip almost sounds like magic.
Freeze it – why didn’t I think of that?
On a long-ago project hacking the Dakota/CVS single-use cameras, it was discovered that a timely powercycle + shorting of solder jumpers could be used to put the cam into bootloader mode and so dump a firmware image + misc. RAM contents (possibly keys). A small percentage of the bytes came back corrupted due to the momentary loss of power. My hacky solution was a short C program to take multiple dumps and recover a clean copy of the memory contents by majority vote (search for ‘filedata finagler’ in http://www.linux-hacker.net/cgi-bin/UltraBoard/UltraBoard.pl?Action=ShowPost&Board=cameras&Post=33 ). Putting the cam on ice instead could have saved some work :-)