Develop binary compilation without requiring a private key

[BeataZdunczyk]

Brief summary

This milestone involves creating a comprehensive procedure for users, outlining the process of signing binaries without the use of a private key, ensuring a consistent and efficient signing process.

Additional context
The procedure must include both steps required for version N (i.e. public key incorporated in the firmware image) and for version N+1 (private key used for signing the capsule). A relation between those two keys should be described, together with instructions for transitioning between two different sets of keys.

[SergiiDmytruk]

@krystian-hebel

outlining the process of signing binaries without the use of a private key

Signing isn't possible without a private key. https://docs.dasharo.com/projects/capsule-updates/ says:

The milestone includes creating a user-friendly procedure for binary signing without embedding private keys into build system, ensuring consistency and efficiency.

So, I understand this as a description of and script for resign (from test keys) the binaries with release keys. Should it be an archive/repo bundling relevant parts of BaseTools with the script to unpack/repack a capsule?

A relation between those two keys should be described, together with instructions for transitioning between two different sets of keys.

So, not 2 keys but 2 sets of keys? Old (potentially compromised/vulnerable key pair) and a new one?

[krystian-hebel]

outlining the process of signing binaries without the use of a private key

Signing isn't possible without a private key.

I agree, something must've been modified when moving this sentence because it used to be about compilation, not signing, in project description.

So, I understand this as a description of and script for resign (from test keys) the binaries with release keys. Should it be an archive/repo bundling relevant parts of BaseTools with the script to unpack/repack a capsule?

Correct. At some point we will substitute test keys to our release keys (their public parts), but that shouldn't change too much in the whole process.

I was thinking about a script that would craft JSON capsule description based on input arguments, and pack/repack capsule accordingly. We will be using it with coreboot+edk2, so in my opinion there is no reason to put it in edk2 repo, by adding it to coreboot we can make assumptions about location of ROM file for example. Something like ./build.sh z790p_ddr4 && ./create_capsule.sh [path-to-keys], or maybe incorporate it into build.sh itself.

So, not 2 keys but 2 sets of keys?

Ideally both. What I wanted to show is that you can't do the transition without access to old private key, even though the final flash content won't have it (neither private nor public part).

Old (potentially compromised/vulnerable key pair) and a new one?

This is one example (except you have to trust the old one, so it has to be done before it is compromised). Another example is transfer of ownership - if someone already uses own keys (either by previous transition or flashing through different means than capsules) and wants to give the platform away, new firmware image must be signed with old private key. Finally, we may decide to merge or split platform groups that are signed with the same set of keys, which would also require a similar transition.

[SergiiDmytruk]

Docs PR: Dasharo/docs#881
coreboot PR (script): Dasharo/coreboot#549