WebAuthn FAQs – Part 8

Question: Explain the rules for string truncation by authenticators.

The WebAuthn specification lays out rules for string truncation by authenticators, recognizing that these devices often have limited resources. Here’s a breakdown:

Why Truncation Is Necessary

Authenticators may need to store arbitrary strings provided by Relying Parties, like user names or display names. These strings can be long, but authenticators might have limited memory.

Truncation Rules

1. Minimum Length: Each string field in the WebAuthn API has a defined minimum length that authenticators MUST support. They cannot truncate strings below this length.
2. Maximum Truncation: Authenticators MAY truncate strings exceeding the minimum length, but only up to a specific maximum length also defined by the specification.
3. Respecting Boundaries: Truncation SHOULD happen at appropriate boundaries to avoid corrupting the string:

• UTF-8 Sequence Boundaries: Truncation must not leave a partial UTF-8 character sequence, as this could lead to invalid characters.
• Grapheme Cluster Boundaries: Ideally, truncation should occur at grapheme cluster boundaries. These clusters represent user-perceived characters, preventing a truncated character from rendering differently or changing the meaning of the string.

Example

Let’s say an authenticator can store a maximum of 64 bytes for a display name. A Relying Party sends a 70-byte name. The authenticator:

• MUST store at least the first 64 bytes.
• SHOULD truncate at a grapheme cluster boundary within those 64 bytes to avoid displaying a partial or incorrectly rendered character.

User Agent’s Role

WebAuthn Clients (often the browser) are responsible for ensuring that authenticators observe these truncation rules:

• If a client knows that an authenticator truncates incorrectly, it SHOULD perform the truncation itself before sending the string to the authenticator.
• Clients SHOULD truncate at grapheme cluster boundaries.
• Clients SHOULD ensure all strings sent to authenticators are validly encoded UTF-8 and handle cases where truncation has produced invalid encoding.

Importance of Truncation Rules

• Usability: Correct truncation prevents display issues and maintains the intended meaning of the string, improving user experience.
• Security: Adhering to UTF-8 boundaries prevents authenticators from receiving invalid data, potentially causing errors or vulnerabilities.
• Interoperability: Consistent truncation across different authenticators ensures that Relying Parties can expect predictable behavior.

Key Takeaway

Truncation is a necessary compromise in WebAuthn due to authenticators’ resource constraints. The defined rules ensure a balance between preserving string integrity, maintaining usability, and protecting security.

Question: Describe the concept and purpose of attestation in WebAuthn.

Attestation in WebAuthn is a critical mechanism that provides verifiable evidence about the origin and trustworthiness of a WebAuthn authenticator and the data it generates (credential IDs, key pairs, etc.). It’s like a “birth certificate” for your authenticator, assuring the relying party (website or service) that the device is genuine and meets specific security standards.

Think of it like this:

Imagine you’re buying a diamond ring. You want to make sure the diamond is real and of high quality, so you ask for a certificate from a reputable gemological institute. This certificate provides independent verification of the diamond’s origin, carat, cut, clarity, and color. Attestation in WebAuthn works similarly.

Here’s how it works:

1. Attestation Statement: During registration with a website, the authenticator (e.g., security key, built-in biometric sensor) creates an attestation statement. This statement contains information about the authenticator itself, such as its model, manufacturer, and unique identifier (AAGUID). It also includes the public key generated for the website and a signature, proving the authenticator’s possession of the corresponding private key.
2. Attestation Object: The attestation statement is packaged into an attestation object, which also includes authenticator data (e.g., signature counter) and information about the client (e.g., browser, operating system). This object is cryptographically protected to prevent tampering.
3. Attestation Conveyance: The client (browser) sends the attestation object to the relying party, who can choose how to handle it:
   • Direct: The relying party receives the full attestation object and verifies it directly.
   • Indirect: The client first sends the attestation object to an anonymization CA (certificate authority), which replaces identifying information with anonymous data before sending it to the relying party.
   • None: The relying party chooses not to receive attestation information, either for privacy reasons or to simplify the process.
4. Verification & Trust: The relying party verifies the attestation signature using the authenticator’s public key, which is included in a certificate chain within the attestation statement. This chain leads back to a trusted root certificate, allowing the relying party to establish trust in the authenticator and its data.

Purpose of Attestation:

• Assurance of Authenticity: Attestation provides evidence that the credential was generated by a genuine authenticator from a trusted manufacturer, not a malicious device trying to impersonate it.
• Verification of Security: Attestation allows the relying party to assess the security characteristics of the authenticator, such as its key protection mechanisms and certification level. This helps them make informed decisions about the level of trust they place in the credential.
• Risk Management: By understanding the authenticator’s properties, relying parties can better manage their risk exposure. They might, for example, require stronger authentication for high-risk transactions based on the authenticator’s attestation data.

Types of Attestation:

• Basic Attestation: Authenticators in the same batch share the same attestation certificate. This provides some anonymity but limits revocation capabilities.
• Self Attestation: The authenticator uses its own credential key pair to sign the attestation statement. This provides no assurance about the authenticator’s origin or security.
• Attestation CA (AttCA): A trusted third-party CA issues unique attestation certificates for each authenticator. This offers strong security and revocation capabilities.
• Anonymization CA (AnonCA): An anonymization CA replaces identifying information in the attestation statement with anonymous data, balancing privacy and security.
• None: No attestation information is provided.

In conclusion: Attestation is a crucial mechanism for establishing trust in WebAuthn. It enables relying parties to verify the authenticity and security of authenticators, thereby strengthening the overall security of user authentication on the web.

Question: What is the difference between an “attestation statement format” and an “attestation type”?

The WebAuthn specification uses two key concepts related to authenticator attestation: “attestation statement format” and “attestation type”. They address different aspects of how an attestation statement is structured and what it ultimately means for the Relying Party.

Here’s a breakdown of their differences:

Attestation Statement Format

• Syntax: Focuses on the structure and encoding of the attestation statement. It dictates how the signature is represented and how the various pieces of data (like the authenticator data and client data hash) are incorporated into the statement.
• Think of it as: The “language” or “grammar” used to express the attestation. Different formats use different ways to represent the same underlying information.
• Examples: “Packed”, “TPM”, “Android Key”, “Android SafetyNet”, “FIDO U2F”, “None”, “Apple”.

Attestation Type

• Semantics: Deals with the meaning and trust model behind the attestation statement. It defines what kind of trust a Relying Party can place in the statement after verifying its cryptographic validity.
• Think of it as: The “meaning” or “interpretation” of the attestation statement. It tells the Relying Party how much confidence they can have in the authenticator’s claims.
• Examples: “Basic” (or “batch”), “Self”, “Attestation CA” (AttCA), “Anonymization CA” (AnonCA), “None”.

Analogy

Imagine you receive a letter (the attestation statement) written in a foreign language.

• Attestation Statement Format is like the script and grammatical rules of that language. It allows you to understand the structure of the letter, even if you don’t yet understand the meaning.
• Attestation Type is the translation of that letter. It provides you with the actual meaning and content of the letter, enabling you to understand what the sender is trying to communicate.

Key Points

• An attestation statement format doesn’t inherently determine its type. For instance, the “Packed” format can be used with multiple attestation types.
• The attestation type is important for the Relying Party to make trust decisions about the authenticator and the credential it generated.
• The choice of attestation format and type is made by the authenticator, the Relying Party can only express preferences.

In essence, the format tells you how the attestation statement is written, while the type tells you what it means.

Question: What are the different attestation types supported by WebAuthn?

WebAuthn supports several attestation types, each with different trust models and privacy implications. Here’s a breakdown:

1. Basic Attestation (Basic)

• Also known as: Batch Attestation
• Mechanism: Authenticators of the same model (e.g., from the same manufacturing batch) share the same attestation key pair. This means a Relying Party can verify that a credential came from a specific authenticator model, but not identify the individual authenticator.
• Trust Model: Trust is placed in the manufacturer to securely manage the attestation key pair and produce authenticators of a certain quality.
• Privacy: Offers a moderate level of privacy, as individual authenticators cannot be tracked, but devices from the same batch are linkable.

2. Self Attestation (Self)

• Also known as: Surrogate Basic Attestation
• Mechanism: The authenticator uses the credential private key itself to sign the attestation statement. No separate attestation key is involved.
• Trust Model: No inherent trust. This type is usually used by authenticators without robust hardware security measures for storing an attestation key.
• Privacy: Provides the highest level of privacy, as no identifiable information about the authenticator is revealed. However, it offers the lowest level of assurance.

3. Attestation CA (AttCA)

• Mechanism: A trusted third-party Attestation CA (previously called “Privacy CA”) issues individual certificates for each authenticator’s attestation identity key (AIK). The authenticator uses its endorsement key (EK) to securely communicate with the AttCA.
• Trust Model: Trust is placed in the AttCA to verify the authenticator’s identity and issue valid certificates.
• Privacy: Offers a good balance of privacy and security. The EK is kept secret and not revealed to Relying Parties, limiting tracking. Each credential gets a unique AIK certificate.

4. Anonymization CA (AnonCA)

• Mechanism: Similar to AttCA, but the AnonCA issues attestation certificates that intentionally omit uniquely identifying information.
• Trust Model: Trust is placed in the AnonCA to maintain user privacy while still providing a level of assurance about the authenticator.
• Privacy: Provides a high level of privacy, as Relying Parties cannot link credentials based on attestation.

5. No Attestation Statement (None)

• Mechanism: The authenticator provides no attestation information.
• Trust Model: No trust is established. The Relying Party has no cryptographic proof of the authenticator’s properties.
• Privacy: Offers maximum privacy but at the cost of security. Typically used when attestation is not desired or the authenticator lacks attestation capabilities.

Important Notes:

• Relying Parties can specify their preferred attestation types during registration.
• The choice of attestation type is ultimately up to the authenticator.
• Relying Parties need to assess the trustworthiness of attestation statements based on their policy and knowledge of authenticator models and attestation CAs.

Question: Explain the process of generating an attestation object.

The process of generating an attestation object is a crucial part of the WebAuthn registration ceremony. It provides a mechanism for authenticators to cryptographically attest to the origin and integrity of a newly created public key credential. Here’s a detailed breakdown of the process, drawing upon the provided WebAuthn Level 3 specification:

1. Gather Necessary Inputs

• attestationFormat: This is the identifier string representing the specific attestation statement format to be used. Examples include:
  – “packed”: A compact, WebAuthn optimized format.
  – “tpm”: A format commonly used by authenticators that utilize a Trusted Platform Module (TPM).
  – “android-key”: A format used by Android platform authenticators.
  – “fido-u2f”: A format used by FIDO U2F authenticators.
• authData: This is a byte array containing the authenticator data. This includes vital information such as the authenticator’s AAGUID, the credential ID, the credential public key, signature counter, flags indicating user presence and verification, and any applicable extensions.
• hash: This is the SHA-256 hash of the serialized client data. The client data encapsulates contextual information about the Relying Party and the user agent, ensuring the signature is bound to the specific context of the registration.

2. Create the Attestation Statement

• attStmt: The authenticator generates the attestation statement (attStmt) by invoking the signing procedure specific to the chosen attestationFormat. This procedure takes authData and hash as inputs. The signing process typically involves signing the concatenation of authData and hash using the attestation private key. The exact details vary depending on the attestation statement format.

3. Assemble the Attestation Object

• The attestation object is structured as a CBOR (Concise Binary Object Representation) map, containing the following keys:
  – fmt: The attestation statement format identifier, which is the same as the attestationFormat input.
  – authData: The authData byte array.
  – attStmt: The generated attestation statement attStmt, encoded according to the rules of the selected attestationFormat.

Simplified Illustrative Example (using “packed” format):

Let’s imagine we are generating an attestation object using the “packed” attestation statement format.

1. We have authData, which contains the authenticator data (AAGUID, credential ID, public key, etc.).
2. We have hash, which is the SHA-256 hash of the client data.
3. The “packed” format dictates that attStmt includes the signature (calculated over authData || hash using the attestation private key), and optionally a certificate chain (x5c).

The resulting attestation object would look like this (in simplified JSON representation for clarity):

{
    "fmt": "packed",
    "authData": "....", // Base64url encoded authData
    "attStmt": {
        "alg": -7,        // ES256 signature algorithm
        "sig": "....",   // Base64url encoded signature
        "x5c": [         // Optional certificate chain
             "-----BEGIN CERTIFICATE-----...", // Base64 encoded certificate 1
             "-----BEGIN CERTIFICATE-----..."  // Base64 encoded certificate 2 (and so on)
        ]
    }
}

Key Points

• Verification: The Relying Party will subsequently verify the attestation object to establish trust in the authenticity of the credential. It will use the specified attestation statement format (fmt) to parse and verify the attestation statement (attStmt).
• Security: The attestation object is cryptographically protected against tampering. The attestation statement is signed, and the certificate chain (if present) allows the Relying Party to verify the signature and trace the attestation back to a trusted root.
• Privacy: Different attestation statement formats and attestation types offer varying levels of privacy. For example, Anonymization CA formats are designed to protect the user’s privacy by avoiding uniquely identifiable information.

In essence, the process of generating an attestation object involves gathering the necessary inputs, creating the attestation statement, and packaging it all into a CBOR map. This object serves as cryptographic evidence for the Relying Party, allowing it to assess the trustworthiness of the newly created credential.

Question: How are attestation signatures generated for the “packed”, “fido-u2f”, and assertion signature formats?

Let’s break down how attestation signatures are generated for the “packed”, “fido-u2f” formats, and also cover how the general assertion signature process works in WebAuthn.

Core Concepts

• Attestation Signature: A cryptographic signature generated during credential registration. It provides proof to the Relying Party about specific properties of the authenticator and the new credential being generated.
• Assertion Signature: A cryptographic signature generated during authentication. It proves to the Relying Party that the user possesses the private key associated with a registered credential.
• Authenticator Data: A data structure containing information about the authenticator and the ceremony (registration or authentication). It includes elements like the RP ID hash, flags indicating user presence and verification, a signature counter, and more.
• Client Data Hash: A SHA-256 hash of the client data, which itself holds details about the Relying Party’s origin, the challenge, and other contextual information.

1. Packed Attestation Signature

The “packed” attestation format is flexible and supports different attestation types:

• Basic/AttCA Attestation:
  1. Data to Sign: The authenticator data (including the attested credential data) and the client data hash are concatenated.
  2. Signing: This concatenated data is signed using the authenticator’s attestation private key.
  3. Output: The signature (sig), the attestation certificate (attestnCert), and its certificate chain (x5c) are packaged into the attestation statement.
• Self Attestation:
  1. Data to Sign: The same as with Basic/AttCA (authenticator data + client data hash).
  2. Signing: This data is signed using the credential private key (not the attestation private key, as there isn’t one in self attestation).
  3. Output: Only the signature (sig) is included; no certificates are provided.

2. FIDO U2F Attestation Signature

FIDO U2F, a legacy format, has a more specific process:

1. Registration Response Message: The authenticator crafts a U2F registration response message containing:
   • Application Parameter: SHA-256 hash of the RP ID.
   • Challenge Parameter: The client data hash.
   • Key Handle Parameter: The credential ID.
   • Public Key: The credential public key (converted to raw ANSI X9.62 format).
2. Signing: The authenticator signs this entire message using its attestation private key.
3. Output: The attestation certificate (x5c) and the signature (sig) are packaged into the attestation statement.

3. Assertion Signatures

1. Data to Sign: The authenticator data (for the assertion, not including attested credential data) and the client data hash are concatenated.
2. Signing: The authenticator signs this concatenated data using the credential private key associated with the user’s chosen credential.
3. Output: The signature (sig) is returned as part of the AuthenticatorAssertionResponse.

Important Notes

• Verification: The Relying Party must verify all these signatures during registration or authentication. The verification process depends on the specific attestation statement format and attestation type being used.
• Security: The Relying Party should take care to generate random, unpredictable challenges. Attestation itself doesn’t prevent man-in-the-middle attacks during registration, so Relying Parties need to use secure communication channels (e.g., TLS) to protect the entire registration process.
• Algorithm: The signature algorithm (alg) used is determined during credential creation and is included in both the attestation and assertion processes. Common algorithms include ES256, RS256, and PS256.

Question: What privacy considerations should authenticators take into account regarding attestation certificates?

The WebAuthn specification highlights two main privacy considerations regarding attestation certificates:

1. Linking User Identities: Attestation certificates, if unique enough, can be used to track users across different websites or online services. Imagine a scenario where every authenticator has a globally unique attestation certificate. A malicious actor could collect these certificates from various websites and potentially link them together, identifying a single user across these sites even if the user employs different usernames or email addresses.

2. Identifying Individual Authenticators: Similarly, unique attestation certificates can be used to identify and track individual authenticators. This can have privacy implications if it reveals sensitive information about the user, such as their location or device usage patterns.

Mitigation Strategies:

The WebAuthn specification recommends several strategies to mitigate these privacy risks:

• Batch Attestation (Basic Attestation): Manufacturers can ship authenticators in batches, with all devices in a batch sharing the same attestation certificate. This effectively anonymizes users within the batch, as their individual authenticators can’t be distinguished. The downside is that if one attestation certificate from a batch is compromised, the entire batch is affected.
  • Batch Size: The batch size needs careful consideration. Large batches provide better anonymity but increase the impact of a compromise. WebAuthn suggests that batches should be large enough to offer meaningful anonymity, ideally at least 100,000 devices, while remaining small enough to limit the fallout from a potential compromise.
• Anonymization CA (AnonCA): Instead of static batching, authenticators can use an Anonymization CA, a trusted third party that dynamically generates per-credential attestation certificates. This approach provides strong anonymity as each credential gets a unique certificate, preventing cross-site tracking or individual authenticator identification.
• Self-Attestation: In this case, the authenticator uses the credential private key to sign the attestation statement. This approach provides no identifiable information to the Relying Party and ensures maximum privacy. However, it also offers the lowest level of assurance, as the Relying Party has no external verification of the authenticator’s properties.

Overall, authenticator manufacturers and developers should strive to strike a balance between privacy and security. The ideal solution will depend on the specific use case and the level of trust required by the Relying Party.

Question: What measures should be taken to protect personally identifying information stored within authenticators?

The WebAuthn specification outlines a number of recommendations for authenticator developers to protect personally identifying information (PII) stored within authenticators. The overarching goal is to prevent an adversary with physical access to an authenticator from extracting PII about the authenticator’s enrolled user(s).

Here are the key measures:

1. Minimize PII Storage

• User Handle is NOT PII: The userHandle, used to identify a user account, is considered opaque and not personally identifying. Relying Parties should not store PII within the userHandle.
• Avoid Other PII: Unless absolutely necessary, authenticators should avoid storing other PII like email addresses, usernames, or even hashes of this information.

2. User Verification as Gatekeeper

• PII Access After Verification: Authenticators SHOULD only expose PII to clients (e.g., to display a rich UI for credential selection) after successful user verification has been performed.
• Isolate Multi-User Data: If the authenticator supports multiple users, it SHOULD NOT expose PII of users other than the one currently verified.
• No Verification, No PII: Authenticators incapable of user verification SHOULD NOT store any PII at all.

Additional Considerations

• Secure Storage: Any PII that must be stored should be protected using robust security mechanisms within the authenticator, such as encryption or storage in a secure element.
• Data Minimization: Only collect and store the minimum amount of PII necessary for the authenticator’s functionality.
• Clear User Consent: If PII is stored, obtain explicit user consent for its collection, storage, and any potential disclosure.

Example

A fingerprint-protected security key might store the user’s display name to present a more user-friendly interface. However, it should only display this name after the user has successfully authenticated with their fingerprint, preventing someone else from seeing it.

Summary

By following these measures, authenticator developers can significantly enhance user privacy and ensure that personally identifying information remains protected even if the authenticator is lost or stolen.

References

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