Hi linux22, dobp and folks,
Congrats, Naldi, for managing to do LUKS unlocking with TPM2 + PIN, with LMDE + `
dracut
` ! I actually stumbled upon `
dracut
` a couple months ago, that looked exciting (solving many problems), but I understood somehow that it was not available to us. Your explanations about late Debian implementation of TPM management are interesting (they'r probably not lazy, there are probably complex struggles behind this. Debian is the most democratic distro). It's nice to see that now the PIN solution can work with LMDE. Have you heard about the upcoming ukify command, by systemd? It will make a UKI with one command, apparently.
I recently understood a basic thing. A year ago I asked here for confirmation that `
/boot/efi
` was or wasn't encrypted. Dobp replied first, with interesting points about security, but what I still did not understand (I thought there was a contradiction because your tutorials say "with /boot encrypted", and I saw that the partition that boots the OS is not encrypted...). Now I get it. I found our (I say "our" because I followed your tutorials) Secure Boot keys in /boot, and I thought holy sh... if `
/boot
` is not encrypted, then for 3 years, anyone could have stolen my EFI keys! But then I understood that while yes, `
/boot/efi
` is not encrypted, `
/boot
` *IS* indeed encrypted. It doesn't show on `lsblk` because `/boot` is just a subfolder of `
/
`, but it is encrypted.
/boot/efi
on the other hand is not encrypted, but as dobp explained, only signed binaries can be ran from it (and I add : our keys are not inside it).
When I followed your tutorial in 2019, I just wanted Secure Boot. Only much later did I understand the difference between "simple" Secure Boot, and UKI, Unified Kernel Image UEFI apps.
I stumbled upon old posts, where you said (or maybe in a "preface" of your tutorials) why you chose UKI in the first place (a long, long time ago). Because all your other successful attempts at Mint secure boot were ruined at the first kernel update. So that happened by chance!
So, years later I understood that I happened to be one of the happy few who had their `initrd` protected from tampering. Not just a simple Secure Boot, but a premium secure boot!
I hadn't reached that level of understanding when I made my last post ITT, that was moved to another section of the forums (of course nobody replied, it would have needed lots of rephrasing and contextualisation to be interesting as a separate thread).
In the Kroah-Hartman article I posted
, he precisely explains how UKI is better than simple secure boot, and is the future. But of course that is still vulnerable, until (he says) we have (like Windows??) a fully
measured boot, meaning that when a secure stage is completed in the boot process, a cryptographic key is computed, stored in a TPM register, then when the second stage is done, another key is computed with the 1st one, in a chain a bit like the blockchain principle, making the boot process cryptographically secure.
I see that you are now also using these unused TPM registers, but I'd have to dig deeper, I don't know if it's the same thing as what I read.
I haven't checked this thread here in a long time, so I just saw your post about
https://github.com/wmcelderry/systemd_with_tpm2. Well, he says it's not a UKI ! And now I want a UKI ! But he says,
NB2: Apparently the Linux kernel now measures it's own initrd, so if the systemd-cryptenroll is called with the correct registers, then that may be covered off
but it is not quite satisfying. (but he has another repo with UKI, which I will check.)
Anyway, I learnt lots of interesting things about encryption and security, it wouldn't have happened without your tutorials!
As for me, I disabled TPM, I think I will do your 2019 tutorial again, I'm exhausted, I don't want to think anymore. (but I've had to, because I'm doing something a little but custom) (I also dived into LibreBoot for a moment, fertig! (enough! (for me)))
Lots of congrats again for bringing more security to Mint and Debian based distros!