Secure Boot, TPM2, LUKS, and a potential security hole in the Wiki

PBS · 2021-11-19 09:25:56

I've been doing a lot of reading over the last few days to understand what Secure Boot and the TPM2 chip can do for my security, and how best to take advantage of them. Assuming I've not misunderstood something, I've come to the following albeit slightly controversial conclusions.

Secure Boot provides no benefit to an Arch Linux installation that can't be better achieved using the TPM.
The Arch Wiki's advice for automatically unlocking a LUKS volume on boot leaks your disk decryption key in certain common setups. (E.g. dual booting.)
The correct way to solve problem 2 requires a missing feature in systemd-boot, or whatever other bootloader you're using.

Below I'll attempt to explain my reasoning for these statements. Are they correct?

(I've done the obligatory reading of Lennart's blog entry https://0pointer.net/blog/authenticated … linux.html, and nothing I've said conflicts with it because I'm only talking about Arch Linux here.)

Goals of Secure Boot

First let's look at what the benefits of Secure Boot are supposed to be.

It can protect against malware from installing rootkits that infect the kernel or bootloader. The way that Windows laptops are usually shipped, i.e. with Secure Boot enabled but possible to disable in BIOS, guarantees this. If such a rootkit is installed, the computer will refuse to boot, alerting the user to the presence of the malware so they can then remove it. Of course, for the computer to have reached this state, there must have been malware running as root anyway, so you're already pretty pwned. But the idea is that malware running as root is still less powerful than a rootkit, because of kernel features (e.g. the equivalents of selinux/apparmor/grsecurity) that can restrict the damage it can do. So there is a tangible benefit to Windows users.
It can stop someone else booting unauthorised images on your machine. Simply replace all secure boot keys with your own and sign your images. This is used, for example, by corporate sysadmins to lock down machines they give to employees, allowing the machine to connect to the company VPN without any risk of the employee maliciously leaking the VPN details online. Some Linux users also like to do this. If that includes you, you can let me know why below, but I suspect there are two main reasons: stopping a thief from being able to use your computer, and more importantly, the next point.
"It allows you to trust the machine when you type in your disk encryption password. This defeats the Evil Maid attack." I've put this in quotes because it's wrong as it stands. If your Maid can insert a hardware keylogger, you'll need to epoxy the keyboard down and/or use tamper-proof seals. If your Maid can replace the computer with an identical copy, you'll need to rely on some kind of fingerprint; the low-tech method is to look for a defect unique to your machine that only you know about, the hi-tech method is to set up one-time passcodes, but that relies on a separate piece of trusted hardware (or god-level mental arithmetic), so only kicks the can further down the street. The point is, there's always an Eviller Maid than the one you thought of. I will assume that you've managed to outsmart your Maid, a process which has nothing to do with Secure Boot. In that case, the quoted statement is true. You know that if the machine boots, it's running your approved software, so it's safe to tell it your password.

(As an aside, none of these benefits address the "$5 Wrench attack" (https://xkcd.com/538). Protection against this attack exists, and is called Deniable Encryption, but doesn't seem to be in widespread use. This is a separate topic.)

Secure Boot on Arch Linux

Does Arch Linux achieve these goals? Can it achieve them?

First of all, note that a) and b) are incompatible if you to ever need to update your kernel. If you want a), you need distribution-signed images.* (Otherwise, the signing of updates must be done on your local machine. The way this is usually done is to store the keys on the disk readable only by root. If you get malware, it's a trivial task for the malware to find these keys, check they match firmware, and sign the rootkit with them.) But then anyone can boot the distribution installation image on your machine, negating b) and c). Arch Linux encourages regular updates and allows the use of custom kernels and initrds. This requires local signing. Therefore, a) is not achievable.
What about b) and c)? It's actually possible to achieve the same guarantees of c) a different way, using the TPM2 chip (see below). So c) is achievable without Secure Boot.
So that leaves just b). I would like to argue that b) is a pointlesss endeavour; an ego trip, nothing more. If you already have c), then b) just stops a thief from being able to use your computer. What's the point? I don't care if they can - they're not going to return it anyway, and letting them use it saves e-waste. Note also that the 'enterprise' use case I outlined in b) doesn't actually require b), it only requires c). So b) provides no benefit over c).

(*I'm assuming such distributions have solved the initrd signing problem discussed on Lennart's blog. Otherwise you can't even have a).)

We conclude that Secure Boot is useless on an Arch Linux system, and should be left disabled. (Unless of course I've overlooked something, or ignored an important use case - if so please tell me so I can correct my ignorance.)

The Trusted Platform Module

Finally, on to the TPM. One of the things that the TPM can do is to generate a hash value, unique to the combination of machine plus image that you booted, and make it available to the image. If you try to harvest the value by booting a different image which prints the value to the screen, you will get something different. This makes the hash value a good candidate for unlocking an encrypted disk on boot. (I find it hard to find proper documentation of the PCR registers beyond the Arch Wiki, but I think the register I'm talking about is number 4.)

The problem with PCR register 4 is that it if you're booting unified kernel images directly, without a boot manager, the value will change every time you update your kernel. For this reason, the Arch Wiki (https://wiki.archlinux.org/title/Truste … _with_LUKS) recommends instead using PCR registers 0+7, which depends only on the Secure Boot state and firmware.

Problems

Whether you use 4 or 0+7, either way this opens up a potential security hole when dual booting. If user has set up a boot manager, say Grub, which can boot into Windows or Linux, and Linux is set up with full disk encrpytion that unlocks automatically on boot using the TPM, then the secret key can leak to Windows. When Grub has been booted, the PCR register will always be the same whether you subsequently boot into Windows or Linux. This means if your Windows is infected with malware, it could easily read the PCR register, scan for any Linux partitions encrypted using LUKS, check if the register matches any of the LUKS keyslots, then use that to read the actual LUKS encryption key. From then on, the security of your full-system encrypted Linux is pwned. This should also be borne in mind if sharing a laptop with an untrusted Windows user.

Worse still, the standard way to set up Secure Boot with a Windows+Linux dual boot is to keep Microsoft's key in the firmware. This means that even with Secure Boot enabled, if you use registers 0+7 your Linux full disk encryption is blown if someone steals your laptop and simply boots into the stock Windows image. (Yes, of course if someone steals your laptop they can cold-boot it to get the keys out of RAM after Linux has booted, as warned on the Wiki. But this is significantly harder to perform than simply installing Windows, which can be done by any casual attacker.)

There are other common setups in which the LUKS key may also leak. On some laptops, it may be necessary keep a certain set of Manufacturer/Microsoft keys in firmware to avoid bricking the laptop. Even if not necessary, it may be advisable anyway, due to the risk of bricking. (Yes, the only reason this paragraph exists is because vendor UEFI implementations are crap. It's a sad, but not surprising situation.) In these setups, even with Secure Boot enabled and a boot manager that will only boot signed images, the encryption can be defeated by installing Windows and configuring the boot manager to boot it. Since it's the same boot manager, Windows gets the same hash value even with register 4. Of course, with registers 0+7, you could get it even easier, by just installing Windows and replacing the existing bootloader.

Solutions

The simplest solution I can see is to embed a certificate into the EFI binary of the bootloader. In the example above, you could happily disable secure boot (as it's providing no real benefit there anyway), and set up a bootloader with your own certificate built-in, which will clear the TPM register you use for LUKS if the image to be booted is not signed by the corresponding key. Then you make sure to sign your kernels with that key. Now anything can boot, but only your approved bootloader can get the right hash value in register 4, and only your approved kernel can be given it by the bootloader. This provides c) without b). (Explicitly, it lets you trust the machine hasn't been tampered with, because if it had, it couldn't auto-unlock the drive.**) The only problem is that none of the avaiable bootloaders seem to support this. If they do, I'd be delighted to know. The same goes if the TPM can do other advanced functions that let you achieve the same guarantees.

(**There is a loophole here, which is that you have to type in your login password before you get to see your familiar files and know that the drive has been unlocked. This means someone could set up a system that looks just like yours right up until you type in your login password, before it would necessarily reveal itself as fake. After that you know that the attacker, if they could get physical access to your machine in the future, could reimage the computer with a copy of the hard drive they'd made earlier, then use the harvested login password to get into the system. This attack would be flat-out blocked by b). However, even without b), the user is alerted to the attack, and can thwart it either by preventing further physical access in the fuutre, or better, extending a suitable TPM register that is impossible to restore whose value is necessary for extracting the disk decryption key. They could then change their login password and re-set up LUKS unlocking from TPM, and all would be back to normal. Of course, none of this works if you used the same login password as the emergency password for the LUKS volume, so don't do that.)

An Evil Maid Variant

None of what I've discussed protects against the following variant of the Evil Maid attack. The Maid images your hard drive, waits a few years for a security vulnerability to emerge, then copies it back to your machine and exploits their way in.

To protect against this, you need to revoke old kernels. You could of course use dbx for this, but I don't like that for three reasons: in principle, it will eventually fill up a finite amount of space, second, it makes downgrading complicated, and without Secure Boot the dbx can be cleared anyway. I'd much rather periodically change keys every few months. This almost works, but raises the problem that when you change your key, your previous backup kernel (if you have one) no longer boots. The only way around this is to have two keys in use at any one time, periodically generating new keys with overlapping lifespans. This can all be made to work if you can have an EFI image signed by two keys. So that is my question: can I sign an EFI image with two different keys?

(Note that the suggestion of re-signing the backup kernel is not a good one. Suppose an update silently breaks your signing tools, making them generate corrupt images. Now, by resigning, you've just destroyed your only working backup image. In general I would like to preserve the principle that your only working backup kernel should never be touched.)

Conclusions

I apologise about the blog-post length of this forum post. In conclusion,

Secure Boot lets you protect against one of a) rootkits, or c) software tampering by someone with physical access.
On Arch Linux you can't have a), so might as well choose c).
You can achieve c) using the TPM instead, with less risk to bricking your system, at the sacrifice of only the unnecessary b) locking out thieves.

All of these are of course subject to the caveat that I may not know what I'm talking about, hence the reason this post exists. Please let me know if, how and why I'm wrong.

PBS · 2021-11-20 16:41:47

I had second thoughts about point 1. Secure Boot is the far simpler solution for achieving c. In view of the KISS principle, Secure Boot therefore has an advantage.

The solution I proposed in (**) for achieving c without Secure Boot also relies on a TPM feature that I'm not sure exists: persistent TPM registers that can only be extended, not written directly. If this feature does not exist, then you can only achieve a weaker version of c, and need Secure Boot for the full version. Even if it does, it's off the beaten track, which again violates the KISS principle.

Therefore only points 2 and 3 remain valid. I think these remain an interesting question.

diabonas · 2021-11-20 18:00:25

PBS wrote:

I've been doing a lot of reading over the last few days to understand what Secure Boot and the TPM2 chip can do for my security, and how best to take advantage of them. Assuming I've not misunderstood something, I've come to the following albeit slightly controversial conclusions.
Secure Boot provides no benefit to an Arch Linux installation that can't be better achieved using the TPM.

It is correct that a lot of what Secure Boot does can be achieved using only a TPM. However that does not mean the Secure Boot is completely useless, for the reasons outlined below.

PBS wrote:

[...]
The Arch Wiki's advice for automatically unlocking a LUKS volume on boot leaks your disk decryption key in certain common setups. (E.g. dual booting.)
The correct way to solve problem 2 requires a missing feature in systemd-boot, or whatever other bootloader you're using.

These statements stem from a misunderstanding of how storing secrets in a TPM and sealing them to a certain system state works.

PBS wrote:

Finally, on to the TPM. One of the things that the TPM can do is to generate a hash value, unique to the combination of machine plus image that you booted, and make it available to the image. If you try to harvest the value by booting a different image which prints the value to the screen, you will get something different. This makes the hash value a good candidate for unlocking an encrypted disk on boot. (I find it hard to find proper documentation of the PCR registers beyond the Arch Wiki, but I think the register I'm talking about is number 4.)

The values of the PCR registers are not confidential and should never be considered as such. The purpose of the PCR registers is that you can seal other secrets to a known good state of the PCR registers. The TPM will then only release these secrets when the PCR state matches.

PBS wrote:

The problem with PCR register 4 is that it if you're booting unified kernel images directly, without a boot manager, the value will change every time you update your kernel. For this reason, the Arch Wiki (https://wiki.archlinux.org/title/Truste … _with_LUKS) recommends instead using PCR registers 0+7, which depends only on the Secure Boot state and firmware.

Exactly, that is the point where Secure Boot becomes useful: instead of having to change the authorisation policy of your disk encryption secret every time you update your kernel (and therefore PCR 4 changes), you use PCR 7 instead, which measures the Secure Boot keys used to verify the signed unified image containing kernel, microcode and initramfs. Since the Secure Boot key does not change, you do not have to update the authorisation policy for the secret stored in the TPM.

PBS wrote:

Whether you use 4 or 0+7, [...]

Small nitpick, you should always use PCR 0 as part of all measurements since the firmware forms the root of trust, so this should read "0+4 or "0+7".

PBS wrote:

If user has set up a boot manager, say Grub, which can boot into Windows or Linux, and Linux is set up with full disk encrpytion that unlocks automatically on boot using the TPM, then the secret key can leak to Windows. When Grub has been booted, the PCR register will always be the same whether you subsequently boot into Windows or Linux. This means if your Windows is infected with malware, it could easily read the PCR register, scan for any Linux partitions encrypted using LUKS, check if the register matches any of the LUKS keyslots, then use that to read the actual LUKS encryption key. From then on, the security of your full-system encrypted Linux is pwned. This should also be borne in mind if sharing a laptop with an untrusted Windows user.

As already pointed out above, the PCR registers are not secret and do not form a part of the disk encryption key. But even setting this aside, this paragraph is factually incorrect:

If you are using PCRs 0 and 4, all EFI binaries executed during boot are measured into PCR 4. If you are booting into Windows, these are typically your Linux boot manager and the windows bootloader, which differs from the binaries used when booting Linux (Linux boot manager and unified kernel image). As a result, the PCR state does not match and access to the disk encryption key would be denied when booting into Windows.
If you are using PCRs 0 and 7, the keys used to verify the signed EFI binaries are measured into PCR 7. If you are booting into Windows, this includes the Microsoft signing key, while booting into Linux should typically only use the custom Secure Boot key you use to sign the boot manager and unified kernel image. Again, the PCR state would not be the same when booting into Windows and Linux.

PBS wrote:

Worse still, the standard way to set up Secure Boot with a Windows+Linux dual boot is to keep Microsoft's key in the firmware. This means that even with Secure Boot enabled, if you use registers 0+7 your Linux full disk encryption is blown if someone steals your laptop and simply boots into the stock Windows image. [...] On some laptops, it may be necessary keep a certain set of Manufacturer/Microsoft keys in firmware to avoid bricking the laptop.

The above point about PCR 7 changing holds true whether you keep the Microsoft or other preinstalled signing keys as part of your Secure Boot setup or not.

PBS wrote:

The simplest solution I can see is to embed a certificate into the EFI binary of the bootloader. In the example above, you could happily disable secure boot (as it's providing no real benefit there anyway), and set up a bootloader with your own certificate built-in, which will clear the TPM register you use for LUKS if the image to be booted is not signed by the corresponding key. Then you make sure to sign your kernels with that key. Now anything can boot, but only your approved bootloader can get the right hash value in register 4, and only your approved kernel can be given it by the bootloader.

For the part about "clearing the TPM register" see my comments on how sealing secrets to a certain PCR state work. Other than that, this approach is more or less exactly what you get by using Secure Boot with custom keys, for the reasons I outlined above.

PBS wrote:

There is a loophole here, which is that you have to type in your login password before you get to see your familiar files and know that the drive has been unlocked. This means someone could set up a system that looks just like yours right up until you type in your login password, before it would necessarily reveal itself as fake.

If you are interested in attesting the state of the system before entering your password, I suggest looking into tpm2-totp, also available in the Arch repositories.

Last edited by diabonas (2021-11-20 18:04:06)

PBS · 2021-11-22 08:30:01

Thanks for your reply.

diabonas wrote:

If you are using PCRs 0 and 4, all EFI binaries executed during boot are measured into PCR 4. [...]
If you are using PCRs 0 and 7, the keys used to verify the signed EFI binaries are measured into PCR 7. [...]

These are the magic words I was missing. Now it's clear that point 2) is invalid, because the solution 3) is already performed by the UEFI.

diabonas wrote:

These statements stem from a misunderstanding of how storing secrets in a TPM and sealing them to a certain system state works.

I hadn't appreciated the difference between reading PCR registers and using them to unseal secrets. But this is surely an orthogonal issue; the answer is the first quote?

For example, there is nothing stopping a bootloader from simply booting an image itself rather than through UEFI, thereby not causing a measurement to be performed and leaving the TPM in the same state. Then whatever runs next can ask the TPM to unseal anything, hence negating the benefits of sealing over just reading PCRs. Presumably the answer to this question is that yes, there's nothing technical stopping you from writing a bootloader like this, but it would be a crappy bootloader.

diabonas wrote:

If you are interested in attesting the state of the system before entering your password, I suggest looking into tpm2-totp, also available in the Arch repositories.

This project is exactly what I had in mind when I said

pbs wrote:

the hi-tech method is to set up one-time passcodes

Since you seem to be the creator, a small question might be in order. Have you considered the Maid who replaces your computer with a identical copy and mirrors the screen output of your original laptop to it, including the one-time-code? This attack could be performed without hardware modification of the original laptop using a high-enough quality camera. It's basically a MITM. I suppose if your attacker isn't capable of performing hardware modifications, you can thwart them by activating the wifi kill switch on their fake laptop. And if they are capable of hardware modifications, all bets are usually off anyway. So the answer is yes, it protects against this attack as well as you can hope for.

diabonas · 2021-11-23 09:58:27

PBS wrote:

I hadn't appreciated the difference between reading PCR registers and using them to unseal secrets. But this is surely an orthogonal issue; the answer is the first quote?

Correct, I just wanted to clarify this as I have seen other people actually use the PCR values as secrets, which they are absolutely not made for. Implementations like systemd-cryptenroll get this right though, so you as a user do not have to worry about this.

PBS wrote:

For example, there is nothing stopping a bootloader from simply booting an image itself rather than through UEFI, thereby not causing a measurement to be performed and leaving the TPM in the same state. Then whatever runs next can ask the TPM to unseal anything, hence negating the benefits of sealing over just reading PCRs. Presumably the answer to this question is that yes, there's nothing technical stopping you from writing a bootloader like this, but it would be a crappy bootloader.

The boot loader could indeed load and execute unsigned code either by design or unintentionally (cf. the last set of GRUB vulnerabilities), but for a boot loader that is aware of Secure Boot, that would be considered a security issue. But yeah, that is certainly an area boot loader developers have to take great care of, e.g. by making sure to measure additional variables like configuration files as well that could alter the boot process.

PBS wrote:

Since you seem to be the creator, a small question might be in order.

Not directly the creator, that credit goes to Andreas Fuchs, but at least one of the two maintainers

PBS wrote:

Have you considered the Maid who replaces your computer with a identical copy and mirrors the screen output of your original laptop to it, including the one-time-code? This attack could be performed without hardware modification of the original laptop using a high-enough quality camera. It's basically a MITM. I suppose if your attacker isn't capable of performing hardware modifications, you can thwart them by activating the wifi kill switch on their fake laptop. And if they are capable of hardware modifications, all bets are usually off anyway. So the answer is yes, it protects against this attack as well as you can hope for.

I am not aware of any defences against an adversary that is capable of undetectedly replacing your computer with an identical copy, short of trying cut the necessary line of communication to the attacker e.g. by only operating the device in an isolated faraday cage. There are slight improvements to displaying the TOTP directly on-screen by using a separate device plugged into USB that automatically does the verification for you. However, an attacker could pass through the USB port from the fake to the real device to thwart this.

I think this scenario is well outside of any threat model for a TPM or Secure Boot. There are some hardware-based approaches, e.g. using stickers or glitter nail polish to make your device unique in order to make it harder to tamper with it or duplicate it, but these fall outside of the domain of computer science.

xuanyao · 2023-08-13 07:21:58

diabonas wrote:

The above point about PCR 7 changing holds true whether you keep the Microsoft or other preinstalled signing keys as part of your Secure Boot setup or not.

sorry for continuing on this old thread. how does PCR 7 alone prevent unsealing keys.

suppose you seal the key in windows or a specific linux distro. you can just boot into another official windows or linux distro then PCR7 should match?

Arch Linux

#1 2021-11-19 09:25:56