[dice,cwt] Add CWT implementation

[tommychiu-github]

Add some helper functions and a CDI_* builder manually.
Some of the changes in the builder will be replaced by a following RP on opentitantool > codegen feature.

[tommychiu-github]

I unintentionally close the former PR (#24824) while resolving the conflicts.
Please move to this new one, sorry for the inconvinence. @timothytrippel @stevenchtsai

WRT to the dup of #24754, the thought is to have a reference implementation & output, for cross checking against the auto-codegen.
Moreover only the last commit will be replaced by the codegen output, the rest commits in this PR are requisites.

[pamaury]

I am not sure I understand why you want to have a manual C implementation. If you want to have a reference implementation and output, I would suggest to follow the same approach as for the X509 certificates: have a reference rust implementation (easier to review in my opinion) and check that the rust and autogenerated C implementation yield the same results.

[timothytrippel]

A similar function exists in https://cs.opensource.google/opentitan/opentitan/+/master:sw/device/silicon_creator/lib/cert/dice.c;drc=40107c126540a065de2de6c55c92a3f9f4ca5c49;l=122 ; lets move it to a util lib and share between dice.c and dice_cwt.c

[timothytrippel]

The owner_manifest_measurement is missing from the cert. This contains the measurement of the "owner configuration block", should this be included?

[tommychiu-github]

Yep, it can be part of the "Authority Descriptor"

[timothytrippel]

is Cdi1 the same max size?

[tommychiu-github]

No, it'll be different if we include owner_manifest_measurement in the CSR.
These constants will be calculated against the template thus we don't need to define manually.

[timothytrippel]

I am not sure I understand why you want to have a manual C implementation. If you want to have a reference implementation and output, I would suggest to follow the same approach as for the X509 certificates: have a reference rust implementation (easier to review in my opinion) and check that the rust and autogenerated C implementation yield the same results.

I agree with @pamaury here. The reference rust implementation would be more consistent with how the X.509 certs are implemented too, and we can reuse the rust implementation in host code to parse the device generated certs as well. Also there should be unittests generated for your device code as well to test its correctness. If this is really just a stepping stone until #24754 is implemented, and all the manually implemented code will be replaced shortly, could you please comment exactly the locations in the code that will be replaced by #24754?

[tommychiu-github]

I am not sure I understand why you want to have a manual C implementation. If you want to have a reference implementation and output, I would suggest to follow the same approach as for the X509 certificates: have a reference rust implementation (easier to review in my opinion) and check that the rust and autogenerated C implementation yield the same results.

I agree with @pamaury here. The reference rust implementation would be more consistent with how the X.509 certs are implemented too, and we can reuse the rust implementation in host code to parse the device generated certs as well. Also there should be unittests generated for your device code as well to test its correctness. If this is really just a stepping stone until #24754 is implemented, and all the manually implemented code will be replaced shortly, could you please comment exactly the locations in the code that will be replaced by #24754?

Thanks for the input.
Actually it'll be better to separate the utility changes from the manual CDI implementation, for easier review and merge flow.
Will keep only 682b8078b6f5761f6c2b489ef2cee23f698c42c6 in this PR, and move others to a new one (#24850).

And to align with the X509 implementation (codegen, unit test, verifier), I'll set the manual CDI implementation to "draft" for now, till we complete all the related changes.

[tommychiu-github]

Verification result for this implementation.

$ hwtrust --verbose dice-chain DiceChain
Proper(
    Chain {
        Root public key: "-----BEGIN PUBLIC KEY-----\nMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEDJ/ChN8wq5MokcByBnjRHC/Mjd5J\nH7kfpD4icOzchTCnGwusRivw4N/egP9Bm+yZae0LrspWkGe6mkJBrLEHvA==\n-----END PUBLIC KEY-----\n",
        DICE Certificate[0]: Payload {
            Issuer: "da517a972ab8b3772eb169507f593d66c7d1bc35a998ae1831c369ca75bc0f5e",
            Subject: "2cc11542a43c450dd06b930c2c9b9781758b16a5d6cc4bb4198798b0e1e67045",
            Mode: Normal,
            Code Hash: "1111111111111111111111111111111111111111111111111111111111111111",
            Config Hash: "7a7c35059d78b25665ac0a96ee30540484690e4f0b4d7c5bd9bf23217cb1edfb",
            Authority Hash: "c19a797fa1fd590cd2e5b42d1cf5f246e29b91684e2f87404b81dc345c7a56a0",
            Config Desc: ConfigDesc {
                component_name: None,
                component_instance_name: None,
                component_version: None,
                resettable: false,
                security_version: Some(
                    0,
                ),
                rkp_vm_marker: false,
                extensions: [],
            },
        },
        DICE Certificate[1]: Payload {
            Issuer: "2cc11542a43c450dd06b930c2c9b9781758b16a5d6cc4bb4198798b0e1e67045",
            Subject: "9b56d423c87a7116e4c51eb68a3aaecefded7faa1662642ba781dbe90e52fb9e",
            Mode: Normal,
            Code Hash: "3333333333333333333333333333333333333333333333333333333333333333",
            Config Hash: "7a7c35059d78b25665ac0a96ee30540484690e4f0b4d7c5bd9bf23217cb1edfb",
            Authority Hash: "c19a797fa1fd590cd2e5b42d1cf5f246e29b91684e2f87404b81dc345c7a56a0",
            Config Desc: ConfigDesc {
                component_name: None,
                component_instance_name: None,
                component_version: None,
                resettable: false,
                security_version: Some(
                    0,
                ),
                rkp_vm_marker: false,
                extensions: [],
            },
        },
    },
)
Success

[timothytrippel]

@tommychiu-github What is the tool you used to verify this chain? the hwtrust tool? Is this tool something that could be vendored into the repo so that it could be used validate the DICE chain the FT provisioning flow test: https://cs.opensource.google/opentitan/opentitan/+/master:sw/host/provisioning/ft_lib/src/lib.rs;l=426?q=ft_lib%2F&ss=opentitan%2Fopentitan ?

[tommychiu-github]

Yes, I'm using hwtrust tool from the Android source tree - https://source.corp.google.com/h/googleplex-android/platform/superproject/main/+/main:tools/security/remote_provisioning/hwtrust/src/;l=1
It should be possible to vendor in this module. Was there any example in the OT?