Remove default private image signing key from openbmc [was: Security Working Group meeting - Wednesday April 15 - results]
Milton Miller II
miltonm at us.ibm.com
Fri Apr 24 08:05:59 AEST 2020
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
More information about the openbmc
mailing list