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.
Prerequisites
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
Key Custodian 1 should keep these values secret. Then, they should press enter, and walk away.
Key Custodian 2 should press enter to receive their secret.
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.
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 1Finally, we import the DKEK. Each custodian will be asked to provide their secret.
sc-hsm-tool --import-dkek-share dkek.pbe --pwd-shares-total 4Each 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.
The DKEK is deciphered and the plaintext key is imported onto the NitroKey.
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/opensc-pkcs11.so -l --pin 648219 --keypairgen --key-type rsa:2048 --id 10Use the following to enumerate keys on the device:
pkcs15-tool -DTake 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 648219This 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 648219Setting up your replacement NitroKey
Initialize the device:
sc-hsm-tool --initialize --so-pin 25F73632F138383F --pin 648219 --dkek-shares 1sc-hsm-tool --import-dkek-share dkek.pbe --pwd-shares-total 2Note 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 -Dreturns no keys present.
Issue:
sc-hsm-tool --unwrap-key wrap-key.bin --key-reference 10 --pin 648219to import your wrap-key.bin onto the new device.
Once again, issue:
pkcs15-tool -D
We see that the key has been imported back onto the device.
Conclusion
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.
