A coldboot attack is very easy to mount. Simply reboot from USB and dump RAM. See https://blog.f-secure.com/cold-boot-attacks/
“Using a simple tool, Olle and Pasi learned how to rewrite the non-volatile memory chip that contains these settings, disable memory overwriting, and enable booting from external devices. Cold boot attacks can then be carried out by booting a special program off a USB stick.”
Does pureboot mitigate against this type of attacks or is there anything the user can do?
A few countermeasures I can think of
pureboot password to change boot order. I know this probably can be bypassed with physical access. But any bypass will take time and can probably make encryption key in RAM degrade enough
I think that the article laid out the proper defense:
Make sure that you set a password to change the Coreboot settings and set the computer so it can’t boot from a USB port or do a network boot.
Set your computer to always hibernate (suspend to disk), rather than sleeping (suspending to RAM).
If you plan on leaving your computer in a place where people might tamper with it, do a proper shutdown. Then when you boot up, check your Librem Key to make sure that the Coreboot settings haven’t been changed.
You do benefit from being in a technological niche, since so few computers use Coreboot, but there are enough Chromebooks in the world, that a sophisticated attacker will have figured out how to deal with Coreboot, and not just focus on the UEFI from AMI, Award or Phoenix.
@kieran I’m mostly concerned about 1 and 2, where 1. computers is forcefully taken during use but a quick keyboard combination locks the screen without the time needed for a proper shut down. 2. the computer is taken when the user is in the bathroom, getting a (fake) delivery etc and it’s not feasible to completely shut down in every such instance
@peterpan I don’t think it helps if someone directly dump memory from RAM with an external OS?
Sure. But won’t help with the situation where a computer is forcefully taken during use but a quick keyboard combination locks the screen without the time needed for a proper shut down
You can create a hot key combination to hibernate your PC:
Create a script file to execute the hibernation: sudo nano /usr/local/bin/hibern8
Add the following lines to the file: #!/bin/bash systemctl start systemd-hibernate
Then, make it executable: sudo chmod +x /usr/local/bin/hibern8
Then, edit your visudoer’s file to allow it to execute the hibern8 command without a password: sudo visudo
Add the following line to the file: usernameALL=(ALL) NOPASSWD: /usr/local/bin/hibern8
(replace username with the username of your user.)
How could TPM password prevent USB booting or coreboot being overwritten? I think the TPM can only be used to measure boot metrics and detect tempering and and an admin password is just used to remeasure the boot metrics?
The script you provided for hibernation is very handy. Thank you!
Presumably Pureboot contacts the TPM chip to validate that you entered the TPM admin password before letting you change Pureboot settings or overwrite Pureboot.
The documentation isn’t clear whether you can turn off USB booting. I know that it can be done in Seaboot, but I don’t have a clue about Heads/Pureboot and I don’t own a Librem 13/15 to check. Probably this is question for @MrChromebox.
I don’t know about your computer but on mine there is no such thing as a fast hibernate. That means, in a very hypothetical situation, hibernate wouldn’t complete before the computer is snatched, and cold boot / liquid nitrogen attacks are possible.
Fast shutdown is probably safer for this application.
Presumably this is solvable by clearing the key before going into standby and then re-requesting the password to get the key back after coming out of standby. That is a convenience v. security trade-off.
That approach would presumably also work for lock but there is a big ‘if’ with that because, while the computer is locked, many processes operate in the background and some of them will need access to the disk. So it is almost as if “lock” has to become integrated with “standby”.
You could also modify that script so that instead of locking the computer hibernates/shuts down on key removal. Then no quick key entry is required (though I’d go for power button over key combination).
3.2 Decay at reduced temperature
It has long been known that low temperatures can signifi-
cantly increase memory devices’ retention times [29, 2, 46, 23, 41, 40]. To measure this effect, we performed a second series of tests using machines A–D.
In each trial, we loaded a pseudorandom test pattern into memory, and, with the computer running, cooled the memory module to approximately −50◦C. We then powered off the machine and maintained this temperature until power was restored. We achieved these temperatures using commonly available “canned air” duster products (see Section 4.2), which we discharged, with the can inverted, directly onto the chips.
As expected, we observed a significantly lower rate
of decay under these reduced temperatures (see Table 2).
On all of our sample DRAMs, the decay rates were low enough that an attacker who cut power for 60 seconds would recover 99.9% of bits correctly.
As an extreme test of memory cooling, we performed
another experiment using liquid nitrogen as an additional
cooling agent. We first cooled the memory module of Machine A to −50◦C using the “canned air” product. We then cut power to the machine, and quickly removed the DRAM module and placed it in a canister of liquid nitrogen. We kept the memory module submerged in the liquid nitrogen for 60 minutes, then returned it to the machine. We measured only 14,000 bit errors within a 1 MB test region (0.17% decay). This suggests that, even in modern memory modules, data may be recoverable for hours or days with sufficient cooling.
But I’m less worried about physical removal of RAM than if they simply reboot it from a USB drive and dump RAM directly in the Librem. If pureboot can at least protect against this kind USB booting without simple bypass https://blog.f-secure.com/cold-boot-attacks/ I will be happy.
Yes you can, the script only says:
1 - If the Librem Key is removed do action A
2 - If the Librem Key is plugged then to action B
What actions A or B are can be edited and changed.
You can create a modified version of this set it to power off the laptop if the key is removed.
Since the script used the device and vendor ID to identify the USB device in question you can also use this script with a generic USB device, say a usb thumbdrive, a USB wifi dongle, a LTE/UMTS/GSM HiLink Modem/Networkcard. You just need the correct vendor and device ID
That means, in a very hypothetical situation, hibernate wouldn’t complete before the computer is snatched, and cold boot / liquid nitrogen attacks are possible.