Website Security Solutions | Latest Guides | Blog

This is perhaps one of the most abstract uses of an HSM, so let’s start with a real-world scenario. Your IT department recently read the last article in this series and wants to setup an offline root CA whose private key is stored on the Nitrokey HSM. Just like any hardware, the NitroKey has the potential to be a single-point-of-failure. Nitrokey’s backup model allows for backups to be taken that are only restorable (to another nitrokey) by providing a DKEK (Device Encryption Key) file and some number its corresponding valid passwords. What if, however, you want to require multiple company officers to be present for this operation? Much like accessing nuclear launch codes, or two keys required to operate weapons in a submarine, an M of N scheme requires M (a pre-defined subset) of N key custodians to be present in order to perform this very sensitive operation! In our example today, we will be demonstrating how to setup 4 elected company officers with their own private password, and require any 2 of them in order to recover from the loss of the HSM device.


Make sure that you have read the last two articles in our series. There are no additional dependencies, but follow along “Nitro HSM Setup” to get a working environment created. You will need your nitrokey’s SO pin in order to perform these operations.

Getting Started

It’s worth noting that the M of N scheme must be asserted when the device is first provisioned. Otherwise, you will want to re-provision it which erases all key material on the device.

First, we will create a DKEK with 4 “password shares” and a threshold requiring 2 of them to be present in order to decrypt the DKEK.

sc-hsm-tool --create-dkek-share dkek-share-1.pbe --pwd-shares-threshold 2 --pwd-shares-total 4
sc-hsm-tool create-dkek-share sc-hsm-tool create-dkek-share 2 sc-hsm-tool create-dkek-share 3

Key Custodian 1 should keep these values secret. Then, they should press enter, and walk away.

sc-hsm-tool create-dkek-share 4

Key Custodian 2 should press enter to receive their secret.

sc-hsm-tool create-dkek-share 5

It is time for Key Custodian 2 to press enter and walk away.

This process is repeated until each of the 4 key custodians has exclusive access to only their secret.

sc-hsm-tool enciphering

Finally, the DKEK is enciphered and written to the file system. Each key custodian should keep a copy of the DKEK for redundancy’s sake, but it is only useful for import if M of N custodians are present to provide their secret!

Now we will use this specially crafted DKEK for provisioning our device.

sc-hsm-tool --initialize --so-pin env:SOPIN --pin env:USERPIN --dkek-shares 1

Finally, we import the DKEK. Each custodian will be asked to provide their secret.

sc-hsm-tool --import-dkek-share dkek.pbe --pwd-shares-total 4

Each key custodian receives the same “Prime” value, and a unique Share ID and Share Value. The first Key Custodian is prompted to present BOTH the shared Prime and their custodian secret.

sc-hsm-tool import-dkek-share sc-hsm-tool import-dkek-share 2 sc-hsm-tool import-dkek-share 3 sc-hsm-tool desciphering

The DKEK is deciphered and the plaintext key is imported onto the NitroKey.

sc-hsm-tool desciphering finished

Creating a Key

We can’t very well export a key that doesn’t exist, so let’s create one now in order to demonstrate the key export. Notice that the pin, NOT the SO PIN is needed for this operation.

pkcs11-tool --module /usr/lib/x86_64-linux-gnu/ -l --pin 648219 --keypairgen --key-type rsa:2048 --id 10

Use the following to enumerate keys on the device:

pkcs15-tool -D

Take note of the “Key ref” value. This will be used as input to the next command.

sc-hsm-tool --wrap-key wrap-key.bin --key-reference 1 --pin 648219

This will generate a file, wrap-key.bin which must be saved somewhere safe.

In order to restore this key material to another NitroKey, it must have been provisioned with the SAME DKEK (which as you remember requires at least 2 of the 4 possible key shares).

Then, it can be imported onto the new device with:

sc-hsm-tool --unwrap-key wrap-key.bin --key-reference 10 --pin 648219

Setting up your replacement NitroKey

Initialize the device:

sc-hsm-tool --initialize --so-pin 25F73632F138383F --pin 648219 --dkek-shares 1
sc-hsm-tool --import-dkek-share dkek.pbe --pwd-shares-total 2

Note that we are only using 2 of the 4 key shares here, to demonstrate that we only need m of n custodians to import a key. I elected to provide share IDs 3 and 4.

Notice that because we’ve initialized the device for the first time...

pkcs15-tool -D

returns no keys present.


sc-hsm-tool --unwrap-key wrap-key.bin --key-reference 10 --pin 648219

to import your wrap-key.bin onto the new device.

Once again, issue:

pkcs15-tool -D
pkcs15-tool list

We see that the key has been imported back onto the device.


The NitroKey HSM has a mature mechanism for splitting up ultimate responsibility for the security of the key material amongst multiple key custodians. This protects against not only attack from an external party, but from disgruntled employees trying to do damage on their way out the door. This is an extremely impressive feature for a device that comes in at such a low price point. Even some of the bigger players in the space do not provide such an elegant solution.

Author: Jeremy Schatten

    Next Guide...
    Encrypting files with GPG using GPG4WIN

    Usually we focus on SSL/TLS and its role in encryption in-transit. However, equally worth understanding is encryption at-rest. While encryption in-transit (also called in-flight) focuses on secure transmission via an insecure channel, both the sending and receiving endpoint have access to the…