BMC image generation without private key

BMC image generation without private key

[Lei Yu]

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.

-- 
BRs,
Lei YU

Re: BMC image generation without private key

[Brad Bishop]

On Mon, 2023-01-16 at 17:53 +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.

It depends.  If you just put the path to they private key in there, then
yes.  But the tools that look at 'SIGNING_KEY' support signing helpers
(socsec) and pkcs11 (mkimage), which can be used to get the image signed
without access to the key.

There is an example of this here:

https://gerrit.openbmc.org/c/openbmc/openbmc/+/50797/5

As you can see it was never fully reviewed and it was not accepted, so
maybe there are problems with it.  But I think the concepts/design
sound.

Thanks,
Brad

Re: BMC image generation without private key

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 1961 bytes --]


Lei Yu <yulei.sh@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.

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.

    > 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.

    > 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.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: BMC image generation without private key

[Lei Yu]

On Wed, Jan 18, 2023 at 4:22 AM Michael Richardson <mcr@sandelman.ca> wrote:
>
>
> Lei Yu <yulei.sh@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.

Re: BMC image generation without private key

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1388 bytes --]

On Tue, Jan 17, 2023 at 03:21:40PM -0500, Michael Richardson wrote:

> 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 don't have any security guidelines or NIST papers[1] to quote here, but
my impression is that this is a great over-simplification.  Every design 
for signing firmware I've ever seen used in production separates the build
server from the signing server, so there must be good reason for it.

I suspect it stems from it being a lesser-evil if someone unauthorized signs
a one-off image than it is if the private key escapes.  Build servers run
a lot of code and thus have a lot of surface to attack.  A signing
server can have a single remote API ("here is an image and my identity
... give me a signature"), which keeps the signing key(s) safer.

Requiring the private key to be present on the build server likely also
precludes any use of HSMs[2].

1. https://csrc.nist.gov/CSRC/media/Publications/white-paper/2018/01/26/security-considerations-for-code-signing/final/documents/security-considerations-for-code-signing.pdf

2. https://www.opencompute.org/documents/ibm-white-paper-best-practices-for-firmware-code-signing
-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: BMC image generation without private key

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 2100 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: BMC image generation without private key

[Lei Yu]

On Wed, Jan 18, 2023 at 8:10 PM Patrick Williams <patrick@stwcx.xyz> wrote:
>
> 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.

The patches related to SIGNING_PUBLIC_KEY are sent to:
https://gerrit.openbmc.org/c/openbmc/openbmc/+/60336
https://gerrit.openbmc.org/c/openbmc/openbmc/+/60337

The singing mentioned above is related to the tarball and is verified
during BMC code update.
It does not involve the verification on BMC boot (which is a different topic).

>
> 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.

This is interesting, this means a new flash layout, is it?

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