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.

Sign up for GitHub

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

Jump to bottom

Clarify use creating and verifying TPM attestation statements. #2193

Open
wants to merge 7 commits into
base: main
Choose a base branch
from
Open

Clarify use creating and verifying TPM attestation statements. #2193

Changes from 6 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
8d690aa
Clarified signing and verification procedures for TPM attestation
mwiseman-byid Oct 26, 2024
e51255d
Minor formatting fixes
mwiseman-byid Oct 26, 2024
4d5c9ea
Add note that qualifiedSigner, clockInfo, and firmwareVersion may be …
mwiseman-byid Oct 26, 2024
73435ba
Change verify to check sig of certInfo before processing it
mwiseman-byid Oct 26, 2024
96e5e07
Disallow HardwareModuleName in attestation certificate's SAN. Update …
mwiseman-byid Oct 27, 2024
1314870
Correct spelling
mwiseman-byid Oct 30, 2024
21d38c0
Merge branch 'w3c:main' into main
mwiseman-byid Nov 1, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 28 additions & 14 deletions index.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6536,8 +6536,11 @@ engine.
setting the `extraData` parameter to the digest of |attToBeSigned| using the hash algorithm corresponding to the "alg" signature algorithm.
(For the "RS256" algorithm, this would be a SHA-256 digest.)

Set the |pubArea| field to the public area of the credential public key, the |certInfo| field to the output parameter of the
same name, and the |sig| field to the signature obtained from the above procedure.
Set the |pubArea| field to the public area of the credential public key (the TPMT_PUBLIC structure), the |certInfo| field (the TPMS_ATTEST structure)
to the output parameter of the same name, and the |sig| field to the signature obtained from the above procedure.

Note: If the |pubArea| is read from the TPM using the TPM2_ReadPublic command, that command returns a TPM2B_PUBLIC structure. TPM2B_PUBLIC
sbweeden marked this conversation as resolved.
Show resolved Hide resolved
is two bytes of length followed by the TPMT_PUBLIC structure. The two bytes of length must be removed prior to putting this into the |pubArea|.

: Verification procedure
:: Given the [=verification procedure inputs=] |attStmt|, |authenticatorData| and |clientDataHash|, the [=verification procedure=] is
Expand All @@ -6551,24 +6554,30 @@ engine.

Concatenate |authenticatorData| and |clientDataHash| to form |attToBeSigned|.

Verify integrity of |certInfo|
- Verify that |x5c| is present.
- Verify that |aikCert| meets the requirements in [[#sctn-tpm-cert-requirements]].
- If |aikCert| contains an extension with OID `1.3.6.1.4.1.45724.1.1.4` (`id-fido-gen-ce-aaguid`) verify that the value of this
extension matches the <code>[=authData/attestedCredentialData/aaguid=]</code> in |authenticatorData|.
- Verify the |sig| is a valid signature over |certInfo| using the attestation public key in |aikCert| with the
algorithm specified in |alg|.

Validate that |certInfo| is valid:
Note: |certInfo| is a TPMS_ATTEST structure.
- Verify that `magic` is set to `TPM_GENERATED_VALUE`.
- Verify that `type` is set to `TPM_ST_ATTEST_CERTIFY`.
- Verify that `extraData` is set to the hash of |attToBeSigned| using the hash algorithm employed in "alg".
- Verify that `attested` contains a `TPMS_CERTIFY_INFO` structure as specified in [[!TPMv2-Part2]] section 10.12.3,
whose `name` field contains a valid Name for |pubArea|,
as computed using the procedure specified in [[!TPMv2-Part1]]
section 16. Note that the hash algorithm is included within the attested `name` field of the TPMS_CERTIFY_INFO structure.
- Verify that |x5c| is present.
- Note that the remaining fields in the "Standard Attestation Structure" [[!TPMv2-Part1]]
whose `name` field contains a valid Name for |pubArea|, as computed using the procedure specified in [[!TPMv2-Part1]] section 16 using the nameAlg in the |pubArea|.

Note: The hash algorithm is also included within the attested `name`
field of the TPMS_CERTIFY_INFO structure and will also match nameAlg in |pubArea| when returned by the TPM.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggest changing "will also match" to "MUST also match", thereby making this normative and an error if the RP detects that the hash algorithm is different in these two locations.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By making this a note, this is an informative statement so not sure if we can make this normative. This clarification, in fact, is what I believe is the source of the original concern that there was a possibility these would be different, when, in fact, the TPM never changes the algorithm. Making this check a MUST alludes that the TPM might return these different. That said, as the algId in the Name is not protected it is possible for software (local or in transit) to change it but the worse case would be a DOS attack (unless someone finds a pre-image attack). With that said, I'm open to the suggestion if you still believe that's needed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem I have with lowercase "will also match" is that it's suggestive, without providing guidance to the RP as to what to do if its observed that the values are not the same in both locations. I'm not going to die on this hill though.


Note: The remaining fields in the "Standard Attestation Structure" [[!TPMv2-Part1]]
section 31.2, i.e., `qualifiedSigner`, `clockInfo` and `firmwareVersion` are ignored.
These fields MAY be used as an input to risk engines.
Depending on the properties of the |aikCert| key used, these fields may be obfuscated.
If valid, these MAY be used as an input to risk engines.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does the RP determine if the fields are valid or not?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The content of these fields is determined by which TPM hierarchy the AK is in. (tl;dr: If the AK is in the Endorsement hierarchy the fields are valid, if the AK is in the Storage hierarchy, the fields are random - this is for privacy reasons). To provide information about where the AK is may be a privacy concern so this is not provided in the protocol. The properties of the AK (including whether to even trust it) are out of scope for this protocol and it would be up to the RP to know that out of band.


- Verify the |sig| is a valid signature over |certInfo| using the attestation public key in |aikCert| with the
algorithm specified in |alg|.
- Verify that |aikCert| meets the requirements in [[#sctn-tpm-cert-requirements]].
- If |aikCert| contains an extension with OID `1.3.6.1.4.1.45724.1.1.4` (`id-fido-gen-ce-aaguid`) verify that the value of this
extension matches the <code>[=authData/attestedCredentialData/aaguid=]</code> in |authenticatorData|.
- If successful, return implementation-specific values representing [=attestation type=] [=AttCA=] and [=attestation trust
path=] |x5c|.

Expand All @@ -6582,6 +6591,11 @@ TPM [=attestation certificate=] MUST have the following fields/extensions:

- The Subject Alternative Name extension MUST be set as defined in [[!TPMv2-EK-Profile]] section 3.2.9.

Note: Previous versions of [[!TPMv2-EK-Profile]] allowed the inclusion of an optional attribute,
called HardwareModuleName, that contains the TPM serial number in the EK certificate.
HardwareModuleName SHOULD NOT be placed in in the [=attestation certificate=]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest changing "SHOULD NOT" to "MUST NOT" for privacy preserving reasons.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree MUST NOT would be my preference. However, my concern with MUST NOT is if there are any existing implementation that followed the original wording, MUST NOT would make those existing implementations (if >0) non-compliant which would not be their fault. I'm OK with the guidance of the WG on this.

Subject Alternative Name.

- The Extended Key Usage extension MUST contain the OID `2.23.133.8.3`
("joint-iso-itu-t(2) internationalorganizations(23) 133 tcg-kp(8) tcg-kp-AIKCertificate(3)").

Expand Down Expand Up @@ -9406,7 +9420,7 @@ for their contributions as our W3C Team Contacts.
"TPMv2-EK-Profile": {
"title": "TCG EK Credential Profile for TPM Family 2.0",
"publisher": "Trusted Computing Group",
"href": "https://www.trustedcomputinggroup.org/wp-content/uploads/Credential_Profile_EK_V2.0_R14_published.pdf"
"href": "https://trustedcomputinggroup.org/wp-content/uploads/TCG-EK-Credential-Profile-V-2.5-R2_published.pdf"
},

"FIDOAuthnrSecReqs": {
Expand Down