Florentin Putz October 2021
Bring Your Own FIDO2 Extensions
Today at ETAA ‘21, I gave a talk about our paper, “Future-Proof Web Authentication: Bring Your Own FIDO2 Extensions”. The full paper is freely available here; you can watch my talk here.
We show how researchers and developers can design and implement their own extensions for using FIDO2 as a well-established and secure foundation to demonstrate innovative authentication concepts or to support custom deployments. Our open-source implementation targets the full FIDO2 stack, such as the Chromium web browser and hardware tokens, to enable tailor-made authentication based on the power of the existing FIDO2 ecosystem.
To give an overview of existing extensions, we survey all published FIDO2 extensions by manually inspecting the source code of major web browsers and authenticators. Their current design, however, hinders the implementation of custom extensions, and they only support a limited number of extensions out of the box. We discuss weaknesses of current implementations and identify the lack of extension pass-through as a major limitation in current FIDO2 clients.
The following is an excerpt from our paper. The full paper contains much more details.
Introduction
Stronger forms of authentication than passwords can protect online accounts from phishing attacks and mitigate the impact of data breaches. The FIDO2 standards are now implemented in all major web browsers and allow users to securely log in to websites without passwords, using either a hardware security key (e.g., a YubiKey) or a built-in authenticator in modern smartphones or laptops. Website operators can easily implement support for FIDO2 using the WebAuthn JavaScript API, which also supports custom extensions to implement special use cases.
Extensible web standards such as X.509 or TLS have played a key role during the advancement of the Internet so far. A standards organization such as the IETF cannot predict all possible future use cases of the standard beforehand, but custom extensions provide flexibility to the otherwise fixed specification and prevent fragmentation via the creation of new competing standards to satisfy new use cases. The behavior of a protocol can then be modified without the effort to get the modifications accepted into the main standard.
Why extend FIDO2?
At its core, FIDO2 is a well-established and secure platform for accessing public-key credentials, with little restrictions imposed on the authenticator. In the future, however, innovative authentication approaches might require modifications to the standard, e.g., by transmitting or receiving additional information to the authenticator. FIDO2 extensions can be used to support new uses cases, implement additional features, and mitigate shortcomings of the standard.
The potential of FIDO2 extensions becomes clear by looking at the extensions that have been proposed so far: A major weakness of FIDO2 is the lack of efficient recovery options, which has been criticized in previous user studies. Yubico proposed a new FIDO2 extension to address this problem, by implementing an efficient way to automatically register backup credentials, which can be used in case the authentication token gets lost.
Developers and researchers can also use FIDO2 extensions to prototype and demonstrate new authentication designs within the existing FIDO2 ecosystem on real-world web browsers. Companies can use FIDO2 extensions to adapt the protocol for tailor-made authentication in internal deployments.
Contributions
Web browsers currently do not support any third-party FIDO2 extensions. Furthermore, there is no clear development path to implement custom extensions in current web browsers. Even FIDO2 extensions which do not require any special processing by the web browser need explicit browser support instead of automatically being forwarded to the authenticator. Although extensions are an important part of any standard, the extensibility of the FIDO2 standards unfortunately has not received much attention as of today. This calls for a detailed analysis of FIDO2 extensions:
- As our core contribution, we show how to design and implement tailor-made authentication based on the power of the existing FIDO2 ecosystem. Our source code and additional documentation is available online.
- We survey all publicly known FIDO2 extensions by manually inspecting the source code of major web browsers and authenticators.
- We describe limitations of current FIDO2 extension implementations and identify the lack of extension pass-through as a major weakness that inhibits the development of innovative FIDO2 extensions.
System model
The FIDO2 authentication protocols WebAuthn and CTAP2 can be extended to support special use cases. The following figure shows the general protocol flow of a FIDO2 extension, as specified by §9 of the WebAuthn specification. The RP initiates an extension request with the client, which then processes the request and responds to the RP.
WebAuthn distinguishes between different types of extensions. An extension is always a client extension, as it involves communication with the client. The extension specification defines the form of the JSON client extension input/output and what kind of client extension processing the client needs to perform to transform the inputs to the outputs.
If the extension also involves processing on the authenticator, it is additionally an authenticator extension and defines the form of the CBOR authenticator extension input/output and what kind of authenticator extension processing the authenticator needs to perform to transform the inputs to the outputs. In this case, the client also needs to know how to convert the JSON client extension input to the CBOR authenticator extension input, and how to convert the CBOR authenticator extension output back to the JSON client extension output.
Each FIDO2 extension has an extension identifier string, which can be registered in the IANA “WebAuthn Extension Identifiers” registry. This registry has been defined and established by RFC 8809 and contains an up-to-date list of all currently registered WebAuthn extension.
Authenticators supporting CTAP 2.1 must implement the hmac-secret extension and the credProtect extension if they support some form of user verification (§9 in CTAP2). Clients can use the CTAP authenticatorGetInfo method to detect which extensions an authenticator supports.
Survey of FIDO2 extensions
Our survey on FIDO2 extensions as of July 2021 consists of two parts, with the full results available in our paper:
- We first identify all extensions that have been published so far.
- We determine which clients and authenticators support these extensions. Since it is standard compliant for a client to ignore any extensions, the currently available feature trackers for web browser WebAuthn implementations do not indicate support for individual extensions. The figure below gives an overview of FIDO2 extension support for popular web browsers, client libraries, and authenticators.
Most extensions are specified in the FIDO2 standards themselves (“standard extensions”), such as the hmac-secret extension for using a symmetric key with a FIDO2 credential. Additionally, there are three non-standard extensions which are not specified in the official FIDO2 standards. First, there is Yubico’s recovery extension, which has a separate specification but no web browser implementation yet. Second, there is Google’s caBLE extension, which is part of the Google Chrome browser but has no public specification. Third, there is the googleLegacyAppIdSupport extension, which is implemented in some browsers but has no formal specification yet.
There is no automatic way to query all extensions supported by a web browser, so we need to manually inspect each browser’s source code to see which FIDO2 extensions they implement. We checked the Chromium source code (which forms the base of Google’s Chrome browser and Microsoft’s Edge browser), the Gecko source code (which corresponds to Mozilla’s Firefox browser), and the WebKit source code (which forms the base of Apple’s Safari browser).
The table above shows all WebAuthn and CTAP2 extensions currently supported by these browsers. Chrome supports 11 FIDO2 extensions, including the non-standard caBLE extension, while Firefox and Safari only support two extensions each. All browsers support the appid extension for compatibility with legacy U2F credentials.
Implementing custom extensions
In order to showcase the possibilities of FIDO2 extensions and the required steps to implement one, we define a proof-of-concept extension that we implement on all parts of the FIDO2 stack: RPs (web applications), clients (browser and non-browser), and authenticators. Implementing a custom FIDO2 extension is not straightforward and often undocumented, so we try to facilitate the process for other researchers and developers.
We focus on how to implement custom extensions in the web browser, as they are the most common FIDO2 client. Our paper describes the process of developing custom extensions also for the relying party, for a Python client library, and for hardware authenticators.
Web browsers receive the authentication request from the RP and communicate with the authenticator. As web browsers do not currently support FIDO2 extension pass-through, we need to modify the browser to support our custom extension. We have implemented the greeter extension in the Chromium browser, as it is the foundation of the most popular web browser on the market, Google Chrome. Unfortunately, Chromium does not implement FIDO2 extension support in a modular way, which means that we need to modify different components of the browser stack in order to implement support for our greeter extension. Chromium does not provide any documentation for this, so we had to find out the correct approach by inspecting the implementation of other FIDO2 extensions in the source code.
The figure above shows how Chromium processes and sends FIDO2 extensions to authenticators. Let us assume a web application with the JavaScript code described in Section 5.1. Chromium’s rendering engine Blink contains the V8 JavaScript engine, which runs this code and dispatches the command navigator.credentials.create() to the corresponding Blink module implementing this Web Platform API. This command is part of the general Credential Management API, which gets called first. This gets treated as a WebAuthn request in CredentialsContainer::create(), because we specified publicKey in the code above.
The JavaScript request contains a parameter object following the PublicKeyCredentialCreationOptions WebIDL specification. This object also contains the client extension inputs according to AuthenticatorExtensionsClientInputs, which we need to modify to include our own extension input. In Chromium, these parameters from JavaScript get converted into Mojo structures in authenticator.mojom, which are used for IPC between different parts of Chromium. In our case, the relevant Mojo structure is PublicKeyCredentialCreationOptions. We need to change both the Mojo structure and the converter from IDL to Mojo. Afterwards, the call arrives at AuthenticatorCommon::MakeCredential() inside Chromium’s content layer. We need to modify this function to include our extension as a RequestExtension. This function then calls the MakeCredentialRequestHandler inside Chromium’s device layer. We modify the CTAPMakeCredentialRequest, which converts our request into a CTAP message. Afterwards, this gets sent to the authenticator, which responds back to us.
The response path is similar and traverses back to the content layer and finally to the Blink layer, where the client extension output gets converted into the WebIDL AuthenticationExtensionsClientOutputs and passed back to the V8 JavaScript engine.
Extension pass-through
Extension pass-through is an important feature that allows FIDO2 clients to transparently forward extension inputs and outputs between RP and authenticator, even for unknown extensions. An older draft of the WebAuthn specification noted that extension pass-through can “facilitate innovation, allowing authenticators to experiment with new extensions and RPs to use them before there is explicit support for them in clients.”. While inspecting the web browser source codes, however, we noticed that no web browser currently supports extension pass-through. This makes it very difficult to establish custom extensions, as users will not be able to use them.
FIDO2 extensions can address shortcomings of the current FIDO2 standards and allow them to easily adapt to new use cases. In practice, the applicability of FIDO2 extensions is limited due to browser design decisions. In order to facilitate the development and usage of innovative FIDO2 extensions, we argue that web browsers should pass-through unknown extensions to authenticators, as the WebAuthn specification suggests.
Some custom FIDO2 extensions might pose the risk of exposing too much fine-grained data to RPs, which would allow them to discriminate between authenticators. This is the reason why Chromium does not support the official uvi and uvm extensions. This potential problem can be approached by letting the user opt-in to pass-through custom FIDO2 extensions, e.g., via a configuration option in chrome://settings/securityKeys or via the permission API that is already used for camera or microphone access.
Supporting FIDO2 extensions via browser extensions
Apart from supporting pass-through, web browsers can also facilitate the development of innovative FIDO2 extensions by making it easier to implement them. As we have shown before, Chromium’s support for FIDO2 extensions is currently hard-coded in many different parts of the browser stack. This could be improved using a modular architecture. Another interesting approach would be to allow implementing custom FIDO2 extensions as regular web browser extensions. Chromium already has an extensive web extensions API, which could be extended with an API for FIDO2 extensions. This would also facilitate the use case of internal company deployments, as it is already possible in an enterprise setting to provision web browsers with a set of extensions.
Outlook
Without support for custom FIDO2 extensions in web browsers, it is unlikely that FIDO2 extensions will be utilized to a similar extent than X.509 or TLS extensions. The domain of developing new FIDO2 extensions currently is rather limited to developers of web browsers or members of the FIDO Alliance, like Google is already doing with their caBLE extension. Third-party developers have difficulties of implementing and testing their custom FIDO2 extensions in web browsers. In practice, the primary use case of custom extensions is probably not the public Internet but rather internal deployments with a limited target audience. In this case, the argument of possible authenticator discrimination is not applicable anymore as these internal deployments already have custom authentication policies in place.
The previously mentioned restriction on the usage of custom extension might also explain the limited support for implementing custom extensions in FIDO2 authenticators and clients. Documentation is often limited, if available at all. The software architectures are not designed to be modular with regards to FIDO2 extensions. One instance of a well designed modular extension architecture is the python-fido2 client library, although it still requires modification of the internal source code and lacks public documentation.
Read the full paper, which contains much more details.