Re: [systemd-devel] Enrolling PCR11 does not work as expected
In order to achieve the check of a number of PCRs, what do you guys think of this approach? 1. When running ukify, add the "measure" flag so that the expected value of the PCR11 is printed. 2. Then, script the reset of an unused PCR (in my case, 23), and the extend it with the current value of PCRs 7 and 14, and the expected value of PCR 11 3. Run systemd-cryptenroll against PCR 23 4. add a configuration drop to /etc/systemd/system/systemd-cryptsetup@.service.d, so that at ExecPre a similar script of that in 2 is run, but in this case resetting PCR 23 and extending it with the actual values of PCRs 7, 14 and 11. Do you guys this approach is sound? Thank you, Felix On 2023-07-05 14:26, Lennart Poettering wrote: On Mi, 05.07.23 13:11, Felix Rubio (fe...@kngnt.org) wrote: For what is explained on the the systemd-pcrphase.service(8) and comparing it to what I see in the log of the systemd services, there are three events in relation to this question: systemd-pcrphase-initrd.service [...] [systemd-ask-password-console.service] [...] systemd-pcrphase-sysinit systemd-pcrphase This means that, indeed, running cryptenroll after the new kernel has booted will never provide the correct PCR registry for 11. But then... what options do I have? Do I need to choose between having PCRs 7 and 14, so that I make sure that SB is up and running and all the certs from shim have not changed, or to have only PCR 11 so that I know that the UKI has not changed although SB can potentially be even disabled (please, correct me if wrong)? The idea is that with systemd-measure you sign the pre-calculated PCRs for all phases you care about with a key, and then you use enroll the public key that matches that signature in the disk encryption, rather than literal PCR values. Using signed PCR policies enables you to do multiple things at once: 1. You can easily enroll one public key, and have it cover multiple phases of the boot, simply by providing multiple signatures for the PCR values expected in the various boot phases. 2. You can easily enroll one public key, and then update the UKI and still boot up correctly, by providing a new set of signatures for the new expected PCR values for the various boot phases. Hence, the PCR 11 logic we have in place is *not* designed with TPM policies that bind to explicit PCR values in mind. Instead it is designed in mind with policies that bind to public keys that match signatures of those PCR values. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Enrolling PCR11 does not work as expected
I understand that, but systemd-measure is only about PCR 11. Is there any way to provide a list of PCRs, so that additionally can be embedded on the UKI? Thank you, Felix On 2023-07-05 14:26, Lennart Poettering wrote: On Mi, 05.07.23 13:11, Felix Rubio (fe...@kngnt.org) wrote: For what is explained on the the systemd-pcrphase.service(8) and comparing it to what I see in the log of the systemd services, there are three events in relation to this question: systemd-pcrphase-initrd.service [...] [systemd-ask-password-console.service] [...] systemd-pcrphase-sysinit systemd-pcrphase This means that, indeed, running cryptenroll after the new kernel has booted will never provide the correct PCR registry for 11. But then... what options do I have? Do I need to choose between having PCRs 7 and 14, so that I make sure that SB is up and running and all the certs from shim have not changed, or to have only PCR 11 so that I know that the UKI has not changed although SB can potentially be even disabled (please, correct me if wrong)? The idea is that with systemd-measure you sign the pre-calculated PCRs for all phases you care about with a key, and then you use enroll the public key that matches that signature in the disk encryption, rather than literal PCR values. Using signed PCR policies enables you to do multiple things at once: 1. You can easily enroll one public key, and have it cover multiple phases of the boot, simply by providing multiple signatures for the PCR values expected in the various boot phases. 2. You can easily enroll one public key, and then update the UKI and still boot up correctly, by providing a new set of signatures for the new expected PCR values for the various boot phases. Hence, the PCR 11 logic we have in place is *not* designed with TPM policies that bind to explicit PCR values in mind. Instead it is designed in mind with policies that bind to public keys that match signatures of those PCR values. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Enrolling PCR11 does not work as expected
On Mi, 05.07.23 14:17, Mantas Mikulėnas (graw...@gmail.com) wrote: > On Wed, Jul 5, 2023 at 2:11 PM Felix Rubio wrote: > > > For what is explained on the the systemd-pcrphase.service(8) and > > comparing it to what I see in the log of the systemd services, there are > > three events in relation to this question: > > > > systemd-pcrphase-initrd.service > > [...] > > [systemd-ask-password-console.service] > > [...] > > systemd-pcrphase-sysinit > > systemd-pcrphase > > > > This means that, indeed, running cryptenroll after the new kernel has > > booted will never provide the correct PCR registry for 11. But then... > > what options do I have? Do I need to choose between having PCRs 7 and > > 14, so that I make sure that SB is up and running and all the certs from > > shim have not changed, or to have only PCR 11 so that I know that the > > UKI has not changed although SB can potentially be even disabled > > (please, correct me if wrong)? > > > > I think the idea is to use `systemd-measure` to precompute PCR 11 for a > specific phase, then use the precomputed PCR value instead of the "live" > PCR value when sealing the data. > > systemd-cryptenroll does not accept raw PCR values directly (though I use a > separate python script for that); instead it accepts --tpm2-public-key= as > a public key that could be used to *sign* PCR values, and an external > --tpm2-signature= path that'll contain the signed data. > > So I believe you're supposed to use systemd-measure to precompute and sign > PCR 11, put the signed file in /boot, and tell systemd-cryptenroll to use > that when unlocking. (Later you only need to re-sign the PCR measurements > in /boot without needing to re-do cryptenroll.) Actually, my recommendation is to embed the signature file in the UKI itself, after all the signatures are specific to specific UKIs, and hence it makes sense to glue them into the UKIs. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Enrolling PCR11 does not work as expected
On Mi, 05.07.23 13:11, Felix Rubio (fe...@kngnt.org) wrote: > For what is explained on the the systemd-pcrphase.service(8) and comparing > it to what I see in the log of the systemd services, there are three events > in relation to this question: > > systemd-pcrphase-initrd.service > [...] > [systemd-ask-password-console.service] > [...] > systemd-pcrphase-sysinit > systemd-pcrphase > > This means that, indeed, running cryptenroll after the new kernel has booted > will never provide the correct PCR registry for 11. But then... what options > do I have? Do I need to choose between having PCRs 7 and 14, so that I make > sure that SB is up and running and all the certs from shim have not changed, > or to have only PCR 11 so that I know that the UKI has not changed although > SB can potentially be even disabled (please, correct me if wrong)? The idea is that with systemd-measure you sign the pre-calculated PCRs for all phases you care about with a key, and then you use enroll the public key that matches that signature in the disk encryption, rather than literal PCR values. Using signed PCR policies enables you to do multiple things at once: 1. You can easily enroll one public key, and have it cover multiple phases of the boot, simply by providing multiple signatures for the PCR values expected in the various boot phases. 2. You can easily enroll one public key, and then update the UKI and still boot up correctly, by providing a new set of signatures for the new expected PCR values for the various boot phases. Hence, the PCR 11 logic we have in place is *not* designed with TPM policies that bind to explicit PCR values in mind. Instead it is designed in mind with policies that bind to public keys that match signatures of those PCR values. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Enrolling PCR11 does not work as expected
On Wed, Jul 5, 2023 at 2:11 PM Felix Rubio wrote: > For what is explained on the the systemd-pcrphase.service(8) and > comparing it to what I see in the log of the systemd services, there are > three events in relation to this question: > > systemd-pcrphase-initrd.service > [...] > [systemd-ask-password-console.service] > [...] > systemd-pcrphase-sysinit > systemd-pcrphase > > This means that, indeed, running cryptenroll after the new kernel has > booted will never provide the correct PCR registry for 11. But then... > what options do I have? Do I need to choose between having PCRs 7 and > 14, so that I make sure that SB is up and running and all the certs from > shim have not changed, or to have only PCR 11 so that I know that the > UKI has not changed although SB can potentially be even disabled > (please, correct me if wrong)? > I think the idea is to use `systemd-measure` to precompute PCR 11 for a specific phase, then use the precomputed PCR value instead of the "live" PCR value when sealing the data. systemd-cryptenroll does not accept raw PCR values directly (though I use a separate python script for that); instead it accepts --tpm2-public-key= as a public key that could be used to *sign* PCR values, and an external --tpm2-signature= path that'll contain the signed data. So I believe you're supposed to use systemd-measure to precompute and sign PCR 11, put the signed file in /boot, and tell systemd-cryptenroll to use that when unlocking. (Later you only need to re-sign the PCR measurements in /boot without needing to re-do cryptenroll.) -- Mantas Mikulėnas
Re: [systemd-devel] Enrolling PCR11 does not work as expected
For what is explained on the the systemd-pcrphase.service(8) and comparing it to what I see in the log of the systemd services, there are three events in relation to this question: systemd-pcrphase-initrd.service [...] [systemd-ask-password-console.service] [...] systemd-pcrphase-sysinit systemd-pcrphase This means that, indeed, running cryptenroll after the new kernel has booted will never provide the correct PCR registry for 11. But then... what options do I have? Do I need to choose between having PCRs 7 and 14, so that I make sure that SB is up and running and all the certs from shim have not changed, or to have only PCR 11 so that I know that the UKI has not changed although SB can potentially be even disabled (please, correct me if wrong)? Thank you! Felix On 2023-07-05 10:36, Lennart Poettering wrote: On Mi, 05.07.23 08:30, Felix Rubio (fe...@kngnt.org) wrote: Hi everybody, In my setup (sd-boot+UKI+LUKS) I am using PCRs 7+11+14 to unlock the LUKS drive. Should I use only PCRs 7+14 everything works, but when I add 11 I need to provide the rescue password every single time I boot. I have extracted the values of those PCRs using tpm2_pcrread in two consecutive boots, and they are equal, so at least the issue is reproducible. To enroll the PCRs, after a new kernel (and, therefore, the UKI) has been generated, I run the following command: systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto --tpm2-pcrs=7+11+14 After reading the documentation on systemd-measure (that I am not using at the moment): could it be that there are events added to PCR 11 after the unlocking has happened, so that I am enrolling the wrong PCR value? Otherwise... what am I doing wrong? We mesaure the "boot phase" into PCR 11 too. See systemd-pcrphase.service(8) for details. Generally the assumption is that PCR 11 is used for signed PCR policies, i.e. under vendor control. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Enrolling PCR11 does not work as expected
On Mi, 05.07.23 08:30, Felix Rubio (fe...@kngnt.org) wrote: > Hi everybody, > > In my setup (sd-boot+UKI+LUKS) I am using PCRs 7+11+14 to unlock the LUKS > drive. Should I use only PCRs 7+14 everything works, but when I add 11 I > need to provide the rescue password every single time I boot. > > I have extracted the values of those PCRs using tpm2_pcrread in two > consecutive boots, and they are equal, so at least the issue is > reproducible. > > To enroll the PCRs, after a new kernel (and, therefore, the UKI) has been > generated, I run the following command: > > systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto --tpm2-pcrs=7+11+14 > > > After reading the documentation on systemd-measure (that I am not using at > the moment): could it be that there are events added to PCR 11 after the > unlocking has happened, so that I am enrolling the wrong PCR value? > Otherwise... what am I doing wrong? We mesaure the "boot phase" into PCR 11 too. See systemd-pcrphase.service(8) for details. Generally the assumption is that PCR 11 is used for signed PCR policies, i.e. under vendor control. Lennart -- Lennart Poettering, Berlin
[systemd-devel] Enrolling PCR11 does not work as expected
Hi everybody, In my setup (sd-boot+UKI+LUKS) I am using PCRs 7+11+14 to unlock the LUKS drive. Should I use only PCRs 7+14 everything works, but when I add 11 I need to provide the rescue password every single time I boot. I have extracted the values of those PCRs using tpm2_pcrread in two consecutive boots, and they are equal, so at least the issue is reproducible. To enroll the PCRs, after a new kernel (and, therefore, the UKI) has been generated, I run the following command: systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto --tpm2-pcrs=7+11+14 After reading the documentation on systemd-measure (that I am not using at the moment): could it be that there are events added to PCR 11 after the unlocking has happened, so that I am enrolling the wrong PCR value? Otherwise... what am I doing wrong? Felix
