Hi Teddy, On 2 May 2016 at 02:57, Teddy Reed <[email protected]> wrote: > 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.
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 _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
