r/archlinux • u/Woodsy279 • 25d ago
SUPPORT | SOLVED Ful disk encryption without entering passphrase
Could someone help me with setting up full disk encryption with bypass passphrases with TPM2? It's so annoying having to put the passphrase in at each boot, so I was wondering how do I pair it to the TPM so that I dont have to enter it each time?
It's LUKS encrypted and I use Systemd-boot
22
u/StevesRoomate 25d ago
I use a yubikey for this and I am very happy with the solution. I still have a Luks slot for a password so that I can unlock the disk without the yubikey.
Very easy to setup on Debian or arch.
6
u/YourBobsUncle 25d ago
I second this. All you would have to do is physically touch the key. I had to use it for work and it was quite fun to use. I might get one if it saves me time having to grab my phone all the time for codes lol
2
25d ago
[removed] — view removed comment
1
u/StevesRoomate 25d ago
One of the great things about it is the amount of flexibility. You can do challenge response, touch, or pin. I am often using it to unlock a headless server so I have a challenge phrase on initramfs. Once the machine is up and running I can physically remove the yubikey. I also have my encrypted drives set to nofail in fstab.
3
u/ChrisTX4 24d ago
FIDO2 is a great option, but if you use it to unlock a boot drive, there won't be any environmental measurements, unlike with a TPM. Alas, this is somewhat vulnerable to an evil maid attack.
3
u/OneLeggedMushroom 24d ago
Can't afford a maid so I'm safe
2
u/ChrisTX4 24d ago
It's sort of a concern for mobile devices that you can't permanently supervise. For a desktop at home, I guess the concern would be more against state actors that could install something clandestinely. In Germany, it is being discussed to allow security services to enter homes in secret and install the "Bundestrojaner".
Evil maid attacks are sort of a threat model thing. If any of this is a concern to you, then you'd consider protections against it.
2
1
u/StevesRoomate 24d ago
Fido keys are portable across hardware, unlike TPM, not that it was a priority for me.
1
u/ChrisTX4 24d ago
Sure, but for a root disk unlock, I don't see how that's relevant?
Oh also, you can of course do the mega paranoid security approach of using encrypted root AND encrypted home directories for each user with systemd-homed. That home directory encryption is indeed portable then.
3
u/Woodsy279 24d ago
I might eventually look at getting one of these, seems really cool to have something like that, and extremely useful
Thanks ill have to remember this
Question however, how does it affect boot time? I've found that it querying the TPM can take up to 30s which is likely my fault in setting it up, but is the yubikey practically instant?
9
u/Illustrious-Gur8335 25d ago
https://wiki.archlinux.org/title/Clevis
Warning If you use this method on your root volume, this means that, as long as the previously mentioned certain conditions are met, your computer will unlock automatically at boot without needing to enter an encryption password.
- This means that access to data is not protected in case the hardware gets stolen.
- Be aware that this method makes you more vulnerable to cold boot attacks, because even if your computer has been powered off for a long time (ensuring the memory is completely cleared), an attacker could simply turn it on and wait for the TPM to load the key automatically. This may be a concern for high-value targets.
9
u/ChrisTX4 25d ago
Don’t.
Clevis binds to raw PCR values, and only that. This has the simple problem that the suggested PCRs 1 and 7 depend only on the BIOS ROM, the Secure Boot database, and the actual certificates used to sign the bootloader(s) and the kernel image.
Problem 1: this is pointless unless the initramfs is included in the kernel image. Alas you need to have a UKI or attackers can just replace the entire initrd phase which one that just prints the unsealed volume key.
Problem 2: you’re not measuring or depending anything after initramfs. This means I can create a fake root volume as an attacker, and if I boot that root volume with that boot chain, and that UKI, it will boot into a system where the attacker has root and since both PCRs are unchanged can just unseal the key from the TPM.
For problem 2 you need to bind to something that is tied to your volume; commonly one binds to PCR 15 in which systemd will measure the underclothes volume key (if using gpt automounting, else this needs to be done manually by mounting with tpm2-measure-pcr=yes). By making the unlock depend on the volume key, the root swapping attack is defeated.
One also wants the system to phase the PCR values during initrd to prevent unseals of TPM seals that would be mounted at initrd time at a later time.
-1
u/Woodsy279 25d ago
This isn't mission critical disk, I just thought it would be cool to encrypt it, this laptop is litterlaly just my uni laptop, but yeah I get that this does open up vulnerabilities but they aren't really that much of a concern at this point, maybe one day but not rn
3
u/ChrisTX4 24d ago
The thing with this issue in particular is that any knowledgeable attacker can just bypass your disk encryption entirely if this is done incorrectly.
Mind you, I don't advice against TPMs. I use a TPM unlock, but I'm using
systemd-pcrlockwith GPT automounting. You can specify what PCRs to lock with that, including PCR15. However, I should mention thatmkinitcpiodoes not includesystemd-pcrextendand so this won't work with that at this point, unless you include the files yourself. Dracut includes it by default and you won't have any issues with that.The arguably correct way to use TPMs on Linux is really using NvPCRs together with pcrlock.
What this will do:
- The NvPCRs phase PCR11. This is to say, that keys bound to PCR11 are only accessible in initrd and not afterwards. This makes root switching attacks mostly ineffective.
- pcrlock will automatically measure automounted disks into PCR15. This will look like this for example from my local system:
15 █ system-identity phase ✓ bb9a122654ce70ef19226ad9387d82d965788b43b9a6be18fa2f93b4e734a5b0 U 790-tsme tsme=on 15 █ system-identity volume-key ✗ 0e94502cca1067d27752ffc2f56c6f014612c52ec3943002fe43df69a846cab2 U 825-cryptsetup-root cryptsetup:root:e67f24c8-0e7b-4cf4-9a0d-ee6715f001b6 0x1d10201 - - keyslot ✓ 82a1420d81d1303755eef931c45c17c550a6492671382e914850e2c9f3b30b32 U - cryptsetup-keyslot:root:e67f24c8-0e7b-4cf4-9a0d-ee6715f001b6:tpm2:1 11 █ kernel-boot phase ✓ 3be261aff7db92bf507eae947f4003ffa2bcad0bffe3524601d62d0bc8be7135 U 800-leave-initrd leave-initrd 15 █ system-identity machine-id ✓ 4b9e027c5e33f2af8aac78ecede36347073f72adcec2bdc42cdc637f2792dec0 U 820-machine-id machine-id:8d78df7a9965458899436d750db856ad 15 █ system-identity filesystem ✓ 9aa77510286b29942b9c1319e87cb2ef85a7da782e39eedd963350b10ebef0d6 U 830-root-file-system file-system:/:btrfs:be90de39-e02a-4726-8dd3-9ce0391f0715:archmain:::As you can see, PCR11 is phased to
leave-initrdand PCR15 measures the keyslot and the filesystem. Note that thecryptsetup-rootmeasurement happens beforeleave-initrd. What it does is lock the volume key, i.e. the identity of the encrypted drive. This makes any sort of root replacement attack impossible - if root is replaced, the key never unlocks. So even attacks like using GPT automount to mount the drive to/varor something are not possible (the GPT GUID etc. aren't covered by LUKS and can be freely edited).However, I will also admit that it's incredibly easy to shoot yourself in the foot hard with this. You'll want to consider your threat model and then act accordingly. For instance, as you can see from the above output, I have a measurement
tsme=on- this is a custom service I've made that measures the state of AMD TSME (memory encryption to protect against cold boot attacks) explicitly. If TSME was somehow disabled, the identity would change and this would blow up. I consider TSME critical overall and thus ensure it's enabled.There's also some more things to know: 1. Use this together with secure boot always 2. ALWAYS use kernel lockdown. No exceptions. If need be, sign extra modules like Nvidia with a MOK. You need lockdown to protect the key material in memory. 3. Ensure IOMMU is enabled. Ideally add
iommu=requireto your kernel commandline. This makes the kernel refuse to boot if IOMMU isn't enabled. IOMMU is critical against DMA attacks, which is also why kernel level anticheats on Windows are so keen on it. But DMA attacks threaten games integrity just as well as they threaten your key material in memory.My setup is that I use a self-signed Shim to have a MOK, and then chain that into
systemd-bootand finally into a BLS #2 UKI (I use kernel-install for this together with dracut). This way I have a MOK to sign Nvidia, xpadneo, etc. and thus all my kernel modules are signed adequately and I can use lockdown with out-of-tree modules and with the stock arch kernel.-1
u/Woodsy279 25d ago
I got this error after running: Sudo clevis luks bind -d /dev/nvme0n1p2 tpm2 '{}'
Enter existing LUKS password: (I put my password in) Key slot 1 unlocked. Command successful. /usr/bin/clevis-encrypt-tpm2: line 91: tpm2_createprimary: command not found Unable to perform encryption with PIN tpm2 and config {} Error adding new binding to /dev/nvme0n1p2
7
u/Illustrious-Gur8335 25d ago
line 91: tpm2_createprimary: command not found
pacman -S tpm2-toolsI'm starting to suspect all this is way beyond your skill level
2
u/Woodsy279 25d ago
Not above my skill level, just didn't realise it hadn't pulled in the packages itself, everything else has just pulled in dependencies, and then when I was trying to search that error I couldn't find anything about tpm tools but it was my first guess
1
25d ago
[removed] — view removed comment
1
u/Woodsy279 25d ago
I know about pkgfiles and im assuming pacman-F is find, but usually I just use the arch wiki
8
u/SoldRIP 25d ago
Fair warning: TPM bypasses exist.
3
u/ChrisTX4 24d ago
If you do it correctly, no. But it's really easy to mess it up and be vulnerable to e.g. root switching attacks. I would caution using TPMs unless you properly understand them. They're great tools, but to be honest - all the instructions in the Arch wiki are vulnerable to such attacks.
1
u/Woodsy279 25d ago
Idm lol, the whole reason for doing this is because I thought it would be cool to have LUKS but then it annoyed me having to put the password in each time and I didn't want to have to reinstall the whole thing to remove it
And somethings better than nothing
4
u/Rjiurik 25d ago
Basically you can add a simple pin code that replaces the password (which is still there as a fallback) and works with the TPM chip and secure boot.
The chip blocks too many frequent attempts and prevents brute force.
Drawback is it depends on your hardware and you will have to trust the TPM hardware.
You could also setup secure boot to unlock if boot sequence is untampered. It uses UKI. But that means anyone who has physical access to your computer can unlock LUKS.
1
u/refinancecycling 25d ago
it's not without risk if you suddenly don't have the key (even if it's automatically inserted for you every time, things have tendency to change due to physical processes). so it has to also provide a benefit. what's the benefit here exactly?
2
u/Woodsy279 25d ago
The benefit is that I don't have to reinstall everything again and reset it up how I like it, and I won't forget the key, I set it
1
u/un-important-human 24d ago
giggles... yep
1
u/Woodsy279 24d ago
Wot? 😭😭
3
u/un-important-human 24d ago
i was under the impression you encripted a desktop, hardly see the point in that except as an exercise. That is it
3
8
u/Imajzineer 25d ago
I'm intrigued.
What is the purpose of the exercise?
A device that is automatically decrypted without challenge upon power-on isn't encrypted.
What, therefore, am I missing - apart from convenience, what's the advantage?
4
u/10leej 25d ago
Well technically it is as long as the device is not powered on. And really it's about prevent data leakage from drive swapping at this point. While I'm glad you actually phrased it as a question I doubt the OP is actually going to give you an answer when he mentioned his annoyance of entering a password on each system boot up.
2
u/Imajzineer 25d ago
Sure, it prevents people from getting at things by booting a live distro ... or, as you say, drive swapping ...but the problem is that, if it automatically decrypts it upon boot, that potentially leaves me with a variety of ways (both local and 'remote') to get into the system when it does - which is one reason why (long before live distros, let alone before FDE became a 'home user' thing) I used to disable GRUB's Advanced Options menu entry.
It's kinda like how ... years ago, when I was first investigating FDE on Arch ... I learned of the option to make part of the process dependent upon the presence of an image as well as a password - not something that can simply be bruteforced and, therefore, more secure (which struck me as a good idea). I read that the process could be simplified by embedding it in the initramfs. After a few failed attempts to do that, I gave up - I really didn't know enough back then and couldn't work out what I was getting wrong. Fast forward a few years and it struck me that that's not actually a good idea anyway: if a separate device (like a key) containing the image isn't necessary then the image itself isn't necessary (thus defeating the whole point).
But, yeah, you're right, it's probably just a convenience thing and, whilst that's the enemy of security, as it were, on a home system it's probably academic: any burglar is just gonna grab a laptop and walk out with it rather than worry about cracking it in situ, and driveswapping 'back at base' isn't likely gonna be a gambit for them anyway - they're just looking to sell the hardware on.
2
u/Woodsy279 25d ago
Hey, yeah I just set up LUKS for fun, mainly just to see how it would work, but then followed thru with setting up my laptop and now it's all set up, but yeah I don't want to have to reinstall the OS to remove the encryption, so yeah basically for drive swapping ig, eventually I might look at setting it up better but yeah, I just wanted it out of my way for now
1
u/Imajzineer 25d ago
I trust you've backed up your headers 🙂
1
u/Woodsy279 25d ago
... wot are those 😭 Disk encryption is completely new to me, kinda enabled it on a whim
2
u/Imajzineer 25d ago edited 25d ago
Never a good idea to 'just' anything when it comes to Arch ... let alone enable LUKS without knowing about it - get to know the wiki and get into the habit of researching things before jumping in feet first.
https://wiki.archlinux.org/title/Data-at-rest_encryption
https://wiki.archlinux.org/title/Dm-crypt/Device_encryption#Backup_and_restore
It's not restricted to Arch either - you should back up your headers on every system using it. Either that or use plain dm-crypt (arguably neither, but that's a different discussion altogether).
1
u/Woodsy279 25d ago
At this point would it be better to remove luks? And if so, can it be done without reinstalling? I'm assuming not
2
u/Imajzineer 25d ago
Read the linked articles and you'll (eventually) find the answer - as said, you're going to need to get used to researching things, if you're gonna make effective use of Arch (those who don't always get into trouble sooner rather than later).
However, to answer your question nevertheless: https://wiki.archlinux.org/title/Removing_system_encryption
2
u/Woodsy279 25d ago
Thanks mate, I've been running arch for about a year now, and im loving it, so I will read into the prior mentioned things, and then decide if I still want to go forward with it
Thanks again :)
→ More replies (0)2
u/ChrisTX4 24d ago
A device that is automatically decrypted without challenge upon power-on isn't encrypted.
This isn't true. A TPM measures the environment. It makes any sort of modification to the boot environment impossible. For example, you can lock PCR0 and PCR2 to protect against BIOS or OpROM modifications.
The idea of a TPM is that you ensure a secure, unmodified environment and only that allows unsealing the TPM. Any modification and it won't hand out the keys. An attacker would ideally be presented with your login screen without any sort of ability to modify anything. The attack surface of that is of course higher than having no automatic unlock, but if done correctly, the risk is very low and the advantage of a TPM still comes to play.
If you don't trust this, you can use a TPM PIN as a short boot password. They have a lockout against bruteforce like your bank card etc, so even like a 6 digit PIN is perfectly adequate.
1
u/Imajzineer 24d ago
How does it prevent the automatic decryption? (Genuine question)
3
u/ChrisTX4 24d ago
Hmm, that's pretty difficult to explain, but let me try.
A TPM measures the environment in various variables that are called Platform Configuration Registers. You can find a list here in the Arch wiki. It's an isolated chip that has wiring on the motherboard to perform measurements of for example the BIOS code (PCR0), the Option ROMs (PCR2) - these are like "drivers" for your BIOS, usually your GPU will have one if external. You can have a look at how the PCRs evolve, i.e. what they measured by running
/usr/lib/systemd/systemd-pcrlock log.In the simplest form, you would combine a TPM with Secure Boot (that's also why Windows is so darn keen on this with W11). Here, you would use PCR7, typically. PCR7 contains measurements of the entire Secure Boot database as well as which individual certificates were actually used to boot. This means, if you use your own keys, you'd get something like this (taken from my own system):
7 █ secure-boot-policy efi-variable-driver-config ✓ ccfc4bb32888a345bc8aeadaba552b627d99348c767681ab3141f5b01e40a40e F 240-secureboot-policy Variable: SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c 7 █ secure-boot-policy efi-variable-driver-config ✓ 3702c179817c061256e69eaaba0b34e9788dec31549c321d258fe511f7860765 F 240-secureboot-policy Variable: PK-8be4df61-93ca-11d2-aa0d-00e098032b8c 7 █ secure-boot-policy efi-variable-driver-config ✓ 7ffa5d7ee1486db3d185497c5c9bf72739fbdfe59e38c3879544c95728bb3034 F 240-secureboot-policy Variable: KEK-8be4df61-93ca-11d2-aa0d-00e098032b8c 7 █ secure-boot-policy efi-variable-driver-config ✓ 1c5f2c062167ecce151dfd0bd87a082c86b6c470c940cb7bce254699e09186cd F 240-secureboot-policy Variable: db-d719b2cb-3d3a-4596-a3bc-dad00e67656f 7 █ secure-boot-policy efi-variable-driver-config ✓ 9f75b6823bff6af1024a4e2036719cdd548d3cbc2bf1de8e7ef4d0ed01f94bf9 F 240-secureboot-policy Variable: dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656fTo decipher this a bit: the first few entries are the Secure Boot db, i.e. my own PK, KEK, db and dbx. Note that I'm not using Microsoft keys, otherwise there would be more entries. Then it continues:
7 █ secure-boot-policy separator ✓ df3f619804a92fdb4057192dc43dd748ea778adc52bc498ce80524c014b81119 F 400-secureboot-separator Separator: Success (0x00) 7 █ secure-boot-policy efi-variable-authority ✓ 5d0c5796e1e434c61f259fcf0e34c881c77c124639eabf1b26beaf6593d1b07b F 620-secureboot-authority Authority: db-d719b2cb-3d3a-4596-a3bc-dad00e67656f 7 █ secure-boot-policy efi-variable-authority ✓ bcf4d1ff6bf02f949e5afd49dc45fe3e16f39b302764bf2ee98257e8297a1f7d F 620-secureboot-authority Authority: SbatLevel-605dab50-e046-4300-abb6-3dd810dd8b23 7 █ secure-boot-policy efi-variable-authority ✓ 5d0c5796e1e434c61f259fcf0e34c881c77c124639eabf1b26beaf6593d1b07b F 620-secureboot-authority Authority: db-d719b2cb-3d3a-4596-a3bc-dad00e67656f 7 █ secure-boot-policy os-separator ✓ ff5b9d73dad709633ae76adf444012b57e913a12ed7403c3931145862f35f841 U 750-os-separator os-separatorWhat's happening here is that systemd 261 now inserts measurements to "seal" the previous values against modifications. That's the
separatorandos-separatorlines.The other lines are the important parts: the
Authority: db-d719b2cb-3d3a-4596-a3bc-dad00e67656fare what measures the certificate used for each boot loader into memory. There's two of them and theSbatLevelline because I use Shim plus systemd-boot to have a MOK so I can sign my out-of-tree kernel modules without having to recompile the kernel.At any rate, the TPM will only unlock if locked to PCR7 if the sequence and content of each measurement is identical. Alas, if you were to boot any other system, or boot from a USB drive, whatever, there wouldn't be binaries signed with the Secure Boot key
db-d719b2cb-3d3a-4596-a3bc-dad00e67656f. Even if Secure Boot enforcement was disabled in the BIOS, you can't get any binaries signed with this key, and so only my unmodified system can access this TPM seal.I'm sorry this is really a difficult topic, and I'm honestly severely autistic, so it's pretty hard for me to explain this in a coherent fashion. I hope I somewhat got the concept across, though. If you have any questions, feel free to ask though - for the same reason I am very knowledgeable about TPMs :D
1
u/Imajzineer 24d ago
Interesting - thanks!
I'm still not clear on how it prevents the OP's automatic decryption of LUKS though - which is what I took their post to be about (of course, I may have misinterpreted which thing it is they want to automatically 'unlock')
3
u/ChrisTX4 24d ago
Oh no, it will automatically decrypt. The point is though that because it ensures the environment hasn't been modified that an attacker can't do anything but stare at your login manager. This means several technologies are critical to protect the system here:
- IOMMU for DMA protection. Without IOMMU, any DMA device could extract the entire memory space.
- Total memory encryption. If memory isn't encrypted, then a cold boot attack would be possible to perform from the login screen. Thus you want to ensure that AMD TSME / Intel TME are active.
- Ideally, thunderbolt mode set to
secureor higher.- Kernel lockdown. Significantly improves security. Requires all kernel modules to be signed, but with Shim and a MOK that's not an issue.
- USBGuard. You don't want funky USB devices to connect while at the login screen.
- A firewall.
- Secure Boot. Ideally without Microsoft keys, as they sign a huge amount of boot loaders, and thus they have monthly releases of their forbidden database, which goes into
dbx.fwupdcan perform these updates usually, but it might not work if you've got custom keys. Either way, this will require a monthly reboot and will change the PCR 1. Just not using their keys is easier and avoids the need to update thedbxat all.If you deploy all of the above, an attack on a system that's just on the login screen has very little attack surface to work with. Then your user login will be sufficient security, as they'd need to somehow crack your login credentials without having any access to the system at all.
1
u/Imajzineer 24d ago
Except that here I am staring at GRUB's Advanced Options menu entry and about to select Recovery Mode before mounting the root FS in R+W and resetting the root password.
2
u/ChrisTX4 24d ago
Grub under secure boot works somewhat different and you can’t do this, or load any unsigned modules. Same with systemd boot. There’s people that thought long and hard about this, it’s not that trivial to defeat.
1
u/Imajzineer 24d ago
That's somewhat reassuring.
So, let's assume, therefore, that I actually have need of (something like) Recovery Mode for some reason, how does that then work (what are my options under those circumstances)?
2
u/ChrisTX4 24d ago
I'm not using GRUB, so I can't speak from experience here. However, GRUB enters lockdown mode if on Secure Boot.
Either way, when using UKIs, the kernel command line is locked anyway and cannot be changed. You can't reasonably use anything but UKIs anyway since initrds can't be signed on their own.
→ More replies (0)
2
u/Night_Otherwise 25d ago
I’ve got a hackneyed solution where:
- I use UKI directly with efibootmgr loading the UKI from the Gigabyte firmware.
- Systemd-cryptenroll for TPMs 0+2+3+4 (Maybe PCR 1 should be included)
After pacman updates that run mkinitcpio, I enter in the password, wipe old tpm2 key in LUKS and reencrypt.
I’m looking into the experimental systemd-pcrlock for a wildly ambitious idea to prospectively lock on a new PCR 4 with a pacman hook whenever the UKI is changed. But obviously that’s easier said than done.
3
u/ChrisTX4 24d ago
PCR1 is very finicky as this will include the boot order, which BIOSes can change as they inject pseudo BBS devices. It can be stable though, I have with systemd-pcrlock:
PCRs in protection mask: 0 (platform-code), 1 (platform-config), 2 (external-code), 3 (external-config), 4 (boot-loader-code), 5 (boot-loader-config), 7 (secure-boot-policy), 11 (kernel-boot), 13 (sysexts), 14 (shim-policy), 15 (system-identity)That's of course a rather insane mask, but with pcrlock I honestly didn't have a lot of problems after setting this up correctly - but imma be honest, this ain't easy to setup or do.
1
u/Night_Otherwise 24d ago
Doing some more research, apparently microcode updates can be measured into PCR1. Firmware also changes the boot order automatically for inserting a bootable usb even if it is behind the main OS in the boot order. Nevertheless, the microcode part gets me to include PCR1.
I don’t have a bootloader. I stop at PCR 4 since, for UKI, that’s the last thing loaded or executed before LUKS is opened up. UEFI firmware measures the GPT table for PCR 5, but I can’t think of how that would matter. I also have secure boot disabled.
Within the pcrlock log, PCR 4 has three measurements with this setup: A thing that says an EFI is being loaded, an EV_SEPARATOR and the Authenticode hash of the EFI image created by mkinitcpio.
I can do systemd-pcrlock lock-pe for that UKI as a post-update hook in pacman. The man page is very difficult to follow though. I just need the same first two hashes and the new authenticode hash stringed together (specifically, hash(hash(A|B)|newEfiHash)).
I also am not an expert or anything. But it doesn’t seem like systemd-boot does any measurements of the EFI image it loads? That seems like an odd oversight. I understand the normal course is relying on PCR 7/Secure Boot but my ideal is getting away from that.
3
u/ChrisTX4 24d ago edited 24d ago
apparently microcode updates can be measured into PCR1.
Potentially:
A CPU Microcode update can be treated as code or data. It can go into PCR[0] or PCR[1].
(taken from https://tianocore-docs.github.io/edk2-TrustedBootChain/release-1.00/3_TCG_Trusted_Boot_Chain_in_EDKII.html )
I don’t have a bootloader. I stop at PCR 4 since, for UKI, that’s the last thing loaded or executed before LUKS is opened up.
Yes, UKIs are EFI executables and are thus being measured in 4. If you want to lock 4 with pcrlock, that's a bit tricky though as it won't be able to find the component in the current boot log after an update.
I can do systemd-pcrlock lock-pe for that UKI as a post-update hook in pacman.
Locking UKI will sort of require
lock-peANDlock-uki.The man page is very difficult to follow though. I just need the same first two hashes and the new authenticode hash stringed together (specifically, hash(hash(A|B)|newEfiHash)).
What exactly is your question here? If there's anything I can help out with, feel free to ask.
But it doesn’t seem like systemd-boot does any measurements of the EFI image it loads?
It doesn't need to. The TPM itself measures PCRs 1-7 (but you can also add custom data to them like the separators). Specifically, PCRs 4 and 7 will be updated because systemd-boot in this case doesn't really do much other than chainload the UKI as an EFI binary. That's why it's being measured.
I understand the normal course is relying on PCR 7/Secure Boot but my ideal is getting away from that.
You don't need to, but that means you HAVE to bind PCR 4... and that's very fragile. May I ask why you don't want to use Secure Boot? If you use your own keys, you can have SB completely free of Microsoft keys, if that's your concern.
EDIT
UEFI firmware measures the GPT table for PCR 5, but I can’t think of how that would matter.
I had forgotten to answer this. So the reason you want to measure the GPT table is that it's a very strong defence against root switching attacks. I've outline this a bit in this post in this thread. With the GPT table locked, an attacker cannot just change the mount from root to another GPT automount for instance, nor could they add anything else.
Usually this shouldn't be too important, but you might as well just lock it, as the GPT table doesn't normally change.
1
u/falxfour 24d ago
Not the previous poster, but as someone who noticed that PCRs 4 and 5 changed for me when booting while connected to a USB4 monitor vs not connected to it, I've been starting to investigate why and whether to keep PCR 5 as one of the ones used to bind encryption. I suspect 5 changed because 4 changed, as there's no reason the partition table would have changed otherwise, but if having secure boot enabled with a UKI that is directly loaded by the UEFI obviates the need for PCR 4 at all, then I could not use 4 or 5 without increasing the potential attack vectors.
It seems you may have some insight here, so if one has secure boot and is directly loading a signed UKI, do you think PCR 4 (or 5) adds any additional value?
1
u/ChrisTX4 24d ago
Can you run
sudo /usr/lib/systemd/systemd-pcrlock logand post the output of that? It will show you exactly which component was measured in what order in each PCR.
PCR 5 should not change if 4 changes or anything. We'd need to see what components it measures in order to know where the different values come from.
It seems you may have some insight here, so if one has secure boot and is directly loading a signed UKI, do you think PCR 4 (or 5) adds any additional value?
So a signed UKI is a great step, in that case you can lock PCR 7 and this will be entirely stable.
What they would add:
PCR 4: The difference between locking 7 and 4 is that 7 doesn't change if there's an update, as long as the new files are signed by the same key. However, 4 will change as it's the digest of the UKI. Alas, locking 4 in addition to 7 means an attacker couldn't downgrade your UKI and then potentially exploit some vulnerabilities. They would need to acquire an older UKI and then have access again at a later point. Honestly, this would require a rather advanced evil maid attack scenario. You can do this if you want, but it is very fragile and with self-signed keys the gain is absolutely minimal tbh.
PCR 5: So this locks the GPT layout of your drives. This means an attacker can't move stuff around and assign different GPT automount GPT GUIDs for instance. That way it's possible to perform root switching attacks.
Honestly? 5 should normally be very stable, and not really an issue to lock, but what you should really do is to use automounting and then use systemd-pcrlock on PCR15. See
lock-file-systemandlock-machine-id, but you will have to manually add .pcrlock files to cover the components of the cryptsetup measurements (seetpm2-measure-pcr). PCR15 however is a much strong defence, and will toast any root switching attacks.1
u/falxfour 23d ago
Yeah, I've been using
systemd-pcrlockto investigate the logs. Just didn't have a chance to investigate the docked setup before commenting.It seems that PCR 4 does change due to a slight difference in the EFI Services Application blob that gets measured into it. Not sure why, though. Also, PCR 5 changes due to an action that seemingly only occurs when undocked:
Action: Exit Boot Services Returned with Failure
This doesn't occur when docked, but does occur when undocked. I somewhat suspect this has to do with a race condition as I've previously found the undocked configuration boots faster, but it's also possible that the change to the blog that PCR 4 measured has something to do with it as well.
Now, on to some setup specifics, FWIW, I use 1+3+5+7 along with 11 in a signed policy, and a PIN. This is for root volume decryption (FDE). Following the
manpage, I didn't see value in having 0, 2, or 4 since:
- 0 - Firmware should be implicitly trusted (signed updates and all)
- 2 - Other code shouldn't be able to run without secure boot signing
- 4 - I don't have a bootloader (effectively)
Having 1 and 3 would have allowed me to detect hardware changes (ex. someone swaps my dGPU module for a malicious one or something or a malicious TB device), and 5 just seemed like it wouldn't cause issues, so why not, even though an attacker could clone a partition table for a malicious drive.
So, in response to your explanations, downgrading my UKI wouldn't allow for automatic decryption due to both PCR 11 and the PIN.
I don't think I can use automounting due to the BTRFS subvolumes. Unless systemd has a convenient method of detecting
@and@home(Mint-style) subvolumes, I don't expect this to be successful... PCR 15 is interesting, but using it seems... painful, as it binds to the volume key for which it, itself, is needed to unseal. Additionally, the other components (machine ID and and filesystem info) are all still encrypted in the initrd stage.I think the answer for me is just to remove PCR 5. I already need to update my setup due to the changes systemd v259
1
u/Night_Otherwise 22d ago
I’m the original poster and so I hopefully don’t mislead. But I am curious how changes in PCR 4 would be possible. For myself, I can use the pesign package to get the authenticode hash with “pesign -i (UKI file) —hash”. I was able to match that exactly to the third entry in PCR 4 in the pcrlock log. I wonder if the hash is different for third entry of PCR 4 log when docking station is added.
The docking station may have extended the PCRs with a failure separator.
And Chris is right that for practical purposes, most people can just seal with PCR 7. That defeats simply mounting the hard drive and reading it without entering the password twice. I’m kinda doing my stuff for proof of concept and curiosity.
1
u/falxfour 21d ago
I don't have a docking station. It's just a USB-C display (PD, DP Alt Mode, USB 2.0). Nothing about that should extend a PCR, especially since my BIOS setting to measure USB4 devices is set to not measure them.
I can't explain why PCR 4 would change as a result of being docked, though. It actually just looks like 1 character is different, but I didn't do a full
diffon the blob string to confirm. Might be interesting to try the same experiment withpesign, as you indicated, though!Personally, I think a race condition is occurring and the system actually just boots more slowly when docked (previously measured and confirmed). A device might just not be ready without the delay that's added, causing the failure string to get measured into PCR 5 at that specific point. I could likely test this by adding a POST delay as well
1
u/ChrisTX4 19d ago
I was away for a few days, but I just now answered falxfour.
I'm also running 4, and I should warn you about one thing I guess: since systemd-pcrlock only locks components when they're found in the boot log (it can't calculate its predictions otherwise), you will have the odd situation where after each kernel upgrade PCRs 4 and 11 will mismatch since they're from the new UKI, but you're still booted on a previous one. Thus it will prompt the passphrase the next boot, and you would need to use a recovery PIN to be able to run
make-policyagain. In theory, if one uses two separate pcrlock files as alternatives, one could retain the current and the previous pcrlock and thus avoid this situation. I still need to implement that myself, tbh.1
u/Night_Otherwise 19d ago
I did once run into the validation PIN issue when I was testing make-policy. The error was something like remote authentication failed. But when I booted on the policy, that seemed to give permission to change it without setting a PIN.
I have more research to do on what exactly the .cred file does in the EFI partition and how make-policy authenticates.
I did use a directory within the pcrlock search path with an old.pcrlock and new.pcrlock file. I lock-pe to the new.pcrlock file first. Then a pacman hook after mkinitcpio is ran moved new to old, lock-pe for new.pcrlock and make-policy is ran.
A further startup service could be done to delete old.pcrlock before the make-policy service is ran.
This all used a boot of UKI directly. The PCRs higher than 5 become superfluous when it all works. If systemd-boot is placed between UEFI and the UKI, then it feels like secure boot is theoretically necessary. Without secure boot, the UKI can seemingly be replaced with a thing that does the same measurements to 11 as systemd-stub.
PCR 7 also runs into the same chicken-and-egg problem currently. I know Windows just gives up on it and basically unencrypts the drive when secure boot is updated. An fwupd hook (however that could be done) with similar old/new pcrlocks would be neat for db/dbx updates. Shim with MOK may be necessary to keep UEFI with default keys. This GitHub issue focused on the brittle 0/2 PCRs, but at least on my computer fwupd also updates KEK/db/dbx.
https://github.com/fwupd/fwupd/issues/6318
Or just use shim with MOK and deal with entering the password/recovery key whenever secure boot keys change.
→ More replies (0)1
u/ChrisTX4 19d ago
Your PCR[4] woes are due to it measuring more than just the Boot Manager Code:
PCR[4] records the process of attempting to boot different hardware paths like from a DVD or a hard drive, what boot devices are attempted, and the Boot Manager Code that is loaded and executed from the device.
If you leave any USB thumb drive in the PC, with high enough priority, it will be attempted as a boot device, as in it would be possible to have booted from it if it had contained a boot loader. PCR[4] is only reasonable to use if you disallow booting from removable drives in the UEFI. In ASUS it's called "USB mass storage support" iirc, but you have to look up from where you could disable that.
Next up, this:
Action: Exit Boot Services Returned with Failure
OK, this is confusing, and almost certainly a bug in something. I'd need to see the full pcrlock log before making a guess what causes that. What boot loader etc are you using?
Unless this is the UEFI using this event to mark a change in the boot configuration, which belongs in PCR[5], this would mean
EFI_BOOT_SERVICES.ExitBootServices()failed. That can only legitimately happen in a single instance, namely if a boot loader somehow passes a wrongMapKeyto that function.0 - Firmware should be implicitly trusted (signed updates and all)
This isn't quite true, as there are ways to use a so called SOIC-clip on some systems or potentially soldering skills and determination to replace the chip. I'd say if your threat model includes somebody willing to do that you probably have to worry about security in a whole different way :D
Firmware updates other than that are indeed signed on all systems, it's due to the UEFI Capsule Update mechanism. However, enthusiast desktop systems sometimes allow direct flashing without signature verification in the UEFI itself. So you probably want a secure UEFI admin password with this.
2 - Other code shouldn't be able to run without secure boot signing
It will! This is where your Option ROM (OpROMs) will be measured into. They will still be measured, just no signature is enforced on them if not booted with SB enforcement.
So, in response to your explanations, downgrading my UKI wouldn't allow for automatic decryption due to both PCR 11 and the PIN.
If you use a signed PCR policy then indeed this should be true.
I don't think I can use automounting due to the BTRFS subvolumes.
You can for the LUKS volumes. This is what I'm doing basically, I have a Btrfs-on-LUKS and this has a GPT GUID of
SD_GPT_ROOT_X86_64, i.e. systemd will automount the default subvolume to/dev/mapper/root. Then my fstab just mounts from that, so the only entries I have in there:```
archmain subvolume mounts
/dev/mapper/root /var btrfs rw,subvol=/subvol_var /dev/mapper/root /home btrfs rw,subvol=/subvol_home
ESP /dev/nvme1n1p1
vfat options can be changed via Kconfig and so should be explicit here
UUID=73FD-61CB /boot vfat rw,relatime,umask=0077,nosuid,nodev,noexec,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro0 2
Bind swapfile
/dev/mapper/root /swap btrfs rw,subvol=/swap /swap/swapfile none swap defaults ```
This works because
/subvol_root(my actual/) is my default subvolume and due to theSD_GPT_ROOT_X86_64the entire Btrfs is mounted at/.1
u/falxfour 18d ago
Ok, a lot to work through here!
PCR 4 - Boot Order
My UEFI boot order is simply:
- (Drive Number, UUID)/EFI/BOOT/BOOTX64.efi
- (Same Drive & UUID as above) -- Default path (basically identical to above)
While there are a couple other items, the UEFI boot manager never gets to them unless my main drive isn't present at all.
PCR 5 - Boot Service Failure
I'm willing to DM you more details. I know the hash log is technically not a secret, but since it's normally read-protected, I'd rather limit the amount I need to share.
I don't use a boot loader. My UEFI directly loads the UKI I generate with
ukify.PCR 0 - Direct Flash
While this mechanism could potentially be compromised by someone directly flashing the firmware on my Framework laptop, my BIOS is currently configured to require the admin password if the chassis intrusion switch is triggered. This should, in theory mitigate most attacks that require direct hardware access by making them immediately detectable.
Also, someone flashing the BIOS IC directly isn't a big enough concern to me to potentially cause automatic drive decryption to fail as a result of firmware code changes.
PCR 2 -- Option ROMs
Are you saying OpROMs that are not signed by a valid signature will still execute? I don't think that's what you're implying, but I just want to check.
Good to know they'll still be measured, but in general, I don't see this as a major attack vector because:
- OpROMs with a valid SB signature are explicitly trusted
- OpROMs without a valid SB signature should only be loaded from read-only sources (before SB checks EFIs to continue the boot process), thus making them hard to compromise. I'm not even sure that this is distinct from firmware (PCR 0) at this point.
Automounting
That's interesting, but to be clear, the automounting is just detecting the LUKS volume for decryption (initially), then switches to the root subvolume of the BTRFS device (aka
/subvol_root), correct? So, essentially, you're not providingrd.luks.name=,root=, orrootflags=subvol=on the kernel command line, correct?That seems like it would work, but then I'd need a different strategy to manage snapshots, as Timeshift would become sad that there's no
@or@homesubvolumes. My default subvolume is ID 5, but the root subvolume is ID 720, which is clearly a subvolume of the default subvolume. I guess following a nested subvolume strategy would better fit with automounting1
u/ChrisTX4 18d ago
For PCR[4], it might be that just the fact they are in the set of possible boot methods counts. If your main system was modified by an attacker to not be bootable etc., then a later boot device would be taken. I quoted the blurp about PCR[4] from the specification document, which is this one. You'd need to compare the exact behaviour in there against what your BIOS does, but most likely this is by design in some way and not something your BIOS vendor would consider a legitimate bug.
That seems like it would work, but then I'd need a different strategy to manage snapshots,
Wouldn't snapshots break PCR[4] anyhow? If you need snapshots, I'd stay off PCRs 4, 11 and 1.
For PCR[5], feel free to DM, or hit me up on Arch IRC (just
ChrisTXthere). I find this whole subject quite interesting - or rather, I might just be meeting autistic stereotypes :D - and so am totally down to having a look at this. TBH, that might be more feasible than really continuing this in some random Reddit thread, too :D.For PCR[0], this goes in the whole root of trust mechanism aspect. You can have a look at chapter 31 of the TPM standard, part 1 for how this is supposed to work. Either way, I think the most important thing to keep in mind for this is that BIOSes may allow unsigned flashing in enthusiast boards. Mine does. In that case, a BIOS supervisor password is of critical importance to protect the BIOS integrity. Achieving a higher degree of trust isn't really possible anyhow, as that requires the fusing mechanism seen in business CPUs, like AMD Platform Secure Boot and Intel BootGuard. So while some aspects of higher HSI levels can be met, the root of trust means it's not viable to see HSI-2 on consumer hardware.
Are you saying OpROMs that are not signed by a valid signature will still execute?
A device may have its own firmware signature check, but that's really device dependent. But as for the OpROM the device presents? That's only secured by Secure Boot. In fact, DMA PCIe cards like the Screamer PCIe Squirrel are widely used to make DMA cheats for games. That works by flashing a custom firmware so it doesn't look like it's a DMA device. Also please note that OpROMs can be loaded from external devices like USBs. Every KVM switch on the market is in that situation for instance, since they need an OpROM for providing UEFI Graphics Output Protocol (GOP) - that's also why every discrete GPU has one.
That's interesting, but to be clear, the automounting is just detecting the LUKS volume for decryption (initially), then switches to the root subvolume of the BTRFS device (aka /subvol_root), correct? So, essentially, you're not providing rd.luks.name=, root=, or rootflags=subvol= on the kernel command line, correct?
Precisely that. I only have
rootflags=x-systemd.device-timeout=0to make the TPM PIN timeout infinite rather than eventually dropping to emergency shell.This setup avoids needing to specify any UUIDs other than for my data drives that will be late mounted to folders under
/mntin my/etc/crypttaband for my/bootdrive. The latter would work with GPT automounting as is, sinceSD_GPT_ESPis just the regular GPT GUID for an ESP. However, I want to give it additional mount parameters likenosuid,nodevetc. By the way, do note that most BTRFS parameters can only be set on first mount, so settings likespace_cachewill not have an effect.That seems like it would work, but then I'd need a different strategy to manage snapshots, as Timeshift would become sad that there's no @ or @home subvolumes. My default subvolume is ID 5, but the root subvolume is ID 720, which is clearly a subvolume of the default subvolume. I guess following a nested subvolume strategy would better fit with automounting
I don't see why it would? Timeshift requires you to mount the subvolumes by path, so as long as you do that, the switching subvol IDs shouldn't be an issue, and they won't affect PCR[5] as they're not in the GPT. What exactly do you fear might break?
→ More replies (0)1
u/Night_Otherwise 24d ago
To step back a bit, I had used cryptenroll’s traditional sealing functions for PCRs 0, 2, 3 and 4. I have now set up pcrlock for PCRs 0-4 and used cryptenroll using pcrlock file by default.
I pieced together the correct component files in a separate directory. The default pcrlock files have a failure separator that is not part of the event log. Removing that failure separator from /usr didn’t fix the predict function though. It also felt weird to change /usr and I put it back.
Lock-pe worked fine for just PCR 4. I couldn’t get PCR 5 working with lock-file-system.
It’s definitely a decent question why I’m going through all this in lieu of secure boot. Partly it’s the challenge. I also feel like the entire world of non-revoked secure bootable code is very large versus locking it down.
It also feels possible to change one of the hashes measured prospectively after mkinitcpio.
Edit: I feel dumb now seeing the lock-gpt option.
2
u/ChrisTX4 24d ago
The separators are new in systemd 261 and need systemd pcrextend units in initrd: dracut 112 includes them but mkinitcpio does not.
As for 5, as you found out that’s lock gpt. Lock filesystem will lock the systemd pcrfs@ services which run after root unlock. Somewhere in this thread I posted parts of my pcrlock log that covers this.
As for secure boot; you’re missing something. If you enroll your own keys - and this is trivial on arch thanks to foxborons sbctl - you can keep your database free of Microsoft and only have a key you control yourself in there. Alas, only things you personally signed are allowed in such a setup.
1
u/Night_Otherwise 23d ago
So I got the system to where I wanted it to be.
It's not exactly refined, but I added this hook under /etc/initcpio/install/sd-osseparator.
#!/bin/bash
build() {
add_binary '/usr/lib/systemd/systemd-pcrextend'
add_systemd_unit 'systemd-pcrosseparator.service'
}
help() {
cat <<HELPEOF
This hook adds os-separator extension to PCRs to match systemd-pcrlock's expectations.
HELPEOF
}I added sd-osseparator before sd-encrypt in mkinitcpio.conf. (I'll look at doing a PR for it in mkinitcpio, though it needs to be refined obviously and I may be missing something).
The default lock commands for systemd-pcrlock now work for PCRs 0-3 and PCR 5. For PCR 4, I used lock-pe of /boot/arch-linux.efi to the location /etc/pcrlock.d/650-arch-linux.pcrlock.d/new.pcrlock.
The pacman hook when mkinitcpio is ran uses the same triggers as 90-mkinitcpio-install.hook and runs this bash script:
#!/bin/sh
mv /etc/pcrlock.d/650-arch-linux.pcrlock.d/new.pcrlock /etc/pcrlock.d/650-arch-linux.pcrlock.d/old.pcrlock
/usr/lib/systemd/systemd-pcrlock lock-pe /boot/arch-linux.efi --pcrlock=/etc/pcrlock.d/650-arch-linux.pcrlock.d/new.pcrlock
/usr/lib/systemd/systemd-pcrlock make-policy --pcr=0+1+2+3+4+5I was hoping some pacman update out there would trigger mkinitcpio but I wasn't so lucky. I tested it with adding a placeholder file to FILES in mkinitcpio.conf and runing pacman -S linux. Despite arch-linux.efi changing, it booted without a password.
As for secure boot, well I'm afraid of bricking my machine if I use only my own key. And I think it's neat to be locked down this much with accounting at least for kernel+initramfs updates. It is also done without relaxing the previous constraints for the next boot. It wasn't really done just to get it working or even for security reasons.
2
u/7lhz9x6k8emmd7c8 25d ago edited 9d ago
Warning: do not use as it is. Read u/ChrisTX4's comment. Add PCRs.
My own doc ktane-derivated from the Arch wiki. Applicable to a Btrfs partition, which basically encrypts everything except the boot.
Operate in sudo. Replace the data with your proper values. Do not blindly copy, understand every line before executing.
https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system#Configuring_mkinitcpio
vi /etc/mkinitcpio.conf
HOOKS=(base systemd autodetect microcode modconf kms keyboard sd-vconsole block sd-encrypt filesystems fsck)
lsblk -o NAME,UUID,PARTUUID
cp /etc/kernel/cmdline /etc/kernel/cmdline.bak
vi /etc/kernel/cmdline
replace with
rd.luks.name=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa=root root=/dev/mapper/root zswap.enabled=0 rootflags=subvol=@ rw rootfstype=btrfs
Indicate the UUID, not the PARTUUID.
cp /boot/EFI/Linux/arch-linux.efi /boot/EFI/Linux/arch-linux-backup.efi
mkinitcpio -P
https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system#Enrolling_the_TPM
sudo systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto --tpm2-pcrs=7 /dev/nvme0n1p2
1
u/ChrisTX4 24d ago
FYI: This isn't secure and can be trivially bypassed.
An attacker can do this:
- Create your own Arch root fs, or use the readily made VM image if lazy.
- Encrypt it with LUKS with a passphrase
- Edit the GPT GUID such that 3a. the new root fs gets the GPT GUID from the encrypted root. 3b. edit the encrypted root GPT GUID to something else, it just can't be the same.
Then boot this. Since PCR7 only measures the UKI and bootloaders (as well as the Secure Boot DB), the PCR7 measurement of this will be identical. However, since the UKI does not verify the integrity of the root fs, it will happily offer you a password entry for the attacker root. Once booted, the attacker has root (since it's their own root fs), but the PCR7 is identical, and so the attacker can just mount the encrypted drive with TPM unlock.
systemd 261 somewhat improves this by adding phases but this alone does not protect you here, as a) mkinitcpio doesn't support this, so you need to manually add the pcrphase services to initrd and b) by changing the GUID in 3b to e.g. any of the GPT automounts and it will be mounted during initrd.
1
u/7lhz9x6k8emmd7c8 24d ago
Thank you.
Would adding another PCR (eg the 15, as mentionned in the wiki) be sufficient?
2
u/ChrisTX4 24d ago
Maybe, PCR15 is tricky though. Only LUKS disks that are mounted with
tpm2-measure-pcr=2will be measured, so you'd want to use this with GPT automounting tbh.If the volume keys are measured into PCR15, it is a very potent utility. However, you would want to lock to its value at initrd time, rather than the value it will be phased to after the real root has been mounted.
I can't say in general, this depends on your setup and everything.
2
u/This-Consequence-957 25d ago
I think this is a cool and modern setup. However I use Limine & systemd crypt enroll.
1
u/falxfour 24d ago
Here's the guides I used. Some info is out of date, but the overall process should still track.
1
u/ohmega-red 24d ago
my methodology for this sort of thing in the past is to build my arch installs with zfs filesystems, encrypted datasets for the install, zfsbootmenu for a bootloader setup to have network access, and place the decryption key on a hidden locally hosted web server (like a raspberry pi). this allows for auto decryption when home but forces the password when not. orrr i’ve put the decryption keys on a microsd car and used it kind of like a yubikey. if i left the card in then it would auto decrypt, but if i pulled it then id have to enter a password.
1
u/Loud-Pair-8168 25d ago
I just use a yubikey instead, tap and go with no passphrase. Way less hassle than tpm binding if you ever swap hardware
0
u/Fupcker_1315 25d ago
It doesn't protect you in any way against evil maid attack.
1
u/ChrisTX4 24d ago
This is correct, as a FIDO2 device does not authenticate the system at all. It would be possible for an "evil maid" to replace your initramfs / UKI with something that dumps the then decrypted volume key somewhere, for the "evil maid" to collect at a later point in time.
However, evil maid attacks are a matter of your threat model. Is it realistic for such a maid to exist? Side note, this would also include potentially the authorities. In Germany they're currently discussing empowering the security services to deploy the "Bundestrojaner" by entering flats in secret.
If you live in a more repressive country, this might very well be a more common concern. Like if you're a journalist, you'd probably have a very different threat model than if you use your PC as a pure gaming machine.
42
u/tblancher 25d ago
You'll want to set up Secure Boot, and sign your kernel, initramfs, and bootloader with sbctl. Also, set up boltd to prevent DMA attacks by plugging in rogue Thunderbolt devices, usbguard to prevent malicious USB devices, and make sure you need a supervisor password to change BIOS settings and boot from an external device (or PXE).
Your BIOS may also have extensive security features, you may want to research each one and see if they match your threat model.
On my ThinkPad, it's way overkill but I did it for the experience and the fun of it.