flatcar
Rework handling of the Secure Boot keys and certificates
Rework handling of the Secure Boot keys and certificates
We now need the official shim vendor certificate present in the SDK when building the kernel so that it can be inserted and used to verify the verity root hash and signed sysexts.
While we're at it, copy the official signing certificate from Azure Key Vault so that we don't need to fetch it every time, simplifying the signing code.
This change also partly deals with the eventual expiration of our shim vendor certificate. We cannot simply replace the shim with one containing just the new certificate because it needs to be able to boot kernels from older releases. We therefore now keep all the certificates in the coreos-sb-keys package as separate dated PEM files that then get combined into a single DER ESL that the shim build expects. Note that the shim does not check certificate expiry dates. It is therefore also no longer necessary to manually convert the certificate to DER format. The problem of actually upgrading the shim on user systems remains.
Each certificate in the DER ESL requires an owner GUID. We previous used a zero GUID for the DB certificates, but these were only used for testing. I have therefore now generated a static GUID for Flatcar that we should use going forwards.
@sayanchowdhury, you will no longer need to set SHIM_SIGNING_CERTIFICATE in your shim Dockerfile¸ but you will need to ensure the SDK you build from already has the certificate in coreos-sb-keys.
How to use
Nothing to use here, if it builds and the tests pass, we should be good.
Testing done
I did a Jenkins run, including forcing an official build. It passed, except for qemu_update, but that was due to how I forced it to be official, not due to the change.
- [ ] Changelog entries added in the respective
changelog/directory (user-facing change, bug fix, security fix, update) -- N/A - [X] Inspected CI output for image differences:
/bootand/usrsize, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.
We now need the official shim vendor certificate present in the SDK when building the kernel so that it can be inserted and used to verify the verity root hash and signed sysexts.
I like some of the cleanups here, but not everything is settled yet when it comes to changes to the chain-of-trust. Did you see my comments to the doc? The verity root hash does not need to be signed by a key in the kernel keyring if it is validated by grub, and signed sysexts would prevent users from loading their own sysexts (correct me if i'm wrong here), including those from the sysext-bakery.
Even if we would want to sign either of the two, I'm not sure we would want it to be the same key as the one used by shim. Cryptographers prefer to not reuse keys in different contexts like this (eg. if you need to revoke one key, you invalidate unrelated artifacts).
While we're at it, copy the official signing certificate from Azure Key Vault so that we don't need to fetch it every time, simplifying the signing code.
This seems to have a downside - we have to sync another location when the key changes. Why not fetch it at runtime?
This change also partly deals with the eventual expiration of our shim vendor certificate.
Just making sure we're on the same page: the shim vendor certificate is our Flatcar SB CA certificate, which is meant to have a lifetime of ~30 years (compare with Debian https://wiki.debian.org/SecureBoot#Finding_Debian.27s_Secure_Boot_keys). That's not the one we should be worried about expiring.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Did you see my comments to the doc?
Actually no, it hadn't emailed any notification.
Just making sure we're on the same page: the shim vendor certificate is our Flatcar SB CA certificate, which is meant to have a lifetime of ~30 years (compare with Debian https://wiki.debian.org/SecureBoot#Finding_Debian.27s_Secure_Boot_keys). That's not the one we should be worried about expiring.
Our current one has an expiry in 2037, as set by @sayanchowdhury. Still, I thought it best to have something in place in case we need to rotate it sooner.
I'll get back to you on the other points.
Did you see my comments to the doc?
Actually no, it hadn't emailed any notification.
I miss things all the time for the opposite reason - too many notifications... I just saw one for a comment you posted on a commit a month back...
... I'll get back to you on the other points.
No rush, lets get this right :)