Have you ever accidently deleted an important cryptographic key? Or suffered a hardware defect which results in the loss of key material?

The SmartCard-HSM has a built-in mechanism for secure key backup. Here is how to use it.

The backup mechanism exports sensitive key material in an encrypted (AES-CBC) and integrity protected (AES-CMAC) format. It can be easily set up using the sc-hsm-tool, which is provided as part of the OpenSC framework.

During the initialization of the SmartCard-HSM you enable the key backup mechanism by specifying a number of Device Key Encryption Key (DKEK) shares. The DKEK is used to derive the actual keys used for encryption and integrity protection of the exported key blob.

The SmartCard-HSM supports an arbitrary number of DKEK shares. Typical values for the number of shares are :

  • 0 - The SmartCard-HSM generates an internal DKEK
  • 1 - The SmartCard-HSM requests one external DKEK share to be imported
  • 3 - The SmartCard-HSM requests three external DKEK shares to be imported by three different key custodians

In practice one would e.g. use zero key shares to enable the key backup from and to a specific SmartCard-HSM. This prevents the accidently deletion of a key as it could be restored from the backup. But keep in mind that once the SmartCard-HSM suffers a hardware defect, the DKEK of this SmartCard-HSM is lost and therefore all exported key material is unrecoverable.

A better choice to additionally prevent data loss in case of a hardware defect would be to use one or three DKEK shares. The usage of externally generated key shares has the advantage that these DKEKs can be imported to a new SmartCard-HSM and the formerly generated key backups can then be restored.

BTW: The usage of externally generated DKEK shares also allows a smart way of clustering SmartCard-HSMs (e.g. for performance or availability reasons). All SmartCard-HSMs can import key blobs which are exported from another SmartCard-HSM sharing the same DKEK.

Generation of DKEK Shares

Initialize the SmartCard-HSM using a single DKEK share

$ sc-hsm-tool -X --dkek-shares 1

The SmartCard-HSM is initialized and waiting for the import of the pending DKEK share

$ sc-hsm-tool
Using reader with a card: SCM SCR 355 [CCID Interface] 00 00
Version              : 1.2
User PIN tries left  : 3
DKEK shares          : 1
DKEK import pending, 1 share(s) still missing

Next create a DKEK share and save it to a file protected using password based encryption.

$ sc-hsm-tool --create-dkek-share my_dkek_share.pbe

The sc-hsm-tool guides you through the generation process.

Finally we need to import the generated DKEK share to the SmartCard-HSM:

$ sc-hsm-tool --import-dkek-share my_dkek_shared.pbe
Using reader with a card: SCM SCR 355 [CCID Interface] 00 00
Enter password to decrypt DKEK share : 

Deciphering DKEK share, please wait...
DKEK share imported
DKEK shares          : 1
DKEK key check value : 2BA159D3ADA6A53D

That’s all we need to do. The DKEK is imported (as indicated by the DKEK key check value) and the SmartCard-HSM is ready for key backup and restore.

Key Backup and Restore

To demonstrate the key backup and restore mechanism, we create a sample key on the SmartCard-HSM.

$ pkcs11-tool --module /usr/local/lib/opensc-pkcs11.so -l --pin 648219 --keypairgen --key-type rsa:2048 --id 01
Using slot 1 with a present token (0x1)
Key pair generated:
Private Key Object; RSA 
  label:      Private Key
  ID:         01
  Usage:      decrypt, sign, unwrap
Public Key Object; RSA 2048 bits
  label:      Private Key
  ID:         01
  Usage:      encrypt, verify, wrap

To determine the correct key reference identifier (key ref) of the key that we want to backup, we issue the following command:

$ pkcs15-tool -D
Using reader with a card: SCM SCR 355 [CCID Interface] 00 00
PKCS#15 Card [SmartCard-HSM]:
    	Version        : 0
        Serial number  : UTTMRN43855
        Manufacturer ID: www.CardContact.de
    	Flags          : 

Private RSA Key [Private Key]
    	Object Flags   : [0x3], private, modifiable
        Usage          : [0x2E], decrypt, sign, signRecover, unwrap
        Access Flags   : [0x1D], sensitive, alwaysSensitive, neverExtract, local
        ModLength      : 2048
        Key ref        : 1 (0x1)
        Native         : yes
        Path           : e82b0601040181c31f0201::
        Auth ID        : 01
        ID             : 01
    GUID           : {84e7bcc4-64a1-ba44-ebd5-9e9e9be5a7e0}

Finally we can backup the key to an encrypted and secure file container using the following command:

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

To restore the key from the backup, we issue the following command:

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

Some Security Considerations

DKEK shares are random key values generated using the random number generator of the SmartCard-HSM. They are encrypted using the password supplied by the key custodian and are then written into the file. So the length and complexity of the password and the location where DKEK shares are safely stored should match your security requirements.

The sc-hsm-tool allows to split up the control over a DKEK share by using a n-of-m threshold scheme for the DKEK share’s password. In such a scheme m key custodians are given a share of the password and n key custodians must come together to decrypt the DKEK share for import. This threshold scheme can be used to prevent a single point of failure and to increase the security of the overall scheme.

OpenSC Wiki SmartCard-HSM

Manpage ‘sc-hsm-tool’