Secure Key Backup and Restoration
SafeNet ProtectToolkit-C allows for keys to be backed up to disk files or smart cards, for convenient transfer of sensitive keys to other machines or off-site storage and subsequent recovery. Encrypted parts may also be displayed on the screen.
Determining Backup Requirements
There are no set rules within SafeNet ProtectToolkit-C dictating which keys should be backed up. The individual key owner decides which keys require backup protection.
As a guideline, keys that cannot be recreated or easily reconstructed by other means should generally be backed up. These may include generated key values or long keys manually entered by multiple custodians.
Not all keys can be backed up, since certain key attribute values have to be set in order to allow the backup. The setting of key attributes is therefore an important consideration when creating keys suitable for backup operations and is covered in Key Attributes.
NOTE You cannot backup SafeNet ProtectToolkit-M FIPS mode keysets. If your organization requires you to use FIPS mode tokens we recommend securing your keyset using an NofM schema. See the Key Splitting Scheme Selection for more information.
Available Backup and Recovery Methods
There are two methods of backing up a key:
>The multiple custodians method, where a key is split into shares and distributed among multiple custodians. The shares are encrypted (wrapped) by a second, randomly-selected key called the wrapping key.
>The single custodian method, where the key is encrypted (wrapped) by a specifically-selected wrapping key.
The encrypted key is then stored on the backup medium.
For key backup and restore procedures, see:
Key Splitting Scheme Selection
If a key is to be split into multiple shares, first select the scheme to split the key. It is possible to split the key so that the original key may only be recovered with the co-operation of either:
>all the custodians using the standard scheme, or
>a user-specified minimum number of the custodians using the N of M scheme*
In the N of M scheme, no single custodian is required to recover the key. This is particularly advantageous if a smart card should become corrupted. Corrupted cards will be rejected during an import operation. The custodians will be prompted for another card to continue.
*As defined in A. Shamir – How to Share a Secret, Communications of the ACM, Vol 22, no. 11, November 1979, pp 612-613.
You cannot backup SafeNet ProtectToolkit-M FIPS mode keysets. If your organization requires you to use FIPS mode tokens we recommend securing your keyset using an NofM schema. See the CTKMU for more information about NofM.
A Typical Key Backup and Recovery Scheme
An overall backup scheme typically combines the multiple custodians and single custodian methods. In this scenario, a wrapping key (KWRAP) is generated and backed up using the multiple custodians method. The KWRAP key would then be used to back up other keys using the single custodian method.
This key backup scheme is illustrated in A typical key backup and recovery scheme.
Figure 1: A typical key backup and recovery scheme
Key Attributes
It is important to select key attributes appropriate for the intended purpose while ensuring compatibility with the intended backup scheme.
The standard PKCS #11 key backup method requires that the wrapping key (a key used to back up another key) has the CKA_WRAP attribute set to true. It also requires that the extractable key (the key to be backed up) has the CKA_EXTRACTABLE attribute set to true. These attributes may be chosen arbitrarily by the application. Therefore, once a key is marked as extractable, any wrapping key may be used to back it up. It is thus possible for an attacker to introduce a known-value wrapping key, back up the target extractable key and then decrypt it offline.
To defend against this type of attack, SafeNet ProtectToolkit-C uses an alternate key backup method. This extension allows the wrapping key to have its CKA_EXPORT attribute set to true and the extractable key to have its CKA_EXPORTABLE attribute set to true. In this case, the wrapping key is known as the export key and the key to be backed up is the exportable key, and only the Security Officer may set the CKA_EXPORT attribute to true.
The key backup procedures described below are valid for both the PKCS #11 standard attributes and the extended SafeNet ProtectToolkit-C attributes. The extension method is recommended to mitigate the threat described above.
NOTE When the export/exportable procedure is used with the multiple custodians method, the token Security Officer must be present to create the custodian export keys.
The CKA_EXPORT attribute of any key is set to false when the key is imported. Therefore, after it is restored, it cannot be used again. The user should create a new export key to create a new backup batch of exportable keys.
Prior to key backup, the extractable keys (selected for backup) must have the correct attributes set to allow the export. The table below details the key attribute settings. Also shown are the attribute settings required to enable use of a key as a wrapping key.
|
Attribute |
Wrapping/Export Key |
Extractable/Exportable Key |
|---|---|---|
|
CKA_MODIFIABLE |
FALSE |
- |
|
CKA_SENSITIVE |
TRUE |
- |
|
CKA_WRAP |
TRUE |
- |
|
CKA_EXPORT |
TRUE1 |
- |
|
CKA_UNWRAP3 |
TRUE1 |
- |
|
CKA_EXTRACTABLE |
- |
TRUE1 |
|
CKA_EXPORTABLE |
- |
TRUE1 |
|
CKA_DERIVE |
FALSE |
- |
|
CKA_ENCRYPT |
FALSE |
- |
|
CKA_DECRYPT |
FALSE2 |
- |
|
CKA_SIGN |
FALSE |
- |
|
CKA_VERIFY |
FALSE |
- |
1 The user should choose only one of these two attributes. There are two pairs of attributes that must match (be set to true):
• CKA_EXPORT for the export key and CKA_EXPORTABLE for the exportable key
•CKA_WRAP for the wrapping key and CKA_EXTRACTABLE for the extractable key
2 Wrapping/export keys should not be available for decryption; otherwise the extractable/exportable key may be decrypted directly.
3 The CKA_IMPORT attribute can be used in place of the CKA_UNWRAP attribute. CKA_IMPORT determines whether a key can be used to unwrap encrypted key material. The important difference is that if CKA_IMPORT is set to true and CKA_UNWRAP attribute is set to false, the only unwrapping mechanism available is CKM_WRAPKEY_DES3_CBC. The error code CKR_MECHANISM_INVALID will be returned for all other mechanisms.
Both the command line tool ctkmu and the GUI tool kmu can be used to create keys and change their attributes. See the Command Line Utilities Reference and Key Management Utility (KMU) Reference respectively. More details about key attributes can be found in PKCS #11 Attributes.
Key Backup Procedure
Prior to attempting a key backup, please ensure that you have:
>a valid key or keyset that can be backed up
>a connected smart card reader (if backing up to smart cards)
>sufficient initialized and erased smart cards or disk space to back up the keys
The rules applying to key backup are:
>Attempting a key backup without specifying a wrapping key will result in a multiple custodian backup using a random key (smart cards only).
>When a wrapping key is specified, the unwrapping key used to import a key must be the same as the wrapping key used to export it.
>When using the ctkmu command line utility, the standard scheme will be used by default for multiple custodian key backups, unless the -M parameter is specified. When -M is specified, the N of M scheme is used.
See Available Backup and Recovery Methods for more about these methods.
Either the command line utility ctkmu or the GUI utility kmu can be used for key backup and restoration. These utilities can back up and restore keys from either a disk file or one or more smart cards. Please refer to Command Line Utilities Reference and Key Management Utility (KMU) Reference for the complete ctkmu and kmu references respectively.
The following examples use the ctkmu command line utility. See Importing and Exporting Keys for the procedure when using the KMU GUI utility.
Example 1: Using a Wrapping Key
In this example, a key with the label MyDES2 on slot 2 will be encrypted (wrapped) with the key labeled MyWRAP1. The backup data will be written to the disk file named wrapkey.bin. This operation will prompt for the User PIN.
ctkmu x –s2 –nMyDES2 –wMyWRAP1 fwrapkey.bin
Example 2: Using Multiple Custodians and the Standard Key Splitting Scheme
In this example, the key labeled MyWRAP1 on slot 2 will be backed up to smart cards in slot 4 using the multiple custodians method and the standard scheme. The original key can only be recovered with the co-operation of all custodians.
ctkmu x –s2 –nMyWRAP1 –c4
The operation will prompt for the User PIN and the number of custodians required (minimum of 2). Each custodian will be prompted to enter and confirm a PIN. The PIN is then used to protect the key component on the smart card.
Example 3: Using Multiple Custodians and the N of M Scheme
Specify the -M parameter to use the N of M scheme. The original key can be recovered with the co-operation of a user-specified minimum number of custodians N out of the total M.
ctkmu x –s2 –nMyWRAP1 –c4 –M
After the prompts from Example 2, the utility will prompt for the minimum number of custodians required to recover the key N (minimum of 2, maximum equal to the total number of custodians specified M). Note that N cannot be set equal to M.
See Available Backup and Recovery Methods for more about the N of M scheme.
Key Restore Procedure
Key restoration is essentially a reversal of the procedures above. When restoring or importing key data, remember:
>When restoring a key held by multiple custodians, all custodians (standard scheme) or the minimum number of custodians (N of M scheme) will have to present their smart card so that the individual key shares can be recombined to form the original key.
>When restoring a key or keyset held by a single custodian, the same wrapping key used to encrypt the key must first be available on the token.
Example 1: Single Custodian Key Recovery
In this example, a key will be imported to the token in slot 2 from a disk file named wrapkey.bin. It will be decrypted (unwrapped) with the wrapping key MyWRAP1. This operation will prompt for the User PIN.
ctkmu i –s2 –wMyWRAP1 fwrapkey.bin
Example 2: Multiple Custodian Key Recovery
This example will import a key to slot 2 from smart cards held by multiple custodians. When prompted, each custodian in turn must insert their smart card in the card reader designated as slot 4. Custodians will also be prompted for their PIN. This process continues until enough shares have been assembled to enable reconstruction of the key. This operation will prompt for the User PIN.
ctkmu i –s2 –c4
NOTE The command used to recover keys shared between multiple custodians is the same, regardless of which scheme was used (standard or N of M) to split the key. See Available Backup and Recovery Methods for further information regarding the schemes.
Example 3: Keyset Recovery
This example will restore a keyset from a disk file named keyset.bak for administration with the Keyset Management Utility. It will be decrypted (unwrapped) with the wrapping key MyWRAP1. This operation will prompt for the keyset password and the device Administrator password.
ctkmu i -s3 -wMyWRAP1 keyset.bak
NOTE When restoring the MACHINE_Kyeset or the SYSTEM_Keyset, enter the default value password as the user password. The device administrator password used to create he backup will also be prompted for.
