Improvements to the attestation server: quote and Endorsement key serialized as TPMTPublic

[Foxboron]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

I think it would be practical if we could include a bit more information of the
client being attested.

I'm proposing two changes:

• Include TPM2_Quote output into AttestationParameters
• Change EKPub to TPMTPublic instead of crypto.PublicKey

The basic structs we have today is this:

type Attestation struct {
	TPMInfo      *TPMInfo               `json:"tpmInfo"`
	EKPub        []byte                 `json:"ek,omitempty"`
	EKCerts      [][]byte               `json:"ekCerts,omitempty"`
	AKCert       []byte                 `json:"akCert,omitempty"`
	AttestParams *AttestationParameters `json:"params"`
}

type AttestationParameters struct {
	Public                  []byte `json:"public,omitempty"`
	UseTCSDActivationFormat bool   `json:"useTCSDActivationFormat,omitempty"`
	CreateData              []byte `json:"createData,omitempty"`
	CreateAttestation       []byte `json:"createAttestation,omitempty"`
	CreateSignature         []byte `json:"createSignature,omitempty"`
}

I propose we add two new fields to AttestationParameters for QuoteAttestation and QuoteSignature.

type AttestationParameters struct {
	Public                  []byte `json:"public,omitempty"`
	UseTCSDActivationFormat bool   `json:"useTCSDActivationFormat,omitempty"`
	CreateData              []byte `json:"createData,omitempty"`
	CreateSignature         []byte `json:"createSignature,omitempty"`
	QuoteAttestation        []byte `json:"quoteAttestation,omitempty"`
	QuoteSignature          []byte `json:"quoteAttestation,omitempty"`
}

Where QuoteAttestation is TPM2B_ATTEST bytes, and QuoteSignature is
the TPMT_SIGNATURE bytes from the TPM2_Quote command, the signature should
be from the attestation key (AK) which is the Public field from
`AttestationParameters.

This would allow us to check against valid system states on the remote end.

Another change I would like is if we could move EKPub to not be a serialized
crypto.Publickey, but rather the actual TPMTPublic. go-tpm currently
implements a standardized KEM interface to help with credential activation in
the newer API, and this is based off on the TPMTPublic type.

See labeled_kem in go-tpm: https://github.com/google/go-tpm/blob/main/tpm2/labeled_kem_convert.go#L24

For this to be used on the remote end today with the current API structure you
need to make a bunch of assumptions around the symmetric paramteres and the name
algorithm being used. Which seems hacky when we could instead pass around the
actual public structure of the EK.

See attezt: https://github.com/Foxboron/attezt/blob/master/internal/attest/credential.go

(I could probably parse the EKCert instead.. but that is not a lot better?)

[hslatman]

Hey @Foxboron, I've moved the issue to this repo, as it houses some shared attestation code we use in our stack, and would probably make most sense to make the changes here. There's some duplicate code in the CLI repo, but we've always wanted to get that to use our shared code too, so what's in the CLI is likely to be replaced/refactored with what's (going to be) available in this repo.

Where QuoteAttestation is TPM2B_ATTEST bytes, and QuoteSignature is the TPMT_SIGNATURE bytes from the TPM2_Quote command, the signature should be from the attestation key (AK) which is the Public field from `AttestationParameters.

This would allow us to check against valid system states on the remote end.

This makes sense, and should be fairly easy to add in the request struct. It probably requires some more changes to get it wired through properly in the locations where it is used.

The current struct is used to attest new application key creation by the AK. We could opt to have a different struct, with a similar format specifically for signed quotes, as they can be created/used independently of key creation. I can see it being combined in one go too, though, so maybe we should have multiple (embedded) structs.

Another change I would like is if we could move EKPub to not be a serialized crypto.Publickey, but rather the actual TPMTPublic. go-tpm currently implements a standardized KEM interface to help with credential activation in the newer API, and this is based off on the TPMTPublic type.

See labeled_kem in go-tpm: https://github.com/google/go-tpm/blob/main/tpm2/labeled_kem_convert.go#L24

For this to be used on the remote end today with the current API structure you need to make a bunch of assumptions around the symmetric paramteres and the name algorithm being used. Which seems hacky when we could instead pass around the actual public structure of the EK.

This makes sense too, but it'll take some more effort, since we're currently relying on the current format to parse it as a crypto.PublicKey. It might be an option to try parsing it as a TPMTPublic first, and if it fails, fallback to parsing an crypto.PublicKey, but it would be better if it were an additional, new property, imo.

We currently rely on the legacy package in go-tpm still, but that shouldn't cause issues for (de)serializing the TPMTPublic. It could even be a nice starting point for our migration to the new packages.

[Foxboron]

This makes sense too, but it'll take some more effort, since we're currently relying on the current format to parse it as a crypto.PublicKey. It might be an option to try parsing it as a TPMTPublic first, and if it fails, fallback to parsing an crypto.PublicKey, but it would be better if it were an additional, new property, imo.

We could also just introduce a new field and "deprecate" the old field?

We currently rely on the legacy package in go-tpm still, but that shouldn't cause issues for (de)serializing the TPMTPublic. It could even be a nice starting point for our migration to the new packages.

Yes, but I suspect go-attestation is going to change long term, so just being aware of the current API is probably nice when planning changes.

[Foxboron]

Also, go-tpm has Pub and Priv to convert the respective TPMT structs. So this change should not create a lot of additional code in the future.

https://github.com/google/go-tpm/blob/main/tpm2/crypto.go#L77

[hslatman]

This makes sense too, but it'll take some more effort, since we're currently relying on the current format to parse it as a crypto.PublicKey. It might be an option to try parsing it as a TPMTPublic first, and if it fails, fallback to parsing an crypto.PublicKey, but it would be better if it were an additional, new property, imo.

We could also just introduce a new field and "deprecate" the old field?

Yes, this would be my preferred option.

We currently rely on the legacy package in go-tpm still, but that shouldn't cause issues for (de)serializing the TPMTPublic. It could even be a nice starting point for our migration to the new packages.

Yes, but I suspect go-attestation is going to change long term, so just being aware of the current API is probably nice when planning changes.

Absolutely 🙂

[Foxboron]

Suggestion;

type Attestation struct {
	[...]
	EKPublic        []byte                 `json:"ekPublic,omitempty"`
}

Where we can treat EKPublic as optional until further notice?

and for Quote.

type Attestation struct {
	[...]
	Quote *QuoteParameters `json:"quote"`
}

type QuoteParameters struct {
	Public                  []byte `json:"public,omitempty"`
	QuoteAttestation        []byte `json:"quoteAttestation,omitempty"`
	QuoteSignature          []byte `json:"quoteAttestation,omitempty"`
}