BMC Image Signing Proposal

Andrew Jeffery andrew at aj.id.au
Mon Jan 29 17:30:25 AEDT 2018


Hi Alexander,

On Fri, 2018-01-26 at 14:07 +0300, Alexander Amelkin wrote:
> Hi, Anoo!
> 
> The thoughts are as follows:
> 
> 1. BMC usually runs in a secured environment where probability of 
> tampering with flash IC contents by means other than BMC's firmware 
> itself is negligible.

This does bring up the issue of developing a threat model to develop
against; we should probably do that. However, without one, I feel like
we should design *for* defense in depth and allow people to remove
protections as they see fit for their environment, rather than make
potentially compromising assumptions about what that environment is at
the outset.

For instance, whilst BMCs might typically be isolated from customer
traffic on a separate LAN, there's still the in-band interface which
can be used to poke at the BMC. Vulnerabilities in the IPMI stack could
lead to BMC compromise and undesirable flash writes*. Therefore BMC
flash integrity remains a valid concern despite network isolation.

* This ties into Michael Brown's talks of isolating daemons to their
own user/group and enforcing SELinux policy against them.

> 
> 2. U-Boot already performs image checksum validation before booting a 
> FIT image

Typically the rootfs is not part of the FIT, so it will not be checked.
    Some systems supported by OpenBMC directly mount the rootfs rather
than booting through an initrd, which makes rootfs authentication
somewhat tricky. Regardless, with signed images we should expand the
FIT hash check to be a full signature check.

> 
> 3. User input really needs validation, at least to make the system 
> fool-proof
> 
> Having said that, I suggest that the only thing that really needs doing 
> is signing (and checking) of the overall firmware image file that is 
> supplied by the user (admin) during the firmware upgrade procedure. 
> Applying asymmetric cryptography to a digest hash looks to me like a 
> good idea as it indeed allows for verifying the supplier of the firmware 
> image.

Agreed - do Yadro do this already? If so, what did you do to integrate
image signing into the build process? If not, then I'd be keen to keep
the discussion alive on how we can achieve it.

Cheers,

Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20180129/481e4448/attachment.sig>


More information about the openbmc mailing list