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.
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.
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.
Use only front-facing certificates signed by a trusted certificate authority.
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.
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
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.
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. |
The JWE algorithms used by the mobile SDK are described in the mobile concept guide.
Device and Dispatch Target Services using JWS
Dispatch targets and device information services can be accessed 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 to symmetric ones.
- Take different key material than those used for the end-to-end encryption.
The JWS algorithms used by the mobile SDK are described in the mobile concept guide.