On Sun, May 1, 2016 at 11:56 AM, Simon Glass <[email protected]> wrote: > Hi Teddy, > > On 27 April 2016 at 11:32, Teddy Reed <[email protected]> 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 _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
