[top_darjeeling] Wrong OTP allocation for keys and signatures

[loiclefort]

desc

Current allocation for all keys in Darjeeling OTP look like this:

Key Type: ECC NIST-P384 Curve. 160B = Custom Cert --> {PubKey:48, Signature:48, Device ID:32, metadata:16}

For ECDSA P-384, Public Key and Signature are both 96 bytes, not 48 bytes (as described here: [RFC] Secure Boot Signature Options)

[loiclefort]

@neeraj-rv @andreaskurth

[sameo]

cc @rsahita

[rsahita]

could we use compressed form of the ECC public keys (49 bytes) - but we would still need 193 bytes including all other fields (sig, id, metadata)

[loiclefort]

We could use the compressed form but computing the public key coordinates from the compressed key may impact boot time.

[rsahita]

true - I presume that would be done using OTBN - couple questions - is that IP available early enough, and what would be the latency?

[loiclefort]

AFAIK the plan is to use software ECDSA in the ROM for risk mitigation in case there are any issues with OTBN.

There are some indications about the runtime cost when using OTBN and arguments about the different algorithms/key sizes in [RFC] Secure Boot Signature Options.

[neeraj-rv]

I think one potential option is to combine all the relevant keys wrapped in a single signature Assuming ECDSA-p256 for now (arguably same security level as current RSA)

ROT_CREATOR_AUTH_NON_RAW_MFW_CODESIGN_KEY : 64 B ROT_CREATOR_AUTH_ROM2_PATCH_SIGVERIFY_KEY : 64 B ROT_CREATOR_AUTH_KEYMANIFEST_KEY : 64 B ROT_CREATOR_AUTH_UNLOCK4XFER_KEY : 64 B DEV ID : 32 B METADATA : 16 B SIGNATURE : 64 B

TOTAL: : 368 B

This will enable it to stay within the currently allocated partition and do not need to use compressed keys

[rsahita]

If we switch to p256 thats a good option. this will also free up some space for a cmac for the crwator auth identity cert provisioned