Question: What are the key characteristics of the “packed” attestation statement format?

The “packed” attestation statement format, used in WebAuthn, is designed for efficiency and flexibility. Here’s a breakdown of its key characteristics:

1. Compact Encoding: As its name suggests, it prioritizes a concise representation to minimize data size, which is particularly beneficial for resource-constrained authenticators like secure elements.

2. Extensibility: Despite its compact nature, it allows for future additions and modifications through its structure. This ensures it can adapt to evolving attestation requirements.

3. Support for Multiple Attestation Types: “Packed” is versatile, accommodating three distinct attestation types:
* Basic Attestation (or Batch Attestation): Authenticators of the same model share a common attestation key pair.
* Self Attestation: The authenticator attests itself using its own credential private key, typically used when distinct attestation keys aren’t available.
* Attestation CA (AttCA): A trusted third-party (Attestation CA) issues certificates for each attestation key, enhancing trust and accountability.

4. Structure: A “packed” attestation statement typically consists of the following fields:

* **alg:** A numerical identifier representing the algorithm used for the attestation signature (e.g., -7 for ES256).
* **sig:** The actual attestation signature, a byte string generated using the chosen algorithm.
* **x5c (Optional):**  An array of X.509 certificates forming the attestation certificate chain. The first element is the attestation certificate (`attestnCert`) itself. This field is present for Basic and AttCA attestation, but absent for Self attestation.

5. Signing Procedure: The authenticator generates the signature (sig) by signing the combined authenticatorData and clientDataHash. The signing key varies based on the attestation type:
* Basic/AttCA: The authenticator’s attestation private key is used.
* Self: The credential’s own private key is used.

6. Verification Procedure: Relying Parties validate the attestation statement as follows:

* **CBOR Decoding:** The statement is decoded to extract the `alg`, `sig`, and `x5c` fields.
* **Signature Verification:** The `sig` is verified against the concatenated `authenticatorData` and `clientDataHash` using the public key from the appropriate source (either the attestation certificate in `x5c` or the credential public key for Self attestation).
* **Certificate Chain Validation (If x5c is present):** The certificate chain in `x5c` is validated against trusted root certificates, establishing a chain of trust.
* **Attestation Type Determination:** Based on the presence or absence of `x5c` and external knowledge about certificates, the Relying Party determines the attestation type.

In essence, the “packed” attestation statement format offers a balanced approach, combining efficient data encoding with the flexibility to support different trust models and future extensions.

Question: Describe the syntax and signing procedure for the “packed” attestation statement format.

Let’s break down the “packed” attestation statement format within WebAuthn.

Syntax

The “packed” attestation statement, a critical part of the WebAuthn attestation object, follows this structure expressed in Concise Data Definition Language (CDDL):

$$attStmtType //= (
                      fmt: "packed",
                      attStmt: packedStmtFormat
                  )

packedStmtFormat = {
                       alg: COSEAlgorithmIdentifier,
                       sig: bytes,
                       x5c: [ attestnCert: bytes, * (caCert: bytes) ]
                   } //
                   {
                       alg: COSEAlgorithmIdentifier
                       sig: bytes,
                   }

Field Breakdown

• fmt: A fixed string "packed" identifying this specific attestation format.
• attStmt: Contains the actual data of the “packed” attestation statement, following the packedStmtFormat.
  • alg: A COSEAlgorithmIdentifier specifying the algorithm used for the attestation signature (e.g., ES256, RS256). See [IANA-COSE-ALGS-REG] for the official registry of identifiers.
  • sig: A byte string holding the attestation signature itself.
  • x5c: An optional array containing the attestation certificate (attestnCert) and any intermediate certificates (caCert) in the certificate chain, all encoded in X.509 format. The attestnCert MUST be the first element. This field is OMITTED when using self attestation.

Signing Procedure

The process for generating the “packed” attestation signature mirrors the process for creating assertion signatures, with a key distinction based on the attestation type:

1. Concatenation: The authenticator data (authenticatorData) and the hash of the serialized client data (clientDataHash) are concatenated.
2. Signing:

• Basic or AttCA Attestation: The authenticator signs the concatenated data using a selected attestation private key (mechanism is authenticator-specific). The sig field holds this signature. The x5c field contains the attestation certificate (attestnCert) and its certificate chain (if any). The alg field is set to the algorithm used by the attestation private key.
• Self Attestation: The authenticator signs the concatenated data using the credential private key. The sig field stores the signature. The alg field is set to the credential private key’s algorithm. The x5c field is OMITTED.

Key Points

• Flexibility: The “packed” format accommodates Basic, Self, and AttCA attestation types, offering a versatile solution.
• Compactness: It employs an efficient encoding, suitable for resource-constrained authenticators.
• Extensibility: The x5c field allows for inclusion of certificate chains, enabling trust establishment through a chain of certificates.

Question: Explain the verification procedure for the “packed” attestation statement format.

Let’s break down the verification procedure for the “packed” attestation statement format in WebAuthn.

Context

• Attestation: WebAuthn uses attestation to provide evidence about the authenticator that generated a credential. This helps Relying Parties (websites or services) assess the trustworthiness of a new credential.
• Packed Attestation: A specific format for conveying attestation information. It’s designed to be compact and efficient.

Verification Procedure Inputs

The Relying Party server receives these as part of the registration data:

• attStmt: The “packed” attestation statement itself. It’s a CBOR-encoded structure.
• authenticatorData: Data created by the authenticator during credential generation. Contains important info like the RP ID hash, flags, and the credential public key.
• clientDataHash: A SHA-256 hash of the client data (which includes the challenge, origin, etc.).

Verification Steps

1. CBOR Decoding & Syntax Check:

• The Relying Party server first decodes the attStmt using CBOR (Concise Binary Object Representation).
• It checks that the decoded structure matches the expected syntax for the “packed” format (as defined in the WebAuthn spec).

1. Two Scenarios: x5c Presence

• Scenario 1: x5c is present: This indicates the use of either Basic Attestation or Attestation CA (AttCA)
  • Signature Validation:
    • The server extracts the alg (algorithm identifier) and sig (signature) fields from attStmt.
    • The server also extracts the attestnCert (attestation certificate) from the x5c array.
    • It verifies that the sig is a valid signature over the combined authenticatorData and clientDataHash data. This signature must be made using the public key found in attestnCert and the algorithm specified by alg.
  • Certificate Checks:
    • The server verifies that the attestnCert meets the specific requirements for “packed” attestation certificates outlined in the WebAuthn spec (like subject fields, extensions, etc.).
    • It checks if the certificate has an AAGUID (Authenticator Attestation GUID) extension and that it matches the AAGUID in the authenticatorData.
  • Attestation Type (Optional): The server may examine the certificate chain in x5c and consult external sources (like the FIDO Metadata Service) to figure out if the attestation type is Basic or AttCA.
• Scenario 2: x5c is not present: This means Self Attestation is being used.
  • Algorithm Match: The server makes sure the alg in attStmt is the same as the algorithm used for the credentialPublicKey within authenticatorData.
  • Self-Signature Check: The server verifies that the sig is a valid signature over the combined authenticatorData and clientDataHash. This time, the signature must have been created using the credentialPublicKey itself (since it’s self-attestation) and the algorithm from alg.

1. Trustworthiness Assessment:

• No Attestation: If no attestation was provided (fmt is “none”), the Relying Party checks if its policy allows for this.
• Self Attestation: If Self Attestation was used, the Relying Party checks its policy to see if this level of trust is acceptable.
• Basic/AttCA (with certificates): The server uses the certificate chain (x5c) to:
  • Verify that the attestation public key (from the top certificate) ultimately links back to a trusted root certificate the Relying Party recognizes.
  • OR, verify that the attestation public key itself is one the Relying Party directly trusts.

Outcome

• Success: If all the above steps are successful, the Relying Party deems the attestation trustworthy, and the registration process can continue.
• Failure: If any check fails, the Relying Party should consider the attestation invalid, and it’s typical to reject the registration.

In essence, the “packed” attestation verification procedure involves:

• Decoding and syntax validation.
• Signature validation against either an attestation certificate or the credential public key.
• Checking certificate requirements and optionally determining the attestation type.
• Assessing trustworthiness based on the certificate chain (or lack thereof).

Question: What certificate requirements must be met for the “packed” attestation statement format?

The “packed” attestation statement format, defined in the WebAuthn specification, mandates certain requirements for the attestation certificate. These are designed to provide assurance about the authenticator’s origin and prevent certain attacks. Here’s a breakdown of the certificate requirements:

Required Fields/Extensions:

1. Version: The certificate version MUST be set to 3 (indicated by an ASN.1 INTEGER with the value 2). This signifies that it’s an X.509 v3 certificate, allowing for extensions.
2. Subject Field: This field MUST include the following information:
   • Subject-C: The ISO 3166 code representing the country where the authenticator vendor is incorporated. It’s encoded as a PrintableString.
   • Subject-O: The legal name of the authenticator vendor, encoded as a UTF8String.
   • Subject-OU: The literal string “Authenticator Attestation”, encoded as a UTF8String.
   • Subject-CN: A UTF8String chosen by the vendor, typically reflecting the authenticator model or a similar identifier.
3. AAGUID Extension (Optional): If the root certificate associated with this attestation is used for multiple authenticator models, the certificate MUST include the AAGUID extension. This extension, identified by the OID 1.3.6.1.4.1.45724.1.1.4 (id-fido-gen-ce-aaguid), contains the AAGUID as a 16-byte OCTET STRING. The extension MUST NOT be marked as critical.
   • Encoding Note: The AAGUID is nested within two OCTET STRINGs to comply with X.509 Extension encoding rules.
4. Basic Constraints: This extension MUST be present with the CA component set to false. This indicates that the certificate is not a CA certificate and cannot be used to issue other certificates.

Optional Fields/Extensions:

• Authority Information Access (AIA): This extension, with an entry for id-ad-ocsp, is OPTIONAL. It provides information about how to access the Online Certificate Status Protocol (OCSP) responder for the certificate.
• CRL Distribution Point: This extension, providing information about how to access the Certificate Revocation List (CRL), is also OPTIONAL.

Rationale for Optional Fields:

The AIA and CRL Distribution Point extensions are optional because many attestation certificates are validated using external metadata services. Services like the FIDO Metadata Service often provide up-to-date certificate status information, negating the need for these extensions in some cases.

Importance of Verification:

Relying Parties MUST carefully verify these fields and extensions to establish trust in the attestation statement. Correct verification ensures that the credential originated from a genuine authenticator from a trusted vendor, enhancing the overall security of the authentication process.

Question: What are the key characteristics of the “tpm” attestation statement format?

The “tpm” attestation statement format is specifically designed for authenticators that utilize a Trusted Platform Module (TPM) as their underlying cryptographic engine. Let’s delve into its key characteristics:

1. Attestation Type:

• AttCA (Attestation CA): The “tpm” format exclusively supports the Attestation CA type. This means that the attestation process involves a trusted third party, the Attestation CA, which issues certificates for the authenticator’s attestation identity keys (AIKs).

2. Syntax:

• Structured CBOR Map: The statement follows a structured format expressed as a CBOR map. Here’s a breakdown of the essential fields:
  • ver: Specifies the version of the TPM specification being adhered to (e.g., “2.0”).
  • alg: Contains a COSEAlgorithmIdentifier indicating the algorithm used for generating the attestation signature.
  • x5c: An array holding the AIK certificate (aikCert) and its certificate chain (caCert), all encoded in X.509 format.
  • sig: The attestation signature itself, encoded as a TPMT_SIGNATURE structure as defined in the TPM specification.
  • certInfo: A TPMS_ATTEST structure containing data over which the signature was computed.
  • pubArea: A TPMT_PUBLIC structure representing the public key of the credential being attested.

3. Signing Procedure:

1. Concatenation: The authenticator data and the hash of the serialized client data are combined.
2. TPM Signature Generation: The TPM uses its attestation private key to create a signature over the concatenated data following a specific procedure outlined in the TPM specification.
3. Populating Fields: The pubArea, certInfo, and sig fields within the attestation statement are populated with the respective outputs from the signature generation process.

4. Verification Procedure:

1. CBOR and Structural Checks: The Relying Party ensures the statement is valid CBOR, conforms to the defined syntax, and extracts the fields.
2. Public Key Matching: The public key from the pubArea field is compared against the credentialPublicKey within the authenticator data to confirm they are identical.
3. certInfo Validation: The certInfo structure is meticulously checked for correctness and validity of its internal fields.
4. AIK Certificate (aikCert) Validation:

• Presence is verified.
• Signature over certInfo is checked for validity using the public key from aikCert.
• The certificate is examined for compliance with requirements outlined in the specification.
• The optional AAGUID extension is compared against the AAGUID in the authenticator data if present.

1. Result: If all verifications are successful, the Relying Party determines the attestation type as AttCA and uses the x5c array as the attestation trust path.

In essence, the “tpm” format leverages the inherent security features of the TPM to provide a robust and verifiable attestation mechanism. The involvement of the Attestation CA, the structured format, and the rigorous verification process contribute to its trustworthiness.

Question: Describe the syntax and signing procedure for the “tpm” attestation statement format.

The “tpm” attestation statement format is used by authenticators that employ a Trusted Platform Module (TPM) as their cryptographic engine. It provides cryptographic proof of the credential’s origin and properties, linking it to the specific TPM.

Syntax

The syntax of a “tpm” attestation statement is defined using the Concise Data Definition Language (CDDL) as follows:

$$attStmtType // = (
    fmt: "tpm",
    attStmt: tpmStmtFormat
)

tpmStmtFormat = {
    ver: "2.0",
    (
        alg: COSEAlgorithmIdentifier,
        x5c: [ aikCert: bytes, * (caCert: bytes) ]
    )
    sig: bytes,
    certInfo: bytes,
    pubArea: bytes
}

Fields:

• ver: A string indicating the version of the TPM specification used. Currently, only “2.0” is defined.
• alg: A COSEAlgorithmIdentifier containing the identifier of the algorithm used to generate the attestation signature.
• x5c: An array of byte strings containing the Attestation Identity Key (AIK) certificate (aikCert) followed by its certificate chain (caCert), each encoded in X.509 format.
• sig: A byte string containing the attestation signature in the form of a TPMT_SIGNATURE structure as specified in [TPMv2-Part2] section 11.3.4.
• certInfo: A byte string containing the TPMS_ATTEST structure over which the sig was computed, as specified in [TPMv2-Part2] section 10.12.8.
• pubArea: A byte string containing the TPMT_PUBLIC structure (see [TPMv2-Part2] section 12.2.4) used by the TPM to represent the credential public key.

Signing Procedure

1. Concatenate Data: Concatenate the authenticatorData and clientDataHash to form the attToBeSigned data.
2. Generate Signature: Generate a signature using the procedure specified in [TPMv2-Part3] Section 18.2:
   • Use the TPM’s attestation private key.
   • Set the extraData parameter to the digest of attToBeSigned using the hash algorithm corresponding to the alg signature algorithm (e.g., SHA-256 for “RS256”).
3. Populate Statement: Set the following fields in the tpmStmtFormat:
   • pubArea: The public area of the credential public key.
   • certInfo: The certInfo output parameter from the signature generation procedure.
   • sig: The signature obtained from the signature generation procedure.

In Summary:

The “tpm” attestation statement format leverages TPM-specific structures and procedures to generate a signature over the authenticator data and client data hash. The AIK certificate and its chain provide a trust path to verify the authenticity of the attestation.

Question: Explain the verification procedure for the “tpm” attestation statement format.

The “tpm” attestation statement format is used by authenticators that employ a Trusted Platform Module (TPM) as their cryptographic engine. The verification procedure for this format is designed to ensure the authenticity and integrity of the attestation statement.

Here’s a breakdown of the TPM attestation statement verification procedure, as detailed in section 8.3 of the WebAuthn spec:

1. Data Decoding and Structure Validation:

• CBOR Decoding: The process begins by verifying that the provided attStmt (attestation statement) is a valid CBOR (Concise Binary Object Representation) structure that conforms to the defined syntax for the “tpm” format. If valid, CBOR decoding is performed to extract the fields contained within attStmt: ver, alg, x5c, sig, certInfo, and pubArea.
• Public Key Matching: The public key, as defined by the parameters and unique fields within the pubArea (TPM’s representation of the credential public key), must match the credentialPublicKey present in the attestedCredentialData section of authenticatorData. This confirms that the attested key is the same as the one being registered.

2. certInfo Validation:

• The certInfo (TPMS_ATTEST structure) field contains metadata about the attestation process. This structure is validated as follows:
  • magic: This field MUST be set to TPM_GENERATED_VALUE, confirming that the structure was indeed generated by a TPM.
  • type: This field MUST be set to TPM_ST_ATTEST_CERTIFY, indicating the specific type of attestation being performed.
  • extraData: This field MUST be set to the hash of the concatenated authenticatorData and clientDataHash, using the hash algorithm specified in the alg field. This ensures the integrity of the data being attested.
  • attested: This field MUST contain a TPMS_CERTIFY_INFO structure. This structure, in turn, MUST have a name field containing a valid Name derived from pubArea. The Name is computed using the nameAlg from pubArea and a procedure defined in the TPM specification.

3. Signature Verification and Certificate Chain Validation:

• x5c Presence: The x5c field, containing the AIK (Attestation Identity Key) certificate and its certificate chain, MUST be present.
• Signature Validation: The signature (sig) provided in attStmt is verified using the attestation public key found in the aikCert (AIK certificate) and the algorithm specified by alg. This step ensures that the certInfo was indeed signed by the authenticator’s AIK.
• AIK Certificate Requirements: The aikCert itself is checked to ensure it adheres to specific requirements outlined in the WebAuthn specification (Section 8.3.1), such as having the correct version, Subject Alternative Name, Extended Key Usage, and Basic Constraints.
• AAGUID Matching: If the aikCert includes an extension with the OID 1.3.6.1.4.1.45724.1.1.4 (id-fido-gen-ce-aaguid), the value of this extension (the AAGUID) MUST match the aaguid found in authenticatorData. This confirms that the attestation certificate is linked to the specific authenticator model.

4. Attestation Type and Trust Path:

• If all the above verification steps are successful, the verification procedure concludes that the “tpm” attestation statement is valid. The procedure returns:
  • Attestation Type: An implementation-specific value representing the AttCA (Attestation CA) attestation type.
  • Attestation Trust Path: The x5c array, containing the AIK certificate and its certificate chain.

Note: The WebAuthn Relying Party, after verifying the attestation statement, typically proceeds to establish trust in the attestation by verifying that the AIK certificate chains up to a trusted root certificate. This final trust validation step is outside the scope of the “tpm” attestation statement verification procedure.

In summary, the “tpm” attestation statement verification process involves a series of checks to ensure the data is correctly formatted, that the claimed public key matches the attested one, that the certInfo is authentic and its signature valid, and that the AIK certificate is properly formed and trusted. This procedure is crucial for Relying Parties to gain confidence in the authenticity and security properties of a TPM-based authenticator.

Question: What certificate requirements must be met for the “tpm” attestation statement format?

The TPM attestation certificate, formally known as the AIK certificate, used in the “tpm” attestation statement format MUST meet the following requirements:

• Version: MUST be set to 3.
• Subject field: MUST be set to empty.
• Subject Alternative Name extension: MUST be set as defined in [TPMv2-EK-Profile] section 3.2.9.
• 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)”).
• Basic Constraints extension: MUST have the CA component set to false.

The following extensions are optional:

• Authority Information Access (AIA) extension: with entry id-ad-ocsp.
• CRL Distribution Point extension: [RFC5280]

The AIA and CRL extensions are optional because the status of many attestation certificates is available through metadata services, such as the FIDO Metadata Service.

In addition to the above, the WebAuthn specification also recommends the following:

• If the related attestation root certificate is used for multiple authenticator models, the Extension OID 1.3.6.1.4.1.45724.1.1.4 (id-fido-gen-ce-aaguid) MUST be present, containing the AAGUID as a 16-byte OCTET STRING. The extension MUST NOT be marked as critical.

These requirements ensure the authenticity and integrity of the AIK certificate, allowing Relying Parties to establish trust in the attestation statement generated by a TPM-based authenticator.

Question: What are the key characteristics of the “android-key” attestation statement format?

The android-key attestation statement format is used when the authenticator is a platform authenticator on Android devices running “N” or later. It’s based on the Android key attestation system and leverages a component within a secure operating environment to generate the attestation. Here’s a breakdown of its key characteristics:

1. Attestation Type:

• It exclusively supports Basic Attestation, meaning that authenticators of the same model (or batch) will likely share the same attestation key pair.

2. Syntax:

• The attestation statement consists of a series of DER-encoded X.509 certificates.
• It’s structured within a CBOR map with the following fields:
  • alg: A COSEAlgorithmIdentifier indicating the algorithm used for the attestation signature.
  • sig: The actual attestation signature, created using the credential private key.
  • x5c: An array containing the credCert (credential certificate) followed by its certificate chain.

3. Signing Procedure:

• The authenticator requests an Android Key Attestation from the keystore, providing the client data hash as the challenge.
• The signature (sig) is generated by concatenating the authenticator data and client data hash, then signing this with the credential private key.

4. Verification Procedure:

• The Relying Party verifies the signature against the public key from the first certificate in the x5c array.
• It then checks that this public key matches the credentialPublicKey in the authenticator data.
• The attestationChallenge field (within the certificate extension data) is compared with the client data hash for consistency.
• Authorization lists (teeEnforced or the union of teeEnforced and softwareEnforced, depending on the RP’s requirements) are checked to ensure:
  • No allApplications field is present, as WebAuthn credentials must be scoped to an RP ID.
  • The origin field is set to KM_ORIGIN_GENERATED.
  • The purpose field is set to KM_PURPOSE_SIGN.

5. Certificate Requirements:

• The attestation certificate carries extension data identified by the OID 1.3.6.1.4.1.11129.2.1.17.
• This extension data includes authorization lists that enforce the allowed use of the key.

Security Considerations:

• Since the authenticator data originates outside the secure environment, the Relying Party must carefully verify its consistency with the information in the attestation certificate.
• Like Basic Attestation, this method provides weaker anonymity compared to individually-generated certificates.

In summary: The android-key attestation format leverages the Android Keystore system to provide Relying Parties with a degree of assurance about the authenticity of the credential and the platform it was generated on, but with limited privacy due to the shared attestation key pair across devices of the same model.

Question: Describe the syntax and signing procedure for the “android-key” attestation statement format.

The android-key attestation statement format is used for platform authenticators on Android devices running “N” or later that use the Android Keystore system for key generation and attestation.

Here’s a breakdown of the syntax and signing procedure:

Attestation statement format identifier:

• android-key

Attestation types supported:

• Basic

Syntax:

The attestation statement itself is simply a sequence of DER-encoded X.509 certificates. The syntax is expressed in CDDL as:

$$attStmtType //= (
    fmt: "android-key",
    attStmt: androidStmtFormat
)

androidStmtFormat = {
    alg: COSEAlgorithmIdentifier,
    sig: bytes,
    x5c: [ credCert: bytes, * (caCert: bytes) ]
}

Where:

• alg: A COSEAlgorithmIdentifier specifying the algorithm used for the attestation signature.
• sig: A byte string containing the attestation signature.
• x5c: An array of certificates. The first certificate (credCert) is the attestation certificate, directly attesting to the credential public key. Subsequent certificates (caCert) form the certificate chain up to a trusted root.

Signing procedure:

1. Obtain Authenticator Data and Client Data Hash:

• The authenticator obtains the authenticatorData for the attestation.
• The client provides the clientDataHash, which is the SHA-256 hash of the serialized client data.

1. Request Android Key Attestation:

• The authenticator calls the Android Keystore API keyStore.getCertificateChain(myKeyUUID), providing the clientDataHash as the challenge value. This can be done using mechanisms like setAttestationChallenge.
• The API returns a chain of X.509 certificates, which is stored as x5c.

1. Generate Signature:

• The authenticator concatenates authenticatorData and clientDataHash.
• It signs the resulting concatenation using the credential private key.
• The signature is stored in the sig field.

1. Set Algorithm Identifier:

• The alg field is set to the COSEAlgorithmIdentifier corresponding to the signature algorithm used in step 3.

In Summary:

The android-key attestation statement format leverages the Android Keystore system to generate a chain of certificates (x5c) that link the credential public key to a trusted root. A signature (sig) is generated over the authenticator data and client data hash using the credential private key, providing proof of possession and binding the attestation to the specific WebAuthn operation.

References

Web Authentication: An API for accessing Public Key Credentials – Level 3 (w3.org)