From: Michael Richardson <mcr@sandelman.ca>
To: Lei Yu <yulei.sh@bytedance.com>
Cc: openbmc <openbmc@lists.ozlabs.org>
Subject: Re: BMC image generation without private key
Date: Tue, 17 Jan 2023 15:21:40 -0500 [thread overview]
Message-ID: <27195.1673986900@localhost> (raw)
In-Reply-To: <CAGm54UG=i8Ym-23N7R468xCsH3px5QAr52+zY+1MULBYVcf3Xg@mail.gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2023-01-17 20:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-16 9:53 BMC image generation without private key Lei Yu
2023-01-17 13:49 ` Brad Bishop
2023-01-17 20:21 ` Michael Richardson [this message]
2023-01-18 2:24 ` Lei Yu
2023-01-18 12:05 ` Patrick Williams
2023-01-18 12:10 ` Patrick Williams
2023-01-18 12:20 ` Lei Yu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=27195.1673986900@localhost \
--to=mcr@sandelman.ca \
--cc=openbmc@lists.ozlabs.org \
--cc=yulei.sh@bytedance.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.