The Librem 14 does have a write-protect switch, but it has not been implemented yet.
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?
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.
If there is no librem key, then heads can’t detect tampering?
You can use TMPTOTP instead of a hardware security token. But the hardware security token is easier to use and more secure.
So, to detect tampering, you need a second device that a hacker doesn’t have or can’t mess with.
Can pureboot check tampering in /boot without a second device? UEFI secure boot does that.
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.
But, I want to know whether pureboot is able to check integrity of /boot without a second device.
That may be enough to deter remote attacks.
That depends on your threat model.
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.
I don’t think a remote hacker can gain full access to my system, but if a remote hacker gains full root access, can he flash a new firmware?
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.
PureBoot should not complain as long as the private key signing the files is the same as what PureBoot is expecting. The TPM’s PCRs does not store measurements of hashes for partitions, at least with PureBoot.
I think that’s a good news because if TPM starts measuring /boot, things will become complicated. /boot is already signed with a gpg key. As long as firmware is intact, you just need to check whether /boot is properly signed.
Complexity results from entangling two or more things. If TPM entangles firmware and /boot, then things become complex.