nevisFIDO

The Reference Guide is available as PDF only.

Nevis Mobile Authentication enables secure and convenient authentication by letting users verify their identity via their mobile device. With Nevis Mobile Authentication, users can confirm transactions and prove who they are through the use of multiple identification factors based on something the user knows, has or is. A combination of strong cryptography and standardized authentication schemes makes this possible in an easy and secure way. By storing the users' personal data and secret credentials solely on the user's device, Nevis Mobile Authentication guarantees users privacy and protects companies against potentially business threatening data breaches.

Weaknesses of standard authentication methods

In 2018, the most common authentication method is the password. This is surprising as passwords are among the weakest authentication methods on the market. Passwords can be easily stolen, shared or forgotten. Users avoid to choose strong passwords or use the same password for multiple applications out of convenience. In 2016, the Verizon Data Breach Investigations Report pointed out that 63% of confirmed data breaches involve the use of weak, default or illegally obtained passwords. An additional problem arises from the fact that passwords are stored on servers. This makes servers an attractive target for hackers. A single vulnerability on a server potentially puts millions of user credentials and other sensitive personal data at risk. If passwords are transferred through networks, they can be exposed to phishing attacks, too.

And passwords are not just insecure. They also provide a bad user experience. Increasingly often, users are forced to choose complex passwords including a combination of characters, numbers and symbols, which the user cannot remember by heart. Additionally, users are advised to have a different password for each application. In the end, one individual user must know dozens or hundreds of complicated passwords to access the services he needs.

Several authentication schemes have been proposed to overcome the shortcomings of passwords. Amongst them are one-time passwords, security tokens or biometric schemes. However, the vast majority of those schemes falls short of expectations either with regard to security or to convenience. This is where Nevis Mobile Authentication comes into play, as it combines secure authentication with a positive user experience.

Security through Nevis Mobile Authentication

To make authentication more secure and convenient, there is a growing need for a solution that:

• Prevents phishing attacks
• Does not store user credentials on the server
• Respects the user's privacy
• Provides a positive user experience

Nevis Mobile Authentication offers a convenient and secure authentication solution with the desired characteristics. This is realised through the use of public key cryptography and multi-factor authentication on mobile devices. By employing public key cryptography, Nevis Mobile Authentication facilitates the verification of the user's identity without having to send secret credentials through the network. Multi-factor authentication includes either something the user is (e.g., biometric features such as a fingerprint, retina, voice), knows (e.g., a PIN code) or owns (e.g., a hardware-based key/mobile device). These individual authentication factors are used to authenticate the user against the server. At the same time they protect the private key in the public key cryptography (the user must authenticate to access the keys). The authentication factors cannot leave the user's device, just as the secret private key of the public and private key pair. Together, the public key cryptography and the individual authentication factors make sure that the user does not have to remember complicated passwords anymore. They also make the authentication quick and hassle-free.

The setup conforms with most data privacy regulations and helps eliminate user concerns about personal data stored on a server in the cloud. In case of a successful attack against a server, the attackers can only obtain the public keys, which are meaningless on their own and not considered to be secret in any way. Due to this, the server-side is no attractive target for attackers anymore and man-in-the-middle/man-in-the-browser or phishing attacks can be prevented.

How does it work?

When the user registers himself to the Nevis Mobile Authentication solution, Nevis Mobile Authentication generates a public and a private key pair on the user's mobile device. The public key is sent to the server and stored there. The private key remains on the user's device, protected by an individual authentication factor such as biometric data (fingerprint) or a PIN. This personally identifying information also stays on the user's device, meaning that no secret data will ever leave the device.

Even if an attacker manages to somehow obtain the users fingerprint or pin code he won't be able to impersonate the user using a different mobile device.

Authentication and confirmation scenarios

Nevis Mobile Authentication supports scenarios where an application requires authentication or transaction confirmation:

• The authentication and transaction confirmation take place directly within the same mobile application (in-band).
• The authentication and transaction confirmation take place in a separate mobile application (out-of-band).

In-band authentication and transaction confirmation

In the in-band scenario, a user uses an application on his mobile device. If required (the user tries to access a protected resource for example), the server-side triggers the authentication or transaction confirmation (no. 1 in the figure, In-band authentication and transaction confirmation),by sending an authentication request to the application through the existing communication channel (no.2). The user authenticates (for instance using fingerprint) and (in the case of the transaction confirmation) confirms a transaction (no.3); then the device signs the authentication request and returns the result to the server (no.4), a successful verification on the server-side means that the user is authenticated or the transaction is confirmed.

Out-of-band authentication and transaction confirmation

In the out-of-band scenario, a user uses one application but requires another, separate mobile application to do authentication or transaction confirmation.

An example of an out-of-band scenario is a user who visits a web application via the browser installed on his personal computer (no.1 and no.2). If required, the web application triggers an authentication or transaction confirmation for the user, by sending a push message to the mobile device associated with this user (no.3). The user authenticates in the device (for example using fingerprint) and the device signs the authentication request or transaction information and returns the result to the server (no.4). After successful verification on the server-side, the user is considered to be authenticated or the transaction to be confirmed. The figure Out-of-band authentication illustrates this scenario.

Nevis Mobile Authentication based on FIDO UAF

To implement the aforementioned features, Nevis Mobile Authentication is based on the FIDO UAF 1.1 standard. FIDO is a set of specifications for strong authentication. The FIDO Alliance was launched in 2013 to address the lack of interoperability among strong authentication devices and the problems users face creating and remembering multiple usernames and passwords. There were more than 260 alliance members by the end of September 2016, including leading internet companies such as Google and Microsoft.

FIDO supports the Universal Authentication Framework (UAF) and the Universal Second Factor (U2F) protocols. (U2F is not in the scope of Nevis Mobile Authentication.)

The UAF protocol consists of a client component, installed on the user's mobile device, and a server component, connected with the online service. Upon registration of the user with the online service, the client on the user's device creates a new public and private key pair. The private key is stored on the user's device. The public key is registered with the online service and associated with the user's profile. During the authentication process, the client component on the user device proves the ownership of the private key to the service by signing a challenge. This involves a simple user action only, such as providing a fingerprint, entering a PIN code, using voice recognition or even iris scanning.

FIDO UAF Authenticator

A crucial building block of FIDO UAF is the FIDO UAF Authenticator which can create key material and protect it against unauthenticated access. The FIDO Authenticator performs user authentication to allow the usage of this key material in the FIDO authentication protocols. FIDO Authenticators can implement a variety of authentication mechanisms such as biometrics, PIN etc.

FIDO UAF Usage Scenarios

In addition to defining interfaces for (pluggable) authentication mechanisms on the client device, the FIDO specifications also standardise the authentication protocol between the client and the server. Besides the authentication process, the FIDO specifications also define the registration, transaction confirmation and deregistration processes.

Before a user can use a FIDO authenticator for authentication, the authenticator must be registered at the FIDO server. During the registration process, the user must choose a FIDO authenticator that matches the server’s acceptance policy. In the second step, the user unlocks the FIDO authenticator by using a supported authentication method like a fingerprint reader. Once unlocked, the authenticator creates a new public and private key pair on the user's device. This key pair is unique for this combination of user device, FIDO server and user account. Finally, the public key is sent to the FIDO server and associated with the user's account.

Once the user has registered his device, the online service can request an authentication from the registered device. As depicted in the figure FIDO Login Process, the FIDO server sends a challenge to the user's previously registered device (no. 1 in the figure). The user unlocks his authenticator using the same method as the one used during registration (no. 2). The device uses the account identifier provided by the FIDO server to select the correct key and then signs the challenge (no. 3). The signed challenge is sent back to the FIDO server, which verifies it with the stored public key. If the verification was successful, the FIDO server logs in the user (no. 4).

Besides authentication, the FIDO UAF protocol can also be employed to confirm high-value transactions. In the transaction confirmation process, the server sends a challenge to the client device. In response, the user unlocks the FIDO authenticator using the same method as the one used at registration time, the challenge is signed with the now-unlocked private key, and the signed challenge is sent back to the server. The FIDO server verifies the signed challenge with the public key. If the verification was successful, the transaction is confirmed.