The first revision of the Nitrokey HSM introduces several sophisticated key management features:
n-of-m threshold scheme
The n-of-m threshold scheme enables 4-eye principle, which grants access to cryptographic keys stored on a Nitrokey HSM only when two administrators are present. More precisely, a number n of persons (key custodians) from a group of m need to collaborate in order to access the protected keys. A single person can’t access the keys alone. An attacker would need to compromise n persons. If a single person becomes unavailable or loses their credential, key access is still possible as long as n persons are available.
Each key custodian requires their own Nitrokey HSM containing their personal authentication key. The group of persons (e.g. employees) may change over time. Key custodians don't need to be physically present in any phase, as the protocol is designed to work remotely.
The new Nitrokey HSM implements the n-of-m threshold scheme based on public key authentication. Instead of user PINs, authorised public keys are used by key custodians and setup via a key ceremony during device initialisation. The authorised public keys can’t be changed once the device is in operation. The actual authentication protocol uses a challenge-response mechanism in which a key custodian signs a challenge and the device ID. The Nitrokey HSM verifies the resulting signature using the authorised public keys. Key access is granted only if sufficient (n) key custodians are authenticated.
The n-of-m threshold scheme requires a software development kit (SDK) which is available on request.
Transport PIN Mode
The transport PIN mode allows a security officer to define a PIN protection for the transport of a Nitrokey HSM from the initial device preparation to the final user. The Transport-PIN is like an electronic seal that allows the user to check if their device’s keys have been used before. A Transport-PIN must be changed to a self-selected PIN before access to the keys can be granted.
Key Restriction allows the user to impose certain limits on the algorithms with which a key can be used. This ensures that only approved algorithms (e.g. sign, decrypt, PKCS#1 V1.5, PSS) can be used with the key. Key restrictions are set during key generation and remain in place during the key’s lifetime.
Key restrictions also allow the limitation of the export of keys from the device if a Device Key Encryption Key (DKEK) is set or if the key has been imported into the device.
Key Use Counter
To limit the use of a key and to effectively audit its use, a key use counter can be defined during key generation. The key use counter is decremented with each key operation. An expired key use counter blocks a key from further use.
While it is not advised to import keys from unknown sources, there are situations in which an existing key must be imported to a Nitrokey HSM (e.g. in a CA key migration).
In such cases the provided SDK provides a mechanism that allows keys contained in a PKCS#12 container to be encrypted into a format suitable for import to a Nitrokey HSM.
However, the general advice is to generate keys in the Nitrokey HSM using the Common Criteria certified key generation algorithm and DRNG.2 rated random number generator.
Maximum number of keys
The new Nitrokey HSM can store up to 32 x RSA 2048 keys and 40 x ECC 256 keys.
Since its release the Nitrokey HSM has contained the following features:
The Nitrokey HSM features a build-in PKI that signs public keys of key pairs generated in the device. An external entity (e.g. a CA) can verify the device-generated signature to prove authenticity, integrity and origin of the public key. For this purpose, the Scheme Root CA maintained by our partner CardContact issues certificates for Device Issuer CAs, which in turn issue a unique device certificate for each Nitrokey HSM. Alternatively, for a sufficient large amount of devices you may be interested in running your own root (available on request).
In the certification process, a world-wide unique identifier is assigned and linked with the device authentication key. This ensures that the device identity can be cryptographically proven.
A local or remote client can establish a secure communication channel with the Nitrokey HSM, similar to a SSL/TLS connection. The mechanism uses an asymmetric key agreement scheme in order to negotiate symmetric keys for encryption and integrity protection of the exchanged data. This way the device is linked to the client, protecting the transmission of sensitive data (e.g. PINs or data to be signed) and reenforcing the integrity of the exchanged commands.
Key Backup and Restore
For very important keys it is recommended that users create a backup of the key material. The Nitrokey HSM supports encrypted key backup and restore using the Device Key Encryption Key (DKEK) that can be defined during device initialisation. The DKEK ensures that cryptographic material is never exposed as plain text.
A comprehensive DKEK management scheme allows shared control for the DKEK with XOR shares and an n-of-m threshold scheme.
The Nitrokey HSM supports an initialisation code (SO-PIN) and a User-PIN. The former protects initialisation of the device, while the latter protects access to keys. PINs have an associated retry counter that prevents exhaustive PIN attempts.
Public Key Authentication
Public Key Authentication is an alternative authentication mechanism that can be used instead of the User-PIN. It works by registering a public key from a different Nitrokey HSM during initialisation.
For authentication, a challenge-response protocol is executed between the Nitrokey HSM and the entity requesting authentication.
The new Nitrokey HSM is ideal for operating a CA or PKI and for all use cases which are more complex than a single user scenario. It is available from now on in our online shop.