BMC image generation without private key

Patrick Williams patrick at stwcx.xyz
Wed Jan 18 23:10:29 AEDT 2023


On Mon, Jan 16, 2023 at 05:53:40PM +0800, Lei Yu wrote:
> The OpenBMC build requires a private key to:
> 1. Generate the public key that is put in the image;
> 2. Sign the image and generate the whole tarball.
> 
> For dev builds, it uses the insecure development key in the tree.
> For release builds, it requires the `SIGNING_KEY` env to point to a
> secure key to sign the image.
> 
> It is considered insecure because it requires the build server to
> access the private key.
> 
> An alternative is proposed:
> * A new `SIGNING_PUBLIC_KEY` env is defined to point to a public key.
> * The above key is default to empty, and the behavior is the same as
> before, using the insecure development key to generate and sign the
> image.
> * With a valid `SIGNING_PUBLIC_KEY`:
>    * The public key is installed into the BMC image.
>    * The generated tarball is not signed, only containing the MANIFEST
> and the image.
>    * A new `gen-bmc-tar` tool will be introduced to sign the above
> tarball, like `gen-bios-tar`.
> * If both `SIGNING_PUBLIC_KEY` and `SIGNING_KEY` is set, throw an error.
> 
> With the above proposal, the build does not require the private key
> anymore and the user could install the public key during build, and
> sign the image separately.
> 
> Comments are welcome.

I don't have much opinion on this if you think it is the right direction
for your purposes.

My companies' existing signing system does not rely on the signatures
done during the build.  The output of our build is a single MTD image,
with a FIT image.  When we want to sign the image, we [external to the
build] extract the FIT signature device tree, re-sign it, and update the
MTD with the new signature set.

I've recently added some of the code upstream that eliminates the
separate rootfs and puts everything into a single initramfs.  This is
still in-progress but I plan to have it mostly complete by the end of
the month.

1. https://gerrit.openbmc.org/q/topic:no-rootfs
2. https://gerrit.openbmc.org/c/openbmc/openbmc/+/60110

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20230118/7af8fe55/attachment.sig>


More information about the openbmc mailing list