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
