Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
10.03.2025 19:27, Adrian Vovk wrote: Basically, the bug is: an attacker does a DOS on the TPM in such a way that systemd boots to the rootfs without measuring the `leave-initrd` pcrphase, pcrphase works only with UKI and OP started with mentioning separate kernel and initrd which excludes UKI. This really needs the complete description of the setup and ideally of the attack, otherwise everyone will be discussing something different. or the fake rootfs's pcr15. Once in the rootfs, the TPM doesn't know that it has left the initrd. And that's game over: the attacker stops DOSing the TPM, and extracts the encryption keys for the real rootfs from the TPM. Best, Adrian
Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
On Di, 11.03.25 13:27, Lennart Poettering ([email protected]) wrote: > On Mo, 10.03.25 19:25, Diorcet Yann ([email protected]) wrote: > > > Is PCR15 checked against a pre-calculated value saved in the signed initrd > > before leaving initrd? If it's not the case, then when executing the init > > from the chrooted malicious partition, the original /dev/sda1 LUKS will be > > opened and mounted as var. > > I think you are misunderstanding what PCR15 is supposed to be. it's > not really supposed to be consumed for FDE, but simply populated by > FDE. It's usecase was to later have PCR that identifies the local > system, that we can lock encrypted credentials or systemd-confext > images to. > > To protect the order of things use the "phase" logic, i.e. in PCR 15. > > And to say this very clearly: the model this is designed for assumes > you have one encrypted fs not many. i.e. if everything checks out then > you get access to it, and if it doesn't you don't. I am not sure I > understand your scenario, but you appear to work with two encrypted > disks, one for the rootfs and one for /var/? Yes, there is no > protection for using them for the wrong purpose (ie. the root fs for > /var/ or vice versa), because that was never in the picture of being > an issue. > > If you want multiple encrypted partitions like that, then things are a > lot more complicated, but let me ask you: why even? It makes sense to > split up things so that you have various sets of data with different > protections (i.e. some unprotected, some verity protected, some > encrypted + tpm). But if you have multiple partitions protected the > same way, why split them up, and why create such a headache then. I prepped this now: https://github.com/systemd/systemd/pull/36714 It should add protections that address the aforementioned issues with "misusing" partitions at the wrong places. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
Hello, On Mon, Mar 10, 2025, 12:06 Mikko Rapeli wrote: > Hi, > > On Mon, Mar 10, 2025 at 11:16:25AM -0400, Adrian Vovk wrote: > > Hello, > > > > Just to see if I understand your concern correctly, I'll try boiling it > > down to its simplest, by cutting out the need for two partitions. Here's > > the scenario: > > > > - An attacker replaces the real rootfs with a malicious one that just > drops > > to a shell. The attacker keeps a copy of the original real rootfs > > This should not be possible without breaking encryption keys from the > device. > If the rootfs is not encrypted with device specific keys derived from TPM > measurements or dm-verity where root hash has been hard coded into > secureboot > signed UKI binary for the kernel, then the setup is not secure to start > with. > If dm-verity image has been tampered it will fail signature checks and fail > to mount. > This is inaccurate. systemd's security model allows for the rootfs to be replaced with a different one. There's no good way to actually prevent that: all partition table metadata is spoofable, including UUIDs and whatnot Of course, if you're using dm-verity on the rootfs, the attacker can only replace the rootfs with a copy of itself. But I don't think this is the case here, since the thread started with the presumption that the attacker can replace the rootfs. To be clear, the partition layout I'm thinking about is: dm-verity protected /usr partitions (A/B copies), and then a separate rootfs partition that exists just to store persistent data (/var, /etc, etc). In this scenario, there's nothing preventing someone from replacing the rootfs partition's contents with anything arbitrary. > - The system boots, then tries and fails to decrypt the fake rootfs. > > > - The attacker now starts impeding communication between the TPM and the > > CPU. Potentially by physically interposing on the bus and blocking > > communication. Or by glitching the bus so that the data isn't > successfully > > measured. Anyway, the attacker somehow makes TPM measurements fail > > > > - The attacker unlocks their malicious rootfs, and then the system > > continues booting. The attacker now gains control of the system via the > > root shell. > > This means that TPM, firmware, kernel or initrd have been compromized at > runtime after their TPM measurements and secureboot signatures have been > verified. A denial of service attack is relatively simple but any code > executions should be grave bugs which need updates to get fixed. An initrd > should have only very limited functionality and no fallback interactive > shells or prompts, or network drivers or daemons. > If you can replace the rootfs (which we've established: you can), then that rootfs can contain whatever you want to gain execution early during boot. It can be as easy as a single symlink in /etc: basic.target.wants/systemd-debug-shell.service It may be possible to cut down TPM communication and to make systemd and > other > service to wait for longer time but it is simpler to freeze RAM and CPU > state and change the rootfs entry with physical attack via JTAG, if such > interfaces > are enabled in HW. > The point is to disable the TPM enough that systemd gives up trying to measure pcrphases, and moves on. If it continues booting in that case, there's a big problem > - The attacker stops impeding the communication between the TPM and the > > CPU. The TPM is still in the same state as it was in the initrd. The > > leave-initrd pcrphase, and the PCR15 measurement of the fake root's > volume > > key, are both missing > > > > - The attacker is in control of the system, and the TPM is in the right > > state to unlock the real rootfs. The attacker talks to the TPM to get the > > real rootfs's volume key. Attacker wins > > > > I think, ultimately, this is the same issue as the one you describe. Do > you > > think that's correct? > > > > Lennart would have a better idea than I do of what mitigations to this > > would look like. But I suspect that: > > > > - You can't MITM the TPM, since the communication is encrypted > > > > - Other kinds of attacks cause the OS to know that a measurement failed. > So > > perhaps we need to very strict about ensuring that measurements happen. > > i.e. By not letting the TPM disappear at runtime, and making sure that > > measurements always succeed (and if it does, failing to boot or > something) > > TOCTOU, time of check vs. time of use bugs may exists but they should be > very hard to trigger, e.g. require HW debugger level access. > Well, the TPM is supposed to be secure against hardware debugger access, in theory. Ditto with CPUs, and JTAG lockout. So if there's TOCTOU bugs in our code we need to be robust against them too. Anyway, I don't think this is a TOCTOU bug. Basically, it seems that we're sometimes OK letting communication to the TPM fail. In which case, an attacker can cause the communication to fail, and we'll be none the wiser If device specific
Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
Hello, Just to see if I understand your concern correctly, I'll try boiling it down to its simplest, by cutting out the need for two partitions. Here's the scenario: - An attacker replaces the real rootfs with a malicious one that just drops to a shell. The attacker keeps a copy of the original real rootfs - The system boots, then tries and fails to decrypt the fake rootfs. - The attacker now starts impeding communication between the TPM and the CPU. Potentially by physically interposing on the bus and blocking communication. Or by glitching the bus so that the data isn't successfully measured. Anyway, the attacker somehow makes TPM measurements fail - The attacker unlocks their malicious rootfs, and then the system continues booting. The attacker now gains control of the system via the root shell. - The attacker stops impeding the communication between the TPM and the CPU. The TPM is still in the same state as it was in the initrd. The leave-initrd pcrphase, and the PCR15 measurement of the fake root's volume key, are both missing - The attacker is in control of the system, and the TPM is in the right state to unlock the real rootfs. The attacker talks to the TPM to get the real rootfs's volume key. Attacker wins I think, ultimately, this is the same issue as the one you describe. Do you think that's correct? Lennart would have a better idea than I do of what mitigations to this would look like. But I suspect that: - You can't MITM the TPM, since the communication is encrypted - Other kinds of attacks cause the OS to know that a measurement failed. So perhaps we need to very strict about ensuring that measurements happen. i.e. By not letting the TPM disappear at runtime, and making sure that measurements always succeed (and if it does, failing to boot or something) Best, Adrian On Mon, Mar 10, 2025, 05:23 Yann Diorcet wrote: > Hi, > Sorry for my english, i'm not english native. > > Le lun. 10 mars 2025 à 10:04, Lennart Poettering > a écrit : > > > > On Sa, 08.03.25 19:52, Diorcet Yann ([email protected]) wrote: > > > > > Hello, > > 61;7802;1c> > > > I'm in the process of using SecureBoot, TPM2.0 and LUKS2 to protect an > > > industrial embedded computer. > > > > > > I have a chain of trust in the UEFI (own secure boot > keys/certificates), > > > signed grub2, all files used by grub2 signed including kernel and > > > initramfs, and successfully automatically unlocked LUKS partitions > using > > > TPM2.0 using PCR7. > > > > > > The main concern remaining is to be sure to chroot on the "good" root > > > partition (and not a malicious one allowing to decrypt using TPM the > "good" > > > partition). > > > > > > pcrphase ensures that "good" root partition can only be unlocked in > the good > > > phase (after enter-initrd for example), this is an additional security. > > > > > > tpm2-measure-pcr provides a way to only decrypt other partitions after > the > > > "good" root partition: Using for example 7+11+15 > > > > > > > > > But in the case of multiple partitions unlocked by the initrd, I can't > > > figure why an attacker couldn't succeed to : > > > > > > - Clone the original disk (notably ESP) > > > > > > - Replace root partition by a malicious one > > > > > > - Fake the second (using UUID/PARTLABEL/...) but using LUKS partition > from > > > the "good" root partition > > > > > > - Boot the machine > > > > > > - The initrd will try unlocks the malicious partition as root. As the > TPM > > > token will not work, the attacker will use the password of his > malicious > > > LUKS > > > > Disable the password prompt via "headless" crypttab option. > Thanks for this tip > > > > > (Not sure if I follow what the issue is supposed to be, i.e. not sure > > what "try unlocks" is supposed to mean or what "the second" refers > > to. Just guessing here). > > > > There's a TODO list item somewhere to provide more finegrained conrol > > of which mechanisms are allowed to allow a disk, and conversely to > > measure the actual mechanism used. But until then simply disable > > interactivity fully. > > > > (note that fido2, tpm2, pkcs11 unlocking needs to be enabled manually, > > it's only passphrase/recovery key unlock which is on by default, and > > which you have to turn off via headless) > > > > > - Make the update of the PCR due to the measuring of the malicious > partition > > > fails > > > > hmm, i really cannot parse this? (not the rest either...?) > > If an attacker jams the communication with the TPM (discret one for > example) during the measuring phase of the first partition (which in > my example is the malicious one), the PCR will not be updated. > Allowing the second partition to be unlocked as it would be unlocked > in normal situtation: as the first unlocked partition. > If you don't add counter measure at the end of initrd in order to fail > this trick (as alplanas explained), you will chroot on the malicious > partition with the the good root partition unlocked and mounted as the > second
Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
On 2025-03-08 18:52, Diorcet Yann wrote:
But in the case of multiple partitions unlocked by the initrd, I can't
figure why an attacker couldn't succeed to :
- Clone the original disk (notably ESP)
- Replace root partition by a malicious one
- Fake the second (using UUID/PARTLABEL/...) but using LUKS partition
from the "good" root partition
This is done by "systemd-pcrfs[-root]". The attacker needs to have
access to the system (as a normal user to use something like lsblk)
tpm2-measure-pcr take the LUKS2 volume key (cryptsetup luksDump
--dump-master-key), and this requires the effective unlock of the device
(via TPM2 or passphrase)
- Boot the machine
- The initrd will try unlocks the malicious partition as root. As the
TPM token will not work, the attacker will use the password of his
malicious LUKS
- Make the update of the PCR due to the measuring of the malicious
partition fails
As commented, using tpm2-measure-pcr, PCR15 will be extended with
HMAC("cryptsetup:$name:$uuid", vk), and vk cannot be impersonated.
- Initrd will try to unlock the second partition, which is the "good"
root partition, and it will succeed, allowing the attacker to finally
access all data from the partition.
Yes, this partition can be unlocked using a policy that uses PCR0..9 for
TPM2 (without PIN). But not necessarily means that the attacker has any
access yet, at least not while we are in the initrd.
With measured boot, the previous stage measure something of the next
stage before delegating. The initrd needs to measure something from the
device to continue the chain of trust. IIRC in the image-based proposal
that was the dm-verity root key. If dm-verity is not used, then
something else needs to be measured. The volume key seems a good
replacement.
The main point here is to "Make the update of the PCR due to the
measuring of the malicious partition fails".
I think that there is a more simple model, that was described in a nice
blog post some months ago. The idea is to never leave the initrd if the
expected value of PCR15 is not meet.
In this model PCR15 does not participate in the unseal of any secret.
Instead you need to mark the encrypted partitions as tpm2-measure-pcr
that are unlocked early in the initrd (root, swap, and the ones with
x-initrd.attach).
Maybe using a generator, we need to order how systemd-cryptsetup will
access those devices. This is optional, but will simplify a lot how to
make predictions for PCR15.
The last step is to have a service in the initrd that is executed after
[email protected], but before the switch root, it will compare
the current PCR15 value with the expected one, and if it fails it will
halt the system.
With something like this an attacker cannot replace any of the disk that
belong to the OS without being detected. This would require the
alteration of initrd in the UKI or on the ESP, that is covered by the
measured boot policy.
There is some code here:
* A generator that order the PCR15 extensions
https://github.com/openSUSE/sdbootutil/blob/main/measure-pcr-generator.sh
* A predictor for PCR15
https://github.com/openSUSE/sdbootutil/blob/main/sdbootutil#L2210
* A validator service that stop the boot process if the expected value
did not match
(also validate the signature of the file that contains the prediction)
https://github.com/openSUSE/sdbootutil/blob/main/measure-pcr-validator.sh
* (Only for non-UKIs) A service that import into the initrd the
prediction
https://github.com/aplanas/dracut-pcr-signature/blob/main/pcr-signature.sh
Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
Le 10/03/2025 à 21:42, aplanas a écrit : On 2025-03-10 18:25, Diorcet Yann wrote: Le 10/03/2025 à 17:27, Adrian Vovk a écrit : 2) Just before opening the var LUKS: PCR15=0 or something predictable cryptsetup is used to open var and update PCR15 thanks to tpm2-measure-pcr=yes. but in this case /dev/sda1 is replaced with the original /dev/sda1 partition. I think that you mean that /dev/sda2 (/var) is replaced with the original /dev/sda1 (rootfs), so mounting the original root in /var, right? Yes that it, sorry for the mistake. PCR15=hash1 3) initrd makes the mount of the fs, makes multiple measurements (notably on PCR11 with leave-initrd) then chroots and executes malicious init. Is PCR15 checked against a pre-calculated value saved in the signed initrd before leaving initrd? If it's not the case, then when executing the init from the chrooted malicious partition, the original /dev/sda1 LUKS will be opened and mounted as var. You need a service in the initrd to do that. systemd AFAIK is not currently providing one, but the plumbing is there to bring your own. Thanks for the links btw Regards, Yann
Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
Hi, On Mon, Mar 10, 2025 at 11:16:25AM -0400, Adrian Vovk wrote: > Hello, > > Just to see if I understand your concern correctly, I'll try boiling it > down to its simplest, by cutting out the need for two partitions. Here's > the scenario: > > - An attacker replaces the real rootfs with a malicious one that just drops > to a shell. The attacker keeps a copy of the original real rootfs This should not be possible without breaking encryption keys from the device. If the rootfs is not encrypted with device specific keys derived from TPM measurements or dm-verity where root hash has been hard coded into secureboot signed UKI binary for the kernel, then the setup is not secure to start with. If dm-verity image has been tampered it will fail signature checks and fail to mount. > - The system boots, then tries and fails to decrypt the fake rootfs. > > - The attacker now starts impeding communication between the TPM and the > CPU. Potentially by physically interposing on the bus and blocking > communication. Or by glitching the bus so that the data isn't successfully > measured. Anyway, the attacker somehow makes TPM measurements fail > > - The attacker unlocks their malicious rootfs, and then the system > continues booting. The attacker now gains control of the system via the > root shell. This means that TPM, firmware, kernel or initrd have been compromized at runtime after their TPM measurements and secureboot signatures have been verified. A denial of service attack is relatively simple but any code executions should be grave bugs which need updates to get fixed. An initrd should have only very limited functionality and no fallback interactive shells or prompts, or network drivers or daemons. For example systemd-boot disables kernel command line editing if secureboot was enabled. Thus with UEFI firmware, signed systemd-boot and kernel and initrd from a signed UKI binary it is not possible to change the boot behavior trivially. It may be possible to cut down TPM communication and to make systemd and other service to wait for longer time but it is simpler to freeze RAM and CPU state and change the rootfs entry with physical attack via JTAG, if such interfaces are enabled in HW. > - The attacker stops impeding the communication between the TPM and the > CPU. The TPM is still in the same state as it was in the initrd. The > leave-initrd pcrphase, and the PCR15 measurement of the fake root's volume > key, are both missing > > - The attacker is in control of the system, and the TPM is in the right > state to unlock the real rootfs. The attacker talks to the TPM to get the > real rootfs's volume key. Attacker wins > > I think, ultimately, this is the same issue as the one you describe. Do you > think that's correct? > > Lennart would have a better idea than I do of what mitigations to this > would look like. But I suspect that: > > - You can't MITM the TPM, since the communication is encrypted > > - Other kinds of attacks cause the OS to know that a measurement failed. So > perhaps we need to very strict about ensuring that measurements happen. > i.e. By not letting the TPM disappear at runtime, and making sure that > measurements always succeed (and if it does, failing to boot or something) TOCTOU, time of check vs. time of use bugs may exists but they should be very hard to trigger, e.g. require HW debugger level access. If device specific encryption key leaks, then the data there can be modified by the attacker. I too fail to see the bug here. Cheers, -Mikko
Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
On Di, 11.03.25 13:16, Lennart Poettering ([email protected]) wrote: > On Mo, 10.03.25 12:27, Adrian Vovk ([email protected]) wrote: > > > Well, the TPM is supposed to be secure against hardware debugger access, in > > theory. Ditto with CPUs, and JTAG lockout. > > > > So if there's TOCTOU bugs in our code we need to be robust against them too. > > > > Anyway, I don't think this is a TOCTOU bug. Basically, it seems that we're > > sometimes OK letting communication to the TPM fail. In which case, an > > attacker can cause the communication to fail, and we'll be none the wiser > > > > If device specific encryption key leaks, then the data there can be modified > > > > by the attacker. I too fail to see the bug here. > > > > > > > Right, this is what we're trying to avoid. > > > > Basically, the bug is: an attacker does a DOS on the TPM in such a way that > > systemd boots to the rootfs without measuring the `leave-initrd` pcrphase, > > or the fake rootfs's pcr15. Once in the rootfs, the TPM doesn't know that > > it has left the initrd. And that's game over: the attacker stops DOSing the > > TPM, and extracts the encryption keys for the real rootfs from the TPM. > > it is true that we currently do not block continued booting if a > measurement fails. > > I figure systemd-pcrextend should start to simply invoke > reboot(RB_HALT_SYSTEM) if a TPM exists but it cannot extend a > PCR. Happy to take a PR for that. I prepped a PR for that now: https://github.com/systemd/systemd/pull/36705 Turned out to be much simpler than I expected... Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
Le mar. 11 mars 2025 à 13:27, Lennart Poettering a écrit : > On Mo, 10.03.25 19:25, Diorcet Yann ([email protected]) wrote: > > > Is PCR15 checked against a pre-calculated value saved in the signed > initrd > > before leaving initrd? If it's not the case, then when executing the init > > from the chrooted malicious partition, the original /dev/sda1 LUKS will > be > > opened and mounted as var. > > I think you are misunderstanding what PCR15 is supposed to be. it's > not really supposed to be consumed for FDE, but simply populated by > FDE. It's usecase was to later have PCR that identifies the local > system, that we can lock encrypted credentials or systemd-confext > images to. > > To protect the order of things use the "phase" logic, i.e. in PCR 15. > > And to say this very clearly: the model this is designed for assumes > you have one encrypted fs not many. i.e. if everything checks out then > you get access to it, and if it doesn't you don't. I am not sure I > understand your scenario, but you appear to work with two encrypted > disks, one for the rootfs and one for /var/? Yes, there is no > protection for using them for the wrong purpose (ie. the root fs for > /var/ or vice versa), because that was never in the picture of being > an issue. > > If you want multiple encrypted partitions like that, then things are a > lot more complicated, but let me ask you: why even? It makes sense to > split up things so that you have various sets of data with different > protections (i.e. some unprotected, some verity protected, some > encrypted + tpm). But if you have multiple partitions protected the > same way, why split them up, and why create such a headache then. > > Lennart > > -- > Lennart Poettering, Berlin > hi, I hope I'm not being (totally) off-topic with this : https://oddlama.org/blog/bypassing-disk-encryption-with-tpm2-unlock/ . regards.
Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
On Mo, 10.03.25 12:27, Adrian Vovk ([email protected]) wrote: > Well, the TPM is supposed to be secure against hardware debugger access, in > theory. Ditto with CPUs, and JTAG lockout. > > So if there's TOCTOU bugs in our code we need to be robust against them too. > > Anyway, I don't think this is a TOCTOU bug. Basically, it seems that we're > sometimes OK letting communication to the TPM fail. In which case, an > attacker can cause the communication to fail, and we'll be none the wiser > > If device specific encryption key leaks, then the data there can be modified > > by the attacker. I too fail to see the bug here. > > > > Right, this is what we're trying to avoid. > > Basically, the bug is: an attacker does a DOS on the TPM in such a way that > systemd boots to the rootfs without measuring the `leave-initrd` pcrphase, > or the fake rootfs's pcr15. Once in the rootfs, the TPM doesn't know that > it has left the initrd. And that's game over: the attacker stops DOSing the > TPM, and extracts the encryption keys for the real rootfs from the TPM. it is true that we currently do not block continued booting if a measurement fails. I figure systemd-pcrextend should start to simply invoke reboot(RB_HALT_SYSTEM) if a TPM exists but it cannot extend a PCR. Happy to take a PR for that. But then again, this isn't perfect either, because being able to issue the PCR extension is one thing. Actually verifying it had the desired effect on the right PCR of the right TPM is another. Or in other words: to be fully correct we would need to get a TPM quote on the relevant PCR from the TPM, validate it and check that the measurement is in there. And if not, also reboot. Note that nothing of this is really a "bug" though, it's just an effect of designing your trust model to be tighter or more relaxed. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
On Mo, 10.03.25 11:16, Adrian Vovk ([email protected]) wrote: > Hello, > > Just to see if I understand your concern correctly, I'll try boiling it > down to its simplest, by cutting out the need for two partitions. Here's > the scenario: > > - An attacker replaces the real rootfs with a malicious one that just drops > to a shell. The attacker keeps a copy of the original real rootfs > > - The system boots, then tries and fails to decrypt the fake rootfs. > > - The attacker now starts impeding communication between the TPM and the > CPU. Potentially by physically interposing on the bus and blocking > communication. Or by glitching the bus so that the data isn't successfully > measured. Anyway, the attacker somehow makes TPM measurements fail > > - The attacker unlocks their malicious rootfs, and then the system > continues booting. The attacker now gains control of the system via the > root shell. > > - The attacker stops impeding the communication between the TPM and the > CPU. The TPM is still in the same state as it was in the initrd. The > leave-initrd pcrphase, and the PCR15 measurement of the fake root's volume > key, are both missing > > - The attacker is in control of the system, and the TPM is in the right > state to unlock the real rootfs. The attacker talks to the TPM to get the > real rootfs's volume key. Attacker wins > > I think, ultimately, this is the same issue as the one you describe. Do you > think that's correct? > > Lennart would have a better idea than I do of what mitigations to this > would look like. But I suspect that: > > - You can't MITM the TPM, since the communication is encrypted Nope. PCR measurements are not encrypted, at least not by systemd. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
On Mo, 10.03.25 19:25, Diorcet Yann ([email protected]) wrote: > Is PCR15 checked against a pre-calculated value saved in the signed initrd > before leaving initrd? If it's not the case, then when executing the init > from the chrooted malicious partition, the original /dev/sda1 LUKS will be > opened and mounted as var. I think you are misunderstanding what PCR15 is supposed to be. it's not really supposed to be consumed for FDE, but simply populated by FDE. It's usecase was to later have PCR that identifies the local system, that we can lock encrypted credentials or systemd-confext images to. To protect the order of things use the "phase" logic, i.e. in PCR 15. And to say this very clearly: the model this is designed for assumes you have one encrypted fs not many. i.e. if everything checks out then you get access to it, and if it doesn't you don't. I am not sure I understand your scenario, but you appear to work with two encrypted disks, one for the rootfs and one for /var/? Yes, there is no protection for using them for the wrong purpose (ie. the root fs for /var/ or vice versa), because that was never in the picture of being an issue. If you want multiple encrypted partitions like that, then things are a lot more complicated, but let me ask you: why even? It makes sense to split up things so that you have various sets of data with different protections (i.e. some unprotected, some verity protected, some encrypted + tpm). But if you have multiple partitions protected the same way, why split them up, and why create such a headache then. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
On Mo, 10.03.25 10:14, Yann Diorcet ([email protected]) wrote: > > (Not sure if I follow what the issue is supposed to be, i.e. not sure > > what "try unlocks" is supposed to mean or what "the second" refers > > to. Just guessing here). > > > > There's a TODO list item somewhere to provide more finegrained conrol > > of which mechanisms are allowed to allow a disk, and conversely to > > measure the actual mechanism used. But until then simply disable > > interactivity fully. > > > > (note that fido2, tpm2, pkcs11 unlocking needs to be enabled manually, > > it's only passphrase/recovery key unlock which is on by default, and > > which you have to turn off via headless) > > > > > - Make the update of the PCR due to the measuring of the malicious > > > partition > > > fails > > > > hmm, i really cannot parse this? (not the rest either...?) > > If an attacker jams the communication with the TPM (discret one for > example) during the measuring phase of the first partition (which in > my example is the malicious one), the PCR will not be updated. "Jams the communication with the TPM"? Well, if you your threat model includes that this is possible then yes, measurements whose job is to "destroy" access to objects bound to a PCR will not be effective. But of course, if this is a realistic scenario to you, then the whole TPM logic just falls apart, because why suppress one measurement if you can just suppress them all, and issue them yourself instead with data of your choosing? you can get free access to anything then. > Allowing the second partition to be unlocked as it would be unlocked > in normal situtation: as the first unlocked partition. > If you don't add counter measure at the end of initrd in order to fail > this trick (as alplanas explained), you will chroot on the malicious > partition with the the good root partition unlocked and mounted as the > second partition. which counter measure do you precisely mean? Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
10.03.2025 18:16, Adrian Vovk wrote: Hello, Just to see if I understand your concern correctly, I'll try boiling it down to its simplest, by cutting out the need for two partitions. Here's the scenario: - An attacker replaces the real rootfs with a malicious one that just drops to a shell. The attacker keeps a copy of the original real rootfs - The system boots, then tries and fails to decrypt the fake rootfs. - The attacker now starts impeding communication between the TPM and the CPU. Potentially by physically interposing on the bus and blocking communication. Or by glitching the bus so that the data isn't successfully measured. Anyway, the attacker somehow makes TPM measurements fail You do not really need anything of that sort. It will not be possible to unlock using TPM anyway. You do need that initrd is configured to fall back to the interactive passphrase. - The attacker unlocks their malicious rootfs, and then the system continues booting. The attacker now gains control of the system via the root shell. - The attacker stops impeding the communication between the TPM and the CPU. The TPM is still in the same state as it was in the initrd. The leave-initrd pcrphase, and the PCR15 measurement of the fake root's volume key, are both missing Again - no physical intervention is needed. - The attacker is in control of the system, and the TPM is in the right state to unlock the real rootfs. The attacker talks to the TPM to get the real rootfs's volume key. Attacker wins I think, ultimately, this is the same issue as the one you describe. Do you think that's correct? Sort of. OP described the case of the LUKS container in the initrd, but I guess the same is also possible after switch to root. Depending on the initrd and the exact root container setup. Lennart would have a better idea than I do of what mitigations to this would look like. But I suspect that: - You can't MITM the TPM, since the communication is encrypted This is not needed. - Other kinds of attacks cause the OS to know that a measurement failed. So perhaps we need to very strict about ensuring that measurements happen. You can bind root to the PCR15 value *before* initrd and make sure initrd will update PCR15 after unlocking root. In this case PCR15 state will be different with the fake root and automatic unlock of the real root is not possible. You can use the service suggested by Alberto that prevents leaving initrd if PCR15 is different. It is possible to prohibit interactive unlock for root container, but that will effectively lock you out if anything happens with TPM. But there are so many possibilities to configure that this discussion needs at least one real life example that demonstrates that this attack is even possible. i.e. By not letting the TPM disappear at runtime, and making sure that measurements always succeed (and if it does, failing to boot or something) Best, Adrian On Mon, Mar 10, 2025, 05:23 Yann Diorcet wrote: Hi, Sorry for my english, i'm not english native. Le lun. 10 mars 2025 à 10:04, Lennart Poettering a écrit : On Sa, 08.03.25 19:52, Diorcet Yann ([email protected]) wrote: Hello, 61;7802;1c> I'm in the process of using SecureBoot, TPM2.0 and LUKS2 to protect an industrial embedded computer. I have a chain of trust in the UEFI (own secure boot keys/certificates), signed grub2, all files used by grub2 signed including kernel and initramfs, and successfully automatically unlocked LUKS partitions using TPM2.0 using PCR7. The main concern remaining is to be sure to chroot on the "good" root partition (and not a malicious one allowing to decrypt using TPM the "good" partition). pcrphase ensures that "good" root partition can only be unlocked in the good phase (after enter-initrd for example), this is an additional security. tpm2-measure-pcr provides a way to only decrypt other partitions after the "good" root partition: Using for example 7+11+15 But in the case of multiple partitions unlocked by the initrd, I can't figure why an attacker couldn't succeed to : - Clone the original disk (notably ESP) - Replace root partition by a malicious one - Fake the second (using UUID/PARTLABEL/...) but using LUKS partition from the "good" root partition - Boot the machine - The initrd will try unlocks the malicious partition as root. As the TPM token will not work, the attacker will use the password of his malicious LUKS Disable the password prompt via "headless" crypttab option. Thanks for this tip (Not sure if I follow what the issue is supposed to be, i.e. not sure what "try unlocks" is supposed to mean or what "the second" refers to. Just guessing here). There's a TODO list item somewhere to provide more finegrained conrol of which mechanisms are allowed to allow a disk, and conversely to measure the actual mechanism used. But until then simply disable interactivity fully. (note that fido2, tpm2, pkcs11 unlocking needs to
Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
Le 10/03/2025 à 17:27, Adrian Vovk a écrit : Hello, On Mon, Mar 10, 2025, 12:06 Mikko Rapeli wrote: Hi, On Mon, Mar 10, 2025 at 11:16:25AM -0400, Adrian Vovk wrote: > Hello, > > Just to see if I understand your concern correctly, I'll try boiling it > down to its simplest, by cutting out the need for two partitions. Here's > the scenario: > > - An attacker replaces the real rootfs with a malicious one that just drops > to a shell. The attacker keeps a copy of the original real rootfs This should not be possible without breaking encryption keys from the device. If the rootfs is not encrypted with device specific keys derived from TPM measurements or dm-verity where root hash has been hard coded into secureboot signed UKI binary for the kernel, then the setup is not secure to start with. If dm-verity image has been tampered it will fail signature checks and fail to mount. This is inaccurate. systemd's security model allows for the rootfs to be replaced with a different one. There's no good way to actually prevent that: all partition table metadata is spoofable, including UUIDs and whatnot Of course, if you're using dm-verity on the rootfs, the attacker can only replace the rootfs with a copy of itself. But I don't think this is the case here, since the thread started with the presumption that the attacker can replace the rootfs. To be clear, the partition layout I'm thinking about is: dm-verity protected /usr partitions (A/B copies), and then a separate rootfs partition that exists just to store persistent data (/var, /etc, etc). In this scenario, there's nothing preventing someone from replacing the rootfs partition's contents with anything arbitrary. > - The system boots, then tries and fails to decrypt the fake rootfs. > > - The attacker now starts impeding communication between the TPM and the > CPU. Potentially by physically interposing on the bus and blocking > communication. Or by glitching the bus so that the data isn't successfully > measured. Anyway, the attacker somehow makes TPM measurements fail > > - The attacker unlocks their malicious rootfs, and then the system > continues booting. The attacker now gains control of the system via the > root shell. This means that TPM, firmware, kernel or initrd have been compromized at runtime after their TPM measurements and secureboot signatures have been verified. A denial of service attack is relatively simple but any code executions should be grave bugs which need updates to get fixed. An initrd should have only very limited functionality and no fallback interactive shells or prompts, or network drivers or daemons. If you can replace the rootfs (which we've established: you can), then that rootfs can contain whatever you want to gain execution early during boot. It can be as easy as a single symlink in /etc: basic.target.wants/systemd-debug-shell.service It may be possible to cut down TPM communication and to make systemd and other service to wait for longer time but it is simpler to freeze RAM and CPU state and change the rootfs entry with physical attack via JTAG, if such interfaces are enabled in HW. The point is to disable the TPM enough that systemd gives up trying to measure pcrphases, and moves on. If it continues booting in that case, there's a big problem > - The attacker stops impeding the communication between the TPM and the > CPU. The TPM is still in the same state as it was in the initrd. The > leave-initrd pcrphase, and the PCR15 measurement of the fake root's volume > key, are both missing > > - The attacker is in control of the system, and the TPM is in the right > state to unlock the real rootfs. The attacker talks to the TPM to get the > real rootfs's volume key. Attacker wins > > I think, ultimately, this is the same issue as the one you describe. Do you > think that's correct? > > Lennart would have a better idea than I do of what mitigations to this > would look like. But I suspect that: > > - You can't MITM the TPM, since the communication is encrypted > > - Other kinds of attacks cause the OS to know that a measurement failed. So > perhaps we need to very strict about ensuring that measurements happen. > i.e. By not letting the TPM disappear at runtime, and making sure that > measurements always succeed (and if it does, failing to boot or something) TOCTOU, time of check vs. time of use bugs may exists but they should be very hard to trigger, e.g. require HW debugger level access. Well, the TPM is supposed to be secure against hardware debugger access, in theory. Ditto with CPUs, and JTAG lockout. So if there's TOCTOU bugs in our code we
Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
On 2025-03-10 18:25, Diorcet Yann wrote: Le 10/03/2025 à 17:27, Adrian Vovk a écrit : 2) Just before opening the var LUKS: PCR15=0 or something predictable cryptsetup is used to open var and update PCR15 thanks to tpm2-measure-pcr=yes. but in this case /dev/sda1 is replaced with the original /dev/sda1 partition. I think that you mean that /dev/sda2 (/var) is replaced with the original /dev/sda1 (rootfs), so mounting the original root in /var, right? PCR15=hash1 3) initrd makes the mount of the fs, makes multiple measurements (notably on PCR11 with leave-initrd) then chroots and executes malicious init. Is PCR15 checked against a pre-calculated value saved in the signed initrd before leaving initrd? If it's not the case, then when executing the init from the chrooted malicious partition, the original /dev/sda1 LUKS will be opened and mounted as var. You need a service in the initrd to do that. systemd AFAIK is not currently providing one, but the plumbing is there to bring your own.
Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
Hi, Sorry for my english, i'm not english native. Le lun. 10 mars 2025 à 10:04, Lennart Poettering a écrit : > > On Sa, 08.03.25 19:52, Diorcet Yann ([email protected]) wrote: > > > Hello, > 61;7802;1c> > > I'm in the process of using SecureBoot, TPM2.0 and LUKS2 to protect an > > industrial embedded computer. > > > > I have a chain of trust in the UEFI (own secure boot keys/certificates), > > signed grub2, all files used by grub2 signed including kernel and > > initramfs, and successfully automatically unlocked LUKS partitions using > > TPM2.0 using PCR7. > > > > The main concern remaining is to be sure to chroot on the "good" root > > partition (and not a malicious one allowing to decrypt using TPM the "good" > > partition). > > > > pcrphase ensures that "good" root partition can only be unlocked in the good > > phase (after enter-initrd for example), this is an additional security. > > > > tpm2-measure-pcr provides a way to only decrypt other partitions after the > > "good" root partition: Using for example 7+11+15 > > > > > > But in the case of multiple partitions unlocked by the initrd, I can't > > figure why an attacker couldn't succeed to : > > > > - Clone the original disk (notably ESP) > > > > - Replace root partition by a malicious one > > > > - Fake the second (using UUID/PARTLABEL/...) but using LUKS partition from > > the "good" root partition > > > > - Boot the machine > > > > - The initrd will try unlocks the malicious partition as root. As the TPM > > token will not work, the attacker will use the password of his malicious > > LUKS > > Disable the password prompt via "headless" crypttab option. Thanks for this tip > > (Not sure if I follow what the issue is supposed to be, i.e. not sure > what "try unlocks" is supposed to mean or what "the second" refers > to. Just guessing here). > > There's a TODO list item somewhere to provide more finegrained conrol > of which mechanisms are allowed to allow a disk, and conversely to > measure the actual mechanism used. But until then simply disable > interactivity fully. > > (note that fido2, tpm2, pkcs11 unlocking needs to be enabled manually, > it's only passphrase/recovery key unlock which is on by default, and > which you have to turn off via headless) > > > - Make the update of the PCR due to the measuring of the malicious partition > > fails > > hmm, i really cannot parse this? (not the rest either...?) If an attacker jams the communication with the TPM (discret one for example) during the measuring phase of the first partition (which in my example is the malicious one), the PCR will not be updated. Allowing the second partition to be unlocked as it would be unlocked in normal situtation: as the first unlocked partition. If you don't add counter measure at the end of initrd in order to fail this trick (as alplanas explained), you will chroot on the malicious partition with the the good root partition unlocked and mounted as the second partition. > > Lennart > > -- > Lennart Poettering, Berlin Yann
Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
On 2025-03-10 08:41, Andrei Borzenkov wrote:
On Mon, Mar 10, 2025 at 11:03 AM aplanas wrote:
On 2025-03-08 18:52, Diorcet Yann wrote:
> - Fake the second (using UUID/PARTLABEL/...) but using LUKS partition
> from the "good" root partition
This is done by "systemd-pcrfs[-root]". The attacker needs to have
access to the system (as a normal user to use something like lsblk)
The attacker will have a different root filesystem that allows
anything.
Right. But my point was that to impersonate the original root they have
to know those values and for that they need access to the system.
I do not know in the OP case, but in some other situations if the user
has enough access to know those values the system can be already be
considered compromised.
tpm2-measure-pcr take the LUKS2 volume key (cryptsetup luksDump
--dump-master-key), and this requires the effective unlock of the
device
(via TPM2 or passphrase)
> - Boot the machine
>
> - The initrd will try unlocks the malicious partition as root. As the
> TPM token will not work, the attacker will use the password of his
> malicious LUKS
>
> - Make the update of the PCR due to the measuring of the malicious
> partition fails
As commented, using tpm2-measure-pcr, PCR15 will be extended with
HMAC("cryptsetup:$name:$uuid", vk), and vk cannot be impersonated.
The catch here is that you need to bind your *root* to the PCR15 too.
I.e. you need both
systemd-cryptenroll --tpm2-pcrs=...+15:sha256=0x0 ... /dev/your-root
and /etc/crypttab in initrd
cr_root /dev/your-root - tpm2-measure-pcr,...
Otherwise the described attack looks possible (probably, depending on
the other PCRs to which root is bound).
That does not make any sense to me ...
For systemd-cryptsetup to measure PCR15 it need to read the vk, and to
read the vk the volume needs to be already unlocked. PCR15 cannot
participate in the unlock policy.
> - Initrd will try to unlock the second partition, which is the "good"
> root partition, and it will succeed, allowing the attacker to finally
> access all data from the partition.
Yes, this partition can be unlocked using a policy that uses PCR0..9
for
TPM2 (without PIN). But not necessarily means that the attacker has
any
access yet, at least not while we are in the initrd.
See above. Attacker has already substituted the root, so /if/ this
unlocks succeeds, the attacker has access to the system.
And I agree on that, but I also wrote that for that to be true the
initrd needs complete the switch root (and delegate the execution the
init process to the compromised device).
My point is that there is a lapse of time where the compromised device
and the real root are open (bad thing), but the control is still in the
trusted initrd (good thing). In this brief moment the attacker has no
control of the system yet.
Another way to mitigate this is to additionally bind to the PCRs that
measure bootloader state like PCR5. As long as the fake root has a
different GUID it should prevent automatic unlocking. Not sure how
UEFI firmware will respond to two completely identical disks.
I thought about PCR 5 too, but IIUC the measured information is easy to
replicate.
I think that there is a more simple model, that was described in a
nice
blog post some months ago. The idea is to never leave the initrd if
the
expected value of PCR15 is not meet.
Yes, but the point is that you need to arrange for that additionally.
That I do not understand.
The last step is to have a service in the initrd that is executed
after
[email protected], but before the switch root, it will
compare
the current PCR15 value with the expected one, and if it fails it will
halt the system.
Well, with e.g. dracut an attacker still can break early, before your
script runs, and manually invoke systemd-cryptsetup.
For that you need to change the cmdline, that was measured and part of
the policy that open the device.
The protection must belong to the LUKS
partition itself. It must be bound to the PCRs which allow detection
of the altered command line among other things. Binding root to PCR7
most certainly is *not* enough.
The current implementation of tpm2-measure-pcr is based on extending
PCR15 with the LUKS2 volume key, and the key point is that to extract
this volume key you already need to open the device. That is the point
that I think you are missing.
But I see that maybe there are other alternatives, like reading the
LUKS2 raw header with the keyslots and encrypted vk. That measure could
participate in the policy, and even if it can be replicated, I do not
see how can be used, but this is not how tpm2-measure-pcr works.
Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
On Sa, 08.03.25 19:52, Diorcet Yann ([email protected]) wrote: > Hello, 61;7802;1c> > I'm in the process of using SecureBoot, TPM2.0 and LUKS2 to protect an > industrial embedded computer. > > I have a chain of trust in the UEFI (own secure boot keys/certificates), > signed grub2, all files used by grub2 signed including kernel and > initramfs, and successfully automatically unlocked LUKS partitions using > TPM2.0 using PCR7. > > The main concern remaining is to be sure to chroot on the "good" root > partition (and not a malicious one allowing to decrypt using TPM the "good" > partition). > > pcrphase ensures that "good" root partition can only be unlocked in the good > phase (after enter-initrd for example), this is an additional security. > > tpm2-measure-pcr provides a way to only decrypt other partitions after the > "good" root partition: Using for example 7+11+15 > > > But in the case of multiple partitions unlocked by the initrd, I can't > figure why an attacker couldn't succeed to : > > - Clone the original disk (notably ESP) > > - Replace root partition by a malicious one > > - Fake the second (using UUID/PARTLABEL/...) but using LUKS partition from > the "good" root partition > > - Boot the machine > > - The initrd will try unlocks the malicious partition as root. As the TPM > token will not work, the attacker will use the password of his malicious > LUKS Disable the password prompt via "headless" crypttab option. (Not sure if I follow what the issue is supposed to be, i.e. not sure what "try unlocks" is supposed to mean or what "the second" refers to. Just guessing here). There's a TODO list item somewhere to provide more finegrained conrol of which mechanisms are allowed to allow a disk, and conversely to measure the actual mechanism used. But until then simply disable interactivity fully. (note that fido2, tpm2, pkcs11 unlocking needs to be enabled manually, it's only passphrase/recovery key unlock which is on by default, and which you have to turn off via headless) > - Make the update of the PCR due to the measuring of the malicious partition > fails hmm, i really cannot parse this? (not the rest either...?) Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
On Mon, Mar 10, 2025 at 11:03 AM aplanas wrote:
>
> On 2025-03-08 18:52, Diorcet Yann wrote:
>
> > But in the case of multiple partitions unlocked by the initrd, I can't
> > figure why an attacker couldn't succeed to :
> >
> > - Clone the original disk (notably ESP)
> >
> > - Replace root partition by a malicious one
> >
> > - Fake the second (using UUID/PARTLABEL/...) but using LUKS partition
> > from the "good" root partition
>
> This is done by "systemd-pcrfs[-root]". The attacker needs to have
> access to the system (as a normal user to use something like lsblk)
>
The attacker will have a different root filesystem that allows anything.
> tpm2-measure-pcr take the LUKS2 volume key (cryptsetup luksDump
> --dump-master-key), and this requires the effective unlock of the device
> (via TPM2 or passphrase)
>
> > - Boot the machine
> >
> > - The initrd will try unlocks the malicious partition as root. As the
> > TPM token will not work, the attacker will use the password of his
> > malicious LUKS
> >
> > - Make the update of the PCR due to the measuring of the malicious
> > partition fails
>
> As commented, using tpm2-measure-pcr, PCR15 will be extended with
> HMAC("cryptsetup:$name:$uuid", vk), and vk cannot be impersonated.
>
The catch here is that you need to bind your *root* to the PCR15 too.
I.e. you need both
systemd-cryptenroll --tpm2-pcrs=...+15:sha256=0x0 ... /dev/your-root
and /etc/crypttab in initrd
cr_root /dev/your-root - tpm2-measure-pcr,...
Otherwise the described attack looks possible (probably, depending on
the other PCRs to which root is bound).
> > - Initrd will try to unlock the second partition, which is the "good"
> > root partition, and it will succeed, allowing the attacker to finally
> > access all data from the partition.
>
> Yes, this partition can be unlocked using a policy that uses PCR0..9 for
> TPM2 (without PIN). But not necessarily means that the attacker has any
> access yet, at least not while we are in the initrd.
>
See above. Attacker has already substituted the root, so /if/ this
unlocks succeeds, the attacker has access to the system.
Another way to mitigate this is to additionally bind to the PCRs that
measure bootloader state like PCR5. As long as the fake root has a
different GUID it should prevent automatic unlocking. Not sure how
UEFI firmware will respond to two completely identical disks.
> With measured boot, the previous stage measure something of the next
> stage before delegating. The initrd needs to measure something from the
> device to continue the chain of trust. IIRC in the image-based proposal
> that was the dm-verity root key. If dm-verity is not used, then
> something else needs to be measured. The volume key seems a good
> replacement.
>
> > The main point here is to "Make the update of the PCR due to the
> > measuring of the malicious partition fails".
>
> I think that there is a more simple model, that was described in a nice
> blog post some months ago. The idea is to never leave the initrd if the
> expected value of PCR15 is not meet.
>
Yes, but the point is that you need to arrange for that additionally.
> In this model PCR15 does not participate in the unseal of any secret.
> Instead you need to mark the encrypted partitions as tpm2-measure-pcr
> that are unlocked early in the initrd (root, swap, and the ones with
> x-initrd.attach).
>
> Maybe using a generator, we need to order how systemd-cryptsetup will
> access those devices. This is optional, but will simplify a lot how to
> make predictions for PCR15.
>
> The last step is to have a service in the initrd that is executed after
> [email protected], but before the switch root, it will compare
> the current PCR15 value with the expected one, and if it fails it will
> halt the system.
>
Well, with e.g. dracut an attacker still can break early, before your
script runs, and manually invoke systemd-cryptsetup. This will not
even require any faking of LUKS UUID or partition GUID. And it will
not require any fake root. The protection must belong to the LUKS
partition itself. It must be bound to the PCRs which allow detection
of the altered command line among other things. Binding root to PCR7
most certainly is *not* enough.
> With something like this an attacker cannot replace any of the disk that
> belong to the OS without being detected. This would require the
> alteration of initrd in the UKI or on the ESP, that is covered by the
> measured boot policy.
>
> There is some code here:
>
> * A generator that order the PCR15 extensions
>
> https://github.com/openSUSE/sdbootutil/blob/main/measure-pcr-generator.sh
>
> * A predictor for PCR15
>https://github.com/openSUSE/sdbootutil/blob/main/sdbootutil#L2210
>
> * A validator service that stop the boot process if the expected value
> did not match
>(also validate the signature of the file that contains the prediction)
>
> https://github.com/openSUSE/sdbootutil/blob/main/measure-pcr-validator.sh
>
> * (Only for
Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
Thanks for you reply. My point is that defeating the PCR update in the measuring step of systemd-crypsetup could be not so hard to realize (see the two ways in my initial email) Le dim. 9 mars 2025 à 09:02, Andrei Borzenkov a écrit : > 08.03.2025 22:40, Andrei Borzenkov wrote: > > 08.03.2025 21:52, Diorcet Yann wrote: > >> Hello, > >> > >> I'm in the process of using SecureBoot, TPM2.0 and LUKS2 to protect an > >> industrial embedded computer. > >> > >> I have a chain of trust in the UEFI (own secure boot keys/certificates), > >> signed grub2, all files used by grub2 signed including kernel and > >> initramfs, and successfully automatically unlocked LUKS partitions > >> using TPM2.0 using PCR7. > >> > >> The main concern remaining is to be sure to chroot on the "good" root > >> partition (and not a malicious one allowing to decrypt using TPM the > >> "good" partition). > >> > >> pcrphase ensures that "good" root partition can only be unlocked in the > >> good phase (after enter-initrd for example), this is an additional > security. > >> > >> tpm2-measure-pcr provides a way to only decrypt other partitions after > >> the "good" root partition: Using for example 7+11+15 > >> > >> > >> But in the case of multiple partitions unlocked by the initrd, I can't > >> figure why an attacker couldn't succeed to : > >> > > > > tpm2-measure-pcr is in /etc/crypttab which is included in the signed > > initrd and so cannot be forged. As long as the second device depends on > > the result of the measurement of the first (root), replacing root will > > fail to automatically unlock it. > > > > Sorry, you actually were right. Normally root will not depend on any > previous measurements and we trust device metadata to provide the list > of PCRs. > > You will need to add the PCR into which root is measured to the root > metadata. It would normally be in the initial well known state directly > after boot (so, when root is normally unlocked) but will change if you > exchange the real root for the fake one. > > >> - Clone the original disk (notably ESP) > >> > >> - Replace root partition by a malicious one > >> > >> - Fake the second (using UUID/PARTLABEL/...) but using LUKS partition > >> from the "good" root partition > >> > >> - Boot the machine > >> > >> - The initrd will try unlocks the malicious partition as root. As the > >> TPM token will not work, the attacker will use the password of his > >> malicious LUKS > >> > >> - Make the update of the PCR due to the measuring of the malicious > >> partition fails > >> > >> - Initrd will try to unlock the second partition, which is the "good" > >> root partition, and it will succeed, allowing the attacker to finally > >> access all data from the partition. > >> > >> > >> The main point here is to "Make the update of the PCR due to the > >> measuring of the malicious partition fails". > >> > >> Indeed the measuring may be never executed: > >> > >> > https://github.com/systemd/systemd/blob/bd0d22c2a5bdbf427c68eab630dc06f55dc96c72/src/cryptsetup/cryptsetup.c#L1085 > >> > >> This may happens in few cases: > >> > >> - volume_key_size == 0? Is it possible to make cryptsetup to unlock a > >> malicious partition during initrd with this condition? I'm not aware of > >> the details for example with LUKS2 > >> > >> - Making the measure_volume_key fails will not produce any counter > >> reaction (just an error message for example "Could not extend PCR: 15"): > >> "OK if fails" > >> > >> A way to make it happens, is to glitching at a specific moment the > >> communication with the TPM2.0, or using MITM faking/failing an update of > >> the PCR allowing automatic unlock of the "good" root partitions as > >> second partition. Adding a check on measure_volume_key return value may > >> be not sufficient. > >> > >> > >> Maybe I missing some pieces, but I only see two ways to defeat that: > >> > >> - Enforcing the use of TPM2.0 exclusively (no fallback on password): > >> cryptsetup exiting with non zero exit code making initrd fails. Is it > >> possible? > >> > >> - Don't use multiple encrypted partitions. > >> > >> > >> May I miss understanding something? > >> > >> > >> Regards, > >> > >> Yann > >> > >> > >> > >> > > > >
Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
08.03.2025 22:40, Andrei Borzenkov wrote: 08.03.2025 21:52, Diorcet Yann wrote: Hello, I'm in the process of using SecureBoot, TPM2.0 and LUKS2 to protect an industrial embedded computer. I have a chain of trust in the UEFI (own secure boot keys/certificates), signed grub2, all files used by grub2 signed including kernel and initramfs, and successfully automatically unlocked LUKS partitions using TPM2.0 using PCR7. The main concern remaining is to be sure to chroot on the "good" root partition (and not a malicious one allowing to decrypt using TPM the "good" partition). pcrphase ensures that "good" root partition can only be unlocked in the good phase (after enter-initrd for example), this is an additional security. tpm2-measure-pcr provides a way to only decrypt other partitions after the "good" root partition: Using for example 7+11+15 But in the case of multiple partitions unlocked by the initrd, I can't figure why an attacker couldn't succeed to : tpm2-measure-pcr is in /etc/crypttab which is included in the signed initrd and so cannot be forged. As long as the second device depends on the result of the measurement of the first (root), replacing root will fail to automatically unlock it. Sorry, you actually were right. Normally root will not depend on any previous measurements and we trust device metadata to provide the list of PCRs. You will need to add the PCR into which root is measured to the root metadata. It would normally be in the initial well known state directly after boot (so, when root is normally unlocked) but will change if you exchange the real root for the fake one. - Clone the original disk (notably ESP) - Replace root partition by a malicious one - Fake the second (using UUID/PARTLABEL/...) but using LUKS partition from the "good" root partition - Boot the machine - The initrd will try unlocks the malicious partition as root. As the TPM token will not work, the attacker will use the password of his malicious LUKS - Make the update of the PCR due to the measuring of the malicious partition fails - Initrd will try to unlock the second partition, which is the "good" root partition, and it will succeed, allowing the attacker to finally access all data from the partition. The main point here is to "Make the update of the PCR due to the measuring of the malicious partition fails". Indeed the measuring may be never executed: https://github.com/systemd/systemd/blob/bd0d22c2a5bdbf427c68eab630dc06f55dc96c72/src/cryptsetup/cryptsetup.c#L1085 This may happens in few cases: - volume_key_size == 0? Is it possible to make cryptsetup to unlock a malicious partition during initrd with this condition? I'm not aware of the details for example with LUKS2 - Making the measure_volume_key fails will not produce any counter reaction (just an error message for example "Could not extend PCR: 15"): "OK if fails" A way to make it happens, is to glitching at a specific moment the communication with the TPM2.0, or using MITM faking/failing an update of the PCR allowing automatic unlock of the "good" root partitions as second partition. Adding a check on measure_volume_key return value may be not sufficient. Maybe I missing some pieces, but I only see two ways to defeat that: - Enforcing the use of TPM2.0 exclusively (no fallback on password): cryptsetup exiting with non zero exit code making initrd fails. Is it possible? - Don't use multiple encrypted partitions. May I miss understanding something? Regards, Yann
Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
08.03.2025 21:52, Diorcet Yann wrote: Hello, I'm in the process of using SecureBoot, TPM2.0 and LUKS2 to protect an industrial embedded computer. I have a chain of trust in the UEFI (own secure boot keys/certificates), signed grub2, all files used by grub2 signed including kernel and initramfs, and successfully automatically unlocked LUKS partitions using TPM2.0 using PCR7. The main concern remaining is to be sure to chroot on the "good" root partition (and not a malicious one allowing to decrypt using TPM the "good" partition). pcrphase ensures that "good" root partition can only be unlocked in the good phase (after enter-initrd for example), this is an additional security. tpm2-measure-pcr provides a way to only decrypt other partitions after the "good" root partition: Using for example 7+11+15 But in the case of multiple partitions unlocked by the initrd, I can't figure why an attacker couldn't succeed to : tpm2-measure-pcr is in /etc/crypttab which is included in the signed initrd and so cannot be forged. As long as the second device depends on the result of the measurement of the first (root), replacing root will fail to automatically unlock it. - Clone the original disk (notably ESP) - Replace root partition by a malicious one - Fake the second (using UUID/PARTLABEL/...) but using LUKS partition from the "good" root partition - Boot the machine - The initrd will try unlocks the malicious partition as root. As the TPM token will not work, the attacker will use the password of his malicious LUKS - Make the update of the PCR due to the measuring of the malicious partition fails - Initrd will try to unlock the second partition, which is the "good" root partition, and it will succeed, allowing the attacker to finally access all data from the partition. The main point here is to "Make the update of the PCR due to the measuring of the malicious partition fails". Indeed the measuring may be never executed: https://github.com/systemd/systemd/blob/bd0d22c2a5bdbf427c68eab630dc06f55dc96c72/src/cryptsetup/cryptsetup.c#L1085 This may happens in few cases: - volume_key_size == 0? Is it possible to make cryptsetup to unlock a malicious partition during initrd with this condition? I'm not aware of the details for example with LUKS2 - Making the measure_volume_key fails will not produce any counter reaction (just an error message for example "Could not extend PCR: 15"): "OK if fails" A way to make it happens, is to glitching at a specific moment the communication with the TPM2.0, or using MITM faking/failing an update of the PCR allowing automatic unlock of the "good" root partitions as second partition. Adding a check on measure_volume_key return value may be not sufficient. Maybe I missing some pieces, but I only see two ways to defeat that: - Enforcing the use of TPM2.0 exclusively (no fallback on password): cryptsetup exiting with non zero exit code making initrd fails. Is it possible? - Don't use multiple encrypted partitions. May I miss understanding something? Regards, Yann
