sbin/attest-enroll needs to support enrolling an EKcert, and it should validate it

[nicowilliams]

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.

[nicowilliams]

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.

[osresearch]

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.

[osresearch]

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

[nicowilliams]

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

[nicowilliams]

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

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.

[nicowilliams]

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).

[nicowilliams]

#40 (comment)