RE: BMC Image Signing Proposal

[Stewart Smith <stewart@linux.vnet.ibm.com>]

Yugi Mani <yupalani@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 )

-- 
Stewart Smith
OPAL Architect, IBM.