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:
If you have an Android phone with an unlockable bootloader,
LOCK IT AGAIN WHEN YOU’RE DONE REFLASHING.
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.
9 comments on “Can freezing an Android device crack its encryption keys?”
How is this news? There can be no security if physcal access is granted to the attacker!
The only exceptions are maybe military IT systems, housed in massive, airtight, reinforced concrete bunkers, buried deep underground.
You're saying you can reliably decrypt *any* disk volume subjected to FDE, after the device that houses it has been turned off and its RAM has faded away?
In some ways, assuming a decent password, you have a *better* chance from far away. (Get some zombie malware installed and you'll be right where you need to be whenever the computer is on and the password has been correctly entered – in fact you'll never need to know what it is 🙂
It is possible to be secure, or at least secure enough, even when an attacker has stolen your computer or phone…
If that were true, there wouldn't be a UK law forcing you to hand over your encryption keys…
Not necessarily. They may want you to demonstrate what a good citizen you are.
I have read often where the torturers often torture suspects already knowing most of the answers to see if they are telling the truth. That way if they get something new, how credible it might be.
So go on, kids, hand over your info like good citizens. Don't make us get out the freezer again.
I don't know about the freezing bit but I know that microwaving one long enough will erase the crap out of it.
Properly designed hardware and software (firmware) means there is no excuse for the system to NOT wipe keys from RAM in the event of power failure. Even sudden and complete failure (removal of battery) allows a few milliseconds of operation as capacitors drain. Way more than enough time to wipe a few hundred bytes of RAM. How do you think systems have handled power failures in the past? 30+ years ago I was working with systems that would sense the power being cut, save pertinent information, and then sit and wait powered off until power was restored – load up the information and continue as if nothing had ever happened.
This is actually old news really, cooling ram to see what data it could hold was done a few years ago.
It is still a very interesting read for anyone that does not know about this.
and who said cooling was better for computer hardware 🙂
I believe as a hardware/software person that John Doe is correct, once you lose physical control of the device, the security is gone.
As far as being in a bunker, that's not access unless you can get in…
It may not be easy, but most security systems have a back up to rescue lost data by the proper people. Of course most of these require knowledge of the machine and OS. But physical access is required. On a mainframe, if you get access to the console and know the system, all bets of security are off…
The laws forcing encryption keys are for quick access to device information, not because you can't get to it. If it's a legal invasion, the laws are structured to make it quick and easy. Like the USA limits you to key size because the computers decode of a large key may take years, and they don't want to wait! The USA government wants to be able to look at whatever without any problems…
Actually, if my memory serves, the US limits on key size (which applied only to software exported from the US) were removed nearly 15 years ago.