BMC Image Signing Proposal

[Vernon Mauery]

On 23-Feb-2018 12:44 PM, Stewart Smith wrote:
>Yugi Mani <yupalani at microsoft.com> writes:
>> We should consider both of these requirements for image signing:
>> 1. Update verification
>> 2. Boot Verification
>>
>> Appending signature to image meets verification during firmware update. To do verification on every boot, we need something like FIT.
>> https://chromium.googlesource.com/chromiumos/third_party/u-boot-next/+/chromeos-v2013.06/doc/uImage.FIT
>>
>> As far as actual signing is concerned, we don't have access to private key for security reasons. We should support two models:
>> Model 1:
>> Source code has private key and signing is part of build process ("bitbake obmc-phosphor-image")
>>
>> Model 2:
>> Source code does not have private key, Signing is done externally and
>> some post-processing is done to add hash to image.  (maybe a new task,
>> "bitbake obmc-phosphor-image -c add_hash")
>
>For reference, for OpenPOWER host firmware, we support three models:
>
>Local mode (a.k.a. development mode) — Build the container and sign
>using locally available private keys. Signatures are generated using
>simple openssl operations. Because the private keys are exposed on the
>local system (the build machine), this mode should be used only for
>development signing, or when the user is confident that the build
>machine is secure against unauthorized access.
>
>Independent mode — Generate the signing requests locally and export the
>requests for signing externally. External signing is by user's method of
>choice: any method capable of generating a ECDSA p521 signature (the
>built-in support uses openssl). Resulting signatures are re-imported to
>the container build process, to create the completed container. No
>private or privileged information is exposed at the build machine.
>
>Production mode — Build the container locally and interface with the
>remote signframework to retrieve signatures and (public) keys as
>needed. Signing is done remotely on a secure signing server using a
>hardware security module (HSM). Private keys are stored securely in the
>HSM and never exposed. Completed signatures are returned by the
>signframework and integrated into the container.
>
>(gratuitously copy&pasted from Nick's great docs up at
>https://github.com/open-power/sb-signing-utils/wiki )

Historically, we have supported two signing modes, similar to one and 
three:

Local mode (a.k.a. development mode) - similar to what you describe 
where the keys are insecure and should not be used to generate 
production images.

Re-Sign mode (for Production images) - takes a binary image, parses and 
deconstructs it, verifies the signature, and puts it back together with 
a new signature and public key certificate. This makes it so we only 
ever sign 'blessed' images with the production key, where this blessing 
comes from the validation team. The production build server initially 
signs the release image with a non-production key and that image gets 
tested. Then it gets re-signed with the production key only if it passes 
validation.

--Vernon