Architecture

Overview

An ASM is a platform specific component developed by an authenticator vendor, which can be plugged in to FIDO UAF Clients.

An ASM implements the FIDO UAF ASM API, which is how a FIDO UAF Client communicates with it. If the ASM is for a hardware-based authenticator, the ASM is typically implemented on top of a hardware driver, which then talks to the authenticator device. If the ASM is for a software-based authenticator, the ASM is typically implemented on top of an authenticator-specific SDK.

The ASM is responsible for:

• Receiving the authenticator data provided by the RP, e.g., origin and challenge, and returning the response.

• Hiding authenticator communication specifics from the FIDO UAF Client, e.g., authenticator algorithms, low level drivers, USB, SPI, Bluetooth, and NFC.

• Implementing UI specific to the authenticator.

• Providing authenticator management capabilities, e.g., changing enrollment settings and changing authenticator state.

The following diagram represents the ASM Architecture:

ASM Core

The ASM Core is responsible for providing the main entry point for a FIDO UAF Client to interact with the ASM, and the encapsulated authenticators. If built as a standalone ASM, the ASM Core exposes the appropriate FIDO UAF ASM interface, allowing the ASM to be discovered by a FIDO UAF Client.

The ASM Core is responsible for discovering and loading all the registered authenticators in the ASM. An ASM may contain multiple independent authenticators, with each authenticator consisting of an implementation of each of the IMatcher, IAuthenticatorKernel, and IAuthenticatorDescriptor interfaces.

Authenticator Core

The Authenticator Core coordinates between the ASM Core, and the IMatcher and IAuthenticatorKernel implementations for a specific authenticator. The Authenticator Core is designed to be flexible to accommodate different modes of user verification, and chooses the IMatcher and IAuthenticatorKernel implementation described by an IAuthenticatorDescriptor implementation. This is a common implementation for all the authenticators.

IAuthenticatorDescriptor

The com.noknok.android.client.asm.sdk.IAuthenticatorDescriptor defines the attributes driving or defining the authenticator’s behavior, such as the IMatcher implementation used by the authenticator, and a class that selects which implementation of IAuthenticatorKernel to use with the authenticator. The ASM Core dynamically discovers all implementations of the IAuthenticatorDescriptor interface based on the asmdescriptors.json configuration file in the ASM, and uses these implementations to construct each of the authenticators contained by the ASM.

IMatcher

The com.noknok.android.client.asm.sdk.IMatcher interface implementation is the component of the authenticator which is responsible for verifying the user locally, for example, by asking for a PIN or a fingerprint swipe. Each authenticator will implement an IMatcher interface to not only manage the user verification process, but also to render the associated user interface to the user. The matcher may be implemented in a secure environment, such as a Trusted Execution Environment, to provide better protection for stored user verification data, and ensure integrity for the user verification process. In such a case, the IMatcher implementation will be responsible for coordinating communications with a separate Matcher trustlet running in the TEE.

IAuthenticatorKernel

The com.noknok.android.client.asm.sdk.IAuthenticatorKernel is the interface to the FIDO Crypto Module, which is the component of the authenticator which is responsible for performing UAF cryptographic operations. These operations include generating user keys during UAF registration, using a user key to generate a signature during authentication, and using an attestation key to generate a signature proving the authenticity of the authenticator to the UAF server.

Third parties, such as Qualcomm, may implement the FIDO Crypto Module in a secure environment, such as a Trusted Execution Environment, to provide better protection for stored user keys and the attestation key, and ensure the integrity of cryptographic operations. In such a case, the IAuthenticatorKernel implementation will be responsible for coordinating communications with a separate FIDO Crypto Module trustlet running in the TEE.

In cases where the IMatcher and IAuthenticatorKernel are running in separate trustlets, the FIDO Crypto Module vendor will define a User Verification Token (UVT) format to allow the result of the user verification process performed by the matcher to be communicated to the FIDO Crypto Module. The UVT may also include additional information about the success of the user verification process; consult the documentation from the provider of your FIDO Crypto Module to understand what UVT format your IMatcher implementation will need to emit.

Sequence Diagram

A detailed flow of the user verification sequence is shown in the following diagram:

Individual Steps of the User Verification Sequence

1. Start User Verification

   1. Matcher API calls Matcher Trustlet

   2. Matcher Trustlet verifies user

   3. Matcher Trustlet returns UVT

   4. Matcher API returns the UVT

2. IAuthenticatorKernel.processRequest(uafRequest)

   1. FIDO Crypto Module (AK) Trustlet must

      1. Unwrap provided UVT

      2. Verify UVT contents

      3. Create a UAF response and return