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
