Re: Fedora 38 and signed PCR binding

[Dan Streetman <ddstreet@xxxxxxxx>]

On Sat, Nov 11, 2023 at 5:10 PM Aleksandar Kostadinov
<akostadi@xxxxxxxxxx> wrote:
>
> On Thu, Oct 12, 2023 at 1:14 AM Dan Streetman <ddstreet@xxxxxxxx> wrote:
> > On Sun, Oct 8, 2023 at 8:09 AM Aleksandar Kostadinov <akostadi@xxxxxxxxxx> wrote:
> > ...
> > > Here's what I did:
> > > > sudo systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto --tpm2-public-key-pcrs=11 /dev/sda3
> >
> > This probably isn't what you want, because you're specifying
> > --tpm2-public-key-pcrs= but not --tpm2-public-key=, so the
> > --tpm2-public-key-pcrs= doesn't actually do anything (it should
> > probably either fail or at least print a warning).
>
> in man pages I see:
> --tpm2-public-key= option accepts a path to a PEM encoded RSA
>            public key, to bind the encryption to. If this is not specified
>            explicitly, but a file tpm2-pcr-public-key.pem exists in one of the
>            directories /etc/systemd/, /run/systemd/, /usr/lib/systemd/
>            (searched in this order), it is automatically used.
>
> I do have such a file.

ah ok, yeah that should be fine then.

>
> > Since you didn't specify --tpm2-pcrs=, it will default to use only
> > PCR7, using the current value (at the time you ran
> > systemd-cryptenroll).
>
> I specify --tpm2-public-key-pcrs=11, should I specify also
> --tpm2-pcrs? I don't want to bind to plain PCRs.

If you don't specify --tpm2-pcrs= at all, it will bind to PCR 7, even
if you bind to a signature as well (at least this is the current
behavior).

If you want to bind only to a signature, you should use --tpm2-pcrs=""
(i.e. empty string) to prevent binding to PCR 7.

This is probably not the most intuitive default behavior, which we
might want to change...

>
> > Just for testing, can you try:
> > sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs="" /dev/sda3
> >
> > That will enroll your tpm with *no* pcr values, so it should always
> > successfully unlock your volume using the tpm (note, you probably
> > don't want to do this other than for testing). Then see if it uses the
> > tpm to unlock the volume on boot. If so, you just need to get the
> > specific PCR parameters correct (and make sure to supply your PEM
> > public key to systemd-cryptenroll using --tpm2-public-key=), and
> > provide the correct signature.
>
> This is a nice check actually. And in fact it does not open the volume
> automatically. Which is super strange. As it worked with the normal
> grub based boot process.
>
> sudo systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto
> --tpm2-pcrs= /dev/sda3
> then removed `tpm2-measure-pcr=yes` from /etc/crypttab, then
> `dracut-f` and finally `ukify ..` with the exact same arguments as
> before.
>
> Did I miss something?

let's try manually unlocking it just to make sure the enrollment was
ok, so after enrolling it try:

systemd-cryptsetup test /dev/sda3 - tpm2-device=auto,headless=true

(you don't need headless=true, that only skips asking you for the luks
password if the tpm unlocking didn't work)

that should unlock the luks device and create the /dev/mapper/test
device. if that doesn't work, then there's some problem with the tpm
enrollment into your luks device. if it does work, then the problem is
with your boot setup. my guess would be you aren't building the initrd
with all the right bits needed to unlock it (you'll probably have to
manually add in some crypt modules to the dracut call)

>
> Strange is that in `journalctl -b` I still see "Couldn't find
> signature for this PCR bank, PCR index and public key." So I wonder
> what could be broken and how to fix it. How to inspect the initrd
> inside the UKI?

well you built the initrd before running ukify, so just take a look at
it before you build the uki

>
> <...>
>