New Variants of Cold-Boot Attack

If someone has physical access to your locked—but still running—computer, they can probably break the hard drive’s encryption. This is a “cold boot” attack, and one we thought solved. We have not:

To carry out the attack, the F-Secure researchers first sought a way to defeat the the industry-standard cold boot mitigation. The protection works by creating a simple check between an operating system and a computer’s firmware, the fundamental code that coordinates hardware and software for things like initiating booting. The operating system sets a sort of flag or marker indicating that it has secret data stored in its memory, and when the computer boots up, its firmware checks for the flag. If the computer shuts down normally, the operating system wipes the data and the flag with it. But if the firmware detects the flag during the boot process, it takes over the responsibility of wiping the memory before anything else can happen.

Looking at this arrangement, the researchers realized a problem. If they physically opened a computer and directly connected to the chip that runs the firmware and the flag, they could interact with it and clear the flag. This would make the computer think it shut down correctly and that the operating system wiped the memory, because the flag was gone, when actually potentially sensitive data was still there.

So the researchers designed a relatively simple microcontroller and program that can connect to the chip the firmware is on and manipulate the flag. From there, an attacker could move ahead with a standard cold boot attack. Though any number of things could be stored in memory when a computer is idle, Segerdahl notes that an attacker can be sure the device’s decryption keys will be among them if she is staring down a computer’s login screen, which is waiting to check any inputs against the correct ones.

Tags: , , ,

Posted on September 24, 2018 at 6:52 AM • 29 Comments

Comments

Phaete • September 24, 2018 7:20 AM

So the researchers designed a relatively simple microcontroller and program that can connect to the chip the firmware is on and manipulate the flag.

Connect as in “connect that USB plug to the PC” or
Connect as in “connect those wires to that small chip”

Couldn’t find that info, it makes it a factor 100 times more difficult or not.
But yeah, if solder, then it’s the same principle they already did with the iPhone.
Hardware hacking becomes more powerful as the old generation of grey beards passes on and info becomes obscure

aserraric • September 24, 2018 7:54 AM

Your introduction is misleading. You need access to a locked, but running computer to execute a “cold boot” attack. You cannot perform such an attack on a computer that is properly shut down, since the key is no longer in RAM in this case.

So, you would have to carry out the hardware modification (undetected), then wait for the victim to sign on, and then execute the actual attack.

echo • September 24, 2018 9:00 AM

People keep forgetting the wetware was hacked ten steps before. As he path follows a lot of steps where control and coercion accumulate slowly until a vulberability occers should not come as a surprise. The door then slams shut.

What looks like a lot of “if” “but” “maybe” effeort for an individual is least effort for an organsation. Individuals don’t properly perceieve their own OODA loop even if they are aware of the concept.

Security, like design, is all about psychology.

Mike D. • September 24, 2018 10:20 AM

@Phaete: Some systems have a JTAG or similar debug/reflash connector. Some don’t.

@aserraric: Or, since you have physical access, you just yank power out of the box, forcing an abnormal power-off, downstream of any UPS, connect your doohickey, and power it back up, letting the doohickey jump in and clear the flag before boot continues.

The correct mitigation for this attack is to always wipe down the memory after power-on but before boot, say via hardware reset logic, or some un-overridable ROM boot code, on the same chip as the memory in question. They shouldn’t be trusting a flag.

echo • September 24, 2018 11:06 AM

@Mike D

Flags are fast and cheap much like flags (or “deindexing”) used by Facebook et al to “delete” information at the request of the user. As we know and as you highlight “delete” doesn’t mean delete. If the information still exists it can be used and abused without concious knowledge or approval of the owner.

wumpus • September 24, 2018 11:13 AM

@aserraric

You’re assuming Windows performs a real shutdown when the user clicks on “Shutdown”. In general, it does not. You have either have to hold down the shift key, change the default “fast shutdown” to off or try something like “shutdown /s /f /t 0” in the command area. Otherwise you get the “fast shutdown” that dumps the RAM and lets this attack work.

Unless you are assuming a non-Microsoft OS (which should be step one if you care about your data), this is going to work.

Lore • September 24, 2018 12:35 PM

The simple solution to these types of attacks is to not encrypt data in the first place. No encryption, no keys to steal.

Michael Watts • September 24, 2018 12:42 PM

Though any number of things could be stored in memory when a computer is idle, Segerdahl notes that an attacker can be sure the device’s decryption keys will be among them if she is staring down a computer’s login screen, which is waiting to check any inputs against the correct ones.

I don’t see why the decryption keys need to be stored in memory for this purpose. You don’t need to compare user-submitted decryption keys to a known correct value in order to validate them — just do the decryption, and if you get garbage, the keys were wrong. If you don’t, the keys were correct.

Crazy monk • September 24, 2018 4:55 PM

@aserraric: “carry out the hardware modification (undetected), then wait for the victim to sign on, and then execute the actual attack.”

@Mike D: “yank power out of the box, forcing an abnormal power-off, downstream of any UPS, connect your doohickey, and power it back up, letting the doohickey jump in and clear the flag before boot continues.”

Careful hardware modification does not necessarily require power to be off to happen… just steal (or confiscate) a still-running computer, open it up while it’s still running, clamp your modification onto the chip (carefully) while it’s still running, reboot into your own diagnostic code to read all the keys you wish.

Please note that this is unlikely to help as much for logins, where only hashes are stored (both on disk and in ram)… but it is highly likely to work where you actually need to decrypt something back to plaintext (not just check for a password match), such as hard drive encryption! That’s where the actual decryption keys need to be stored somewhere easily accessible by the running machine for it to function.

Because of this, I though everyone always assumed that physical access to a running machine meant you could gain full access to its data… only fully powering it down made it safer (but is even that truly safe? do we know for sure that volitile ram chips can never contain a faint imprint to some degree while powered off? isn’t this why the Guardian was forced to grind the chips in their machines to powder to destroy them?)

David H. • September 24, 2018 6:05 PM

@Crazy monk,

Check out a paper entitled “Lest We Remember: Cold Boot Attacks on Encryption Keys” – https://citp.princeton.edu/research/memory/ (full 16 page PDF linked from that URL)

It’s several years old now, but they demonstrate just how long it takes data to decay in several different DRAM modules, mostly DDR2. Data recovery on cooled modules was possible even after several minutes. I read in another research paper that DDR3 decay was much faster — a good thing — on the order of a few seconds, but I cannot recall where I read that figure. I hope with the current DDR4 generation of DRAM that the cold boot attack variants are much less practical to execute.

Thomas • September 25, 2018 4:17 AM

This is a “cold boot” attack, and one we thought solved.

When did we think that?
What was supposed to have solved it?

cold-boot means the attacker has physical control over the hardware. Those attacks are difficult to defeat (just ask anyone who’s build a games console in the last decade or two).
Other than going old-skool-mission-impossible and mixing thermite into the RAMs silicon how do you prevent a cold-boot attack?

fde • September 25, 2018 9:20 AM

@Thomas

Full disk encryption with a strong password where the keys are fully erased after shutdown. It won’t stop an evil-maid attack, but if the disk is ever stolen and never returned, data shouldn’t be readable.

echo • September 25, 2018 10:09 AM

@fde

Veracrypt are dogmatic. They avoid relying on TPM for user convenience because they want to prtect against “evil maid attacks” and believe TPM provides a false sense of security. I actually think I know what I want and why (without being mansplained by Veracrypt if you will forgive the feminist escalating but God oh mighty dealing with individuals beliefsystems is frustrating at the best of times). Microsoft actually handle this quitewell atthe user interface level although in the opposite way when it comes to turning TPM off because it is on by default in Windows.

If Veracrypt applied a similar model and supporting dialogues and coumentation and big red flag pop-ups they could both provide a TPM implementation which is easier for the user and likely to result in more uptake of Veracrypt, thus innoculating the ecosystem against attacks and making everything for everyone safer, and satisfy their own dogmatic demands relevant to a correct appreciation of the security level.

Not everyone is on the receiving end of an APT level attack. Sometimes you just need to protect data at rest from being stolen or wherethe state does interact protect from the dufus level Deputy Dawgs who don’t have a clue what they have in their hands even if you point it out to them and give them an explanation. As things turn out by being akward Veracrypt not only put people off their product but also because of incompatibilities and other nonsense along with Linux installation defaults put people of dual booting and migrating away from Windows to (allegedly) more secure systems.

The actual biggestsingle security headache for me is my laptop refuses to recognise an external keyboard when docked during boot time. The IHV claims this is by design. This makes no sense to me and is just another barrier to dual booting. Unless I want to unplug my laptop every single time I boot the thing I’m stuck with the default which I edited to boot in Windows because Windows is less of a headache. Going all in for Windows and Bitlocker is the easiest choice for me until Linux and Veracryot stop being so stupid and/or my vendor modifies this action at the firmware level which is extremely unlikely given how long this has been a “feature”. (Ditto external speaker sound via the model of dock I have but this is another story.)

Clive Robinson • September 25, 2018 11:18 AM

@ @Crazy monk, David H,

Not only can DRAM hold data for more than 10mins at room temprature two other effects compound the problem,

1, Temprature.
2, Burn in.

If you pump suitable cryo-gas into the computer you can freeze the memory contents for much longer.

But you can also burn data into the DRAM such that it’s near permanent. So storing a crypto key in memory can be a very bad idea if it ends up in the same memory location…

Thus there is a way to over come both issues that I’ve mentioned on the odd occasion which is to store the key as a “data shadow” between two or more constantly evolving values, done by a fast interupt etc.

echo • September 25, 2018 1:14 PM

There have obviously been snatch and grab cases by law enforcment such as the ‘Silk Road’ case. Somebody taking a lot of precautions could prevent a snatch and grab and cryogenic freezing of DRAM contents. It struck me though that one ancient Chinese weapon was a trap designed as a room where when the victim was alone and sleeping with gaurds outside the whole floor tilted and dropped them in to a deep hole with lots of metal spikes at the bottom. Itdoes make me wonder though with respect to “snatch and grab” and potentional board level counermeasures.

Clive Robinson • September 25, 2018 4:20 PM

@ echo,

<

blockquote>Somebody taking a lot of precautions could prevent a snatch and grab and cryogenic freezing of DRAM contents.

If you look far enough back on this blog you will find quite a few conversations where “the usuall suspects” @Nick P and myself in particular gave quite detailed information on how to do such things.

Likewise RobertT and myself, of relevance here is a conversation we had, have a read down from,

https://www.schneier.com/blog/archives/2012/08/is_iphone_secur.html#c858651

As for the Chinese room, yes there are stories of “fall away floors” for the unwary, even floors that were speciffically “tuned” like a musical instrument called “nighting gales” so a defender would know exactly where to hack with a sword in the dark.

There is when you analyse it little difference between security by “Dead fall” and security by “Dead man’s switch”

But as I’ve explained before it’s actually not that difficult to build a PC server into a small fire proof safe that is A60 heat and burgler rated to build your own “hardware security module”. This buys you upto 60mins of time against an attacker be they LEO or contractor on a “black bag job” for an IC entity etc.

It’s also quite easy to design a system where you never know the secret encryption key, nor is it ever in plaintext form in the jurisdiction you are in except inside the security module.

Simplistically your hardware security module has a self generated PubKey, it keeps the private key internally and only puts out the public key once onto a thumb drive or equivalent. Thus the owner of the thumb drive is the only person who can send secret messages to the hardware module. If they go out of juresdiction with the public key then generate the secret symetric key encrypt it with the public key and send it to you or directly to the hardware module. Then you being in another juresdiction and having never known what the key is can not be coerced into revealing it.

Obviously it’s a bit more complicated in that you have to prevent replay and other attacks but it gives you the 20,000ft view.

echo • September 25, 2018 7:13 PM

@Clive

I’m happy with my Swiss Cheese Security and being too little value and not worth the bother pain in the neck. This is the on your back at zero feet looking up view.

Clive Robinson • September 26, 2018 3:10 AM

@ echo,

This is the on your back at zero feet looking up view.

Hopefully somewhere where the grass is green and fragrant and the sky is blue, and at times where there realy is nothing more pressing to do B-)

ATN • September 26, 2018 4:08 AM

Anyway, it doesn’t look we are talking of PCs here but only embedded systems.
On PC, you have to be sure the key is not exfiltrated somewhere else (at time of first use) without your knowledge.
For instance, in my experience, you can “lock with password” a hard disk in the BIOS of a PC – but the password you give is not what is used by the BIOS to send the command “lock the disk with this password”, the password you give is stored in the FLASH BIOS, and the disk is locked by something else (probably also stored in the FLASH BIOS) – that some people “in the know” (not me) can extract easily.
Setting yourself a password in your own boot disk by directly sending the SATA command with your own password leads to an unbootable system, at least for the BIOS brands I am using.

echo • September 26, 2018 10:04 AM

@Clive

Hopefully somewhere where the grass is green and fragrant and the sky is blue, and at times where there realy is nothing more pressing to do B-)

This is more charming than some things I have heard by a long chalk.

Etienne Mathieu • September 26, 2018 10:20 AM

Putting a computer Operating System on citizens desks was a moronic idea in the first place.

I propose a law that that requires all computers with Operating Systems to be registered as a weapon, given a Computer Identification Number (CIN), and the user required 40 hours of certification training before use. Bearing responsibility and prosecution in the control or use of that weapon.

Computers with Operating Systems and multiple CPU will be registered as Assault weapons, and only small storage clips can be used.

Owners and users with X-stations and VT100 compatible terminals will be exempt.

Ron • September 27, 2018 12:20 AM

The pill doesn’t protect against HIV, and MemoryOverwriteRequest doesn’t protect against physical attacks. Both warn you about this in their respective documentation.

Did F-Secure read their own references before publishing?

F-Secure’s blog about the their cold boot attack cites the TCG MemoryOverwriteRequest specification. Page 6 of the specification says: “The methods in this specification are not intended to protect against active physical attacks beyond the scope of the above scenario”. Attaching a microcontroller is an active physical attack.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.