Create certificates for signing boot images for UEFI Secure Boot #9747
Comments
HW42
added
the
P: default
andrewdavidwong
added
security
Can you change RSA to something else like ECC or so? |
No. It seems even shim doesn't support EC crypto yet (see rhboot/shim#697, note that while that PR is primarily about some Chinese crypto standards it also shows that the more common EC crypto stuff is not included). I would guess that UEFI firmware support is not any better. So for compatibility we will have to stick to SHA256 and RSA for now. |
Side note: There are many certs in the field (including the "Microsoft UEFI CA 2023") that have dates past UNIX time reaching 2**31, so we don't have to worry about avoiding it. But by 2037, we hopefully have already rotate it, so no need to extend it. Re naming the CA:
EC crypto would be nice for new stuff, but as explained above currently not feasible. We could consider using a bigger key. For usage via a MS signed shim it's pointless since their CA is 2048 bit. But for users that import our key directly it would match what we use elsewhere. This raises the risk of running into incompatibilities somewhat. Most keys I have seen are 2048 bit. But for example Rocky Linux uses an intermediate cert with 3072 bit, so I guess support isn't to bad. (MS's UEFI CA 2023 is itself signed by an CA that has a 4096 bit key, but since the "UEFI CA" cert is already the trust anchor that part of the chain doesn't need to be verified by firmware, so doesn't say much about support.) This is intended to point the issuing CA, usually as a HTTP-URL pointing to a DER encoded version of it. But for a self-signed root that doesn't make much sense so I would drop it completely. (This also matches the CA/B recommendations) I think "Digital Signature" is not really needed for the root CA (but also doesn't hurt). We should stick to one method for generating serial numbers. Big randomly generated number as with the root is probably the best idea. While time validity is not verified by firmwares I don't think we should rely on it. Since this is a core part of X509 certs, I think sooner or later we will run into problems somewhere if we have signatures with invalid times. So I think this should cover the expected support duration of a release. (We can rotate more often, but the older certs shouldn't expire.) Given that strict one cert per year is not what we want (see above and below) I don't like naming it by a year. We could use a full date (like Fedora does for it's CA), to make it obvious that this is no reference to it's validity period. I probably would simply use a counter. Looking at common practice of other distros the trend is to have multiple intermediates that are limited in what they are used for, often one per component (grub/linux/...) and architecture. From what I understand this is to aid revocation, since it's better to revoke an intermediate cert than many hashes of singed files. I'm not sure how important this is going to be since SBAT should cover most of those cases. But probably still a good idea. For us I think this would primarily mean an intermediate per component (grub, UKI, ...). And rotating them from time to time. |
I think I've seen specific recommendation to use 2048 and not more for compatibility reasons. For example rhboot/shim-review#411 (comment)
If we'd need KEK CA at some point, I guess we can name it with "KEK CA", and keep the normal one with just "CA". It may look ambiguous without extra context, but IMO it's just a matter of a single doc page (or README in qubes-secpack?) that list the certs and their purpose.
Ok.
Both are big random, just different "big" ;) I used different tools to generate them - one is done using efikeygen and the other with certutil. I guess I can do both with efikeygen if I figure out correct options...
Well, we don't know expected support duration up front - we have it defined based on release date of the next release. In practice it's usually something about 2 years, but it isn't fixed. Since shim embeds the CA, and this key is used for signing various boot files (grub, xen-unified.efi, maybe something else), I imagine we will publish updates of those anyway, even if only to have it signed with a new key. One problematic case could be somebody installing system past the cert validity time, but we do publish point releases so that should be covered too (we just need to be careful to align point releases and key rotation correctly).
A counter is fine with me too. FWIW I've seen using year in the name to just signify when the key was created, not necessarily when it is valid - for example the current RPM Fusion key is "RPM Fusion free repository for Fedora (2020)".
IIUC the current recommendation is to do cert revocation only if that cert got compromised. All the other cases should be covered by SBAT, which already allows precise revocation of individual components. Space in dbx is limited, and having more certs that potentially could be revoked may actually be a disadvantage. |
The problem you're addressing (if any)
For for UEFI Secure Boot we need to create certificates (root and intermediates) to sign boot images. See #8026. Creating a sub-issue since the discussion in the parent issue is already rather crowded.
For now this is only about the certificates for signing boot code that will be included into shim and/or UEFI firmware. At some point we might also want to maintain a KEK CA, but for now I don't see the need.
The solution you'd like
@marmarek already prepared candidates:
Here are certificate candidates, please check if all is okay:
@aronowski @HW42
The value to a user and who that user might be
No response
Completion criteria checklist
The text was updated successfully, but these errors were encountered: