I just published an article that describes the history of Secure Boot, Heads, and PureBoot.
I was a bit disappointed by the official Purism documentation on PureBoot. It did a lot of hand-waving without actually explaining how it “measures” the firmware with Heads (to verify the integrity of the system before you type your disk decryption password). So I spent some time reading about Trusted Computing, Heads, Secure Boot, TPMs, etc and I just published the above article to help explain how all of this works together in PureBoot.
Hope you find this helpful if you want to understand how PureBoot actually works under the hood <3
Although I’m a computer expert, this is way too much for me.
I probably wouldn’t do anything beyond pureboot restricted boot.
I will not set up secure boot and measured boot on UEFI devices because it is a pain in the ass to set up, and secure boot and tpm will not protect me from internal physical access.
Firmware password could be enough to deter external physical attacks. Firmware password is easy.
I will probably just implement low-tech tamper detection methods like nail polish.
I don’t think it’s necessary to understand how Heads works under the hood in order to use it. Using it is pretty straight-forward. Understanding how it works is hard.
I will not set up secure boot and measured boot on UEFI devices because it is a pain in the ass to set up
Installing it is hard, but fortunately we have several manufactures that already setup Heads for you, so you don’t need to be a computer expert to benefit from trusted boot
Does UEFI secure boot combined with measured boot allow me to detect tamper evidences left by internal physical access done by a competent hacker?
Yes and no.
None of these technologies will protect you from someone who installs a small device with a microphone inside your laptop chassis.
But if they modify your firmware (eg replacing your FDE password prompt with a fake prompt that just relays your password to the attacker), then Heads will let you know. Yes.
PureBoot should not be trusted alone, as an attacker could simply replace the firmware with a malicious variant, or perform a full Evil Maid attack altogether.
I am assuming that remote hackers can’t mess with pureboot firmware.
Regardless of whether it can be hacked remotely, I want to know whether pureboot requires librem key to check integrity of /boot or whether it can check /boot integrity without librem key. I want to know what it can do without librem key.
Once PureBoot with the Librem Key has signed the boot partition, you do not need a Librem Key again until the files within the partition changes and you want to resign them. Here is a blog article from Purism explaining what PureBoot can do:
But, is librem key not required to detect tampering in firmware?
If I sign /boot files with a gpg private key, then librem key is not required?
It seems that pureboot alone can detect tampering in signed files of /boot and requires librem key to detect tampering in firmware and sign /boot files.
The Librem Key is required to detect tampering of PureBoot itself, but it is not required for signing the boot partition unless the files within it have changed. However, PureBoot’s integrity check of the boot partition, among other partitions, can be circumvented by replacing PureBoot with a malicious variant.
Yes they can. For example, the Coreboot utility script is used for reflashing the boot firmware with either the SeaBIOS or the PureBoot/Heads payload:
As mentioned earlier in this topic, the Librem 14 has a write-protect switch that is intended to prevent this remote attack vector, but it is not currently implemented.
If I manually sign /boot files with a gpg private key on my linux system, will pureboot complain that /boot is compromised?
Do I have to let librem key sign /boot?
I ask this because I don’t know whether TPM records hashes of /boot files. Pureboot may record hashes of /boot files when it signs /boot with librem key.