Enki: Do not add Microsoft Production CA certs when creating keys

[Itxaka]

Currently there is 2 different DB files from Microsoft:

• Production CA 2011 (https://go.microsoft.com/fwlink/p/?linkid=321192)
• Microsoft Corporation UEFI CA 2011 (https://go.microsoft.com/fwlink/p/?linkid=321194)

The first one is the one used to boot windows, while the second one is the one used to sign other things like firmware or option roms.

In our case, enki is currently bundling both when creating keys but we should not need to bundle the Production CA as that opens the door to booting windows thus bypassing the security of having your own keys.

[Itxaka]

@mudler @jimmykarily @mauromorales this is kind of important

[jimmykarily]

Should we add one more option in enki to tell it to install just one of the 2? Or maybe split the 2 certs in 2 different flags? (e.g. --skip-microsoft-production-ca and --skip-microsoft-uefi-ca).

[mudler]

on a related note: Foxboron/sbctl#235 - can we just make an option in enki to expect CAs from the user? or we can re-use already what we have for the DB/cert export from the bios?

In that case instead of mutating enki we can just document how to bundle with the different certs

[Itxaka]

Should we add one more option in enki to tell it to install just one of the 2? Or maybe split the 2 certs in 2 different flags? (e.g. --skip-microsoft-production-ca and --skip-microsoft-uefi-ca).

I would just skip it. I mean, with our current implementation you can either:

• install your signed isos from kairos
• install windows

The idea is if you are using enki to generate the keys, you want to install only the minimun number of certs. Not sure what we gain by allowing a windows key in there which only serves to boot windows.

[jimmykarily]

I'm not sure. the genkey command is starting to look like a generic "mix and match" application for key management. Do we want that? If we don't, how is the user supposed to mix and match keys if they need to? (e.g. kairos + microsoft + vendor).

[mudler]

can we just offer an option to the user to specify a source for CAs? I don't think at this point brings any benefit to try to support them all, but rather be open for customization

[Itxaka]

We dont need to support all I think?

its just:

• 1 set of customer keys
• 1 subset of microsoft UEFI keys (to support option roms and generic firmware signed by it.)
• 1 subset of motherboard keys (to support firmware in the motherboard)

And the third one is optional. The 2 first are mandatory for sure. Im just alking about dropping the 1 subset that enables booting windows as that its a big thing, we should not support that out of the box otherwise you can boot with a premade usb with windows on it without issues.

[mudler]

We dont need to support all I think?

its just:

* 1 set of customer keys

* 1 subset of microsoft UEFI keys (to support option roms and generic firmware signed by it.)

* 1 subset of motherboard keys (to support firmware in the motherboard)

And the third one is optional. The 2 first are mandatory for sure. Im just alking about dropping the 1 subset that enables booting windows as that its a big thing, we should not support that out of the box otherwise you can boot with a premade usb with windows on it without issues.

right, but what about MS keys? these seems to be a moving target as well as 2011 are getting EOL soon.

Anyway for the windows one I agree with, but I would rather prefer we have options for the user to provide the necessary CAs on their own (including the MS ones)

[jimmykarily]

btw, this might also needs us to manipulate installed certs: #2429

@nianyush has been playing with a utility to export existing certs. Maybe that should become a more generic tool to export/install/rotate installed keys?

Otoh, there is already upstream tooling to achieve all these operations. Do we need to implement it again?

[Itxaka]

btw, this might also needs us to manipulate installed certs: #2429

@nianyush has been playing with a utility to export existing certs. Maybe that should become a more generic tool to export/install/rotate installed keys?

Otoh, there is already upstream tooling to achieve all these operations. Do we need to implement it again?

https://github.com/Itxaka/keydump

I guess the idea is to have a more simplified and concise way for our use case, rather than a huge executable that does a hundred things?

[mudler]

btw, this might also needs us to manipulate installed certs: #2429

@nianyush has been playing with a utility to export existing certs. Maybe that should become a more generic tool to export/install/rotate installed keys?

this would make sense, imho enki shouldn't really know about MS certificates, but CAs and certs in general as input into the build process when building the iso.

I'd treat that we use MS certs as a special case - or we stick with a "good default" or we don't at all, and we just document how to generate the keys given the various scenarios.

Otoh, there is already upstream tooling to achieve all these operations. Do we need to implement it again?

[mudler]

btw, this might also needs us to manipulate installed certs: #2429
@nianyush has been playing with a utility to export existing certs. Maybe that should become a more generic tool to export/install/rotate installed keys?
Otoh, there is already upstream tooling to achieve all these operations. Do we need to implement it again?

https://github.com/Itxaka/keydump

I guess the idea is to have a more simplified and concise way for our use case, rather than a huge executable that does a hundred things?

I agree with this 100% - we shouldn't really try to do hundred things in genkey. I'd even be more happy to deprecate it at this point in favor of documenting the steps to generate the keys.

It was meant to simplify generation of the whole chain - but now starts to look like a cumbersome wrapper forced to work in all scenarios, that could be replaced with bash scripts and/or proper documentation on what kinda of certificates are needed

[Foxboron]

this would make sense, imho enki shouldn't really know about MS certificates, but CAs and certs in general as input into the build process when building the iso.

You are reinventing sbctl at that point though :)
If you need features for key/cert management for secure boot feel free to make issues and we can probably work out something. and/or describe the usecase and we can figure out something.

[jimmykarily]

this would make sense, imho enki shouldn't really know about MS certificates, but CAs and certs in general as input into the build process when building the iso.

You are reinventing sbctl at that point though :) If you need features for key/cert management for secure boot feel free to make issues and we can probably work out something. and/or describe the usecase and we can figure out something.

Good point.

[ci-robbot]

I would like to thank you for reporting this issue, Itxaka. As mentioned previously, this ticket doesn't meet all the criteria specified by our project. We need a detailed description of the issue itself, separate from the background and suggested solutions. Please provide a clear explanation of the problem you're encountering with Enki, and ensure that there are steps to reproduce the problem if it's a bug. Additionally, users should mention the versions of the relevant artifacts being used. Once these requirements are met, the ticket can be reassessed and labeled accordingly. Remember, I am just a bot, an experiment of @mudler and @jimmykarily. Have a great day!