On Sun, May 1, 2016 at 11:56 AM, Simon Glass sjg@chromium.org wrote:
Hi Teddy,
On 27 April 2016 at 11:32, Teddy Reed teddy.reed@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!