Posted
by
timothyon Thursday February 14, 2013 @10:26AM
from the no-mr-bond-I-just-want-your-phone dept.

Noryungi writes "Researchers at the University of Erlangen demonstrate how to recover an Android phone's confidential content, with the help of a freezer and FROST, a specially-crafted Android ROM. Quite an interesting set of pictures, starting with wrapping your Android phone in a freezer bag."

As far back as the late 1980's we used freezer's on hard-drives to recover data. It helped against various over-heating issues so you could recover just a little bit more data each time you used the drive. Every few years you hear about some other method to recover data with a freezer including putting a device in the freezer. Funny how it always works. All hail the freezer!

To expand on why this works.The RAM in a phone is dynamic RAM.It does not store data when unpowered, but needs that data to be periodically refreshed many times a second.It turns out, that especially when cooled, the RAM may in fact retain information for some period short enough to allow the device to be unpowered and repowered, and essentially retain all its data. (there may be a few errors).

This, combined with booting into a new OS which then allows you to dump or do other things to the RAM enables the attack.

Again, no one here here claimed they came up with it. There is no "academic honesty" in play. Purely for demonstration purposes only. Do you fault the science teacher for demonstrating a concept he didn't come up with? Is that academic dishonesty? And that's ignoring the fact that the article that demonstrates it gives credit and links to the original study. Keep on keepin' on, AC

It turns out, that especially when cooled, the RAM may in fact retain information for some period short enough to allow the device to be unpowered and repowered, and essentially retain all its data. (there may be a few errors).

Actually, the period can be quite significant. One of my projects involved a kernel that could only dump messages to RAM. To get it out, I'd reboot the board and dump the log buffer. At regular room temperature, but elevated board temperature (jthe CPU was running for a good tilt so the board heated up), a power cycle (under 1s) would let you read it out perfectly. After 10s off, you could see corruption but was mostly readable. After 30s or so, it was barely readable.

It appears the main physical phenomena is that the memory capacitors "distort" ever so slightly so the RAM doesn't completely powerup randomly, but is influenced by what was held there previously. It's a time related thing as well - a memory cell that was rapidly cycled would tend to have a lower time before corruption than a cell which held data staticly for a long time. Since encryption keys tend to fall in the latter, the memory tends to stay that way a bit longer (unless the code periodically switches memory buffers and scrubs the old one - it doesn't take much - just store a new pattern in then and it'll overwrite the old one).

Sections 7 and 8 of the famous Gutmann paper [auckland.ac.nz] detail this effect in memory as well (you may recall the paper dealt with recovery of data off hard drives - but it also dealt with semiconductor nonvolatile memory as well).

A followup paper(PDF) [cypherpunks.to] goes into more detail on semiconductor memory including flash storage.

I remember this being described years ago in PGP Desktop's [1] owner's manual. What the PGP program (pgpserv.exe) did was keep two copies of RAM resident keys, one normal, one bit-inverted (XOR all 1s.) Periodically the program would flip the copies.

[1]: When PGP, the commercial product was split from McAfee and was run by an independent company before becoming part of Symantec.

Of course it does. Didn't you know that is why people are blind for a short time after being removed from carbonite? It is so that forensic investigators can retrieve information from their visual cortex and optic nerves before it gets overwritten. Also hibernation sickness is caused by overheating in the brain caused by bulk memcpy grabbing all the data from the person's memory.

I can't talk about your non-volatile storage issues, but cooling a system down slows state change, meaning it's more likely to stay in its current state for longer. This means you have more time to recover whatever it is you're looking for before the volatile nature of the system means the data is lost for good.

The two work by different methods. In the case of RAM, reducing the temperature lowers the leakage current of the capacitors in DRAM that actually store your bits, increasing the time before the charge drops below a detectable level (i.e. increasing the time before the data becomes unreadable).
In the case of HDDs, freezing them causes metal components to shrink slightly, so any seized bearings may be freed up for long enough to recover data.

I guess the point is that this is an unnecessary hole in the security. The boot loader should not load anything without first wiping the RAM. The attack depends on the ability to boot into fastboot mode, which is then used for flashing a new recovery ROM, and that is booted as well without clearing the RAM. There is no normal situation where a booting system should have access to the previous RAM contents, so wiping the RAM first thing in the boot loader is a safe thing to do.

Some embedded systems use RAM for crash log for recovery, so while it does not make sense in a mobile, it is used and really useful in real life. Writing to RAM is at least 2 order of magnitudes faster than FLASH and not you do not have to have to worry about wear cycles.

They acknowledge that bootloader must be unlocked for this to work though. That's really going to limit the utility of their procedure. Non-Nexus bootloaders are generally locked and encrypted, and the ADB whitelist feature of 4.2.2 should make stock Nexus devices a tough target.

They acknowledge that bootloader must be unlocked for this to work though. That's really going to limit the utility of their procedure. Non-Nexus bootloaders are generally locked and encrypted, and the ADB whitelist feature of 4.2.2 should make stock Nexus devices a tough target.

Even Nexus devices ship with locked bootloaders by default. They can be unlocked by a simple ADB command, but this erases everything on the device.

Wiping the RAM each boot is a waste of time - nobody does that. I'd rather have the normal scenario be "boot quicker", not "protect me from an unreasonable scenario *if I've already unlocked my bootloader*"

If for some reason you need that extra security unlock the bootloader and replace it with one that wipes the RAM on boot. But you still won't be secure from the guy that just wires into the RAM chips directly and dumps them.

Admittedly, I have never used Android device encryption and do not know the specifics of how it works. However, reading the article, what is the big deal about brute forcing a 4-digit PIN on a device that one has local access to? Could the encrypted FS be dumped and brute forced in software? What am I missing?

To answer my own question, my assertion was correct [blogspot.com]. With physical access to the device, brute forcing the PIN protecting the disk encryption is trivial. The million dollar question is: how to sufficiently protect a key in a manner that can be quickly and conveniently unlocked by an average user?

"in a manner that can be quickly and conveniently unlocked by an average user?"

Not sure why I'm bother answering this obvious troll but then use 6 characters. That still brings up the complexity/strength enough to make unbreakable before the limit hits. Please do some reading if you want protection there is some required effort above and beyond a 4 digit number PIN, it's a risk assessment for the OP to make.

On this subject, what would be nice would be to have both a PIN and a symbol password.

The first time the Android device powers up, it will prompt for the longer version. After that, it can use that version, or a short PIN.

Of course, another solution is to do similar to Apple, and have a dedicated chip (or in Apple's case, have it be part of the custom CPU) which stores the volume decryption key in a physically tamper-resistant place and acts as a gatekeeper. That way, accessing the stored password hash wo