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
