[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]

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?

[timothytrippel]

Should this PR be empty? or should be rebased on top of #24754 to use the autogenerated code? or will a new PR be opened to make use of the autogenerated CWT builder code in #24754 to implement theses functions:
https://cs.opensource.google/opentitan/opentitan/+/master:sw/device/silicon_creator/lib/cert/dice_cwt.c;l=142
https://cs.opensource.google/opentitan/opentitan/+/master:sw/device/silicon_creator/lib/cert/dice_cwt.c;l=152

@tommychiu-github @stevenchtsai ?

[tommychiu-github]

Should this PR be empty? or should be rebased on top of #24754 to use the autogenerated code? or will a new PR be opened to make use of the autogenerated CWT builder code in #24754 to implement theses functions: https://cs.opensource.google/opentitan/opentitan/+/master:sw/device/silicon_creator/lib/cert/dice_cwt.c;l=142 https://cs.opensource.google/opentitan/opentitan/+/master:sw/device/silicon_creator/lib/cert/dice_cwt.c;l=152

@tommychiu-github @stevenchtsai ?

No, it should't be closed. However github do it for me when I try to "sync fork" from the upstrem.
Will reopen it after #24754 is landed.

[tommychiu-github]

The commit message will be fleshed out once all dependencies are merged.

[timothytrippel]

I think you can update this PR and replace with autogen code now that it has been merged @tommychiu-github

[tommychiu-github]

Update the latest offline verification result.

hwtrust --verbose dice-chain --allow-any-mode dice.bin 
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: Debug,
            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: "22d8e07c7ca0a9720bc2c29e437872941e4069cf112e60fa5aec0ad842351b2e",
            Mode: Debug,
            Code Hash: "3333333333333333333333333333333333333333333333333333333333333333",
            Config Hash: "b904d48b9a331c580cc7c511492711060fdcced8d6f0979a55766ace4d88ce99",
            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: [
                    (
                        "-71006",
                        "Bytes([34, 34, 34, 34, 34, 34, 34, 34, 34, 34, 34, 34, 34, 34, 34, 34, 34, 34, 34, 34, 34, 34, 34, 34, 34, 34, 34, 34, 34, 34, 34, 34])",
                    ),
                ],
            },
        },
    },
)
Success

[timothytrippel]

mostly, LGTM. A few things should be cleaned up first, then we can get this merged.

[timothytrippel]

Thanks @tommychiu-github !

[github-actions]

Backport failed for earlgrey_1.0.0, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin earlgrey_1.0.0
git worktree add -d .worktree/backport-24835-to-earlgrey_1.0.0 origin/earlgrey_1.0.0
cd .worktree/backport-24835-to-earlgrey_1.0.0
git switch --create backport-24835-to-earlgrey_1.0.0
git cherry-pick -x f8a8be48c2104976943e1ff95ba7d8e0469040a3

[github-actions]

Backport failed for earlgrey_1.0.0, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin earlgrey_1.0.0
git worktree add -d .worktree/backport-24835-to-earlgrey_1.0.0 origin/earlgrey_1.0.0
cd .worktree/backport-24835-to-earlgrey_1.0.0
git switch --create backport-24835-to-earlgrey_1.0.0
git cherry-pick -x f8a8be48c2104976943e1ff95ba7d8e0469040a3