Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose init_data to policy #370

Open
fitzthum opened this issue Apr 17, 2024 · 2 comments
Open

Expose init_data to policy #370

fitzthum opened this issue Apr 17, 2024 · 2 comments

Comments

@fitzthum
Copy link
Member

Now that the init_data spec is merged, we should think about how we will evaluate the init data with Trustee.

Currently we don't really expose the init_data to either the attestation policy or the resource policy in the KBS. We had talked about extending the claims map of each verifier to include init_data, but that hasn't really happened. Maybe we should instead directly provide the init_data to opa engine in addition to the claims map? Should we do this for both the AA and KBS?

@Xynnn007
Copy link
Member

Xynnn007 commented Apr 18, 2024

That's good points and I agree to provide them into OPA. Overall I think KBS is the right place to check plaintext of initdata and potential runtime data rather than AS.

Let's see the whole lifetime of initdata and see what we should do

Stage Comments What we need to enhence
Injected to guest and checked against tee field - Kata side
deliver from guest to trustee Handling in KBS and deliver upon KBS protocol is a better way. We might change the use of evidence field in Attestation or add a new parameter to deliver plaintext initdata. confidential-containers/confidential-containers#176 has similiar requests. This hints that AA should have ability to get the whole plaintext of initdata, which would be achieved either by changing the rpc CheckInitData to carry while initdata or potentially use launch cmdline kbs protocol & kbs-types & AA & kbs_protocol crate
check claims we need to have an uniform of initdata. This may introduce some serialization and deserialization operations to convert Toml to Json and then put it into regorus engine. The check work should be delayed after attestation with AS succeeds kbs

@fitzthum
Copy link
Member Author

Yeah, I think we'll need to extend CheckInitData in the AA to get the plaintext in the first place. The AA should probably store the plaintext somewhere until it is time for attestation.

We could potentially use one of the extra-params fields in the KBS protocol for the initdata, but unfortunately the attestation message doesn't have that field. I guess we could pass it as part of the request but that seems kind of weird.

Once we're into the KBS, we should double check that all the verifiers are actually validating the initdata and then just pass it into the Regorus engine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants