lowRISC / opentitan

OpenTitan: Open source silicon root of trust
https://www.opentitan.org
Apache License 2.0
2.57k stars 764 forks source link

[top_darjeeling] Wrong OTP allocation for keys and signatures #21223

Open loiclefort opened 8 months ago

loiclefort commented 8 months ago

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 commented 8 months ago

@neeraj-rv @andreaskurth

sameo commented 8 months ago

cc @rsahita

rsahita commented 8 months ago

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 commented 8 months ago

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

rsahita commented 8 months ago

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

loiclefort commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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