Open nicowilliams opened 3 years ago
As well, it would be nice to have a way for the HTTPS server to communicate the authenticated principal name to sbin/attest-enroll
, and maybe we can do some crude authorization there.
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.
tpm2-attest ek-verify
will check a cert against the common OEMs, although it expects it in a quote tar file; we would need to move or duplicate that logic to attest-enroll
.
It looks like we can get encrypted secret exchange by adding a -c key.ctx
to the startauthsession
? https://github.com/osresearch/safeboot/blob/master/functions.sh#L169
Yes, I've settled for this scheme regarding EKcerts:
giving an EKcert as the "EKpub" to sbin/attest-enroll
should work, and sbin/attest-enroll
should validate it if given (using a configured set of TPM vendor trust anchors)
there should be a configuration parameter for sbin/attest-enroll
that indicates whether EKcerts are needed
if EKcerts are needed but an EKpub was enrolled, then sbin/attest-enroll
should create a flag in the enrolled device's entry that alerts the attestation server that the client must provide an EKcert (and then the attestation server will validate it)
sbin/tpm2-attest
should always send the EKcert when there is one
It looks like we can get encrypted secret exchange by adding a
-c key.ctx
to thestartauthsession
? https://github.com/osresearch/safeboot/blob/master/functions.sh#L169
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 TPM2B_*
input or output as the first input or output (not counting sessions and handles).
This gets you encryption of those TPM2B_*
s, but to get integrity protection for the rest of the commands' inputs and outputs you also need to deal with the command hashes. It's... painful to get full protection. What should really happen is that the CLI tools should just do this automatically -- well, you'd still have to provide some details, like what key you want to use for keying the encryption session.
Section 11.1 of the TCG TPM Library part 3
guide describes how to do key exchange.
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 https://github.com/tpm2dev/tpm.dev.tutorials/tree/master/Intro#key-exchange-for-encryption-sessions https://github.com/tpm2dev/tpm.dev.tutorials/tree/master/Intro#hmac-sessions https://github.com/tpm2dev/tpm.dev.tutorials/blob/master/TPM-Commands/TPM2_StartAuthSession.md
but I've not covered how to do this with tpm2-tools, or how to do integrity protection with cpHash
(command parameter hash) and rpHash
(response parameter hash).
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.