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

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

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

[Milton Miller II]

On April 23, 2020 about 14:11 in some timezone, Bruce Mitchell wrote:

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

The upgrade files are a tarball, and the MANIFEST include the image 
type and key.

https://github.com/openbmc/docs/blob/master/code-update/code-update.md#steps-to-update

Also, fit images (containg the kernel, device-tree, and any initrd) 
can be signed; see 

https://github.com/openbmc/u-boot/blob/v2016.07-aspeed-openbmc/doc/uImage.FIT/signature.txt


The code management app locates the key, see the answer to the 
next question.


There is also an effort to design some kind of image security 
for the upcoming eMMC support.  The current strawman is to 
use dm-verity with the signature stored in boot-config signed 
into the FIT with the initrd.

https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/28443




>Also how does OpenBMC verify that upgrade images are properly signed?

The bmc code management application, which provides the D-bus 
endpoint, impments verifing the image.  

https://github.com/openbmc/phosphor-bmc-code-mgmt/blob/master/image_verify.cpp

There is similar code for the host images depending on the platform. 
For example OpenPower systems use openpower-pnor-code-mgmt.

https://github.com/openbmc/openpower-pnor-code-mgmt/blob/master/image_verify.cpp


>Is there a document describing how all of this works that I have yet>to find?

https://github.com/openbmc/docs/blob/master/code-update/code-update-diagrams.md




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

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

The MANIFEST includes the key signing type.

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


milton