Hi
I'm wondering a bit about the semantics of having multiple keys with the 'required = "conf"' property. Currently, the fit image (or rather the chosen configuration) must be signed by all such keys. I assume this is for the case where multiple parties (vendor, subvendor, customer?) all have to sign a given image (however they then manage to ensure that they know what they're signing).
However, our use case is a little different. The board we want to do verified boot on doesn't have any hardware support for anchoring the root of trust (no TPM or similar), so we will be relying on creating an SPL that will live in read-only storage after production. We'd like to create 4 key pairs upfront, initially using key-0 for all signing, and keeping the private parts of key-{1,2,3} stored safely offline somewhere. The SPL will be equipped with the public part of all four keys in its control dtb.
When key-0 inevitably leaks (or we suspect that it might have leaked), we will start using key-1. So we need the SPL to accept any image signed with at least one of those 'required = "conf"' keys. [Moreover, the board does have some OTP fuses, so we'd also like to implement logic to check those fuses before actually using key-$n - and if the SPL sees and verifies an image signed with key-N, it should burn the fuses corresponding to keys 0..N-1].
Implementation-wise, I'm thinking of something like
signature { required-mode = "one"; // or "all", the default if not present key-0 { required = "conf"; key-index = <0>; .... }
And then inside the loop, there would be something like
if (board_key_revoked(key_index)) continue;
and before returning, another board hook would be called
board_keys_used_for_verification(int *index, int count)
Does this make any sense? I'm not at all sure about the semantics of say 'require-mode = "all"' combined with all keys having been revoked - but I don't think a board that uses 'required-mode = "all"' would implement board_key_revoked() anyway.
Rasmus