Freezing Android to crack the encryption

frozen-phone-encryption-hacking

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]

Comments

  1. dALE says:

    What do you get when you sit on the ice for too long?

    Polaroids…

    Get it?

  2. 3L_S4N70 says:

    Impressive work

  3. lgrunenberg says:

    Oh I think I was the one to solder a jtag connector to that phone. The world is so small…

  4. CorrosiveOne says:

    Glad to see a real hack on HAD, good job :)

  5. Josh says:

    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…

  6. “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.

  7. 0c says:

    Yet another reason to use the iPhone!

  8. chango says:

    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.

  9. flink says:

    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.”

  10. cde says:

    Isn’t this one of the same ways the PS3 TPU code was extracted? Using a cold spray?

  11. Green Ferret says:

    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…

  12. Brian says:

    I would have to think an upside down can of compressed air would do a much quicker job of cooling a phone down?

  13. Math says:

    This method only work with a unlocked bootloader …

  14. tger says:

    Memory controller designers really need to implement memory clear on boot procedures

  15. randomdude says:

    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 $$$

    • Joe1 says:

      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.

    • Joe1 says:

      Oh, big caveat: Known plaintext exploits
      It’s why a per-boot key should not be reused for other secret information.

  16. HC says:

    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?

  17. DosX says:

    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.

  18. jklu says:

    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.

  19. Tim says:

    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 :-)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 92,020 other followers