[systemd-devel] sd-boot setup and PCRs

[Adrian Vovk]

(whoops accidentally send this only to Felix. Resending to the mailing list
too)

I wouldn't bind anything to PCR4, because it'll wipe out your decryption
key on any update of any component in the boot chain. In other words: PCR4
is not rollback prevention, it's also roll forward prevention as well.

Use PCR11 to bind to that exact variant of your UKI (each UKI has a pcrsig
section that should be different for each variant of the OS, which is used
to verify PCR11). This means that only a UKI for a given variant of a given
distro can decrypt your data.

Use PCR7 to check secure boot state.

Use PCR14 to change the deception key when someone changes MOK (otherwise
someone can boot whatever they want using MOK and decrypt your drive).

Use revocation (DBX, MOKX, SBAT) to revoke vulnerable versions of
kernels/etc. The ability to update these without breaking PCR7 is on the
TODO list. Rollback prevention via the TPM is on the TODO list also.

> if it is possible to override kernel command line, you can trivially boot
into
> /bin/sh unless you also bind LUKS key to the PCR 12 (or whatever is
> used to measure kernel parameters)

When secure boot is on, UKIs reject external command lines. The internal
command line is measured into PCR11. If secure boot is off you can't trust
any of the values in the PCRs anyway so no point bothering.

Best,
Adrian

On Mon, Jun 19, 2023, 10:12 Felix Rubio <felix at kngnt.org> wrote:

> Hi Andrei,
>
> In that case, could happen that a malicious actor that has had in the
> past access to the systemd-boot, shim, and the UKI, comes back with
> those 3 on a USB stick and boots the machine? Then it would indeed make
> sense to bind the LUKS key to PCR 4, this making it 4+7+14, so that the
> use of outdated UKI is not possible.
>
> Thank you!
>
> Felix
>
> On 2023-06-19 14:04, Andrei Borzenkov wrote:
> > On 19.06.2023 10:19, Felix Rubio wrote:
> >> "Signed by whom?" - Signed by an actor trusted by Secure Boot, either
> >> at
> >> the platform level, or by any of the Shim contributors (I have not
> >> checked yet if it comes with a list of certificates, or only contains
> >> the one I enrolled)
> >>
> >> "What is \"your certificate\"?" - The one I generated and enrolled
> >> into
> >> MOK.
> >>
> >
> > In this case PCR 14 will not change. PCR 4 will include measurement of
> > the binary loaded by shim. So if you place the same version of
> > systemd-boot binary on USB it is up to the systemd-boot. The shim
> > readme states that PCR 4 will be extended with "the hash of any binary
> > for which Verify is called through the shim_lock protocol". So as long
> > as systemd-boot calls shim to verify UKI you need the same UKI binary
> > to unlock encrypted device. Which is not much different from simply
> > booting from hard disk.
> >
> > I am not familiar with details of UKI implementation, but if it is
> > possible to override kernel command line, you can trivially boot into
> > /bin/sh unless you also bind LUKS key to the PCR 12 (or whatever is
> > used to measure kernel parameters).
> >
> >> Regards!
> >>
> >> Felix
> >>
> >> On 2023-06-19 06:26, Andrei Borzenkov wrote:
> >>> On 18.06.2023 21:56, Felix Rubio wrote:
> >>>> Hi everybody,
> >>>>
> >>>> After some days offline, today I have gone through the emails
> >>>> exchanged
> >>>> a couple of weeks ago and agreed: UKI is the way to go. Last time I
> >>>> checked about it I read about possible problems related to when some
> >>>> modules would be loaded and so, but I see that my knowledge was
> >>>> outdated.
> >>>>
> >>>> This said, right now my setup looks like: SecureBoot is enabled, I
> >>>> am
> >>>> using Shim, Systemd-Boot as shim's second stage, and a UKI. As the
> >>>> disk
> >>>> is encrypted, for now I am making the decryption predicated to PCRs
> >>>> 7
> >>>> and 14, so that the decryption will only fail when either SB state
> >>>> changes, or when shim certificates/hashes change. So far so good.
> >>>>
> >>>> Out of curiosity now, I am wondering: what would happen in case
> >>>> somebody
> >>>> boots the system from, e.g., a USB drive that contains a signed
> >>>> image?
> >>>
> >>> Signed by whom?
> >>>
> >>>> Even if the shim is the same version, I assume it will fail to
> >>>> unlock
> >>>> because the MOK will not contain my certificate?
> >>>
> >>>
> >>> What is "your certificate"?
> >>>
> >>>> Should that certificate
> >>>> had been stolen and present, be enough to then unlock the disk?
> >>>>
> >>>> I am trying to assess if I should put in the mix PCR 4, so that I
> >>>> can
> >>>> keep track of the UKI image that gets loaded. Do you guys think this
> >>>> would be needed, or is overkill?
> >>>>
> >>>> Regards,
> >>>>
> >>>> Felix
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20230619/a0e62de6/attachment-0001.htm>