Security Considerations

Nevis Mobile Authentication is an extensible and flexible solution, whose security considerations depend on many factors. This chapter provides integrators and system architects with security guidelines focusing on the use cases described in Use Cases and Best Practices.

Overview

FIDO UAF transfers many security critical aspects to client-side components, including the storage of private keys. Storing critical information on the client-side is the core security concept of the FIDO UAF specification. Client-side private key protection and TLS channel binding are assumed but not explicitly specified in the specification.

The Nevis Mobile Authentication Solution adheres to the Nevis product security guidelines and standards.

FIDO UAF Specific Security Considerations

This section lists and explains the Nevis Mobile Authentication answers and solutions to the FIDO UAF Security Considerations for the security considerations posed by the protocol specification.

Consideration	Scope	Solution
4.3.1 Authenticator Security	client	Not applicable - must be solved on the FIDO client-side.
4.3.2 Cryptographic Algorithms	both	The nevisFIDO component of Nevis Mobile Authentication currently supports a subset of the specified algorithms. See Supported Algorithms.
4.3.3 FIDO Client Trust Model	client	Not applicable - must be solved on the FIDO client-side.
4.3.4 TLS Binding	client	Not applicable - must be solved on the FIDO client-side. The client is responsible for server certificate validation.
4.3.5 Session Management	both	Secure session management is ensured by the usage of Nevis cookies or JWT tokens by the client and the SecToken between the nevisProxy and nevisFIDO components.
4.3.6 Persona	both	The nevisFIDO component supports the usage of anonymous tokens and session IDs. The username is only required during the registration.
4.3.7 ServerData and KeyHandle	server	The nevisFIDO component binds the ServerData to the session and verifies the returned data. The ServerData is kept in the session store. Therefore, tampering by an attacker is not possible. Session timeout concepts exist to invalidate ongoing sessions. Such concepts can be configured on nevisFIDO instance level.
4.3.8 UAF Application API	server	The nevisFIDO component uses a static customized metadata configuration. By defining the metadata statements when using the product, a fine granular control of the allowed authenticators is possible.
4.3.9 Policy Verification	server	The nevisFIDO component prevents policy manipulation by a MITM attack. See also RegistrationResponse Policy Validation. Changing the used policies with malicious intent it not possible.
4.3.10 Replay Attack Protection	server	The nevisFIDO component verifies that the server challenge was generated on the server, and that it is used only once. Tampering is not possible. See also Token Redemption.
4.3.11 Cloned Authenticators	both	The nevisFIDO component supports the "Signature-Counter". The Signature-Counter can be used to detect cloned authenticators, and to prevent them from signing in. This is a built-in functionality. It requires no further action when using the product.
4.3.12 Anti-Fraud-Signals	both	The nevisFIDO component does not inherently support fraud detection. A possible fraud use case would be when a malicious user registers an authenticator and commits fraud in a relying party application, then deregisters the authenticator and repeats the process. ❗Fraud prevention is not part of the Nevis Mobile Authentication Solution. To detect and prevent fraud, it is recommended using nevisDetect.

Token Redemption

The proprietary token interface provided by the nevisFIDO component of Nevis Mobile Authentication allows to prepare FIDO operations to later obtain them by redeeming a random and unique token.

A core security consideration of this interface is the fact that it only allows to redeem a requested token once. After the token has been redeemed it cannot be redeemed again. This restriction mainly intends to prevent replay attacks. As this functionality is built in, no further action is required when using the Nevis Mobile Authentication solution.

caution

Tokens must only be transmitted using end-to-end encryption to avoid information disclosure. The token endpoint is vulnerable to session-hijacking allowing a 3rd party to execute an operation in another persons name in certain scenarios. For example: by gaining access to a token it is possible for a 3rd party to gain knowledge of the content of a transaction confirmation message.

However, because the token is a secure random UUID, it is highly unlikely for an attacker to "guess" a valid token.

End-to-end encryption is currently not part of the Nevis Mobile Authentication solution. If it is required in a specific setup, it must be implemented manually.

HTTP API Protection

It is important that nevisProxy appropriately protects the HTTP API of the nevisFIDO component of Nevis Mobile Authentication.

Some endpoints do not require explicit protection against unauthenticated access. These endpoints include:

• The facets service, which must be reachable by a FIDO Client without authentication.
• The status service, because you already need a unique session identifier to query a session's status. Also, the endpoint does not expose sensitive information.
• The authentication endpoints.

However, it is recommended mapping these endpoints via nevisProxy (instead of directly exposing them to the Internet). Refer to Default HTTP API Endpoints for details.

Action Required

To protect the registration endpoint is critical. Without protection, it may be possible for any user to impersonate another user and register a FIDO Client for authentication.

Therefore, only authenticated users must be able to access this endpoint!

This can be achieved as follows: Each user must perform a "legacy login" flow in nevisAuth, which leads to the creation of a SecToken. The SecToken can then be consumed by the registration endpoint of the nevisFIDO component, by using the SecToken username provider. A "legacy login" may be a username/password login.

TLS Channel Binding

As the nevisFIDO component itself as well as the protected relying party application is located behind nevisProxy, it is important to ensure a secure TLS channel between a FIDO Client and the backend.

Action Required

Therefore, the following measures are highly recommended when using Nevis Mobile Authentication in a production environment:

• Use only front-facing certificates signed by a trusted certificate authority. We strongly advise against the use of self-signed certificates in production environments.
• Use client-side certificate pinning to ensure the server certificate is the one expected by the FIDO Client.
• Enable requiring client TLS (2-way TLS) in nevisFIDO.

caution

The current version of the nevisFIDO component does not support the channel binding UAF protocol messages described in the FIDO UAF 1.1 Message Specification.

Advantages of Requiring Client TLS in nevisFIDO

• Only the endpoints exposed by nevisProxy can be used to access nevisFIDO from the outside network.
• Only explicitly allowed applications can use nevisFIDO. One of these applications can be nevisAuth, another application could be a bank application that uses nevisFIDO to confirm transactions.

Because only trusted applications are allowed to use nevisFIDO, some endpoints might not require a protection with a SecToken. Take, for example, an application that validates a credit card transaction invoked by a third party. This application requires access to nevisFIDO to complete a transaction confirmation. If the out-of-band flow is required, the application must have access to the dispatch targets associated with the user owning the credit card. In this context, not protecting the query dispatch targets endpoint of nevisFIDO with a SecToken simplifies the deployment because only the credit card application can access the endpoint, not the user. If a FIDO client application is not-trusted, it will not be able to retrieve the dispatch target information of a user, independent from whether the user itself is authenticated.

Supported Attestation Types

Authenticator attestation is a core concept of FIDO UAF. Currently, Nevis Mobile Authentication only supports Surrogate Basic Attestation , full basic attestation will follow in the near future.

Supported Algorithms for Attestation Validation

When performing the attestation validation, the nevisFIDO component of Nevis Mobile Authentication supports the following pairs of authentication algorithms and Public Key Representation Formats:

Authentication Algorithm	Public Key Representation Format
ALG_SIGN_SECP256R1_ECDSA_SHA256_DER	ALG_KEY_ECC_X962_DER
ALG_SIGN_SECP256R1_ECDSA_SHA256_DER	ALG_KEY_ECC_X962_RAW
ALG_SIGN_SECP256R1_ECDSA_SHA256_RAW	ALG_KEY_ECC_X962_DER
ALG_SIGN_SECP256R1_ECDSA_SHA256_RAW	ALG_KEY_ECC_X962_RAW
ALG_SIGN_SECP256K1_ECDSA_SHA256_DER	ALG_KEY_ECC_X962_DER
ALG_SIGN_SECP256K1_ECDSA_SHA256_DER	ALG_KEY_ECC_X962_RAW
ALG_SIGN_SECP256K1_ECDSA_SHA256_RAW	ALG_KEY_ECC_X962_DER
ALG_SIGN_SECP256K1_ECDSA_SHA256_RAW	ALG_KEY_ECC_X962_RAW
ALG_SIGN_RSA_EMSA_PKCS1_SHA256_DER	ALG_KEY_RSA_2048_DER
ALG_SIGN_RSA_EMSA_PKCS1_SHA256_DER	ALG_KEY_RSA_2048_RAW
ALG_SIGN_RSA_EMSA_PKCS1_SHA256_RAW	ALG_KEY_RSA_2048_DER
ALG_SIGN_RSA_EMSA_PKCS1_SHA256_RAW	ALG_KEY_RSA_2048_RAW
ALG_SIGN_RSASSA_PSS_SHA256_DER	ALG_KEY_RSA_2048_DER
ALG_SIGN_RSASSA_PSS_SHA256_DER	ALG_KEY_RSA_2048_RAW
ALG_SIGN_RSASSA_PSS_SHA256_RAW	ALG_KEY_RSA_2048_DER
ALG_SIGN_RSASSA_PSS_SHA256_RAW	ALG_KEY_RSA_2048_RAW

The algorithms and formats used depend completely on the FIDO Clients' capabilities (described in the specific authenticator metadata statement).

Outgoing TLS Proxies on the Client Side

caution

Nevis Mobile Authentication does not provide out-of-the-box integration with client-side TLS proxies. The reason for this is that the proxy serves as a TLS termination endpoint, which cannot be detected on the server side. If you use environments with this infrastructure in place, securing the communication between the client- and the server-side must be solved outside the product's capabilities.

Out-of-Band End-to-End Encryption

Nevis Mobile Authentication supports optional asymmetric encryption of the message content sent through a dispatch channel. The encryption private key is held by the Nevis Mobile Authentication client whilst the public key is stored in the backend.

info

Encrypting the message content serves to eliminate the following main security concern: If an attacker gets hold of the Nevis Mobile Authentication token used to obtain an UAF request, he could potentially read plaintext transaction information enclosed in the UAF request. This scenario is prevented by encrypting the message before it is sent to a 3rd party dispatcher.

Firebase Cloud Messaging Dispatcher End-to-End Encryption

The provided Firebase Cloud Messaging Dispatcher enforces end-to-end message encryption. It relies on the JWE standard and supports the following algorithms:

Encryption Algorithms	Description
RSA_OAEP_256_WITH_A256GCM	RSAES using Optimal Asymmetric Encryption Padding (OAEP) (RFC 3447), with the SHA-256 hash function and the MGF1 with SHA-256 mask generation function. AES in Galois/Counter Mode (GCM) (NIST.800-38D) using a 256 bit key.
RSA_OAEP_256_WITH_A256CBC_HS512	RSAES using Optimal Asymmetric Encryption Padding (OAEP) (RFC 3447), with the SHA-256 hash function and the MGF1 with SHA-256 mask generation function. AES_256_CBC_HMAC_SHA_512 authenticated encryption using a 512 bit key.
ECDH_ES_A256KW_WITH_A256GCM	Elliptic Curve Diffie-Hellman Ephemeral Static key agreement per "ECDH-ES". Note that the agreed-upon key is used to wrap the Content Encryption Key (CEK) with the "A256KW" function, rather than being used directly as the CEK. AES in Galois/Counter Mode (GCM) (NIST.800-38D) using a 256 bit key.
ECDH_ES_A256KW_WITH_A256CBC_HS512	Elliptic Curve Diffie-Hellman Ephemeral Static key agreement per "ECDH-ES". Note that the agreed-upon key is used to wrap the Content Encryption Key (CEK) with the "A256KW" function, rather than being used directly as the CEK). AES_256_CBC_HMAC_SHA_512 authenticated encryption using a 512 bit key.

Updating Dispatch Target Information using JWS

Dispatch targets can be updated by HTTP clients using JSON Web Signature (JWS). This allows a client to update the information at any given time and in a way that is transparent to the end user (without requiring additional user interaction). This is especially useful for dispatch target identifiers that might change at an arbitrary point in time (as is the case with Firebase Cloud Messaging identifiers).

The JWS is generated with the private signature key of the dispatch target to be modified. The private signature key is assumed to be safely stored by the client modifying the dispatch target. Disclosing the private key would allow any client to modify the dispatch target of the user. This can lead, for example, to a denial-of-service for the user associated with the dispatch target (that is, the user would not be able to authenticate anymore).

The client decides at creation time about the key generation and the algorithms to use. However, to increase the overall security of the key material, it is recommended to follow the next rules:

• Use EC or RSA based keys.
• However, do not use RSA keys with PKCS #1v1.5 padding, because they are vulnerable to padding oracle attacks.
• Prefer asymmetric keys over symmetric ones.
• Take different key material than those used for the end-to-end encryption.