AA: Add API of CheckInitData

[Xynnn007]

This new API is for kata-agent to check the data's integrity binding relationship with the hardware evidence.

Close #446

The main work for TDX and SNP platform has been done by @danmihai1 , this PR just refers most of the code.

cc @fitzthum

[fitzthum]

Nice.

One thing I think we might have forgotten about when designing: ideally the KBS/AS will end up with the plaintext of the InitData so that it can be validated with a policy. We don't seem to have a mechanism for this. Perhaps if the plaintext is provided via this API it should be saved by the AA so that it can be sent as part of remote attestation. We could probably implement this in a follow-on.

[Xynnn007]

Thanks @mkulke for the suggestions. I left the review conversions which might need to be ensured by you. PTAL

Hi @fitzthum

One thing I think we might have forgotten about when designing: ideally the KBS/AS will end up with the plaintext of the InitData so that it can be validated with a policy. We don't seem to have a mechanism for this. Perhaps if the plaintext is provided via this API it should be saved by the AA so that it can be sent as part of remote attestation. We could probably implement this in a follow-on.

Yes, agreed. Added the enum of initdata for plaintext, which could be relied on. Also some conversions to be determined. PTAL

[fitzthum]

So it's worth noting that this is InitData specific code. If we still haven't reached an agreement there, maybe we should leave support for the Plaintext to a later PR.

fwiw, I think this shows a clear benefit of the InitData approach. The policy does not include any information about how it is hashed and even if it did, we would have to do parsing of OPA to get it. We could add an additional field to pass the hash type from the shim (where the data is first hashed), to the kata agent, to the AA, to the KBS, but it seems nicer to have it simply included in the InitData. cc @mkulke

[mkulke]

I would opt for adding plaintext checks later if that doesn't clutter the API. At the moment check_init_data() is ambiguous and needs a dead Option<> param. Maybe we can split it into check_init_data_digest and in follow-up PRs introduce check_init_data_body or consolidate both into check_init_data.

[fitzthum]

I don't mind having one endpoint for both even if only the digest is supported at first. I think we will need a plaintext option for the attestation flow to really add up, but this will require some agreement on the format.

Btw, @Xynnn007 this InitDataPlaintext message doesn't quite match up with your RFC spec which contains a version and digest field as well.

[Xynnn007]

Btw, @Xynnn007 this InitDataPlaintext message doesn't quite match up with your RFC spec which contains a version and digest field as well.

Yes. I once hope that the format in RFC is handled inside kata-agent. That means

• version check
• data field into files
• use the digest field & hash alg to match the data field and call AA's CheckInitData() semantically / DIrectly use data field and hash alg to call AA's CheckInitDataPlaintext() semantically, where the InitDataPlaintext

@mkulke I once thought that one API is enough, and to decrease the potential adaptation work when API changes, I used one API to receive different kinds of parameters as they both are "checking the initdata field binding relationship".

But with your opinions I realize that the steps are probably relatively big. Let me add one simple parameter initDataDigest and leave the plaintext extension in future together with the format issue.

[Xynnn007]

Thanks @fitzthum @mkulke @jialez0 , I fixed the suggestions you've left.

1. Use pad()
2. Only check digest for now and API
3. use tdx_attest::get_evidence rather than impl manually

PTAL

[mkulke]

lgtm

[fitzthum]

LGTM

[jiazhang0]

@fitzthum @Xynnn007 @jialez0 Let me clarify something for the future decision and this time just let it go.

I think it is an not easy decision to add a new API which may introduces extra attack interface. In other word, there is still the possibility to use an approach to check the validation of init data without adding new API. In addition, CoCo is not the only case where AA will be deployed. In some cases, the proxy is not used.

Furthermore, considering certain security principles such as defense in depth and the principle of least privilege, adding a new API is not the only solution to address the problem and requirement at hand. Even if someone argues that the newly added API has successfully passed penetration testing without any vulnerabilities found, the results of penetration testing can only provide temporary confidence. Past performance is not indicative of future results. Therefore, we cannot exclude the potential for unknown vulnerabilities and security risks with new API.

Security often focuses on the future possibilities that arise when the timeline is extended, and aims to proactively address potential risks and threats that may arise in the future.