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

[Teddy Reed]

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.

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