Remove default private image signing key from openbmc [was: Security Working Group meeting - Wednesday April 15 - results]

[Bruce Mitchell]

How does OpenBMC keep the publickey, that is generated from the private image signing key (i.e. OpenBMC.priv),  in the SPI image and in the upgrade files?
Also how does OpenBMC verify that upgrade images are properly signed?
Is there a document describing how all of this works that I have yet to find?

> -----Original Message-----
> From: openbmc [mailto:openbmc-
> bounces+bruce_mitchell=phoenix.com at lists.ozlabs.org] On Behalf Of
> Joseph Reynolds
> Sent: Wednesday, April 15, 2020 11:49
> To: openbmc
> Subject: Re: Security Working Group meeting - Wednesday April 15 -
> results
> 
> On 4/14/20 4:57 PM, Joseph Reynolds wrote:
> > This is a reminder of the OpenBMC Security Working Group meeting
> > scheduled for this Wednesday April 15 at 10:00am PDT.
> 
> The meeting was held, and minutes are linked off the wiki page.
> A fourth agenda item was added.  A summary is below.
> 
> - Joseph
> 
> >
> > We'll discuss current development items, and anything else that comes
> up.
> >
> > The current topics:
> >
> > 1. Remove default private image signing key from openbmc
> 
> The leading idea is to disable the recipe that signs the image, but
> leave the private signing key in the source tree.  Then someone who
> builds will get an unsigned image.  If they enable the image signing
> recipe or use it as an example, they will hopefully see the instructions
> that say to use their own key pair.
> 
> Note that an unsigned image is a good starting point for build processes
> that use a separate image signing step, such as when the image is signed
> by a hardware security module (HSM).  One difficulty with this approach
> is that the public key needs to be put into the BMC's root file system.
> 
> Followup in the email list or
> https://github.com/openbmc/openbmc/issues/3615
> 
> >
> > 2. Discuss issues from the “ipmi password storage” email thread.
> 
> We pretty much re-hashed the ideas from the email thread with no
> conclusions.
> One more idea was added, that we can the BMC's TPM to hold the RMCP+
> keys.
> 
> >
> > 3. Which algorithm should sign OpenBMC images?
> 
> The answer will vary between projects that are downstream from
> OpenBMC.
> We'll keep the default as RSA-SHA256.  Going forward, the plan is: the
> OpenBMC release process will give visibility to this and other ciphers per:
> https://github.com/openbmc/openbmc/wiki/Security-working-
> group#security-end-of-release-checklist
> 
> 
> 4. Use the Yocto cvecheck vulnerability scan for OpenBMC repos No CVE
> checking is done at the project-level, but similar check are being done
> in projects that are downstream from OpenBMC. The idea is a nightly
> Jenkins job to generate a report of all the unfixed vulnerabilities,
> something like: bitbake -c cvecheck obmc-phosphor-image.
> >
> > Access, agenda, and notes are in the wiki:
> >
> > https://github.com/openbmc/openbmc/wiki/Security-working-group
> >
> > - Joseph