CKM_WRAP_TR31_DERIVE
This section provides a summary of CKM_WRAP_TR31_DERIVE.
Note
This mechanism is only available if you are using PTK 7.1.0 or newer with ProtectServer 3 HSM Firmware 7.01.00 or newer.
Supported operations
Operation | Supported |
---|---|
Encrypt and Decrypt | No |
Sign and Verify | No |
SignRecover and VerifyRecover | No |
Digest | No |
Generate Key/Key-Pair | No |
Wrap and Unwrap | Wrap |
Derive | No |
FIPS Mode support
Available in FIPS Mode | Restrictions in FIPS Mode |
---|---|
No | Not applicable |
Key size range (bytes) and parameters
Key size minimum/maximum | Value |
---|---|
Minimum | 16 |
Maximum | 32 |
Parameter
None
Mechanism description
This mechanism is used to wrap a symmetric or asymmetric private key using the wrapped key format described in ASC X9 TR 31-2018: Interoperable Secure Key Exchange Key Block Specification.
The key block protection key (KBPK) must meet the following requirements:
-
CKA_WRAP=True.
-
It must contain a CKA_MECHANISM_LIST attribute with the CKM_WRAP_TR31_DERIVE mechanism specified.
The wrapped key must meet the following requirements:
-
CKA_EXTRACTABLE=True
-
CKA_MODIFIABLE=False, or else CKR_KEY_NOT_WRAPPABLE is returned.
This mechanism uses the Key Derivation Binding Method (CMAC algorithm) to derive the encryption and signing keys from the KBPK. The encryption mode is CBC. The KBPK must be a symmetric key of type CKK_DES2, CKK_DES3, or CKK_AES. A version ‘B’ key block is produced if the base key is DES or version ‘D’ if the base is AES.
It takes an optional parameter: TR-31 INFO Key Block Header. For more information about the proprietary format type 0 TR-31 header, see CKA_TR31_INFO.
If the wrapped object has a CKA_TR31_INFO attribute, the mechanism constructs the new key block header from the CKA_TR31_INFO attribute.
If the wrapped object has a CKA_TR31_INFO attribute and a mechanism parameter is supplied, then CKR_MECHANISM_PARAM_INVALID is returned.
Otherwise, the mechanism constructs the key block header from information in the mechanism parameter.
The mechanism parameter is checked:
-
The Algorithm field must match the Key Type of the wrapped key.
-
The ID must be ‘0’.
-
The Length field must match the mechanism parameter length.
-
The Key Usage and Mode in the header must not contradict the crypto function implied by the key usage attributes. For the list of attributes, see CKM_UNWRAP_TR31.
-
Any extension header blocks must have valid lengths.
The following header extension types will have their values (if any) replaced with appropriate material from the HSM or wrapped key. The caller can use this feature to request the HSM to create header extensions in the new key block.
For example, if you add the empty time stamp extension to the mechanism parameter ('TS04'), then the key block will contain the full time stamp; that is, “TS142021071505472400”.
Extension | Value |
---|---|
‘KC04’ or ‘KC0600’ | Legacy KCV for wrapped key |
‘KC0601’ | CMAC KCV for wrapped key |
‘KP04’ or ‘KP0600’ | Legacy KCV for wrapping key |
‘KP0601’ | CMAC KCV for wrapping key |
‘TS04’ | Time of key-block creation UTC |
‘TC04’ | Time of key creation UTC |
Return to ProtectToolkit-C mechanisms.