WebAuthn FAQs – Part 12

Question: How does the “largeBlob” extension address the limitations of authenticator storage capacity?

The “largeBlob” extension in WebAuthn doesn’t directly address the limitations of authenticator storage capacity. Instead, it provides a mechanism for Relying Parties to store and retrieve opaque data associated with a credential, leveraging the Relying Party’s own storage infrastructure. Here’s how it works:

The Problem:

• Limited Authenticator Storage: Authenticators, especially security keys and some platform authenticators, have limited storage. This makes it impractical to store large amounts of data, such as certificates, directly on the authenticator.

The Solution:

• Relying Party Storage: The “largeBlob” extension allows the Relying Party to store the data on their own servers.
• Association with Credential: The data is associated with a specific credential through its credential ID.
• Retrieval During Authentication: When a user authenticates using that credential, the Relying Party can use the “read” option of the “largeBlob” extension to retrieve the associated data.
• Update During Authentication: Similarly, the Relying Party can use the “write” option to update the stored data during an authentication ceremony.

Example Use Case – Certificates:

A Relying Party might want to issue certificates to users instead of managing a centralized authentication service. Since certificates can be quite large, they can’t be stored on the authenticator itself. Here’s how the “largeBlob” extension helps:

1. Registration: During registration, the Relying Party signals its intent to use large blobs. The authenticator doesn’t need to store the certificate at this point.
2. Certificate Issuance: The Relying Party generates the certificate and stores it on its server, associating it with the user’s credential ID.
3. Authentication: When the user authenticates, the Relying Party uses the “read” option of the “largeBlob” extension to retrieve the certificate from its server. It can then use this certificate to verify the user’s identity.

In essence, the “largeBlob” extension allows authenticators to act as a secure pointer to data stored elsewhere. It doesn’t solve the storage capacity problem of authenticators but enables a workaround using the Relying Party’s more extensive storage capabilities.

Question: What are some security and privacy concerns that Relying Parties should be aware of when using the “largeBlob” extension?

The largeBlob extension, while useful, introduces some security and privacy considerations that Relying Parties must address carefully:

Security Concerns:

• Limited Authenticator Storage: Authenticators have limited storage capacity. Relying Parties should be mindful of the size of blobs they write and avoid exceeding the authenticator’s limits. Oversized blobs can lead to errors or even denial-of-service for the user. User agents should implement appropriate warnings and size limits to guide Relying Parties and protect users.
• Data Integrity and Confidentiality: The specification doesn’t explicitly mandate encryption or integrity protection for stored blobs. Relying Parties might need to implement their own mechanisms to ensure the confidentiality and integrity of the data, especially if sensitive information is stored. Consider using encryption and signing techniques before writing the blob to the authenticator.
• Authenticator Compromise: If an authenticator is compromised, the stored blobs might be accessible to an attacker. Sensitive data stored in blobs could be exposed. Employing additional security measures on the Relying Party side, such as encrypting the blob with a key not stored on the authenticator, can mitigate this risk.
• Denial of Service: Malicious Relying Parties could attempt to fill up authenticator storage with large blobs, potentially disrupting the user’s ability to use other credentials. User agents should implement mechanisms to prevent such abuse, like imposing per-origin quotas on blob storage.

Privacy Concerns:

• User Consent and Transparency: Users should be clearly informed about the type and purpose of data being stored via the largeBlob extension. Obtain explicit user consent before writing any potentially sensitive information. Provide clear UI indicators during both writing and reading operations.
• Data Minimization: Only store essential data using the largeBlob extension. Avoid storing unnecessary personally identifiable information or sensitive data that could raise privacy risks if the authenticator is lost or compromised.
• Data Retention and Deletion: Relying Parties should have clear policies on the retention and deletion of data stored in blobs. Provide users with the ability to delete their data, and ensure data is removed from the authenticator when no longer required.
• Correlation and Tracking: While credential IDs are designed to be non-correlatable, the size of the blob associated with a credential could potentially serve as a weak identifier. An attacker might use this information to track users across different Relying Parties. Employing strong data minimization practices and avoiding storing unique identifiers in blobs can help mitigate this risk.

General Recommendations:

• Transparency and Control: Offer users transparency into what data is being stored and how it’s used. Provide them with control over their data, including the ability to delete it.
• Strong Security Practices: Implement robust security measures on both the client and Relying Party sides to protect blob data. This includes encryption, signing, and secure storage practices.
• Responsible Data Retention: Define clear data retention policies and ensure user data is deleted when no longer necessary.
• Stay Updated: Keep abreast of security best practices and vulnerabilities related to the largeBlob extension and its implementations.

By addressing these security and privacy considerations, Relying Parties can ensure responsible and secure usage of the largeBlob extension while protecting user data and privacy.

Question: What is the purpose of the “device continuity” signal provided by the “devicePubKey” extension?

The “device continuity” signal provided by the devicePubKey extension in WebAuthn helps Relying Parties (websites or services) establish a stronger link between a user’s credential and a specific device. This is particularly valuable when dealing with multi-device credentials, also known as passkeys, which can be synced across multiple devices belonging to a user.

Here’s how it works:

1. Device-bound key pair: When the devicePubKey extension is used during registration or authentication, the authenticator generates a unique, hardware-bound device key pair. The private key is securely stored within the authenticator and never leaves the device.
2. Device Public Key and Signature: The authenticator returns the device public key (“dpk”) to the Relying Party. Additionally, it generates a signature using the device private key over authentication data, including the Relying Party’s challenge.
3. Continuity Signal: By consistently using the devicePubKey extension during both registration and subsequent authentications, the Relying Party receives a series of signatures all tied to the same device private key. This sequence of signatures, always originating from the same device, provides the “device continuity” signal.

Purpose:

• Risk Assessment: Relying Parties can use this signal as part of their risk-based authentication systems. For example, if a login request comes from a new location or device, the Relying Party can consider the presence or absence of a familiar device signature in its risk calculations. A consistent device signature may indicate lower risk, while the absence of a familiar signature could raise red flags.
• Account Recovery: During account recovery, the Relying Party can utilize the device signature to validate that the user is attempting recovery from a previously trusted device, adding an additional layer of security.
• User Experience: For multi-device credentials, device continuity signals can help create smoother user experiences. The Relying Party might offer reduced friction (e.g., fewer authentication challenges) for users consistently logging in from known devices.

In essence, the devicePubKey extension adds valuable contextual information about the device being used, empowering Relying Parties to make more informed decisions about authentication and security.

Question: Explain the process of creating and using a hardware-bound device key pair.

Creating and Using a Hardware-Bound Device Key Pair in WebAuthn

The devicePubKey extension in WebAuthn allows Relying Parties to create and use hardware-bound device key pairs, offering a “device continuity” signal for multi-device credentials, useful for risk-based authentication systems. Here’s a breakdown of the process:

1. Credential Creation (Registration):

• Relying Party Request: The Relying Party initiates a registration ceremony using navigator.credentials.create() and includes the devicePubKey extension in the options.extensions parameter.
• Authenticator Action:
  • If the new credential is not backup-eligible (single-device), the extension is ignored.
  • If the credential is backup-eligible (multi-device), the authenticator checks for an existing device key pair associated with this credential’s {Credential ID, RP ID, userHandle} tuple. If none exists, it generates a new hardware-bound device key pair using the same algorithm as the credential key pair.
  • It then creates a device public key attestation object (attObjForDevicePublicKey) containing:
    • The authenticator’s AAGUID.
    • The device public key (dpk).
    • The scope of the key (device-wide or per-app).
    • A random nonce.
    • An attestation statement (optional, based on Relying Party preference).
  • The authenticator also generates a signature (dpkSig) over the assertion signature input (which includes the RP’s challenge) using the device private key.
• Response: The authenticator returns:
  • The attObjForDevicePublicKey within the authenticator extension output.
  • The dpkSig as the unsigned extension output.

2. Assertion Generation (Authentication):

• Relying Party Request: The Relying Party initiates an authentication ceremony using navigator.credentials.get() and includes the devicePubKey extension.
• Authenticator Action:
  • If the requested credential is not backup-eligible, the extension is ignored.
  • If the credential is backup-eligible, the authenticator locates the device key pair associated with this credential.
  • It generates a new dpkSig signature over the assertion signature input.
• Response: The authenticator returns:
  • The same attObjForDevicePublicKey as during registration within the authenticator extension output.
  • The new dpkSig as the unsigned extension output.

3. Relying Party Verification:

• Signature Verification: The Relying Party verifies both the assertion signature (using the credential public key) and the dpkSig signature (using the dpk).
• Attestation Verification (Optional): If requested, the Relying Party verifies the device public key attestation statement.
• Device Recognition:
  • If the dpk and its associated metadata (AAGUID and scope) match a previously registered device-bound key record for this credential, the Relying Party recognizes it as a known device.
  • If not, and the attestation is valid (if requested), the Relying Party recognizes it as a new device and creates a new device-bound key record.

Key Points:

• Hardware Bound: The device private key is stored securely in hardware and never leaves the device.
• Credential Specific: The device key pair is tied to a specific user credential, not the device itself, preventing cross-credential linking.
• Device Continuity Signal: The consistent presence of a valid dpkSig from the same dpk across multiple authentication ceremonies allows the Relying Party to infer continuous usage from the same device.
• Risk Assessment: This signal, along with other contextual information, can be used by the Relying Party’s risk engine to make informed authentication decisions.

In essence, the devicePubKey extension provides a mechanism to cryptographically tie a user credential to a specific device without revealing globally identifiable device information. This enables the Relying Party to track device usage for a given credential, adding a valuable layer of security to multi-device credential authentication.

Question: How does the “devicePubKey” extension handle different attestation conveyance preferences?

The devicePubKey extension in WebAuthn handles different attestation conveyance preferences during its authenticator extension processing, as outlined in section 10.2.2.2 of the WebAuthn Level 3 specification. Here’s a breakdown of how the authenticator processes these preferences, focusing on the attestation input parameter:

1. “none”:

• Behavior: The authenticator chooses between “none” and “self” attestation at its own discretion. It sets the aaguid field to 16 zero bytes, effectively anonymizing the authenticator’s identity.
• Rationale: For “none” preference, no attestation information is provided, simplifying the process. For “self” attestation, the device private key signs its own public key. This is considered redundant for devicePubKey as possession of the device private key is already proven during authentication. Anonymization is prioritized, preventing device tracking.

2. “indirect” and “direct”:

• Behavior: The authenticator selects an appropriate attestation statement format based on the provided attestationFormats input. The aaguid field is set to the authenticator’s actual AAGUID.
• Rationale: The Relying Party wants some form of verifiable attestation statement. The specific format is chosen by the authenticator, ideally the most preferred format it supports. Using the actual AAGUID allows the Relying Party to learn the make or model of hardware storing the device-bound key, potentially informing trust decisions.

3. “enterprise”:

• Behavior: The Relying Party desires potentially uniquely identifying information in the attestation statement.
  • If permitted: The authenticator selects a suitable format based on attestationFormats, using its actual AAGUID. The epAtt field in the output is set to true.
  • If not permitted: The authenticator uses “none” attestation and sets the aaguid to 16 zero bytes.
• Rationale: This option is for controlled environments where tying registrations to specific devices is desired. Authenticators are restricted from providing such attestation without explicit permission from the user agent or authenticator configuration. This maintains user privacy in general use cases.

Key Points:

• Attestation Scope: The attestation for devicePubKey specifically relates to the hardware-bound device key pair, not necessarily the user credential itself. This allows for device-specific trust assessments.
• Multi-device Credentials: Attestations for multi-device credentials are likely tied to broader entities, as these credentials are not device-bound. Thus, the devicePubKey attestation and the user credential attestation may have different AAGUIDs and formats.
• Relying Party Policy: Ultimately, the Relying Party determines what level of attestation is acceptable for its security and privacy needs. The devicePubKey extension provides options for flexibility.

By offering different handling mechanisms for attestation conveyance preferences, the devicePubKey extension balances security, privacy, and practicality in diverse scenarios.

Question: What is the purpose of the “random nonce” in the “devicePubKey” extension’s attestation calculations?

The “random nonce” in the “devicePubKey” extension serves a crucial security purpose in the attestation process. Here’s why:

Preventing Replay Attacks and Side-Channel Vulnerabilities

• Signature Randomization: Without the nonce, the data signed for the devicePubKey attestation would remain constant for a specific user credential. This creates two problems:
  • Replay Attacks: An attacker could capture a valid attestation signature and replay it in a different context, potentially impersonating the legitimate user.
  • Side-Channel Attacks: A constant signature value could be susceptible to side-channel attacks, where an attacker analyzes timing or power consumption patterns during signature generation to potentially deduce information about the attestation private key.
• Freshness Assurance: The nonce ensures that each attestation signature is unique and tied to a specific instance of the attestation process. This provides evidence to the Relying Party that the attestation is fresh and not a replayed artifact.

How the Nonce Works

1. Generation: The authenticator generates a fresh, random nonce for each devicePubKey attestation operation. The nonce can have a maximum length of 32 bytes, or it can be a zero-length byte string if the authenticator chooses not to generate a nonce.
2. Inclusion in Attestation Data: The nonce is included along with the Authenticator’s AAGUID and the device public key (dpk) in the data that is signed by the attestation private key.
3. Verification: The Relying Party verifies the attestation signature using the device public key and the nonce. The uniqueness of the nonce prevents replay attacks.

Nonce as a Mitigation, Not a Guarantee

While the nonce significantly enhances security, it’s essential to understand that it’s a mitigation, not an absolute guarantee. A sophisticated attacker might still attempt to circumvent this mechanism through other means. Therefore, Relying Parties should employ a layered security approach that combines the devicePubKey extension with other security measures.

In Summary

The “random nonce” in the devicePubKey extension plays a vital role in:

• Randomizing attestation signatures
• Preventing replay attacks
• Mitigating side-channel vulnerabilities
• Assuring the freshness of attestations

This contributes to the overall security and trustworthiness of the device continuity signal provided by the extension.

Question: How does the scope of a device-bound key affect its usage by Relying Parties?

The scope of a device-bound key (defined in the devicePubKey extension) has a subtle effect on how Relying Parties can use it for device continuity signals. Here’s a breakdown:

Two Scopes:

• Entire Device (scope: 0x00): This key is theoretically shared by all applications (e.g., a browser and a native app) on the same device. In practice, the exact implementation of how different applications access these keys can vary by platform.
• Per-App (scope: 0x01): This key is specific to the application that requested its creation. A browser and a native app on the same device would likely have different “per-app” device-bound keys, even for the same user credential.

How Scope Affects Relying Parties:

1. Continuity Assessment:

• Entire Device: Relying Parties can use this key to assess continuity across different applications. If a user authenticates with their browser, and later authenticates with a native app using the same credential, the same device-bound key signature would indicate it’s likely the same device.
• Per-App: Relying Parties can only assess continuity within the same application. A signature in the browser wouldn’t necessarily mean the same device is being used when a native app authenticates.

1. Risk Evaluation:

• Entire Device: The continuity signal is stronger as it spans multiple applications, potentially reducing risk scores for subsequent authentications across the Relying Party’s ecosystem.
• Per-App: The continuity signal is weaker, as it’s limited to a single application. Relying Parties might assign higher risk to authentications coming from different applications on the same device, even if the same credential is used.

Important Considerations:

• Implementation Variances: Platforms may have different ways of implementing device-bound key scope. Relying Parties should be aware of potential variations and not make strict assumptions about shared access.
• Not a Global Identifier: Device-bound keys, regardless of scope, are specific to a user credential and RP ID. They cannot be used to link user activity across different credentials or websites.
• Attestation Provides Context: Attestation for the device-bound key can give the Relying Party information about the hardware security of the device, helping assess the trustworthiness of the continuity signal.

In Summary:

The scope of a device-bound key informs the strength of the device continuity signal that Relying Parties can derive. “Entire device” keys provide stronger continuity across a user’s applications, potentially leading to lower risk scores. “Per-app” keys offer a more limited signal, confined to the requesting application.

Question: What are the key differences between the AAGUID included in the “devicePubKey” extension output and the AAGUID in the attested credential data?

The WebAuthn specification highlights a crucial distinction between the two AAGUIDs you mentioned:

1. AAGUID in “devicePubKey” extension output:

• Scope: This AAGUID identifies the specific authenticator model responsible for storing the hardware-bound device key pair. It is directly tied to the hardware implementing the devicePubKey feature.
• Purpose: It helps the Relying Party understand the security characteristics of the device itself, as the device private key is bound to this hardware. The AAGUID can be used to look up information about the device’s security certifications or protections.
• Uniqueness: It is unique to the specific authenticator model, and will be different for different devices, even if they are from the same manufacturer.

2. AAGUID in attested credential data:

• Scope: This AAGUID identifies the broader category or family of authenticators that created the user’s credential. Especially for multi-device credentials, this AAGUID might not pinpoint a specific device model.
• Purpose: It gives the Relying Party general information about the authenticator that generated the credential, which helps assess the overall security posture of the credential.
• Uniqueness: For single-device credentials, it will be the same as the AAGUID in the devicePubKey output. However, for multi-device credentials, this AAGUID may be more generic, encompassing a range of authenticators from the same manufacturer that share certain characteristics.

In essence:

• The “devicePubKey” AAGUID reflects the hardware-level security of the device private key.
• The attested credential data AAGUID reflects the security posture of the process and authenticator that generated the user credential.

Why the difference matters:

• Multi-device credentials: The devicePubKey AAGUID remains consistent across different devices holding copies of the same multi-device credential, as it always points to the device currently used for authentication. On the other hand, the AAGUID in attested credential data, for multi-device credentials, might be broader, representing the class of authenticators supporting the credential’s synchronization.
• Relying Party Risk Assessment: The Relying Party can use both AAGUIDs to make a more nuanced risk assessment. For example, they can assess both the device’s security (through the devicePubKey AAGUID) and the credential’s overall security posture (through the attested credential data AAGUID).

Additional points:

• Both AAGUIDs can be zero, depending on the attestation options chosen and the authenticator’s behavior.
• Relying Parties should be prepared to handle cases where the two AAGUIDs are different or one or both are zero.

Question: What are the security implications of allowing cross-origin iframes to access the Web Authentication API?

You’re right to be concerned about the security implications. Allowing cross-origin iframes to use the Web Authentication API opens up a potential attack vector, primarily due to the risk of UI Redressing (Clickjacking).

Here’s a breakdown of the risks:

UI Redressing/Clickjacking

• How it works: A malicious website could embed a legitimate WebAuthn Relying Party (like your bank) within an iframe and overlay its own UI elements on top. These elements might be designed to trick the user into performing actions they don’t intend, like approving a transaction or registering a new key for the attacker’s account.
• Exploiting WebAuthn: Although the WebAuthn prompts themselves are typically handled by the client platform (browser or OS) and are less vulnerable to UI redressing, the attacker can still manipulate the surrounding context. For instance, they could hide the actual Relying Party’s information, making the user believe they are interacting with a different website.
• Example: Imagine a malicious page with a button labeled “Claim free prize!” that is actually positioned over an invisible “Confirm payment” button from your bank embedded in an iframe. When the user clicks to claim the prize, they unknowingly authorize a payment to the attacker.

Mitigations

The WebAuthn specification and browsers offer some ways to mitigate these risks:

• Permissions Policy: WebAuthn is disabled by default in cross-origin iframes. Websites need to explicitly grant permission using the allow attribute on the iframe element with the publickey-credentials-get token. This ensures that only explicitly trusted iframes can use the API.
• Intersection Observer v2: This experimental browser API can help detect if an iframe is fully visible to the user. Relying Parties could use this to detect potential UI redressing attempts and take action, such as loading the content in a new popup window to ensure visibility.
• User Awareness: Users should be educated about the dangers of UI redressing and learn to carefully inspect the entire web page, especially around interactive elements, before using WebAuthn.

Important Considerations for Relying Parties

• Strict Origin Validation: Always meticulously validate the origin and topOrigin fields in the client data to ensure they match the expected values. Reject any requests originating from unexpected sources.
• Minimize Embedded Usage: Whenever possible, avoid using WebAuthn in embedded contexts. If necessary, implement strong mitigations like Intersection Observer checks and potentially redirect to a dedicated page for the WebAuthn flow.
• User Guidance: Provide clear and concise information to the user about the WebAuthn process, emphasizing the importance of carefully checking the website’s details before authorizing any actions.

Balancing Act

While cross-origin iframe access can enable some interesting use cases, it’s crucial to weigh the security risks carefully. The decision to allow such access should be made on a case-by-case basis, considering the sensitivity of the information involved and the robustness of the mitigations in place.

References

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