Open

Nexus' statement of commitment

Nexus is dedicated to the implementation of an active, analytics-driven approach to cybersecurity. Security testing and improvement are ongoing activities that are incorporated into our vulnerability and threat management process.

Nexus performs continuous testing on all mobile solution components to ensure the highest possible level of security. We regularly engage external security auditors to validate our security posture. The regular assessments of application and system vulnerability threats cover the following:

• network vulnerability threat assessments,

• penetration testing and code review with leading, independent third parties, and

• security control framework review and testing.

Our commitment to ensure security was recently noted by an external auditor who declared it is evident that Nexus has made a significant effort to reduce the overall risk that is facing certificate-based security. Contact Nexus for more information. 

As trust relates to transparency, all major call flows and APIs are available on our documentation website.

We strongly encourage customers to take all possible precautions to prevent unauthorized access using the current best practices in information security. In case any vulnerabilities are discovered in Nexus' products, they should be reported to Nexus without delay.

Please note that Nexus permits third-party vulnerability and penetration tests with Nexus' approval. Vulnerability and penetration tests shall not be attempted without Nexus' guidance, particularly not in a production environment, as uncontrolled tests may impact system availability, performance and security negatively.

Finally, the overall security in the system has dependencies on the overall PKI solution including the use of Hardware Security Modules (HSMs) and CA software. Lifecycle management processes should mitigate the risks when a device is in vulnerable state, for example lost or misused. Revocation of authentication and signing certificates and the distribution of certificate revocation lists (CRLs) to relying parties should be implemented for this case.

Nexus' CA software Certificate Manager is certified in compliance with Common Criteria for Information Technology Security Evaluation (CC) EAL4+ and covers lifecycle management and revocation processes. 

Introduction to Nexus Smart ID Mobile App

Smart ID Mobile App - a part of Nexus Smart ID

Since the Smart ID Mobile App is an integral part of Nexus Smart ID, it can out-of-the-box leverage the features and processes developed and excelled for many years granting a smooth and secure experience for both users and administrators. 

Nexus Smart ID Workforce provides easy-to-use modules to issue, manage and use trusted employee identities in the form of digital smart cards for mobile devices and physical cards. 

Here are some features that could be combined with the Smart ID Mobile App: 

• Digital access and single sign-on 

• Lifecycle management of users and digital identities 

• User self-service  

Integration with web applications, authentication and digital signing services can be achieved using industry standard protocols, published APIs, and SDKs.

Open

The Smart ID Mobile App includes the following standard components:

• Smart ID Mobile App – stand-alone app for iOS and Android

• Smart ID Mobile SDK – security and communication core to be integrated in third-party mobile apps, for iOS and Android

• Smart ID Messaging (Hermod) - Spring-Boot Java server shipped as Docker container.

The Smart ID Mobile App works in combination with Smart ID Messaging, which represents the server side of the security infrastructure as well as the connection point to other server-side systems and services. 

Security Features

Overview of layered security model

Nexus Smart ID Mobile App implements a layered security model using various technologies and security measures where the combination of these provide a resilient design, with no single point of exposure and failure. The target is to protect the user credential and private key from exposure at all times and keep the app safe from cyber attacks and hackers.

Security blocks

The layered security model of the Smart ID Mobile App is constituted by a set of security blocks, listed below.

Private key security and storage

• Cryptographic Keys

  • Private keys are non-exportable

  • All cryptographic keys are stored AES-encrypted using key derived from the user PIN (see section "Distributed security model").

• Secure Storage

  • Encrypted cryptographic keys are stored in the Mobile App with access to the keys protected by an encryption scheme backed up by Android Keystore and iOS Keychain APIs

• Biometrics

  • PIN optionally protected by biometrics as provided by device OS and model:

    • Fingerprint on Android and TouchID on iOS

    • Face Detection on Android and FaceID on iOS

Mobile App and SDK hardening

• Industry-leading third-party security product for hardening

  • Used in Smart ID Mobile App both for App and SDK protection.

  • Regularly upgraded so that Smart ID Mobile App and SDK are always running the latest version.

• Security capabilities

  • Jailbreak and root detection to make sure Smart ID Mobile App or third-party Apps running our SDK, can only run in a safe environment

  • Code obfuscation which prevents key extraction, tampering, cloning and reverse engineering of the App and SDK

  • Debug mode prevention

  • Checksums (guards) which checks the integrity of the code

  • Encryption of literal strings

Mobile App security 

• OS sandbox model

  • Utilizes built-in OS security and OS sandbox model

  • App runs in an app sandbox, which in turn runs in an OS sandbox separated from the rest of the system, so that only Smart ID Mobile App can access data store in keychain/keystore

• Agile development and deployment model

  • Constantly evolving automation tests catering for quick regression testing on many device types in parallel

  • Short turn-around time from implementation to deployment

  • Automatic update via stores

  • Quick remedies for potential future vulnerabilities

• Security reviews

  • Periodical security review by external contractor

  • Open and transparent process for security audits and reviews together with customers.

• Screenshot protection

  • Prevents user from taking screenshot of Visual ID

  • Prevents user from mirroring the mobile app to a computer or other device

Online authentication

• Smart ID Messaging

  • Messaging server (Hermod) which provides a secure communication channel between the Mobile App/SDK and server-side components for Identity Management, Digital Access, Digital Signing and so on

  • Messaging server actively takes part in an Online PIN process (see section "Distributed security model") invoked in online scenarios where the private key needs to be used in a cryptographic process (Not applicable for offline OTP scenarios)

  • HTTPS communication based on TLS with server side authentication

• Verification

  • Session verification by verification images being displayed both on server side and in the Smart ID Mobile App

• Certificate pinning

  • Provides means to control that the Smart ID Mobile SDK can only communicate with a dedicated Messaging server

PIN policy

• PIN size 

  • Minimum six (6) digits

• PIN blocking policy

  • Three failed PIN entries result in blocking the PIN for 5 minutes

  • 4th-8th failed PIN entries lead to blocking the PIN for 10, 20, 40, 80, 160 minutes

  • 9th failed PIN entry leads to blocking the PIN for 320 min + warning/alert

  • 10th failed PIN entry the profile will be deleted

• PIN pattern policy

  • Restricts users from setting too simple PIN

Security standards

• PKI – Public Key Infrastructure, see PKCS

• Javascript Object Signing and Encryption (JOSE), see https://www.iana.org/assignments/jose/jose.xhtml

• RSA2048 key size, or higher.

• RSA PKCS#1 signature with SHA-256, see RFC 8017: PKCS #1: RSA Cryptography Specifications Version 2.2

• AES encryption, see https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf

• X.509 certificates support, see RFC 2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile

• PKCS#10 Certificate Signing Request, see RFC 2986: PKCS #10: Certification Request Syntax Specification Version 1.7  

• PKCS#12 archive file format bundling private keys with X.509 Certificates, see RFC 7292: PKCS #12: Personal Information Exchange Syntax v1.1

Secure provisioning

• Secure provisioning of certificates and keys

  • Invoked from helpdesk/admin

    • Device authentication via one-time activation code (OTP) included in URL (QR code or web link)

  • Self-service portal using other 2FA method or username & password temporarily

    • Display QR code containing one-time activation code in self-service portal

• Enrollment processes for certificate, keys and one-time passwords (OTP)

  • Creation of one-time password (OTP) profiles, both time-based (TOTP) and event-based (HOTP), see: RFC 6238: TOTP: Time-Based One-Time Password Algorithm  and RFC 4226: HOTP: An HMAC-Based One-Time Password Algorithm

  • Enrollment of raw keys, which means keys not bundled or associated with any certificate

  • Enrollment of X.509 certificates according to a PKCS#10 schema where the private key is generated by Smart ID Mobile App on the mobile device

  • Enrollment of X.509 certificates according to a PKCS#12 schema with the private keys already generated and bundled with the certificates.

  • Refer to Hermod API examples for further details on enrollment processes

• One-time activation codes (relevant for raw keys and certificate based virtual smart cards)

  • Can only be used once, as implied by name, and instantly destructed upon consumption

  • Based on double random UUID's

  • Configurable expiration time where the request order corresponding to the one-time activation code is destructed upon code expiration

Distributed security model

To further strengthen the protection of the PKI private key over the security features that are laid out in the previous sections, Smart ID Mobile SDK in conjunction with Smart ID Messaging implements a dual architecture to prevent extraction on the private key stored in the device. 

Three security elements are required to bypass private key protection:

• The PIN set by the User, optionally further protected by biometrics

• A cryptographic secret generated and stored protected in the App

• A cryptographic secret generated and stored protected in Smart ID Messaging ​

Neither the mobile device nor the server holds all three elements, so stealing a PIN and hacked phone will not enable retrieving a private key. 

The server controls the number of access attempts, to protect the private keys from exposure to for instance a brute force attack. 

The mobile device and server work together using an advanced cryptographical protocol known as SPHINX, which is similar to Diffie-Hellman key establishment. See https://eprint.iacr.org/2018/695.pdf.