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, i.e., the target, can differ based on the dispatch channel. Some dispatchers, like the QR code dispatcher, do not require a target.

The following table shows the relationship between channel and target identifier, per channel:

Channel	Target	Example Target Value
Push Message	Usually an identifier used by the 3rd party push service to identify the physical device of the end user or the mobile application.	70d5ebbd-34dd-433c-83c2-69cf1a0a98d9
E-Mail	E-mail address of the end user	[email protected]
QR Code	There is no target for this channel.	-

Channel

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

Examples of possible dispatch channels are:

• Push notifications
• E-mail delivery
• Physical letter delivery
• QR code containing the information to be transmitted

Dispatcher

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

Examples for dispatchers are:

• Firebase Cloud Messaging (FCM) dispatcher The FCM 3rd party service is used to send push notifications to mobile devices/apps.
• E-mail dispatcher An e-mail dispatcher sends e-mails to users directly.
• QR code dispatcher A QR code is generated by the server and presented to the end user. The end user must scan the QR code with a mobile device to transfer the information to the mobile device.
• Link dispatcher The user contacts the server through a mobile device. The server generates a link; when the user clicks this link, a mobile application with the information contained in the link is opened.

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 customer's or project's requirements, 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.

The next sections describe end-to-end description on the basis of the provided FCM dispatcher. The FCM dispatcher uses the Firebase Cloud Messaging Service to send out mobile push messages to mobile devices.

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.