Re: BMC Image Signing Proposal

[Simon Glass <sjg@chromium.org>]

Hi,

On 28 January 2018 at 23:30, Andrew Jeffery <andrew@aj.id.au> wrote:
> 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.

If you use an initrd in the FIT, it can be checked in the same way as
the kernel. FIT supports a full signature check.

If you use a separate rootfs, verity can be used if it is read-only.
Otherwise I am not sure.

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

Regards,
Simon