-
Notifications
You must be signed in to change notification settings - Fork 28
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
sbin/attest-enroll
needs to support enrolling an EKcert
, and it should validate it
#137
Comments
As well, it would be nice to have a way for the HTTPS server to communicate the authenticated principal name to |
We only have EKcert's for some models of physical TPMs, and not at all for GCP vTPM, so it would need to be an optional thing.
|
It looks like we can get encrypted secret exchange by adding a |
Yes, I've settled for this scheme regarding EKcerts:
|
Sort of. You need a separate session for encryption than for authorization (well, on the wire there's multiple sessions per request, but I'm not sure if you can use the same session for authorization and for encryption). You also need to do this for... every command whose request has a sensitive This gets you encryption of those |
Section 11.1 of the Turns out I've written a little bit about this in the TPM.dev tutorial: https://github.com/tpm2dev/tpm.dev.tutorials/tree/master/Intro#encryption-sessions but I've not covered how to do this with tpm2-tools, or how to do integrity protection with |
Enrolling with an
EKpub
is problematic: we're counting on the user to have determined the TPM to be legitimate, and that requires authenticating and authorizing the user.If we use an
EKcert
we can check that it chains to a vendor root CA we trust, and then we can allow first-come-first-served enrollment by anonymous users as an option.The text was updated successfully, but these errors were encountered: