openSUSE Tumbleweed Adds systemd-boot Support

[drake23]

But don't Uefis also trust e.g. Microsoft's keys? So yes, they can boot what I've signed (given the uefi allows that) but would also always boot some ms signed thingy?

So my point would be that trusting that could be misleading once any third party simply signs with stolen/leaked keys (and e.g. the uefi hasn't been updated to revoke said keys).

To me the elephant in the room would be that at some point vendors would disable user signed booting hence blocking e.g. Linux installs.

Question is: is that fear hypothetical? Or what weighs more: the gain in security (if it actually is a gain) or the potential to exclude Linux from being used?

Also: once the evil maid has your laptop I think it might eventually not matter if they replace my grub bits or somehow look into the tpm. I'm sure quick ways to do that will be found

[yump]

Breaking that would require either a compromised firmware (in which case you are screwed, whatever you do, even "in software"). If we assume the firmware is not compromised, a motivated party would have to steal you computer, make sure they do not trigger chassis intrusion detectors, remove most of the hardware from the computer, desolder the tpm, mill it, use an electron microscope to put probes down, measure everything on boot and then, to avoid being caught, would have to reprogram another TPM to contain exactly the same information. If the TPM is included in the CPU, that's what you have to deal with.

It's not a binary choice between perfect and evil TPM.

Shoddy implementation (or equivalently, deniably evil) is more likely, and as always, a key that the TPM doesn't have, the TPM cannot leak.

[User42]

It's not a binary choice between perfect and evil TPM.

Shoddy implementation (or equivalently, deniably evil) is more likely, and as always, a key that the TPM doesn't have, the TPM cannot leak.

That's not what I said and that's not my point.

TPM-less (or, more correctly, non-hardware-backed) verified boot provides dreadful guarantees (actually a couple minutes resistance at most from a mildly skilled attacker).

With hardware-backed verified boot, we talk about highly skilled technicians needing unimpeded access over a very long time (days, weeks or months). What you quote supports exactly that.

The fact some vendors might possibly do evil implementation of TPM does not invalidate the fact that hardware is necessary to have any time and effort guarantee at all.

Regarding key leak, that's not how TPM works for boot validation and LUKS encryption keys. The only way to extract it is to gain root access on the verified host you want to compromise... But if you already have root access, you don't need to compromise the system... The only way this can be made evil by a vendor requires them to store the final decryption key somewhere, which is not deniably evil.

And all that being said, password+tpm+fido is a thing so you don't have to rely on all those things. But if you cannot trust what you boot (i.e. not verified boot), nothing prevents the compromised system to capture that final key and send it somewhere for future use. So claim all you want that just typing your password in and not relying on secure boot and TPM is better security-wise. The day just anyone is interested in you computer, they'll quietly replace grub by an evil version that will dump you key somewhere (possibly online). If they took the time to image your disk too, that's all your data exfiltrated. It's game over before you even know it.

[yump]

That's not what I said and that's not my point.

TPM-less (or, more correctly, non-hardware-backed) verified boot provides dreadful guarantees (actually a couple minutes resistance at most from a mildly skilled attacker).

With hardware-backed verified boot, we talk about highly skilled technicians needing unimpeded access over a very long time (days, weeks or months). What you quote supports exactly that.

The fact some vendors might possibly do evil implementation of TPM does not invalidate the fact that hardware is necessary to have any time and effort guarantee at all.

Regarding key leak, that's not how TPM works for boot validation and LUKS encryption keys. The only way to extract it is to gain root access on the verified host you want to compromise... But if you already have root access, you don't need to compromise the system... The only way this can be made evil by a vendor requires them to store the final decryption key somewhere, which is not deniably evil.

And all that being said, password+tpm+fido is a thing so you don't have to rely on all those things. But if you cannot trust what you boot (i.e. not verified boot), nothing prevents the compromised system to capture that final key and send it somewhere for future use. So claim all you want that just typing your password in and not relying on secure boot and TPM is better security-wise. The day just anyone is interested in you computer, they'll quietly replace grub by an evil version that will dump you key somewhere (possibly online). If they took the time to image your disk too, that's all your data exfiltrated. It's game over before you even know it.

I fully agree that physical security can't be neglected, however...

The way password+TPM is currently implemented by systemd-cryptenroll is worse than password alone. It's not days, weeks or months. It's 3 hours.

https://github.com/systemd/systemd/pull/27502

Note the linked paper, and the money quotes:

After having gained experience with the attack, we are able to perform the full attack on a new device within two to three hours.

n.b. I'm not sure whether that means a device unlike any they've ever seen, or just a new CPU with a chip-unique secret. If it's the first, some of that time could be front-loaded with a model computer in the attacker's lab.

An FDE tool that does not implement a TPM and PIN strategy with a defense-in-depth approach is the open-source tool systemd-cryptenroll. The systemd-cryptenroll tool is part of the widely adopted systemd project and acts as a management tool for encrypted disks conforming to the popular LUKS standard [44], [45]. Support for TPM based protections has only been introduced recently and includes a TPM-only and a TPM and PIN strategy [21], [41]. Our analysis of the systemd-cryptenroll code shows that a randomly generated 256 bit secret is directly sealed by the TPM, protected either by a PCR policy only or additionally a PIN. The so-called LUKS keyslot (analogous to BitLocker’s VMK) is then encrypted with the base64-encoded secret as passphrase.

Once the NV state is decrypted, the LUKS key is directly accessible and no brute-forcing is necessary.

I did try to warn them about trusting TPMs too much.