openSUSE Tumbleweed Adds systemd-boot Support

[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.

[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]

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.

[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

[User42]

User42
The encrypted boot setup was the default when I installed leap 15.3 back in the day (now upgraded to the, but the setup still holds).

How would one move the SSD to another system when secure boot comes into play?

I think my point is that I do trust software more that uefi/hw implementations when it comes to security. And one should know by now that code signing is not that effective if keys leak out (looking at ms/azure recently)

The modern way of doing trusted computing on the desktop/laptop is to separate concerns as much as possible.

The system is something you can backup/restore or redeploy. The only thing you want to make sure of is that what you boot is what *you* have put in place. This is usually done by encrypting `/` (but dm-verity could work very well there too!) and make sure that your boot chain is *exactly* what you think it is so upon installation, you sign a unified kernel and all the bootloader machinery to make sure the system is exactly in a state you control (with Secure Boot and possibly TPM decryption).

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.


If the alternative is having unsigned grub decrypt your root fs, compromising such system is trivial. I really mean it. All you have to do is boot another system (either by "borrowing" the SSD for a couple minutes or by pressing F12) and replace grub with an evil version.

To make sure what you boot is what you intended, you need hardware, software alone won't bring you far.

And before you object hw can't be trusted and could leak out your keys, it's the same for a pure software solution.

Don't get fooled by grub not being on a mountable partition in legacy BIOS systems. It's as easily accessible as grub itself on a efi fat partition.

[t.s.]

Great news! I've tried switching my installation of TW to systemd-boot a just a few weeks ago, but it was so fiddly I reverted back soon after. I've been using systemd-boot on my Gentoo box for years now, and I find the overall experience with it much more pleasant that GRUB.

I want to use systemd-boot too, but with btrfs and snapshots. And it looks like there's no easy way to set up that.

[drake23]

User42 Thanks for taking the time to respond!

The encrypted boot setup was the default when I installed leap 15.3 back in the day (now upgraded to the, but the setup still holds).

How would one move the SSD to another system when secure boot comes into play?

I think my point is that I do trust software more that uefi/hw implementations when it comes to security. And one should know by now that code signing is not that effective if keys leak out (looking at ms/azure recently)

[User42]

Thanks, so it can't do what GRUB currently can. Hoping this gap will be closed so feature parity is reached and it is really a valid choice

It's not because you don't know how things can be done that they can't be done.

[User42]

No, the open suse setup is actually with encrypted /boot, so grub decrypts /boot BEFORE initramfs gets loaded. Hence my question if systemd boot works with that kind of setup.

I am not sure this is the default way tw is doing things plus this setup has been overseeded by a more secure one (efi + secure boot + unified kernels).

What's the point of encrypting /boot if I can replace grub with my evil version (it's as easy as replacing the kernel) and, even if you have secure boot enabled, if I can craft an encrypted partition that will exploit your existing grub?

Arguably, this is harder but grub does not run under the kernel: there is about 0 vulnerability mitigation and its surface of attack is very large (so we have luks, dm-crypt, different forks of different file systems, probably other interesting modules too). Finding exploits is not far fetched... And all of this for what? To hack together what can be cleanly implemented today under EFI with no bootloader at all (just EFI entries) or a simple one...

The additional advantage is that such simpler boot types tend not to fail as much as grub does (just have a look on any distro's reddit to see at least a dozen "my computer does not boot" and variations systematically solved by booting on a livecd and running grub-mkconfig again).

[andyprough]

Tantrum distro for tantrum people

I don't use Artix dinit, but I can pretty much guarantee that it will run significantly faster than anything you are running, unless you are running something like a custom gentoo rig with s6. It's not a tantrum distro by any stretch of the imagination, it's a distro that's designed for exceptional speed, and it's supported by the larger Arch developer community, just as the openrc variants have been for a significant number of years.