Android Full Disk Encryption Cold Boot Attack (2012) | Hacker News Reader

Android Full Disk Encryption Cold Boot Attack (2012)

www1.informatik.uni-erlangen.de

107 pointslouis-paul49 comments

Article looks a little dated, based on the fact that the test phone is an original Galaxy Nexus and only mentions Android 4.0.

I did a search on the Internet Archive and see caches of this page going back at least as far as 2013:

https://web.archive.org/web/20130115000000*/https://www1.inf...

You may want to update the submission with a year.

PDF says 2012

https://www1.informatik.uni-erlangen.de/filepool/projects/fr...

That was not the 'Cold Boot' I was expecting. Awesome.

The paper is really nice and readable. TL;DR: Freezing the phone makes the RAM static and not clear on reboot, giving you time to sideload their custom recovery image that iterates the ram and looks for AES encryption key patterns.

After reading the article expecting a soft solution to causing a lock-up crash of the OS, I feel that your TL;DR needs to be clarified slightly:

Actual freezing. Like, putting the phone in a freezer to create sub-zero temperatures.

Hence "cold boot attack"

I worked on the original cold boot paper (Halderman et al.) and I understood "cold boot" as "removing power", not as "lowering temperature". (It's a warm boot if you reboot from software, and a cold boot if you reboot by removing power to the machine.) It's understandable that people would have assumed temperature was the reason for "cold" because we had lots of pictures of memory with ice crystals.

Under many circumstances, the attack worked at room temperature; one main reason for using low temperatures was if you needed to physically move the RAM chips from one machine to another.

So wait, freezing the ram makes it slower to fade? So that when you quick reboot the phone the ram is not erased?

from https://www1.informatik.uni-erlangen.de/filepool/projects/fr...

> The remanence effect says that RAM contents fade away gradually over time, as slower as colder the RAM chips are.

This is very similar to work done by J. Alex Halderman et al. in 2008 [1]. If you find this interesting, check out their paper. They give an example of a bitmap image in memory and its degradation over a number of seconds without power. It's a fantastic visual aid and you might be surprised by how well the data survives; if you're fast (5 seconds) it's nearly lossless.

[1] https://citp.princeton.edu/research/memory/

None of this will work against a normal consumer device, since you cannot flash recovery until you do "fastboot oem unlock", which purposefully erases ALL user data. And most consumers do not walk around with unlocked bootloaders.

Actually the authors dutifully note this case, explaining that "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."

Pretty unlikely. A large chunk of that data is not likely in ram, and uploading an image to fastboot will erase a lot of ram as well. You'll get some things maybe. But this isn't nearly the end of the world scenario the article seems to paint.

And also on more recent Android devices you cannot even perform an unlock of the bootoader without knowing the device PIN. Try it on a nexus 5x/6p/9.

From their paper:

> Once the smartphone is up again, the risk of loosing RAM contents is defeated. Flashing the recovery image does not destroy important RAM lines according to our tests.

One thing I've always wondered... is the PIN code or unlock pattern (and disk encryption key) protected by a hardware security module that rate limits attacks? If someone has physical access to the device and can image the flash drive, what's to keep them from brute forcing the tiny PIN code keyspace to gain access to the drive?

Most Android phones throttle the rate you're allowed to enter PINs if you fail multiple times in a row (from minutes to hours). You can set the phone to wipe the entire flash memory if too many PIN entries in a row fail.

But that won't help if you're up to the sort of attacker disk encryption is supposed to protect from, right? Disk encryption protects data at rest, in which case you can assume the attacker has loaded the flash into his own system and don't give a cent about Android's PIN restrictions.

It would if the KDF used to expand the PIN also used some per-device secret in a HSM.

Newer iPhones do this in hardware, not sure about Android phones but a software approach is far less secure than using a hardware chip.

I'd be much more interested in this attack if they could get the keys from a phone with a locked bootloader.

I'd assume, encrypted or not, physical access to a phone with an unlocked bootloader means it's owned.

Does android by default lock the bootloader when encryption is enabled?

The bootloader is locked by default on most (maybe all?) android phones, so unless the user has explicitly unlocked it, they'll be safe

Most recent phones lock the bootloader by default, regardless of whether or not decryption is enabled. Some phones, such as the Nexus series, allow it to be unlocked relatively easily. Others, such as those made by Motorola, require the user to go online and get a unique unlock code for their device. And some, such as LG, don't allow the bootloader to be unlocked at all.

In practical terms, the only people who would ever unlock their bootloaders are those who wish to perform modifications (ie. rooting and customs ROMs), and they typically accept a somewhat lessened amount of security anyway.

Locked bootloader should not have anything to do with encrypted user data being accessible or not... With a locked bootloader on Android devices, it can be difficult to flash a Custom ROM but your password won't help in that case... your password/pin should be used to decrypt your data.

It does, because they can't retrieve the keys from memory otherwise - Unlocking the bootloader is essentially opening the phone up to malicious code execution by anyone with physical access.

It would be more difficult and model-specific, but couldn't they attach a device to read the RAM chips directly? To perform this on most modern phones, they have to disassemble it anyway to be able to toggle the power quickly enough (since there's no user-replaceable battery).

They probably wouldn't be able to attach anything to the ram directly, as the ram chips on modern phones are soldered down BGAs. To get at the pins, they'd have to de-solder them, which would heat up the chips in the process. It might be possible to get at the ram over JTAG or some other debug bus in some devices, though.

This is probably in the realm of "if you're subject to this level of attack you have bigger problems", but, I wonder if it would be possible to laser drill after-the-fact micro vias through the PCB to get at all the BGA pads with absurdly small probes.

Your right, it doesn't have anything to do with user data being accessible, but an unlocked bootloader will mean the barrier to finding a vulnerability is much lower than otherwise.

A locked bootloader is an essential line of defense.

Unlocking the bootloader - a prequisite for loading the ram dumping software - causes the data partitions and cache to be wiped. This might not clear the keys from ram, but now the attacker has to find a way to dump the data from flash before unlocking the bootloader for the keys to be of use.

There are a couple more dimensions on recent (more recent than this article) models running M. There's a TEE (~android TPM equivalent) chip involved in encrypting user data, it knows whether your bootloader is locked or not, and it will not yield the keys to locked user data when running in unlocked mode.

Little reminder to the folks with Mediatek chipsets: the MTK bootloader does not support locking and you can trivially dump the entire flash (and rewrite it) at will.

...which I consider a feature, not a bug. It's "insecure" in that I can't lock others out, but no one else can lock me out of my device either. Furthermore, since there's no "hidden state", I can just restore a full flash dump to get back to a known-good state without possibility of something malicious getting in and hiding from me in some secured area.

Indeed, and that's why I'm happy I have a mtk phone. But still, for some users it might be useful to know that their phones are (by far) easier to break than others'.

It sounds to me like this will not work if I actually power down my device before the attacker gets their hands on it, is that correct? (I tend to power down my phone before going through TSA lines, for example)

It appears to me that RAM content is not cleared completely when you power down the device. Encryption keys may still be present in memory So powered down, you freeze the phone, which keeps the RAM at its current state, and then with some magic tricks you can read that memory. So powering down is not enough. In the future I guess powering down needs an extra action, wiping memory first.

In this particular case, the freezing happens while the power is on with the data you want in RAM. If the phone has already been switched off without freezing, it will lose the contents of its RAM pretty quickly.

Yes, cold boot attacks only work if they can get to the machine before it is turned off. If it has been turned off while warm, the RAM contents very very quickly degrade. This is pretty interesting since most people don't get to turn their phone off when it is stolen. In the case of the TSA you're safe, though.

Fun fact: This is why during raids against cyber criminals reports claim they often dive for their computer to try and turn it off before being restrained. Police can do the same thing with liquid nitrogen and a desktop machine.

Sounds like a coil of heating wire around the chips that's triggered by cryogenic temperatures entering the computer case (or the PC's case being opened) would keep their secrets safe. I.e. if triggered, motherboard power is cut off, and the LiIon battery dumps power through the heating wire and quickly bakes the chips to 500 degrees.

And it's not a very complicated circuit either.

Much easier than having to stay within easy reach of the computer's power switch at all times. Though I suspect that there are a very limited number of people in the world that actually face a threat of police coming into their home with a flask of liquid nitrogen to try to do a key recovery of latent data in RAM. This is probably the same set of people that are worried that someone will spend hundreds of thousands of dollars with an electron microscope to try to recover data from their hard drive.

I'd bet that most people that think they are in this risk category do not have strong enough security practices to prevent data from being cracked by other means.

Might as well take this to the logical conclusion and have some thermite set to go off if anyone tampers with the case.

There was an interesting experiment done on this at a DEFCON a few years back[1].

Thermite, even the more explosive copper-based variant, is pretty poor at destroying disk platters, sadly. Explosives or cutting equipment seem to be better, although the magnitude of the engineering challenge obviously increases.

1: https://www.youtube.com/watch?v=-bpX8YvNg6Y

Cool, I'll definitely have to watch that. Thanks for the link!

Here's an alternate idea: rather than messing around with chemical explosives, how about filling the computer with poisonous snakes?

The problem with an explosive device is then you're facing attempted murder charges when it's discovered.

Does it even matter?

You can easily get a user to install some app that has all kinds of permissions, including all their contacts, camera, mic, current and past call history, phone number, etc. They wouldn't bat an eye.

That kind of user doesn't encrypt their phone.

This is more worrying for a professional locked down corporate device full of sensitive data or trade secrets. For example, I work in health studies - my worry would be patient info getting into the wrong hands.

So, what’s next – business phone implementing a heater that heats the device?

Wouldn't be too hard or add too much bulk

Just put an Intel processor inside!

Intel's TXT partially mitigates the desktop version of this attack by setting a nonvolatile bit indicating that the memory state is sensitive. On clean shutdown, the bit is cleared. On dirty shutdown, firmware clears RAM on boot (and the memory controller won't let that step get skipped).

Android could do a simpler version by unconditionally clearing RAM on boot in the bootloader.

Reply on news.ycombinator.com