Mechanisms

The following table lists the mechanisms currently supported by the nShield PKCS #11 library and the functions available to each one. Entrust also provides vendor-supplied mechanisms, described in Vendor-defined mechanisms.

Some mechanisms may be restricted from use in Security Worlds conforming to FIPS 140 Level 3. See the User Guide for your HSM for more information.
Mechanism Encrypt & Decrypt Sign & Verify SR & VR Digest Gen. Key/Key Pair Wrap & Unwrap Derive Key

CKM_AES_CBC_ENCRYPT_DATA

Y

CKM_AES_CBC_PAD

Y

Y

CKM_AES_CBC

Y

Y1

CKM_AES_CMAC_GENERAL

Y

CKM_AES_CMAC

Y

CKM_AES_CTR

Y

X

CKM_AES_ECB_ENCRYPT_DATA

Y

CKM_AES_ECB

Y

Y1

CKM_AES_GCM

Y

Y13

CKM_AES_KEY_GEN

Y

CKM_AES_KEY_WRAP

Y

CKM_AES_KEY_WRAP_PAD2

Y

Y

CKM_AES_KEY_WRAP_KWP

Y

Y

CKM_AES_MAC_GENERAL

Y

CKM_AES_MAC

Y

CKM_ARIA_CBC16

Y

Y17

CKM_ARIA_CBC_PAD16

Y

CKM_ARIA_ECB16

Y

Y17

CKM_ARIA_KEY_GEN16

Y

CKM_ARIA_MAC16

Y

CKM_ARIA_MAC_GENERAL16

Y

CKM_CONCATENATE_BASE_AND_KEY

Y3

CKM_DES_CBC_ENCRYPT_DATA

Y

CKM_DES_CBC_PAD

Y

Y

CKM_DES_CBC

Y

Y

CKM_DES_ECB_ENCRYPT_DATA

Y

CKM_DES_ECB

Y

Y

CKM_DES_KEY_GEN

Y

CKM_DES_MAC_GENERAL

Y

CKM_DES_MAC

Y

CKM_DES2_KEY_GEN

Y

CKM_DES3_CBC_ENCRYPT_DATA

Y

CKM_DES3_CBC_PAD

Y

Y

CKM_DES3_CBC

Y

Y1

CKM_DES3_ECB_ENCRYPT_DATA

Y

CKM_DES3_ECB

Y

Y1

CKM_DES3_KEY_GEN

Y

CKM_DES3_MAC_GENERAL

Y

CKM_DES3_MAC

Y

CKM_DH_PKCS_DERIVE

Y

CKM_DH_PKCS_KEY_PAIR_GEN

Y

CKM_DSA_KEY_PAIR_GEN

Y

CKM_DSA_PARAMETER_GEN

Y

CKM_DSA_SHA1

Y

CKM_DSA

Y4

CKM_EC_EDWARDS_KEY_PAIR_GEN

Y5

CKM_EC_KEY_PAIR_GEN

Y6

CKM_EC_MONTGOMERY_KEY_PAIR_GEN

Y5

CKM_ECDH1_DERIVE

Y7

CKM_ECDSA_SHA1

Y

CKM_ECDSA_SHA224

Y

CKM_ECDSA_SHA256

Y

CKM_ECDSA_SHA384

Y

CKM_ECDSA_SHA512

Y

CKM_ECDSA_SHA3_224

Y

CKM_ECDSA_SHA3_256

Y

CKM_ECDSA_SHA3_384

Y

CKM_ECDSA_SHA3_512

Y

CKM_EDDSA

Y4,8

CKM_ECDSA

Y4

CKM_GENERIC_SECRET_KEY_GEN

Y

CKM_MD5_HMAC_GENERAL

Y

CKM_MD5_HMAC

Y

CKM_MD5

Y

CKM_NC_ECIES

Y9

CKM_NC_MD5_HMAC_KEY_GEN

Y

CKM_NC_MILENAGE

Y4,15

CKM_NC_MILENAGE_AUTS

Y4,15

CKM_NC_MILENAGE_RESYNC

Y4,15

CKM_NC_MILENAGE_OPC

Y

CKM_NC_MILENAGEOP_KEY_GEN

Y

CKM_NC_MILENAGERC_KEY_GEN

Y

CKM_NC_MILENAGESUBSCRIBER_KEY_GEN

Y

CKM_NC_TUAK

Y4,15

CKM_NC_TUAK_AUTS

Y4,15

CKM_NC_TUAK_RESYNC

Y4,15

CKM_NC_TUAK_TOPC

Y

CKM_NC_TUAKSUBSCRIBER_KEY_GEN

Y

CKM_NC_TUAKTOP_KEY_GEN

Y

CKM_PBE_MD5_DES_CBC

Y

CKM_RIPEMD160

Y

CKM_RSA_9796

Y4

Y4

CKM_RSA_AES_KEY_WRAP

Y14

CKM_RSA_PKCS_KEY_PAIR_GEN

Y

CKM_RSA_PKCS_OAEP

Y

Y

CKM_RSA_PKCS_PSS11

Y

Y

CKM_RSA_PKCS

Y4

Y4

Y4

Y

CKM_RSA_X_509

Y4

Y4

Y4

X

CKM_RSA_X9_31_KEY_PAIR_GEN

Y

CKM_SHA_1_HMAC_GENERAL

Y10

CKM_SHA_1_HMAC

Y10

CKM_SHA_1

Y

CKM_SHA1_RSA_PKCS_PSS11

Y

CKM_SHA1_RSA_PKCS

Y

CKM_SHA224_HMAC_GENERAL

Y10

CKM_SHA224_HMAC

Y10

CKM_SHA224_RSA_PKCS_PSS11

Y

CKM_SHA224_RSA_PKCS

Y

CKM_SHA224

Y

CKM_SHA256_HMAC_GENERAL

Y10

CKM_SHA256_HMAC

Y10

CKM_SHA256_RSA_PKCS_PSS11

Y

CKM_SHA256_RSA_PKCS

Y

CKM_SHA256

Y

CKM_SHA384_HMAC_GENERAL

Y10

CKM_SHA384_HMAC

Y10

CKM_SHA384_RSA_PKCS_PSS11

Y

CKM_SHA384_RSA_PKCS

Y

CKM_SHA384

Y

CKM_SHA512_HMAC_GENERAL

Y10

CKM_SHA512_HMAC

Y10

CKM_SHA512_RSA_PKCS_PSS11

Y

CKM_SHA512_RSA_PKCS

Y

CKM_SHA512

Y

CKM_SHA3_224

Y

CKM_SHA3_224_RSA_PKCS_PSS11

Y

CKM_SHA3_224_RSA_PKCS

Y

CKM_SHA3_256

Y

CKM_SHA3_256_RSA_PKCS_PSS11

Y

CKM_SHA3_256_RSA_PKCS

Y

CKM_SHA3_384

Y

CKM_SHA3_384_RSA_PKCS_PSS11

Y

CKM_SHA3_384_RSA_PKCS

Y

CKM_SHA3_512

Y

CKM_SHA3_512_RSA_PKCS_PSS11

Y

CKM_SHA3_512_RSA_PKCS

Y

CKM_XOR_BASE_AND_DATA

Y12

The nShield library supports some mechanisms that are defined in versions of the PKCS #11 standard later than 2.01, although the nShield library does not fully support versions of the PKCS #11 standard later than 2.01.

In the table above:

  • Empty cells indicate mechanisms that are not supported by the PKCS #11 standard.

  • The entry Y indicates that a mechanism is supported by the nShield PKCS #11 library.

  • The entry X indicates that a mechanism is not supported by the nShield PKCS #11 library.

In the table above, annotations with the following numbers indicate:

Footnote 1

Wrap secret keys only (private key wrapping must use CBC_PAD).

Footnote 2

CKM_AES_KEY_WRAP_PAD has been deprecated and replaced by CKM_AES_KEY_WRAP_KWP.

Footnote 3

Before you can create a key for use with the derive mechanism CKM_CONCATENATE_BASE_AND_KEY, you must specify the CKA_ALLOWED_MECHANISMS attribute in the template with the CKM_CONCATENATE_BASE_AND_KEY set. Specifying the CKA_ALLOWED_MECHANISMS in the template enables the setting of the nCore level ACL, which enables the key in this derive key operation. For more information about the CKA_ALLOWED_MECHANISMS attribute, see Attributes.

Footnote 4

Single-part operations only.

Footnote 5

CKA_EC_PARAMS is a DER-encoded PrintableString curve25519.

Footnote 6

If no capabilities are specified in the template, for example the CKA_DERIVE, CKA_SIGN and CKA_UNWRAP attributes are omitted, then the default capability is sign/verify.

Key generation does calculate its own curves but, as shown in the PKCS #11 standard, takes the CKA_PARAMS, which contains the curve information (similar to that of a discrete logarithm group in the generation of a DSA key pair). CKA_EC_PARAMS is a Byte array which is DER-encoded of an ANSI X9.62 Parameters value. It can take both named curves and custom curves.

The following PKCS #11-specific flags describe which curves are supported:

  • CKF_EC_P: prime curve supported

  • CKF_EC_2M: binary curve supported

  • CKF_EC_PARAMETERS: supplying your own custom parameters is supported

  • CKF_EC_NAMECURVE: supplying a named curve is supported

  • CKF_EC_UNCOMPRESS: supports uncompressed form only, compressed form not supported.

Footnote 7

The CKM_ECDH1_DERIVE mechanism is supported. However, the mechanism only takes a CK_ECDH1_DERIVE_PARAMS struct in which CK_EC_KDF_TYPE can be one of the following:

  • CKD_NULL

  • CKD_SHA1_KDF, CKD_SHA1_KDF_SP800

  • CKD_SHA224_KDF, CKD_SHA224_KDF_SP800

  • CKD_SHA256_KDF, CKD_SHA256_KDF_SP800

  • CKD_SHA384_KDF, CKD_SHA384_KDF_SP800

  • CKD_SHA512_KDF, CKD_SHA512_KDF_SP800

  • CKD_SHA3_224_KDF, CKD_SHA3_224_KDF_SP800

  • CKD_SHA3_256_KDF, CKD_SHA3_256_KDF_SP800

  • CKD_SHA3_384_KDF, CKD_SHA3_384_KDF_SP800

  • CKD_SHA3_512_KDF, CKD_SHA3_512_KDF_SP800

For more information on CK_ECDH1_DERIVE_PARAMS, see the PKCS #11 standard.

For the pPublicData* parameter, a raw octet string value (as defined in section A.5.2 of ANSI X9.62) and DER-encoded ECPoint value (as defined in section E.6 of ANSI X9.62) are accepted for CKK_EC keys. RFC 7748 encoding should be used for CKK_EC_MONTGOMERY keys.

Footnote 8

Both the Ed25519 and Ed25519ph signature schemes are supported, The Ed25519 scheme requires either no CK_EDDSA_PARAMS to be passed or if it is passed it should have the following set:

  • phFlag to CK_FALSE

  • ulContextDataLen to 0.

The Ed25519ph signature scheme requires CK_EDDSA_PARAMS to have the following set:

  • phFlag to CK_TRUE

  • ulContextDataLen to 0.

Footnote 9

Wrap secret keys only.

Footnote 10

This mechanism depends on the vendor-defined key generation mechanism CKM_NC_SHA_1_HMAC_KEY_GEN, CKM_NC_SHA224_HMAC_KEY_GEN, CKM_NC_SHA256_HMAC_KEY_GEN, CKM_NC_SHA384_HMAC_KEY_GEN, or CKM_NC_SHA512_HMAC_KEY_GEN. For more information, see Vendor-defined mechanisms.

Footnote 11

The hashAlg and the mgf that are specified by the CK_RSA_PKCS_PSS_PARAMS must have the same SHA hash size. If they do not have the same hash size, then the signing or verify fails with a return value of CKR_MECHANISM_PARAM_INVALID.

The sLen value is expected to be the length of the message hash. If this is not the case, then the signing or verify again fails with a return value of CKR_MECHANISM_PARAM_INVALID. The Security World Software implementation of RSA_PKCS_PSS salt lengths are as follows:

Mechanism Salt-length

SHA-1

160-bit

SHA-224

224-bit

SHA-256

256-bit

SHA-384

384-bit

SHA-512

512-bit

SHA3-224

224-bit

SHA3-256

256-bit

SHA3-384

384-bit

SHA3-512

512-bit

Footnote 12

The base key and the derived key are restricted to DES, DES3, CAST5 or Generic, though they may be of different types.

Footnote 13

For wrap and unwrap with CKM_AES_GCM, the IV supplied in the CKM_GCM_PARAMS structure must be 12 bytes. For wrap the IV must be all zeroes. This will be overwritten by the actual value used when the wrap command has completed successfully. For unwrap the IV must be the value returned by the corresponding wrap.

Footnote 14

In order to create an unwrapping key for use with the mechanism CKM_RSA_AES_KEY_WRAP where CKA_UNWRAP_TEMPLATE is also set, you must:

  • Specify the CKA_ALLOWED_MECHANISMS attribute in the template with CKM_RSA_AES_KEY_WRAP set as an allowed mechanism.

  • Override the Security Assurance Mechanisms (SAMs) to permit use of CKA_UNWRAP_TEMPLATE with the mechanism CKM_RSA_AES_KEY_WRAP.

Keys with CKA_WRAP_WITH_TRUSTED set cannot be wrapped with the mechanism CKM_RSA_AES_KEY_WRAP. The C_WrapKey operation will return CKR_KEY_NOT_WRAPPABLE for such keys.

With firmware versions 13.4 or later, you do not need to override the Security Assurance Mechanisms. Keys with CKA_WRAP_WITH_TRUSTED can be wrapped with the mechanism CKM_RSA_AES_KEY_WRAP.

For more information about the SAMs, see PKCS #11 security assurance mechanism. For more information about the CKA_ALLOWED_MECHANISMS attribute, see Attributes.

With firmware versions 13.4 or later, you do not need to override the Security Assurance Mechanisms. Keys with CKA_WRAP_WITH_TRUSTED can be wrapped with the mechanism CKM_RSA_AES_KEY_WRAP.

For more information about the SAMs, see PKCS #11 security assurance mechanism. For more information about the CKA_ALLOWED_MECHANISMS attribute, see Attributes.

Footnote 15

Sign only.

Footnote 16

Use of these mechanisms requires the KISAAlgorithms feature to be enabled, see the User Guide for your HSM for more information.

Footnote 17

Wraps secret keys only.