Out-of-Band Message Transmission

The Nevis Mobile Authentication Solution supports the dynamic transmission of out-of-band messages, based on the projects requirements. Certain means of transmitting messages out-of-band are already supported by the product out-of-the box. It is also possible to provide custom implementations.

This chapter describes the terminology and concept behind out-of-band message transmission. An additional feature is the end-to-end encryption of delivered out-of-band messages. This is also explained.

Terminology

Out-of-Band (OOB)

The term out-of-band refers to channels that are not part of the traditional request flow. A traditional request flow consists of a client initiating a conversation with a server, whereupon the server responds and completes the flow. In more sophisticated scenarios, the server can choose to involve clients other than the initiating client in the flow.

These other clients exist independently of the initiating client. Out-of-band channels are the channels through which the server accesses these independent clients.

One example of such an out-of-band scenario is when push notifications are delivered to mobile devices. In a typical use case, a user accesses an e-banking server via (the browser of) his laptop. To verify a transaction, the server sends a push notification to the user's mobile device. This push notification is sent through another channel than the one used by the user/laptop to access the server. This other channel to the mobile device is called the out-of-band channel.

Out-of-Band Message

An out-of-band message is any message delivered over an out-of-band channel. In most cases, out-of-band messages contain sensitive information. Therefore, encrypting the message content and sending it over a trusted out-of-band channel is always advocated. For more information on encryption, see End-to-End Encryption,

In the Nevis Mobile Authentication Solution, out-of-band messages are not customizable. They contain information for the mobile client application, accessed over the out-of-band channel. The mobile client application uses this information to initiate a client-server communication with the server - usually completing a previously started authentication flow.

Dispatching

In the Nevis Mobile Authentication Solution, dispatching is the process of sending out-of-band messages.

The use of a specific term in combination with "dispatching" indicates that the server-to-client communication does not occur through the already established connection but is dispatched via other means.

Dispatch Target

The dispatch target is the intended receiver of the out-of-band message. Every target is directly bound to an end user.

The target is an identifier directly related to the channel used for dispatching. This means that the actual value of the identifier, that is, the target, can differ based on the dispatch channel. Some dispatchers do not require a dispatch target at all: they return the out-of-band payload directly in the HTTP response.

The following table shows the relationship between the built-in dispatchers and their dispatch target requirements:

Dispatcher	Target requirement	Description
FCM Dispatcher	Required	Requires a dispatch target with both a push token (to address the device) and an encryption key (FCM encryption is mandatory).
Link QR Code Dispatcher (recommended)	Optional (recommended)	Supply a dispatch target with an encryption key to prevent QRLJacking. Can be omitted for usernameless authentication or initial out-of-band registration.
QR Code Dispatcher	Optional (recommended)	Supply a dispatch target with an encryption key to prevent QRLJacking. Can be omitted for usernameless authentication or initial out-of-band registration.
Link Dispatcher	Optional (recommended)	Supply a dispatch target with an encryption key to prevent QRLJacking. Can be omitted for usernameless authentication or initial out-of-band registration.

Channel

The dispatch channel represents the means of transmitting the message to the client.

Examples of possible dispatch channels include:

• Push notifications
• QR code
• Deep link
• E-mail delivery
• Physical letter delivery

nevisFIDO provides built-in dispatchers for push notifications, QR codes, and deep links. E-mail and physical letter delivery are examples of channels a custom dispatcher could implement.

Dispatcher

The dispatcher is the concrete implementation of a component that has the task to dispatch the message to the target.

The built-in dispatchers provided by nevisFIDO are:

• FCM (Firebase Cloud Messaging) Dispatcher: Sends a push notification to the mobile device of the user via the Google FCM service. Requires a registered dispatch target with a push token.
• Link QR Code Dispatcher (recommended QR option): Generates a QR code whose content is a deep link URL. Scanning it with the built-in camera app on the device opens the Access App directly; no special QR app is needed.
• QR Code Dispatcher: Generates a raw-payload QR code that can only be processed inside the Access App.
• Link Dispatcher: Returns a deep link URL directly in the HTTP response. Suitable when the web browser already runs on the mobile device and can open the link without a QR code.

For a side-by-side comparison and guidance on choosing the right dispatcher, see the Dispatcher Overview.

Concept

The Nevis Mobile Authentication Solution provides a limited set of dispatcher implementations as part of the product. However, it also allows customers to implement their own dispatcher solution, based on the requirements of the customer or project, and to define how a message is transmitted to the mobile authentication client.

End-to-End Encryption

Nevis Mobile Authentication supports end-to-end encryption of the delivered out-of-band messages. This feature is transparent to the dispatcher in use: all four built-in dispatchers (FCM, Link QR Code, QR Code, and Link) support end-to-end encryption via the same mechanism.

The following sections illustrate the concept using the FCM dispatcher as an example. The same encryption flow applies to all other dispatchers.

Why Use Encryption?

The channel between the FCM server endpoint and the client is encrypted with SSL over TCP. However, the messages itself are not encrypted end-to-end (E2E) between the server and the user device, unless special measures are taken.

Attack Scenarios

The part of the push message that is vulnerable to attacks is the Nevis Mobile Authentication token. These tokens are used to obtain an UAF message for the different UAF operations. Thus, it is not inherently necessary to encrypt the content of the push messages sent by nevisFIDO to a client device. Even if an attacker can get hold of the token, no direct attacks are possible because:

• The attacker does not own the private key of the end user needed to answer the server challenge.
• Token redemption is only possible once, preventing replay attacks.

There is one scenario, however, where it is potentially possible to obtain sensitive information: In transaction confirmation cases, the attacker could abuse the token to get hold of the transaction information of a user. Although the attacker cannot sign the transaction itself, he could obtain sensitive information stored in the transaction text.

Man-in-the-Middle Attacks

It is not possible to prevent Man-in-the-Middle (MITM) attack scenarios, where an attacker intercepts the token during the token redemption process and uses the token to register his own device. But because TLS is used for token redemption, this scenario is unlikely.

E2E Encryption in Nevis Mobile Authentication

E2E encryption can be achieved by generating an asymmetric encryption key pair on the client, registering the public key with the backend, encrypting outgoing messages with the public key, and decrypting messages on the client using the private key. The next figure illustrates this:

Initialisation

As a prerequisite to use the encryption feature, the client must generate the encryption keys locally and store the public key on the Nevis Mobile Authentication backend. See also the previous and the next figure. The interface used to store the public key is part of the nevisFIDO public HTTP API.

Execution

The following figure illustrates the flow when using end-to-end encryption. The dispatcher in use has no impact on the encryption feature, because it is transparent to any dispatch service.

The following list describes the steps of the end-to-end encryption flow. The numbers correspond with the steps in the previous figure.

1. The relying party web application initiates an out-of-band operation.
2. Nevis loads the public key of the dispatch channel of the user.
3. The message content is encrypted with the public key.
4. The encrypted message is sent to the 3rd party dispatch service.
5. The response of the 3rd party dispatch service is handled by Nevis to detect dispatching errors early.
6. The token created during the dispatch operation is forwarded to the application that initiated the out-of-band operation.
7. A visual representation of the token is rendered and shown to the user to allow visual verification of the dispatched message.
8. The mobile client application receives the message out-of-band.
9. The mobile client application loads the matching private key for the encrypted message.
10. The mobile client application decrypts the message content with the private key.