Frosty attack on Android encryption | Hacker News Reader

Frosty attack on Android encryption

h-online.com

24 pointslignuist15 comments

This is hardly a new attack, and certainly isn't Android specific (as suggested by the article).

Similar attacks have been demonstrated on PC RAM for the recovery of similar encryption keys.

Yes, but the iOS crowd needed a distraction from the regression of their previously-fixed lockmode bug for marketing purposes.

iOS, Blackberry (old and X), and WP8 have platform security for FDE keys which would prevent this attack, or at least greatly complicate it.

This same method can be used to extract encryption keys from RAM on a desktop computer. https://citp.princeton.edu/research/memory/

The research that's new here is that they've written and released a recovery image which actually does the work of a "cold boot" attack. However, from their site:

"To break disk encryption, the bootloader must be unlocked before the attack because scrambled user partitions are wiped during unlocking."

Essentially, they are saying that this attack will only work against devices that have unlocked bootloaders. This means that it won't work against anyone's stock Android device, and will only work against devices where the user unlocked the bootloader to flash a new ROM, but didn't relock it again for some reason.

In other words, a practical development of a theoretical attack, which is largely theoretical.

I value your insights a lot.

But who the hell relocks the bootloader after flashing a new ROM? I've never met anyone doing that, and I'm surrounded by Android fanboys (myself included, at times).

For all I know, everyone that unlocked the bootloader once will keep it that way.

That's still a limited group of people, of course. But you seem to have a very different estimation on the number of devices that might be affected.

Can you help me see where I'm wrong or provide some more details about your rationale?

Totally, but remember that this is about recovering FDE keys.

I'm sure that there are plenty of people who leave their bootloaders unlocked, but they're probably also not encrypting their device, so they're out of luck in the case of a physical compromise anyway (and they're probably also running apps as root, so they're out of luck even when it's not a physical compromise).

I don't know of any way to measure this, but my anecdotal experience is that those who encrypt their devices also lock their bootloaders. Maybe I'm wrong, in which case the lesson is: if you're bothering with FDE, lock your bootloader.

A locked bootloader is just another hurdle which those guys didn't opt to attack, but might not stop others. It's been shown that it is possible to bypass locked bootloaders: -> Shortcut specific pcb pins to force USB booting on Exynos devices (c.f. unbrickable mod and similar, http://www.xda-developers.com/android/explaining-and-advanci...)

Or for that matter, just remove the internal MMC and stick it in a reader (most Android devices don't use MTD anymore).

This was what was so shocking about the case with the FBI and the pimp, since that device wasn't even encrypted: http://arstechnica.com/tech-policy/2012/03/fbi-stumped-by-pi...

What I don't get about Android encryption is why I can't choose a long passphrase/pin for boot time, then still use other unlock methods. It seems that if I use a secure boot passphrase, I need to use it each time I unlock, which is too damaging to utility.

I'm mainly concerned about my data being accessible if the device is lost/stolen.

It's possible technically, however standard Android doesn't support it. Here's an app to do it (reqires root):

http://f-droid.org/wiki/index.php?title=EncPassChanger

Surely this could be solved by making the bootloader erase RAM at start-up?

They use their own bootloader, don't they?

And anyways, that just increases the difficulty - the data is still on the RAM chips and can be read via other means than the phone.

Yay for lack of platform security on Android. Just like Firefox, it has gone from the "open, nice, developer friendly" alternative to the security laggard.

more details here https://www1.informatik.uni-erlangen.de/frost

Reply on news.ycombinator.com