BMC Image Signing Proposal

[Vernon Mauery]

On 29-Jan-2018 08:50 AM, Simon Glass wrote:
>Hi,
>
>On 28 January 2018 at 23:30, Andrew Jeffery <andrew at 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.

We would prefer that no environment is used for any action of 
consequence. It is completely untrusted, and only used for things like 
hints of preferences. For example, we would store the last preferred 
image (A or B), but ultimately, the one chosen would have to be 
authenticated before booting anyway; it is just the preferred image 
would be checked first and only fall back to the other one if 
verification failed.

Along the same lines, if the user stopped the BMC from automatically 
booting, we are now in a situation where the Linux runtime's root of 
trust could be compromised (specifically by forcing a boot of something 
that does not verify or by passing custom kernel command line 
arguments). I would prefer if there was a way that if stopped in u-boot, 
you would have to reset the BMC to actually boot to the kernel.

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

Historically, we have just booted with an initramfs (squashfs) that is 
the root filesystem. This means that it is possible to update in place 
without worrying about corrupting the current runtime. Normally our 
updates are A->B->A, but we do have one mode that is always in place.

Our current plan was to have our FIT include U-Boot, Linux, rootfs (as 
squashfs), and DTB, with a signature on U-Boot individually, and then 
another signature on all the parts. We would use an SPL to verify the 
signature of U-Boot and then boot it, and then U-Boot would verify the 
signature of the full FIT before booting Linux.

--Vernon

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