Can freezing an Android device crack its encryption keys?

Every few years, someone reads, or remembers, or rediscovers something we often forget: computer memory isn’t volatile, after all.

RAM chips don’t lose their contents immediately when you turn your computer off, and that can have interesting security ramifications.

Don’t get too excited: RAM contents don’t persist without power in a reliable and consistent way.

If you accidentally pull the plug out of the wall before you’ve saved that fantastic new presentation, don’t expect to get it back.

But if you can cycle the power quickly enough, and reboot under your own control from some secondary device, such as a USB key, you might be able to see the ghostly remnants of what the previously-running operating system was up to.

You can guess where this is going.

If you clean boot a computer with a hard disk that’s running full disk encryption, or FDE, you can’t get anything off it.

Not just the data, but also the operating system, swap and hibernation files are scrambled. Nothing can be accessed without the decryption key.

But what if the decryption key, or a large enough chunk of it, is part of the RAM that didn’t fade to grey when you cycled the power?

That can happen, thanks to the phenomenon of left-behind data in RAM.

(The name you’ll hear is remanence, a word originally used for residual magnetic fields, and now also used to refer to the not-yet-decayed electrical charge in memory chips.)

And if you cut the power abruptly, you prevent the operating system from taking any emergency shutdown measures, such as deliberately purging critical areas of memory to wipe any active encryption keys.

The latest researchers to rediscover remanence in a newsworthy way are from FAU, the Friedrich-Alexander Universität Erlangen-Nürnberg.

They’ve turned their sights on Android, building a custom distro of Android Linux called FROST, short for Forensic Recovery Of Scrambled Telephones.

So far, they’ve only tried it on the Samsung Nexus phone from Google.

That’s because they need three planets to align before the attack will even begin to work:

• The bootloader needs to be unlocked.
• The device needs an easily-removable battery.
• Ideally, the device needs to be at or close to 0°C.

The reason for these limitations are the things that go wrong if they aren’t in place.

If the RAM is at room temperature, its remanence is greatly reduced, so it “forgets” much more quickly.

If you can’t get at the battery, you can’t easily cycle the power abruptly.

If the bootloader is locked, the device will automatically get wiped if you try to unlock it.

The wipe-on-unlock feature is a clean and simple security process enforced by Google, at least on recent devices.

→ Android devices support a stripped-down mode called FASTBOOT, which gets its name because it boots up your device in a second or two. A magic chord of keys pressed down at power-up is typically used when you want to engage FASTBOOT’s services. It has very limited functionality, but the key features are that it allows you to unlock your firmware, and to reflash it. Locked firmware can’t be flashed, for security reasons, and unlocking (assuming your device allows it) it will wipe the device so that your freedom to reflash doesn’t come at the previous owner’s expense.

The first thing you need to do, when you rediscover remanence and want to use it against a specific device, is to find out if your proposed attack is practicable.

That means loading up memory with something you’ll easily find and recognise later, and seeing how well your chosen content survives a power outage.

When a posse of Princeton programmers famously brought remanence into the limelight back in 2008, they used images of Mona Lisa.

The FROST crew picked a more modern mascot, Google’s Android robot:

The results weren’t terribly convincing at room temperature, given that rebooting the phone quickly by jiggling the battery takes an unpredictable time.

Lowering the temperatures offered improved results, as the authors showed graphically:

(They neglected to label the axes, a peccadillo usually restricted to marketing departments, so we’ll have to assume that the X-axis shows reboot time in seconds, and the Y-axis shows the percentage of bits lost. The obvious conclusion: take less than a second, and head towards freezing point.)

The authors eventually settled on popping the target phone in a freezer at -15°C for an hour. They laconically point out that they can’t promise you that your phone will survive, noting that “damaging the phone is your own risk, but we haven’t experienced any problems yet.”

→ A word of warning. If you live somewhere warm and humid, such as Singapore, Dar es Salaam or Brisbane, your phone will rapidly start to collect moisture when you remove it from the freezer. If you’re fiddling with the battery and the buttons of your phone to try to orchestrate this attack, you won’t be able to dry it off as you go along. As the FROSTers say, damaging the phone is your own risk.

To find the FDE decryption keys in memory (Android uses AES encryption), the authors used a modified version of a program called aeskeyfind, originally created for the 2008 paper referenced above.

This cleverly-written tool uses a variety of heuristics to churn through memory, looking for contiguous blocks of RAM that look like the output of the AES key schedule.

This is the algorithm that AES uses at the outset to convert a 128-bit key into 176 bytes of key material to use in the AES process itself, or a 256-bit key into 240 bytes.

And now the burning question. Did the FROSTERs succeed?

Sort-of. They’ve got some visual material that suggests they did, though whether the key information was actually enough to unscramble the encrypted data on the phone is not specified.

The paper is similarly ambiguous, saying somewhat noncommittally that the authors were “able to recover the disk encryption keys (given that no or only a few bits were decayed).”

That’s a bit like saying that “we came out ahead financially every time we placed a winning bet.” It doesn’t tell us much about the practicability of the attack in real life.

Nevertheless, the FROST paper teaches, nay proves, an important lesson:

The authors are unequivocal about this.

When they needed to unlock the bootloader to try to attack an encrypted phone, they ended up with nothing to decrypt.

Oh, and if you pick up your phone to make a call and it seems unusually cold against your ear, look out!

You may have been FROSTed.

Image of frozen lake courtesy of Shutterstock.