BMC image generation without private key

[Lei Yu]

On Wed, Jan 18, 2023 at 4:22 AM Michael Richardson <mcr at sandelman.ca> wrote:
>
>
> Lei Yu <yulei.sh at bytedance.com> wrote:
>     > 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.
>
> The build server requires authorization from the holder of the private key to
> create signatures.   One way is have direst access to the private key.
> I think that if the build server is so untrusted, then maybe there are other
> problems :-)
>
> I didn't find where SIGNING_KEY is used.
> I suspect that the signature is generated by an openssl command, and so
> actually it could be directed to an engine/HSM.

By `SIGNING_KEY` I was referring to below recipes:
https://github.com/openbmc/openbmc/blob/master/meta-phosphor/classes/image_types_phosphor.bbclass#L79
https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-phosphor/flash/phosphor-image-signing.bb#L9

>
> BUT, in some cases the process is to build something as a devel-ish build,
> and then if QA approves, it is signed with the release key afterwards, and so
> your process would make sense.

Be noted that in `phosphor-image-signing.bb`, it installs the public
key to `${D}${sysconfdir}/activationdata/${SIGNING_KEY_TYPE}"`.
This means the BMC image will use this public key to verify the image
to be updated.

If we use a dev-build and sign it with release key, we get a signed
image, that contains the dev public key, which is not expected.
The expected image should be signed with the release key, and contains
the release public key.

That's why my proposal is to define a new `SIGNING_PUBLIC_KEY` to get
the above build.

>
>     > 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.
>
> There is a chain of custody concern between building tarbar and running gen-bmc-tar.
> So, I'd always sign with the development key, and I'd validate that signature
> and then replace it.

The `gen-bmc-tar` will have a `-s` option to point to a release key,
that will be executed in a secure environment, so that we could get a
signed image with the release key.