<div dir="auto">(whoops accidentally send this only to Felix. Resending to the mailing list too)<div dir="auto"><br></div><div dir="auto"><div style="font-size:12.8px" dir="auto">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.</div><div dir="auto" style="font-size:12.8px"><br></div><div dir="auto" style="font-size:12.8px">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.</div><div dir="auto" style="font-size:12.8px"><br></div><div dir="auto" style="font-size:12.8px">Use PCR7 to check secure boot state.</div><div dir="auto" style="font-size:12.8px"><br></div><div dir="auto" style="font-size:12.8px">Use PCR14 to change the deception key when someone changes MOK (otherwise someone can boot whatever they want using MOK and decrypt your drive).</div><div dir="auto" style="font-size:12.8px"><br></div><div dir="auto" style="font-size:12.8px">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.</div><div style="color:rgb(80,0,80);font-size:12.8px" dir="auto"><div dir="auto"><br></div><div dir="auto">> if it is possible to override kernel command line, you can trivially boot into</div><div dir="auto">> /bin/sh unless you also bind LUKS key to the PCR 12 (or whatever is</div><div dir="auto">> used to measure kernel parameters)</div><div dir="auto"><br></div></div><div dir="auto" style="font-size:12.8px">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.</div><div dir="auto" style="font-size:12.8px"><br></div><div dir="auto" style="font-size:12.8px">Best,</div><div dir="auto" style="font-size:12.8px">Adrian </div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 19, 2023, 10:12 Felix Rubio <<a href="mailto:felix@kngnt.org">felix@kngnt.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Andrei,<br>
<br>
In that case, could happen that a malicious actor that has had in the <br>
past access to the systemd-boot, shim, and the UKI, comes back with <br>
those 3 on a USB stick and boots the machine? Then it would indeed make <br>
sense to bind the LUKS key to PCR 4, this making it 4+7+14, so that the <br>
use of outdated UKI is not possible.<br>
<br>
Thank you!<br>
<br>
Felix<br>
<br>
On 2023-06-19 14:04, Andrei Borzenkov wrote:<br>
> On 19.06.2023 10:19, Felix Rubio wrote:<br>
>> "Signed by whom?" - Signed by an actor trusted by Secure Boot, either <br>
>> at<br>
>> the platform level, or by any of the Shim contributors (I have not<br>
>> checked yet if it comes with a list of certificates, or only contains<br>
>> the one I enrolled)<br>
>> <br>
>> "What is \"your certificate\"?" - The one I generated and enrolled <br>
>> into<br>
>> MOK.<br>
>> <br>
> <br>
> In this case PCR 14 will not change. PCR 4 will include measurement of<br>
> the binary loaded by shim. So if you place the same version of<br>
> systemd-boot binary on USB it is up to the systemd-boot. The shim<br>
> readme states that PCR 4 will be extended with "the hash of any binary<br>
> for which Verify is called through the shim_lock protocol". So as long<br>
> as systemd-boot calls shim to verify UKI you need the same UKI binary<br>
> to unlock encrypted device. Which is not much different from simply<br>
> booting from hard disk.<br>
> <br>
> I am not familiar with details of UKI implementation, but if it is<br>
> possible to override kernel command line, you can trivially boot into<br>
> /bin/sh unless you also bind LUKS key to the PCR 12 (or whatever is<br>
> used to measure kernel parameters).<br>
> <br>
>> Regards!<br>
>> <br>
>> Felix<br>
>> <br>
>> On 2023-06-19 06:26, Andrei Borzenkov wrote:<br>
>>> On 18.06.2023 21:56, Felix Rubio wrote:<br>
>>>> Hi everybody,<br>
>>>> <br>
>>>> After some days offline, today I have gone through the emails<br>
>>>> exchanged<br>
>>>> a couple of weeks ago and agreed: UKI is the way to go. Last time I<br>
>>>> checked about it I read about possible problems related to when some<br>
>>>> modules would be loaded and so, but I see that my knowledge was<br>
>>>> outdated.<br>
>>>> <br>
>>>> This said, right now my setup looks like: SecureBoot is enabled, I <br>
>>>> am<br>
>>>> using Shim, Systemd-Boot as shim's second stage, and a UKI. As the<br>
>>>> disk<br>
>>>> is encrypted, for now I am making the decryption predicated to PCRs <br>
>>>> 7<br>
>>>> and 14, so that the decryption will only fail when either SB state<br>
>>>> changes, or when shim certificates/hashes change. So far so good.<br>
>>>> <br>
>>>> Out of curiosity now, I am wondering: what would happen in case<br>
>>>> somebody<br>
>>>> boots the system from, e.g., a USB drive that contains a signed <br>
>>>> image?<br>
>>> <br>
>>> Signed by whom?<br>
>>> <br>
>>>> Even if the shim is the same version, I assume it will fail to <br>
>>>> unlock<br>
>>>> because the MOK will not contain my certificate?<br>
>>> <br>
>>> <br>
>>> What is "your certificate"?<br>
>>> <br>
>>>> Should that certificate<br>
>>>> had been stolen and present, be enough to then unlock the disk?<br>
>>>> <br>
>>>> I am trying to assess if I should put in the mix PCR 4, so that I <br>
>>>> can<br>
>>>> keep track of the UKI image that gets loaded. Do you guys think this<br>
>>>> would be needed, or is overkill?<br>
>>>> <br>
>>>> Regards,<br>
>>>> <br>
>>>> Felix<br>
</blockquote></div>