WebAuthn FAQs – Part 10

Question: Explain the verification procedure for the “android-key” attestation statement format in webauthn.

The “android-key” attestation statement format is used for platform authenticators on Android devices running “N” or later. It leverages the Android Keystore system to provide attestation. Here’s a breakdown of the verification procedure:

1. Decode and Validate the Attestation Statement:

• CBOR Decoding: The attStmt received is in CBOR format. Verify that it is valid CBOR and conforms to the syntax defined for the “android-key” format. Decode the CBOR to extract the following fields:
  • alg: The COSE Algorithm Identifier used for the attestation signature.
  • sig: The attestation signature in bytes.
  • x5c: An array of X.509 certificates. The first one (credCert) is the attestation certificate, followed by its certificate chain (caCert).

2. Verify the Attestation Signature:

• Signature Validation: Verify that sig is a valid signature over the concatenation of the authenticatorData and clientDataHash. This is done using the public key found in the first certificate (credCert) within the x5c array, and the algorithm specified in alg.

3. Match the Public Key:

• Public Key Consistency: Ensure that the public key found in credCert matches the credentialPublicKey present in the attestedCredentialData section of the authenticatorData. This ensures the certificate and the attested credential data refer to the same key.

4. Verify Attestation Challenge:

• Challenge Verification: The attestationChallenge field within the Android Key Attestation certificate extension data must be identical to the clientDataHash. This verifies that the attestation was specifically generated for this registration ceremony.

5. Authorization List Checks:

• Authorization Scope: The certificate contains two authorization lists: teeEnforced (for keys from a Trusted Execution Environment) and softwareEnforced. Depending on the Relying Party’s policy, you may choose to:
  • Accept only keys from a TEE: Use only the teeEnforced list for the following checks.
  • Accept keys from both TEE and software: Use the union of both lists for the following checks.
• Application Scope: The AuthorizationList.allApplications field MUST NOT be present in either authorization list. This ensures the key is scoped to a specific RP ID, not usable by any application.
• Origin: The AuthorizationList.origin field MUST be equal to KM_ORIGIN_GENERATED, signifying the key was generated within the Keystore.
• Purpose: The AuthorizationList.purpose field MUST be equal to KM_PURPOSE_SIGN, indicating the key’s intended use for signing.

6. Return Attestation Information:

• Attestation Type: If all checks pass, return the attestation type as “Basic”.
• Trust Path: Return the x5c array as the attestation trust path. This allows the Relying Party to verify the certificate chain against its trusted root certificates.

Summary:

The “android-key” attestation verification process ensures that the attestation certificate, signature, and related data are valid and consistent with the registration ceremony and the authenticator’s expected behavior. This provides confidence to the Relying Party about the key’s origin and security characteristics.

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

The “android-key” attestation statement format, used for platform authenticators on Android “N” or later, relies on Android’s key attestation mechanism. The certificate requirements are not directly specified within the WebAuthn spec but rather stem from the Android key attestation implementation.

Here’s a breakdown:

Key Attestation Certificate Extension Data:

• OID: The Android key attestation certificate extension data is identified by the OID 1.3.6.1.4.1.11129.2.1.17.
• Schema: The specific schema for this extension data is detailed in the Android developer documentation. This schema outlines the structure and required fields for the extension data.
• Contents: While the precise fields may evolve with Android versions, you’ll generally find:
  • attestationChallenge: This field MUST be present and match the clientDataHash provided during the registration. This proves that the key was generated specifically for this WebAuthn ceremony.
  • Authorization Lists (softwareEnforced & teeEnforced): These lists define how the key can be used. WebAuthn implementations MUST verify specific values within these lists:
    • allApplications: MUST NOT be present in either list, as WebAuthn keys are scoped to the RP ID.
    • origin: MUST be KM_ORIGIN_GENERATED, showing the key was generated by the device.
    • purpose: MUST be KM_PURPOSE_SIGN, confirming the key’s use for signatures.
  • Other fields: The extension data may contain additional fields relevant to Android key attestation, but these are not explicitly mandated by the WebAuthn specification.

General Certificate Properties:

• The certificate chain (x5c) MUST include the key attestation certificate (credCert) as the first element.
• The public key in credCert MUST match the credentialPublicKey within the attested credential data of the authenticatorData.

Important Notes:

• Android Documentation: The definitive source for the latest requirements is the Android developer documentation on key attestation.
• WebAuthn Spec Focus: The WebAuthn spec primarily focuses on the verification procedure, ensuring the client correctly validates the data provided in the Android key attestation certificate.
• Reliance on Android: The security of this attestation format hinges on the robustness of Android’s key attestation implementation and the integrity of the Android device itself.

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

The android-safetynet attestation statement format is designed for platform authenticators on specific Android platforms, leveraging Google’s SafetyNet API. Here’s a breakdown of its key characteristics:

1. Reliance on SafetyNet API:

• This format relies on the Android SafetyNet API for generating attestation statements.
• The SafetyNet API provides information about the integrity of the Android device and the legitimacy of the calling application.

2. Authenticator Data Control:

• Unlike other formats where the authenticator largely controls the authenticator data, in this format, the caller of the SafetyNet API (usually an app) has full control over it.
• This means the authenticator itself isn’t directly involved in shaping the data that’s being attested.

3. Statement Content:

• The SafetyNet attestation statement focuses on the health and trustworthiness of the Android platform:
  • Platform Integrity: Asserts that the device hasn’t been tampered with (e.g., rooted).
  • Application Identity: Verifies the authenticity of the app requesting the attestation.
• It doesn’t provide detailed information about the authenticator hardware itself.

4. Attestation Type:

• It’s categorized as Basic Attestation. This implies:
  • Attestation keys aren’t unique to individual devices.
  • Multiple devices might share the same attestation certificate, offering a degree of user anonymity.

5. Syntax:

• The statement includes two primary fields:
  • ver: The version of Google Play Services running on the device.
  • response: A JWS (JSON Web Signature) object containing the SafetyNet API’s response in a compact serialized format.

6. Verification:

• Relying Parties verify the attestation statement by:
  • Checking the validity of the SafetyNet response using Google’s provided methods.
  • Validating that the nonce within the response matches a hash of the authenticator data and client data, ensuring integrity.
  • Confirming that the response originated from Google’s SafetyNet service.

Limitations:

• Reliance on Google: This format is tightly coupled with Google’s SafetyNet API, making Relying Parties dependent on Google’s services for verification.
• Limited Hardware Information: It doesn’t provide strong assertions about the specific security characteristics of the authenticator hardware.

In essence, the android-safetynet format provides a basic level of trust by confirming the overall integrity of the Android environment and the app involved in WebAuthn operations. It’s less about guaranteeing specific hardware security properties and more about assuring a generally safe platform.

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

Let’s break down the “android-safetynet” attestation statement format as defined in the WebAuthn spec.

Attestation Statement Format Identifier:

• android-safetynet

Attestation Types Supported:

• Basic (This means it’s a relatively simple attestation that doesn’t provide strong, individual device identification.)

Syntax:

The attestation statement follows this structure:

$$attStmtType //= (
    fmt: "android-safetynet",
    attStmt: safetynetStmtFormat
)

safetynetStmtFormat = {
    ver: text,
    response: bytes
}

Field Explanations:

• ver: A text string representing the version number of Google Play Services responsible for the SafetyNet API on the device.
• response: A byte string containing the UTF-8 encoded result from the SafetyNet API’s getJwsResult() call. It’s a JSON Web Signature (JWS) object in compact serialization format. Essentially, it’s a digitally signed statement from Google’s SafetyNet service.

Signing Procedure:

1. Data Preparation:

• Concatenate the authenticatorData (produced by the authenticator) and clientDataHash (calculated by the browser).
• Calculate the SHA-256 hash of this combined data. This hash is called attToBeSigned.

1. SafetyNet Request:

• The Android device makes a request to the SafetyNet API, including attToBeSigned as the nonce value.
• Google’s SafetyNet service processes the request, assessing the device’s integrity.

1. Response Assembly:

• The SafetyNet API returns a JWS response containing:
  • Information about the device’s integrity (e.g., whether it’s rooted or tampered with).
  • The provided nonce (attToBeSigned) to ensure the response is for this specific request.
• The response field in the attestation statement is set to this JWS object.
• The ver field is set to the version of Google Play Services.

In Summary

The “android-safetynet” attestation relies on Google’s SafetyNet service to provide an assessment of the Android device’s trustworthiness. The attestation signature, embedded within the JWS response, allows the Relying Party to verify that the response originated from SafetyNet and that the data hasn’t been tampered with. However, it’s important to remember that SafetyNet attestation doesn’t guarantee strong device identification. It’s more about a general indication of the platform’s integrity.

Question: Explain the verification procedure for the “android-safetynet” attestation statement format.

The “android-safetynet” attestation statement format is a way for platform authenticators on certain Android platforms to provide attestation based on the SafetyNet API. Here’s a breakdown of the verification procedure, based on the WebAuthn spec:

Context:

• This procedure is executed by the WebAuthn Relying Party during registration (navigator.credentials.create()) if the authenticator returns an attestation statement with fmt set to “android-safetynet”.
• The Relying Party has received an attStmt (attestation statement) that needs to be verified.
• The Relying Party has the authData (authenticator data) and clientDataHash (SHA-256 hash of the client data) used during the ceremony.

Verification Steps:

1. Validate CBOR and Decode:

• Check that attStmt is correctly formatted CBOR data according to the defined syntax for “android-safetynet”.
• Decode the CBOR data to extract the ver (version of Google Play Services) and response (SafetyNet API response).

1. Verify SafetyNet Response:

• Use the response value, which is the result of the SafetyNet API’s getJwsResult() call, and the ver value to verify that the response is a valid SafetyNet response. Consult the SafetyNet documentation for the appropriate steps.
• Currently, there’s only one SafetyNet response format, so ver is reserved for future use.

1. Verify Nonce:

• The SafetyNet payload should contain a nonce attribute.
• Concatenate authData and clientDataHash.
• Calculate the SHA-256 hash of this concatenated value.
• Base64-encode the hash result.
• Verify that this Base64-encoded hash matches the nonce in the SafetyNet response. This confirms the response is tied to this specific WebAuthn operation.

1. Validate SafetyNet Service Origin:

• Follow the steps provided in the SafetyNet documentation to ensure the response truly originated from the Google SafetyNet service. This helps prevent spoofed responses.

1. Success or Failure:

• Success: If all the above steps pass, the Relying Party has a verified “android-safetynet” attestation. The Relying Party can decide what trust level to associate with this based on its policies.
• Failure: If any step fails, the attestation is invalid, and the Relying Party should reject the registration.

Important Points:

• Reliance on SafetyNet: The trust in this attestation method hinges on the security of the SafetyNet API and Google’s ability to provide accurate assessments of the Android device’s integrity.
• Limited Information: Unlike other attestation formats, “android-safetynet” primarily offers information about the platform’s health and the calling app, not specific details about the authenticator hardware.
• Relying Party Policy: The Relying Party must define its policies for accepting or rejecting different attestation types based on its security requirements and the level of trust it places in SafetyNet.

In summary, the “android-safetynet” attestation verification procedure leverages Google’s SafetyNet API to confirm the integrity of the Android device and the legitimacy of the response. However, the Relying Party ultimately decides how much trust to place in this attestation based on its own policies.

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

The “fido-u2f” attestation statement format is specifically designed for authenticators that use the FIDO U2F protocol, a predecessor to the more advanced FIDO2/WebAuthn standard. Here are its key characteristics:

1. Attestation Types Supported:

• Basic: Indicates that a batch of authenticators share the same attestation certificate. This offers a degree of user privacy as individual devices can’t be easily distinguished.
• AttCA: Though less common with U2F, it implies an attestation process involving an Attestation CA that issues individual certificates for each authenticator.

2. Syntax:

The “fido-u2f” attestation statement is structured as a CBOR map with two fields:

• x5c: A single-element array containing the attestation certificate in X.509 format. This certificate represents the public key of the authenticator.
• sig: The attestation signature. This signature is generated using the authenticator’s private key and covers the entire (raw) U2F registration response message as defined in the FIDO U2F specifications.

3. Signing Procedure:

• The signature algorithm must be ES256 (Elliptic Curve Digital Signature Algorithm using the P-256 curve and SHA-256).
• The authenticator constructs a U2F Registration Response message as specified in the FIDO U2F specifications. This message includes:
  • Application Parameter: SHA-256 hash of the Relying Party ID the credential is scoped to.
  • Challenge Parameter: The hash of the serialized client data provided by the client.
  • Key Handle Parameter: The credential ID of the newly generated credential.
• The authenticator signs this message with its attestation private key, and the signature is included in the sig field of the attestation statement.
• The attestation certificate for the authenticator is placed in the x5c field.

4. Verification Procedure:

• The Relying Party decodes the CBOR-encoded attestation statement.
• It extracts the attestation certificate (attCert) from the x5c array.
• It verifies that the attCert contains an EC public key using the P-256 curve.
• It retrieves the claimed rpIdHash, credentialId, and credentialPublicKey from the authenticatorData.
• The credentialPublicKey (in COSE_Key format) is converted to the Raw ANSI X9.62 format as used in U2F.
• A verificationData byte string is constructed by concatenating specific elements as defined in the U2F specifications.
• The Relying Party verifies the sig using the verificationData and the public key from attCert, using the ECDSA verification algorithm with SHA-256.
• The Relying Party may optionally inspect the certificate chain and determine whether the attestation is Basic or AttCA based on its knowledge of U2F authenticators and their certificates.

Key Points:

• “fido-u2f” attestation is designed for backward compatibility with older FIDO U2F authenticators.
• The format is relatively simple, reflecting the less sophisticated nature of U2F compared to WebAuthn.
• While “fido-u2f” can convey Basic or AttCA attestation types, Basic is far more common, reflecting the design of most U2F devices.
• This attestation format is expected to be phased out gradually as FIDO2/WebAuthn becomes the dominant standard for web authentication.

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

Let’s break down the “fido-u2f” attestation statement format as defined in the WebAuthn spec.

Attestation Statement Format Identifier:

• fido-u2f

Attestation Types Supported:

• Basic: Indicates that authenticators of the same model likely share the same attestation key.
• AttCA: Indicates that the attestation key is bound to a specific authenticator, often managed by a third-party Attestation CA.

Syntax:

The “fido-u2f” attestation statement is encoded as a CBOR map with the following structure:

$$attStmtType //= (
    fmt: "fido-u2f",
    attStmt: u2fStmtFormat
)

u2fStmtFormat = {
    x5c: [ attestnCert: bytes ],
    sig: bytes
}

Fields:

• x5c: An array containing a single X.509 certificate, which is the attestation certificate (attestnCert).
• sig: The attestation signature. This signature is computed over the entire (raw) U2F registration response message as defined in the FIDO U2F specifications.

Signing Procedure:

1. Algorithm Check: Ensure that the credential public key associated with the attestation is using the ES256 algorithm (COSEAlgorithmIdentifier -7). If it’s not, stop and return an error.
2. Data Preparation:

• authenticatorData: This is the byte array containing the authenticator data for the attestation.
• clientDataHash: This is the 32-byte SHA-256 hash of the client data JSON.

1. Construct U2F Registration Response:

• Create a U2F Registration Response Message according to the FIDO U2F specifications ([FIDO-U2F-Message-Formats] Section 4.3).
• Set the following parameters within the response:
  • application parameter: SHA-256 hash of the RP ID the credential is scoped to.
  • challenge parameter: clientDataHash.
  • key handle parameter: The credential ID of the new credential.

1. Extract Signature and Certificate:

• sig: Take the raw signature portion from the U2F Registration Response. This excludes the user public key, key handle, and attestation certificates.
• x5c: Extract the attestation certificates associated with the attestation public key.

Important Notes:

• Compatibility: This format ensures compatibility with existing FIDO U2F authenticators.
• Verification: Relying Parties use the x5c certificate to verify the sig attestation signature. They also need to validate the certificate chain and ensure it’s trusted.

In essence, the “fido-u2f” attestation statement format leverages the existing U2F registration response message format for attestation. This allows WebAuthn to work seamlessly with older U2F devices while offering a more modern and flexible approach to web authentication.

Question: Explain the verification procedure for the “fido-u2f” attestation statement format.

The fido-u2f attestation statement format is used for authenticators that adhere to the FIDO U2F standard. Here’s a breakdown of the verification procedure for this format:

Inputs

The verification procedure for the “fido-u2f” attestation statement format takes the following inputs:

• attStmt: The attestation statement structure itself, decoded from the CBOR attestation object.
• authenticatorData: The authenticator data claimed to have been used during the attestation process.
• clientDataHash: The SHA-256 hash of the client data, representing the context of the request.

Steps

1. CBOR Decoding and Validation:

• Ensure attStmt is valid CBOR data conforming to the defined syntax for the fido-u2f format.
• Decode attStmt to extract the x5c (certificate chain) and sig (signature) fields.

1. Certificate Chain Validation:

• Check that x5c contains exactly one certificate (attCert).
• Extract the public key (certificate public key) from attCert.
• Verify that certificate public key is an Elliptic Curve (EC) public key over the P-256 curve. If not, return an error.

1. Data Extraction:

• Extract the rpIdHash (Relying Party ID hash) from authenticatorData.
• Extract the credentialId (credential ID) and credentialPublicKey (credential public key) from the attestedCredentialData section within authenticatorData.

1. Credential Public Key Conversion:

• Convert the credentialPublicKey from its COSE_KEY format to the Raw ANSI X9.62 public key format (specified in the FIDO Registry). This involves extracting the x and y coordinates from the COSE_KEY and concatenating them with a prefix.

1. Verification Data Construction:

• Construct the verificationData byte string by concatenating the following elements:
  • 0x00 (a single zero byte)
  • rpIdHash
  • clientDataHash
  • credentialId
  • publicKeyU2F (the converted credential public key)

1. Signature Verification:

• Verify the sig (attestation signature) using the verificationData and the certificate public key. The verification is performed according to section 4.1.4 of the SEC1 standard, using SHA-256 as the hash function.

1. Attestation Type Determination (Optional):

• Examine the x5c (attestation certificate) and consult external sources (e.g., the FIDO Metadata Service) to determine if the attStmt conveys a Basic or AttCA attestation.

1. Result:

• If all verification steps are successful, return implementation-specific values indicating:
  • The determined attestation type (Basic, AttCA, or uncertain).
  • The attestation trust path, which is the x5c array in this case.

Explanation

The procedure ensures that:

• The attestation statement is well-formed and correctly encoded.
• The attestation certificate is appropriate for FIDO U2F, containing an EC public key over the P-256 curve.
• The signature over the attestation data and client data hash is valid, using the public key from the attestation certificate.
• The data used for the signature includes the expected RP ID, client data hash, credential ID, and credential public key.

This verification process is crucial for the Relying Party to establish trust in the authenticity of the authenticator and the integrity of the credential.

Question: What is the purpose and functionality of the “none” attestation statement format?

The “none” attestation statement format in WebAuthn serves a crucial role in balancing security and privacy during credential registration. It’s primarily used in the following scenarios:

1. When the Relying Party doesn’t require attestation:

• Some Relying Parties might choose to forgo attestation for various reasons:
  • User consent: Attestation data may contain device-specific information, and obtaining user consent to share such information might be cumbersome or unnecessary for the Relying Party’s security model.
  • Reduced complexity: Handling and verifying attestation statements adds complexity to the Relying Party’s server-side logic. Opting for “none” simplifies the process.
  • Performance: Fetching and validating attestation data can add latency to the registration process.
• In such cases, the Relying Party signals its disinterest in attestation by setting the attestation option in PublicKeyCredentialCreationOptions to “none”.

2. When the authenticator doesn’t support attestation:

• Some authenticators, particularly those with limited resources or those prioritizing user privacy, might not have the capability to generate attestation statements.

Functionality:

When “none” is selected:

• Client behavior: If the authenticator generates an attestation statement (other than self attestation), the client will replace it with a “None” attestation statement. This ensures the Relying Party receives a consistent response even if the authenticator initially provided a different statement.
• “None” attestation statement: This statement is essentially an empty CBOR map, conveying no information about the authenticator or the credential.
• Verification: Verifying a “None” attestation statement is trivial. The Relying Party simply checks for the presence of the “none” format identifier and an empty attestation statement.

Security and Privacy implications:

• Reduced security: Using “none” means the Relying Party receives no cryptographic proof about the authenticator’s make and model or its security posture. This might be acceptable for Relying Parties prioritizing simplicity or user privacy over strong authenticator assurances.
• Enhanced privacy: “None” attestation provides the strongest privacy guarantee, as no identifying information about the authenticator is shared with the Relying Party.

In summary: the “none” attestation statement format provides a lightweight and privacy-focused option for credential registration when full attestation is either unnecessary or unavailable. It’s essential for Relying Parties to carefully consider the trade-off between security and privacy when choosing this option.

Question: Describe the syntax, signing procedure, and verification procedure for the “apple” attestation statement format.

Apple Anonymous Attestation Statement Format (“apple”)

This attestation statement format is used exclusively by Apple for specific Apple devices that support WebAuthn. It leverages an Anonymization CA approach to enhance user privacy.

Attestation statement format identifier: apple

Attestation types supported: AnonCA (Anonymization CA)

Syntax:

$$attStmtType //= (
    fmt: "apple",
    attStmt: appleStmtFormat
)

appleStmtFormat = {
    x5c: [ credCert: bytes, * (caCert: bytes) ]
}

Semantics of the fields:

• x5c: A list containing the credCert (credential public key certificate) followed by its certificate chain (caCert), each encoded in X.509 format.
• credCert: The X.509 certificate containing the credential public key, used for attestation. This certificate includes a unique nonce as a custom extension for live attestation and integrity protection.

Signing Procedure:

1. Concatenate and Hash: Concatenate authenticatorData and clientDataHash to form nonceToHash. Calculate the SHA-256 hash of nonceToHash and store the result as nonce.
2. Generate Certificate with Nonce: Apple’s anonymous attestation CA generates an X.509 certificate (credCert) for the credential public key. This certificate includes the calculated nonce as an extension with OID 1.2.840.113635.100.8.2. This nonce:

• Acts as proof of attestation.
• Ensures the attestation is live (freshly generated).
• Protects the integrity of both authenticatorData and client data.

1. Form x5c: Construct the x5c list with credCert as the first element, followed by its certificate chain.

Verification Procedure:

1. Decode and Extract: Verify that attStmt is valid CBOR adhering to the defined syntax. Decode it to extract the x5c list.
2. Calculate Expected Nonce: Concatenate the received authenticatorData and clientDataHash and compute its SHA-256 hash. This result should be the expected nonce.
3. Verify Nonce in Certificate: Extract the nonce from the extension with OID 1.2.840.113635.100.8.2 in credCert and verify it matches the expected nonce calculated in the previous step.
4. Verify Credential Public Key: Extract the Subject Public Key from credCert and verify that it matches the credentialPublicKey in the attestedCredentialData of the received authenticatorData.
5. Return Results: If all verification steps are successful, return implementation-specific values indicating the attestation type as AnonCA and the attestation trust path as the x5c list.

Key Points:

• Enhanced Privacy: Apple’s anonymous attestation hides identifiable information from Relying Parties, preventing user tracking.
• Live Attestation: The unique nonce in the certificate ensures that the attestation is freshly generated, preventing replay attacks.
• Integrity Protection: The nonce mechanism also protects the integrity of the authenticatorData and clientDataHash.

This attestation format allows Relying Parties to verify the authenticity and freshness of the attestation while preserving the user’s privacy by using an Anonymization CA.

References

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