You are not logged in.
The Arch wiki on Secure Boot setup using systemd has this
# ukify genkey \
--secureboot-private-key /etc/kernel/secure-boot-private-key.pem \
--secureboot-certificate /etc/kernel/secure-boot-certificate.pem
# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pemThe man page of ukify says the options --secureboot-private-key & --secureboot-certificate are "A path to a private key / certificate to use for signing of the resulting binary.", so this seems to be intended to be the Signature Database (db) key & cert.
But then they are passed to bootctl install, and it's man page is not clear on what they are used for: "When specifying this option, a certificate and private key have to be provided as well using the --certificate= and --private-key= options."; "Enabling this option will make bootctl populate the ESP with signed "PK", "KEK" and "db" signature databases, each containing the given certificate in "DER" format as their only entry.".
I have a suspicion that the key is used to sign the PK, which means it's not supposed to use the db key here, but I don't know how to verify this. The keys generated by systemd all has the same Common Name and I don't know how to see the header in the .auth files (to see which key signed which).
Last edited by Beemo (2025-02-20 17:26:18)
Offline
https://github.com/systemd/systemd/comm … e4f7e3721e
"For now, We sign all variables using the same certificate and key pair."
Ok... that explains the initial question.
But shouldn't the signatures go like PK(PK?), KEK(PK), db(KEK) otherwise they would be rejected by UEFI?
Offline
short crash course in x509: there's nothin in neither x509 nor uefi that prevents the re-use of keys
it's just discouraged to do so to build a working chain of trust:
- the CA self-signs its own certificate and is trusted explicit by adding the root certificate toca systems truststore
every certificate for which a valid trust chain can be established is trusted implicit
for that to work there's no hard requirement for different keys - the same key can be re-used
- full x509 v3 has several extensions which have to be checked - I don't know for sure but unless extensions like subject key information and authority key infofmation are used there isn't even a more in-depth check of the keys themself - all that's checked if the signature checks out with the signers public key
- uefi even simplyfies all that but using x509 simply as carriers for keys and signatures - so even if one would "pollute" them with sll those fancy extensions I guess most uefi implementations don't even check them - and rfc requires an implementation to ignore extensions it doesn'st unless they're marked critical - why only a few base extensions should be marked as critical in the first place
so, tldr: yes, in practice when using proper keys from platform vendor, microsoft and devices they all do have different keys and certificates resulting in a proper PKI - but it does work the same with all the same and doesn't matter as now it is you who is CA, trust authority and trustee all at tge same time - so who cares if you use different keys or the same?
Offline
Ooh I see... the same key I supplied is put in as PK, KEK, db. That makes more sense, I thought bootctl generates new ones like sbctl does.
Offline