[U-Boot] [verified-boot] Multiple levels of signing keys

[Simon Glass]

Hi Teddy,

On 2 May 2016 at 02:57, Teddy Reed <teddy.reed at gmail.com> wrote:
> On Sun, May 1, 2016 at 11:56 AM, Simon Glass <sjg at chromium.org> wrote:
>> Hi Teddy,
>>
>> On 27 April 2016 at 11:32, Teddy Reed <teddy.reed at gmail.com> wrote:
>>> Hello all,
>>>
>>> I'm looking to support "multiple levels" of keys within u-boot's
>>> verified boot. I need something similar to UEFI's key enrollment key
>>> (KEK) and db/dbx model such that I can support on-line signing of new
>>> kernels/rootfs/configurations.
>>>
>>> To make this work we need a KEK that is not online (kept in a safe),
>>> that can be used to sign expirations (revocations) of on-line signing
>>> keys in the case of compromise or private key reveals. I know Chrome's
>>> Coreboot verified boot model supports this, wondering if there's any
>>> staged / WIP for u-boot?
>>>
>>> Off the top of my head I'd imagine this requires extending the FIT to
>>> include sets of public keys and a blacklist of keys and expired or bad
>>> kernel/rootfs/etc hashes. Then either extending the boot code to
>>> inspect multiple FITs or extending mkimage to combine multiple sources
>>> to amalgamate a FIT containing the PK-signed set of keys + hashes and
>>> the on-line key-signed kernels/rootfs/configurations.
>>>
>>> P.S. This may be strongly linked to the need for a TPM to prevent
>>> rollbacks. But as far as I can tell, the two features are distinct and
>>> a TPM is not completely required for a multi-level key approach to
>>> signing FITs.
>>
>> I don't know of anything in this area. Of course it is fairly easy to
>> add new information to the FIT format, and mkimage is in somewhat
>> better shape for modifying these days. If you do this, please do
>> update fit_checksign.c to check an image.
>>
>
> Ok sounds great! I'll work on a patch, something mimicking the
> configuration hashing/signing for the existing top-level node name
> "signature" (signature of a set of key-* subnodes). The most
> challenging API changes will be the verification methods. Right now
> they are very elegant in that they assume a single bundled FDT
> containing keying material. For extensions to work, that will need to
> become stateful and include a discovery phase.

Can you please explain that a bit? I'm not sure what you are referring to.

>
> This feature really only makes sense for an SPL, and the board I'm
> supporting does not relocate the SPL (only a simple malloc and 8kB of
> stack space), so it should be a good test case.
>
> The first round of implementation code might leave mkimage out of the
> mix, and assume building the key extending DTB manually. But thanks
> for pointing out fit_checksign as the appropriate test target-- will
> do! Stay tuned.
>
>
> Take care!
> --
> Teddy Reed V

Regards,
Simon