verified boot: semantics of multiple required keys

[Simon Glass]

Hi Rasmus,

On Thu, 16 Jan 2020 at 03:52, Rasmus Villemoes
<rasmus.villemoes at prevas.dk> wrote:
>
> 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;

You should use the UCLASS_BOARD for that (board.h), perhaps adding a
new method. Same below.

>
> 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.

This sounds OK to me. Please update the vboot test to cover the new
behaviour if you send a patch.

Regards,
Simon