As referenced at the following link and other places, PureBoot for Librem laptops relies on the Intel TPM to verify the earliest stages of the boot process. ( https://docs.puri.sm/PureBoot.html ). If I understand TPM correctly, a cryptographic private key is hidden within the tamper-resistant hardware of the TPM, so that the key is only known to that particular piece of hardware and to Intel (and the actors they share the key with). That is, the owner of the device has no practical way to access the private key(s) of the TPM.
Relying on such technology for PureBoot seems highly contrary to personal freedom and a person’s control over their own devices. Am I misunderstanding TPM or PureBoot? I am glad to see that the Librem 5 does not include a TPM, but for laptops, I hope for some more clarification.
I mean up to a point, if it’s a dedicated cryptographic processor implemented by Intel then in theory it may have a backdoor that allows keys to be exfiltrated to Intel but if you don’t trust this CPU, you probably don’t have any reason to trust the homunculus CPU (IME) or the main CPUs (x86) - all implemented by Intel - and Intel may find that compromising those other CPUs is more productive.
To analyse in more detail would require knowing the precise nature of Intel’s implementation of TPM, which may differ from one platform to another (although I suppose we can take your enquiry as applying specifically and only to the Librem 14, its CPU and its chipset).
Exfiltration from the TPM implementation could be difficult, depending on the specific hardware interface to the TPM implementation.
That is intentional. The keys are intentionally hard to get at by anyone, the owner of the device, or the stealer of the device (or even the manufacturer of the device).
The private key(s) may be “write-only”. That would need checking e.g. can the owner of the device generate a new storage root key and write it to the TPM? But I guess in the worst case, it could be opaque to the owner if the TPM just threw away the new key and continued to use an existing key.
There is an Endorsement Key (EK) in the TPM that allows the TPM to prove its authenticity, and that does involve a private key that Intel knows and that you intentionally don’t know (and presumably can’t change). It is my assumption that the EK is not used in any other cryptographic operations.
Since TPM is just an interface specification, a secure platform is free to ignore the Intel-supplied TPM implementation and use a separate TPM somewhere on the platform. Whether Pureboot can use that I don’t know.
I wonder, what is the role of the Endorsement Key in PureBoot? Is it used in any way? Does relying on the endorsement key in PureBoot facilitate intel or anyone who knows the endorsement key to forge a boot image, et cetera?
The purpose of using the TPM with PureBoot is to have a discrete, separate-from-CPU chip on the device which is tamper-resistant and can perform its own cryptographic operations and store keys that stay on chip and can’t be extracted by an attacker. In this use case you can think of it much like an OpenPGP smart card on the Librem Key or inside a Librem 5.
For the case of PureBoot the only secret it stores is its copy of the HOTP secret it shares with the Librem Key. The way that HOTP works, each side has a copy of the private key and each use that private key along with an incrementing counter to generate a 6-digit code.
When you boot, the system sends firmware measurements to the TPM and if they match what you as the owner (you are in control here) told the TPM was the correct “gold” version of the firmware, it will release that HOTP secret and generate the 6-digit code and send it to the Librem Key, so the Librem Key can validate it matches what it generated on its end.
The TPM and laptop are authenticating itself to your Librem Key, which is under your control. Both devices keep their copy of the HOTP secret, secret by design, but you can also regenerate a fresh secret at any time.
It is separate from the storage root key. It is optionally used by the host software to verify the authenticity of the TPM (but this is only possible if you trust the manufacturer and make yourself in a sense dependent on that manufacturer, and of course assume that the manufacturer is not compromised in some way).
Imagine that you had a computer with a discrete TPM implementation and you were up against a sophisticated, well-resourced attacker who is not the US government and who can interdict your device and replace the TPM implementation with one of their own that has an intentional backdoor. The EK would allow the host software to detect the counterfeit TPM implementation. (I would think that this attack would be much harder against an integrated TPM implementation. How it would apply to a firmware / software TPM implementation is a different question.)
Of course the EK does create yet another unique identifier for your computer, which is not ideal for privacy.
Considering the bigger picture question … “Is a TPM a good thing?” … I think you need to look at it in terms of cost / benefit. Yes, it is yet one more CPU with an attack surface (and there are a number of known attacks against specific TPM implementations) and a potential backdoor - against niche sophisticated attackers. On the other hand, it provides the benefits that Kyle mentions in his post - which are useful against most attackers.