Android Full Disk Encryption Cold Boot Attack (2012) • Hacker News Board

Re: Android Full Disk Encryption Cold Boot Attack (2012)

#41

Post by dmitrygr » Tue, Jan 05, 2016, 2:57 AM UTC

mrb wrote: post #30

dmitrygr wrote: post #24

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.

Re: Android Full Disk Encryption Cold Boot Attack (2012)

#42

Post by mikeash » Tue, Jan 05, 2016, 3:32 AM UTC

Johnny555 wrote: post #29

chrisfosterelli wrote: post #26

Earlier quoted context omitted.

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…

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.

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

Re: Android Full Disk Encryption Cold Boot Attack (2012)

#43

Post by Igglyboo » Tue, Jan 05, 2016, 3:43 AM UTC

Johnny555 wrote: post #21

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?

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

Re: Android Full Disk Encryption Cold Boot Attack (2012)

#44

Post by userbinator » Tue, Jan 05, 2016, 4:59 AM UTC

mschuster91 wrote: post #27

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.

Re: Android Full Disk Encryption Cold Boot Attack (2012)

#45

Post by amluto » Tue, Jan 05, 2016, 5:23 AM UTC

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.

Re: Android Full Disk Encryption Cold Boot Attack (2012)

#46

Post by mschuster91 » Tue, Jan 05, 2016, 5:41 AM UTC

userbinator wrote: post #44

mschuster91 wrote: post #27

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

Re: Android Full Disk Encryption Cold Boot Attack (2012)

#47

Post by baby » Tue, Jan 05, 2016, 7:26 AM UTC

SchizoDuckie wrote: post #6

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.

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.

Re: Android Full Disk Encryption Cold Boot Attack (2012)

#48

Post by baby » Tue, Jan 05, 2016, 7:38 AM UTC

dmitrygr wrote: post #41

mrb wrote: post #30

Earlier quoted context omitted.

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.

Re: Android Full Disk Encryption Cold Boot Attack (2012)

#49

Post by jfindley » Tue, Jan 05, 2016, 9:01 AM UTC

mikeash wrote: post #42

Johnny555 wrote: post #29

Earlier quoted context omitted.

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.

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

Re: Android Full Disk Encryption Cold Boot Attack (2012)

#50

Post by schoen » Tue, Jan 05, 2016, 11:48 AM UTC

greggarious wrote: post #35

Pxtl wrote: post #20

Earlier quoted context omitted.

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.