
Android Full Disk Encryption Cold Boot Attack (2012) - Artemis2
https://www1.informatik.uni-erlangen.de/frost
======
AdmiralAsshat
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...](https://web.archive.org/web/20130115000000*/https://www1.informatik.uni-
erlangen.de/frost)

You may want to update the submission with a year.

~~~
ikeboy
PDF says 2012

[https://www1.informatik.uni-
erlangen.de/filepool/projects/fr...](https://www1.informatik.uni-
erlangen.de/filepool/projects/frost/frost.pdf)

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

~~~
Pxtl
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.

~~~
greggarious
Hence "cold boot attack"

~~~
schoen
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.

------
_jsn
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/](https://citp.princeton.edu/research/memory/)

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

~~~
mrb
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."_

~~~
dmitrygr
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.

~~~
baby
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.

------
Johnny555
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?

~~~
nfd
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.

~~~
widforss
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.

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

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

~~~
awqrre
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.

~~~
stormcloud
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.

~~~
gherkin0
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).

~~~
baobrien
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.

~~~
prutschman
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.

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

~~~
userbinator
...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.

~~~
mschuster91
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'.

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

~~~
chrisfosterelli
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.

~~~
Johnny555
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.

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

~~~
jfindley
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](https://www.youtube.com/watch?v=-bpX8YvNg6Y)

~~~
mikeash
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?

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

~~~
Pxtl
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.

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

~~~
irixusr
Wouldn't be too hard or add too much bulk

~~~
Artemis2
Just put an Intel processor inside!

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

