[ot_certs,opentitantool] enable generating DICE certificates for several profiles

[tommychiu-github]

The current on-device certificate generation mechanism during personalization (and during ROM_EXT execution) generates DICE certificate chain in the X.509 ASN.1 DER format, which is one of the supported standards of the Open Profile for DICE.

However, the Android RKP specification "generateCertificateRequestV2.cddl" requires all layers of the certificate chain from UDSpub to CDI* to be CBOR encoded.

To support such use cases, we would like to enable generating either X.509 (ASN.1 DER) or CWT (CBOR) formatted DICE certificates during personalization and in the ROM_EXT.

One proposal is to implement the CBOR version of DICE certificate chain alongside the X.509 DICE certificate chain, and store it in flash info page 18.	Flash info	Content
18	DICE certificate chain (CBOR)
19	DICE certificate chain (X.509)

[timothytrippel]

Thanks @tommychiu-github, support for CBOR encoded DICE certs is something we considered adding support for in the past. Given the way our tooling works, this should be fairly straightforward to add support for. Specifically, adding support would require the following (@pamaury, let me know if I am missing anything here):

• [ ] adding a CWT cert format parameter to the opentitantool certificate codegen subcommand
• [ ] implementing another version of, or pass a format parameter, to the generate_cert() function of the ot_certs Codegen struct
• [ ] develop a CBOR/CWT cert builder lib in ot_certs Rust lib, similar to the ASN.1/X.509 cert builder;
• [ ] write a lightweight CBOR encoding generator device library, similar to the ASN.1 DER encoding device library; this will be used by the cert builder above that will generate device code to generate the certs on-device
• [ ] modify the parse_certificate() function in the ot_certs Rust lib to be able to parse an X.509 or CBOR certificate (for test/verification purposes during personalization)

Regarding your proposal however, would a device need both an X.509 AND a CWT DICE cert chain in flash info? or would a device need either a X.509 OR CWT DICE chain in flash info?

[pamaury]

Your description is correct @timothytrippel . I admit I don't know the details of CBOR enough to estimate how much work this would require. If CBOR certificates are sufficiently close to X509 in structure then potentially a lot of code can be shared between the two generators and the biggest part of the work would be the certificate parser and the device encoding library.

[tommychiu-github]

My proposal is to have both X.509 AND CWT DICE chain on device concurrently. The reason is that different skus may need different format of the DICE chain. Since this implementation is in the common repository it might be good to have both of them at the same time. Does this assumption make sense?

[timothytrippel]

To document here: after some discussion, I believe we want to support several DICE certificate profiles, or different combinations of base certificates and custom extensions to support

• the TCG profile with the DiceTcbInfo extension
• the Open DICE profile with OpenDiceInput extension
• the Android RKP profile with a more restrictive version of the OpenDiceInput extension

Additionally we want to support both X.509 and CWT certificate formats, where applicable, for all profiles.

I put together an RFC to describe what we are looking for: https://docs.google.com/document/d/1zBudM3YyasCoYhchRDLJUKKDEtlCQ4Yc5dx9HEE45HU/edit?usp=sharing