Out-of-Band Channel Linking

The channel linking mechanism allows the end user to verify the link between devices that participate in out-of-band authentication. Currently, the visual string channel linking is the only channel linking method supported out-of-the box by Nevis Mobile Authentication.

This is how it works: The system generates a random string in the backend and sends the string to both devices used for the out-of-band authentication. Each device shows the string to the end user. The end user must confirm that the same string is presented on both devices.

The following figure illustrates the process:

Attack Scenario

The goal of channel linking and verification is to create protection against attacks. The main use case is where an attacker tries to access a system as being a legitimate user.

Suppose a system is protected by out-of-band authentication. If a given attacker knows the identifier of a legitimate user, the attacker could try to access the system from his own device (for instance a laptop). This will trigger a push notification being sent to the client of the legitimate user. If this user then inadvertently authenticates himself, for example per fingerprint, he will give access to the attacker. By adding a supplementary layer of security it is possible to mitigate such an attack.

Imagine the following scenario: You sit in a coffee shop and want to execute some eBanking transactions. You therefore start the login process to the eBanking application, on your laptop. If your eBanking application is protected by Nevis Mobile Authentication, the system will send a push notification to your mobile device, requesting you to authenticate. Now assume an attacker sits in the same coffee shop. This attacker tries to log in to the same eBanking application, with your username. As a consequence, a corresponding push notification is being sent to your mobile device. If you confirm this push notification, thinking it belongs to the eBanking login process you just started, you will in fact confirm the attacker's authentication request. This leads to the attacker being logged in instead of you.

You can avoid such a scenario if you are able to verify that the authentication request sent to your device B really belongs to the login process you started on your device A. This is where the channel linking mechanism comes in.

Security Considerations

The channel linking and verification must be concluded before the FIDO UAF authentication. Otherwise nevisFIDO would expose the user as authenticated in the status service, even though the user did not verify the channel verification.

One security concern could be that an attacker steals the verification content, for example by intercepting the response to the dispatch token request. However, this does not imply a risk: Also in this case the user is able to link the verification information on his mobile device with the verification information on his laptop.

An exception would be if the attacker gains control of the laptop of the user and presents the verification information to the user's mobile device. As this scenario is highly unlikely, there are no additional security measures in place to cover it.