Skip to main content
Version: 2.4.x.x Java 8 ELS

FIDO Universal Authentication Framework

Nevis Mobile Authentication is built on top of the FIDO UAF 1.1 Protocol. This chapter introduces this protocol without going into the actual implementation in Nevis. Since it is a very high level overview, some simplifications for the sake of simplicity have been made when describing the different concepts. Refer to the official FIDO UAF 1.1 Protocol Specificationt gor a complete description of the protocol. For a wider overview, check the FIDO UAF Architectural Overview.

UAF Architecture​

According to the FIDO UAF Architectural Overview document:

The FIDO UAF strong authentication framework enables online services and websites, whether on the open internet or within enterprises, to transparently leverage native security features of end user computing devices for strong user authentication and to reduce the problems associated with creating and remembering many online credentials.

In this context, the main difference of FIDO UAF is that the authentication is not performed at server level but at client level. This means that the FIDO Server does not contain any private credentials of the user (as described below, it just stores public keys). The private credentials remain in the client device. This makes it impossible to steal credentials of the users if the server is compromised. In a typical case, a customer using a mobile device (phone or tablet) will be able to authenticate in a FIDO Server using an embedded authenticator in the device (for instance a fingerprint recognition system).

To illustrate the FIDO UAF 1.1 Protocol, we can rely on a simplified architecture diagram. It depicts the entities involved in the FIDO UAF Protocol:

FIDO Authenticator​

A FIDO UAF Authenticator is a secure entity that is integrated with the user's device and is responsible for storing and managing all sensitive data used by FIDO UAF like the user's biometric identifier or PIN code which could be used to locally authenticate the user. The authenticator can also create and store the key material to be used in the authentication protocols. As such, after the user was authenticated at the FIDO UAF Authenticator it will access the users private key so it can provide a response to the cryptographic challenges and authenticate itself to an online service.

In FIDO UAF, the authenticator creates a unique public-private key pair for each online service to which the user has registered himself. By doing so, the different accounts of this user at the online services are unlinkable among each other. This prevents an online service from making connections between the user's account at this service and at another service, and helps the user to protect his privacy.

Services relying on FIDO Authentication (Relying Parties) can use and maintain a list of trusted authenticators. Whenever a user is being authenticated, it is checked whether the used authenticator is listed as trusted or not. If an authenticator is compromised it could be removed from the list so related threats could be eliminated instantly.

FIDO Client​

The FIDO Client implements the client-side of the FIDO UAF Protocols. It interacts with FIDO Authenticators and the Relying Party client application to communicate with the FIDO Server.

Relying Party Application​

An application that uses the FIDO Protocol to authenticate users. This typically consists of a Relying Party client application (e.g., a native mobile app) and a Relying Party server application (the backend).

FIDO Server​

The FIDO Server implements the server side of the FIDO UAF Protocols. It interacts with the Relying Party server application to communicate with the FIDO Client. The FIDO Server manages the association of registered FIDO Authenticators to user accounts and verifies user authentication and transaction confirmation responses.

Application and Facets​

Application is defined in the FIDO UAF Specification as:

  • A set of functionality provided by a common entity (the application owner, aka the Relying Party), and perceived by the user as belonging together.
  • The central part of the FIDO UAF Specification is providing secure authentication to applications. Each application is identified by an identifier called AppID.

As stated in the FIDO UAF Specification:

  • AppID: The AppID_is an identifier for a set of different facets of a Relying Party's application. The_AppID is a URL pointing to the TrustedFacets, i.e. list of FacetIDs related to this AppID.

The concept of facets is in direct relation to the AppID:

  • Application Facet: An (application) facet is how an application is implemented on various platforms. For example, the application MyBank may have an Android app, an iOS app, and a Web app. These are all facets of the MyBank application.

An example: Let's assume a Relying Party banking application hosted under the domain ebanking.muvonda.com. The AppID for this application would point to the facets endpoint of the Relying Party server application. The facets endpoint supplies a list of trusted facets, in this case a "support" application, the main e-banking application and an Android application.

The relation between an application, the AppID and Facets is illustrated in the following figure:

UAF Protocol​

The UAF protocol defines four operations: registration, authentication, transaction confirmation (which can be considered a variant of authentication) and deregistration. The following concepts are used in the four operations and are described to avoid duplications.

Policy​

The policy describes the required authentication by the server. For instance, a policy can impose to use either a face recognition authenticator or a PIN/ password authenticator. It is also possible to define policies that impose the use of several authenticators simultaneously (face recognition and fingerprint for example).

Metadata​

The metadata describes the properties of all the FIDO Authenticator models known to the FIDO Server: vendor, version, algorithms supported, type of authentication (fingerprint, PIN, face recognition...) etc. The metadata is used to validate that the contents of the responses (RegistrationResponse and AuthenticationResponse) sent by the FIDO Client have actually been generated with the FIDO Authenticators referenced in those responses. It is also used to verify that the FIDO Authenticators generating the responses comply with the policy (by comparing the policy with the properties of the authenticator model). For example, if the policy requires to use fingerprint authentication and the FIDO credentials have been generated using the FIDO Authenticator model ACME, the metadata is used to verify that ACME is a known authenticator and that it supports fingerprint authentication.

Registration​

Before being able to authenticate using the FIDO UAF Protocol, some credentials must be created on client-side and registered in the FIDO Server. This operation is called registration. Once the credentials are registered, the client will be able to authenticate using those credentials.

The registration process for FIDO credentials is the following:

  1. The Relying Party client application sends a request to the Relying Party server asking to register.
  2. The Relying Party client application sends a GetUAFRequest to the FIDO Server asking to perform a registration.
  3. The FIDO Server returns a ReturnUAFRequest containing a RegistrationRequest to the Relying Party server. In this RegistrationRequest the server includes the policy. The Relying Party server forwards this request to the client application.
  4. The user authenticates using the FIDO Authenticators required by the policy of the FIDO Server.
  5. After a successful authentication, each of the FIDO Authenticators used to authenticate, generate a pair of public and private keys (the credentials to be registered). The private keys are kept in the FIDO Authenticators.
  6. The client application sends a SendUAFResponse containing a RegistrationResponse to the Relying Party server. This message consists mainly of the public keys generated by the FIDO Authenticators, a signature that must be validated by the server and an identifier of the FIDO Authenticators model used to authenticate. The SendUAFResponse is forwarded to the FIDO Server.
  7. The FIDO Server validates the received RegistrationResponse. The validation consists mainly on verifying that:
    • The authenticators used to create the public key comply with the policy.
    • The signature is valid.
  8. If the validation in step 7 is successful, the public key in RegistrationResponse is stored as the credential for the user by the FIDO Server.
  9. The FIDO Server returns a ServerResponse informing that the registration was successful, which then is transmitted from the Relying Party server to the Relying Party client application.

Authentication​

Once the FIDO credentials have been created, the private key is stored in the FIDO Authenticator and the public key is registered in the FIDO Server, the FIDO Client can authenticate. The authentication process is the following one:

  1. The Relying Party client application tries to access the web application (Relying Party).
  2. Since the application is not authenticated, the Relying Party sends a GetUAFRequest to the FIDO Server asking to authenticate.
  3. The FIDO Server returns a ReturnUAFRequest contaning an AuthenticationRequest to the Relying Party. In this AuthenticationRequest the server includes the policy. The Relying Party forwards the AuthenticationRequest to the application. The embedded FIDO Client in the application handles this AuthenticationRequest.
  4. The user authenticates using the FIDO Authenticators required by the policy of the FIDO Server.
  5. The FIDO Client generates a SendUAFResponse containing an AuthenticationResponse that is sent from the Relying Party client to the Relying Party server. This message consists mainly of the signed challenge sent by the client using the private keys generated in the registration operation. The AuthenticationResponse is forwarded to the FIDO Server.
  6. The FIDO Server validates the received AuthenticationResponse. The validation consists mainly on verifying that:
    • The private keys used to sign the challenge correspond to FIDO Authenticators that comply with the policy.
    • The signature of the challenge is valid. To validate the signature, the FIDO credentials of the user stored during the registration operation are used.
  7. The FIDO Server returns a ServerResponse informing that the authentication was successful. The Relying Party detects that the client application is successfully authenticated and notifies the application.

Transaction Confirmation​

The FIDO UAF Protocol defines an special case of authentication known as transaction confirmation. The transaction confirmation is used when in addition to perform authentication, the user must validate some information (this information is referred to as transaction message). A typical use case would be a banking transaction: the user authenticates to execute the transaction but in addition to that the amount of the transaction must be verified by the end user to avoid tampering (this is the case represented in the diagram below). Other examples: a web shop asking the user to confirm a purchase by showing the product and amount, a public institution mobile application asking the user for confirmation when submitting a tax declaration, etc.

The information to be validated can be either a text or an image. In this scenario, the FIDO Client is not the one that generates the message to be validated by the end user, but the web application (in the FIDO UAF Specification, this entity is referenced as Relying Party). The transaction confirmation process is the following:

  1. The Relying Party application contacts the Relying Party to execute a transaction (this might imply or not sending a GetUAFRequest to the Relying Party).
  2. The Relying Party sends a GetUafRequest to the FIDO Server with the transaction information.
  3. The FIDO Server returns an AuthenticationRequest to the FIDO Client, with the policy and the transaction message. The transaction message is usually generated by the Relying Party.
  4. The transaction message is presented to the user who confirms it.
  5. The user authenticates in the FIDO Client using the authenticators required by the policy of the FIDO Server.
  6. The FIDO Client sends a SendUAFResponse containing an AuthenticationResponse to the Relying Party server. This message consists mainly of the signed challenge sent by the client and a signed hash of the transaction message. Both elements are signed using the private keys generated during the registration operation. The AuthenticationResponse is forwarded to the FIDO Server.
  7. The FIDO Server validates the received AuthenticationResponse. The validation consists mainly of verifying that:
    • The private keys used to sign the challenge correspond to FIDO Authenticators that comply with the policy.
    • The signature of the challenge is valid. To validate the signature, the FIDO credentials of the user stored during the registration operation are used.
    • The signed hash of the transaction message is valid. To validate the signature, the FIDO credentials of the user stored during the registration operation are used.
  8. The FIDO Server returns a ServerResponse informing that the transaction confirmation was successful. The Relying Party (bank application) is informed about this and the transaction is executed. The Relying Party notifies the application that the transaction was successful.

Deregistration​

The FIDO UAF Protocol also considers the case where credentials must be removed. This operation is called deregistration. The process is the following one:

  1. The Relying Party client application contacts the Relying Party server to remove FIDO credentials.
  2. The Relying Party client application sends a GetUAFRequest to the FIDO Server asking to perform a deregistration.
  3. The FIDO Server removes the public credentials that were stored during the registration operation.
  4. The FIDO Server returns a ReturnUAFRequest containing a DeregistrationRequest to the Relying Party server which forwards it to the Relying Party client application.
  5. The private keys (private and public) generated in the FIDO Authenticator during the registration process are deleted.

FIDO UAF Step-up Authentication​

Clarification​

The FIDO step-up authentication case needs some explanation as it differs from the definition of step-up used in nevisAuth. The FIDO UAF Specification refers to "step-up authentication" during authentication request generation as the following:

In the case where it is expected that the user is already known due to a previous authentication step.

There are scenarios (like the Multiple Users in Device case of In-Band Authentication) where a user is previously known but not already authenticated which leads to the following clarification:

caution

"FIDO Step-up Authentication" is not necessarily a step-up authentication in the same sense the definition is used for example in the nevisAuth context. It is rather a concept which allows to force a client to use the authenticators registered by a given user (by including them in the policy), instead of supplying the FIDO Client with more "generic" policies.

Usage​

This case is mainly used in scenarios where the user (to be more specific: the users FIDO UAF credentials) are already known to the FIDO Server. In this case it's possible to reply to a FIDO Client wanting to authenticate with an authentication request specifically tailored to the authenticators in use by this user.

Impact in Policy​

In FIDO step-up authentication scenarios where the username is provided in the initial GetUAFRequest, the FIDO Server will return a policy containing the AAIDs and KeyIDs of all authenticators the user has previously registered which are valid based on the static policy configuration. This directly corresponds to the step-up authentication specification:

In case of step-up authentication (i.e. in the case where it is expected the user is already known due to a previous authentication step) every item in Policy.accepted must include the AAID and KeyID of the authenticator registered for this account to avoid ambiguities when having multiple accounts for this Relying Party.

The following diagram shows the behavior depending on whether the user name is provided (step-up case) or not: