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

Using EKhash = H(EKpub), when the EKpub is derived from an EKcert, is problematic #170

Open
nicowilliams opened this issue Oct 14, 2022 · 3 comments

Comments

@nicowilliams
Copy link
Contributor

In HCP we use Safeboot w/ an EKcert, then we derive an EKpub from the EKcert, then we compute a hash of the EKpub and name the enrollment after that hash. At attestation time the client sends its EKpub and the server looks up the enrollment by EKhash = H(EKpub).

The way the EKcert->EKpub conversion is done is simple:

  • validate the EKcert
  • extract the subject public key from the EKcert
  • load that public key into an swTPM as a public key object with all the attributes expected of an EK (the standard authPolicy, attributes, etc.)
  • extract the TPM2B_PUBLIC for that loaded object from the swTPM

But there are at least two ways in which the TPM2B_PUBLIC of an EK as produced by the TPM where it resides, and as produced by another TPM as used above can differ:

  • if the key is an RSA key, the exponent should be 2^16 + 1, which is the default exponent, and which should be written as the all-zeros value that indicates the default
    The swTPM writes all-zeros.
    A TPM could write 2^16 + 1, and at least one brand does.

  • if the key is a restricted, decrypt-only RSA key, then the scheme is required to be OEAP and that is allowed to be expressed as the default scheme (NULL)
    We've not observed any TPM writing in the OEAP scheme instead of the NULL scheme, but it could happen.

The upshot is that either we must

  • enroll both, an EKcert and an EKpub (checking that the spk matches, naturally),
  • send the EKcert during attestation,
    or
  • normalize the the EKpub sent by the client at attestation time.

(Readers should note that enrollment also supports enrolling with an EKpub directly, and this is for the case where virtual TPMs are used where there is a mechanism other than EKcerts for validating the legitimacy of a TPM.)

@nicowilliams
Copy link
Contributor Author

I think the normalization approach will probably be the best.

@osresearch
Copy link
Owner

Normalizing the EKpub on the server might make more sense? The server is the one choosing to use the hash, not the client, and a different server might choose an equality test or something else like checking the modulus, which means that the client doesn't know what fields are important.

This normalization is also easier to do in the Python server than the shell scripts of the client, right?

@nicowilliams
Copy link
Contributor Author

nicowilliams commented Oct 17, 2022

This normalization is also easier to do in the Python server than the shell scripts of the client, right?

I'm thinking it's just tpm2_loadexternal then tpm2_readpublic to normalize.

The swtpm does remember whether the exponent was given as 0x00010001 or 0x00000000, so we'll have to resort to ugly games.

A dd command works. However, I fear this is too ugly, and that we might need to do something else.

Options:

  • hash just the raw public key from the EKpub, not its full TPM2B_PUBLIC
  • require the EKpub in addition to the EKcert at enrollment time (this might not be easy to pull off for organizations running enrollment)

nicowilliams added a commit to nicowilliams/safeboot that referenced this issue Nov 1, 2022
nicowilliams added a commit to nicowilliams/safeboot that referenced this issue Nov 1, 2022
nicowilliams added a commit to nicowilliams/safeboot that referenced this issue Nov 1, 2022
nicowilliams added a commit to nicowilliams/safeboot that referenced this issue Nov 1, 2022
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