New features for CEX7P
EP11, the Enterprise PKCS#11 coprocessor mode, gained several new features with the 7th generation of the Crypto Express Card (needs bundle S14 installed). EP11 offers a Secure Key PKCS#11-like API which can be used to implement a PKCS#11 token library. With this EP11 version it is now possible to implement version 2.40 of the PKCS#11 standard.
Current PKCS#11 libraries that use EP11 include but are not limited to ICSF on z/OS, openCryptoki on Linux and grep11 in the IBM Cloud. If only a subset of the EP11 functionality is required and no PKCS#11 API is needed, the EP11 system API can also be used directly. An example for this is the IBM Blockchain offering.
Starting with CEX7P EP11 adds several new features like SHA-3 support, Edwards and Montgomery curve support, protected key import support and first post-quantum algorithm with CRYSTALS-Dilithium for experimental purposes.
EP11 provides these new functions through vendor-defined mechanisms since the new functions are not included in the current PKCS#11 standard. Once a new standard becomes available which provides named mechanisms, EP11 will strive to add corresponding support.
New digest mechanisms with SHA-3
SHA-3 is the latest Secure Hash Algorithm standardized by NIST (link resides outside of Ibm.com). CEX7S adds hardware acceleration for SHA-3 and is exploited by EP11 to provide customers with data digest and HMAC support based on SHA-3. EP11 supports the four different output units for SHA-3: 224, 256, 384 and 512. The selected output size depends on the particular use case and security requirements. More information can be found in this NIST document (PDF, 391 KB) (link resides outside of Ibm.com).
At this time SHA-3 is complementing SHA-2 since SHA-2 is still deemed to be secure. However, SHA-3 is likely to supersede SHA-2 in the future once more feasible attacks against SHA-2 are found. We recommend customers to have a first look at the SHA-3 algorithm but see no reason to force a migration yet. However, for workloads using SHA-1, a migration to SHA-2 can be skipped and SHA-3 should be considered as a viable alternative while SHA-1 is regarded as insecure (link resides outside of Ibm.com).
The IBM z15 CP Assist for Cryptographic Functions (CPACF) also provides message digest support with SHA-3 and should be preferred, as it outperforms the HSM by orders of magnitude. This is true for all operations that do not require any key material for input. Some PKCS#11 providers transparently map message digest calls to CPACF whenever possible without reducing security.
In any case, EP11 must be called for HMAC or signature operations if Secure Key functionality is required. EP11 now also provides SHA-3 for the RSA-OAEP encryption scheme as well as the standardized mask generation functions (MGFs) SHA-1 and SHA-2 (needs bundle S07 installed).
The following digest mechanisms for SHA-3 are available:
The following HMAC mechanisms for SHA-3 are available:
The following Mask Generation Functions are available with the CKM_RSA_PKCS_OAEP mechanism:
Edwards and Montgomery curves for TLSv1.3
With the CEX7S card, hardware support for selected Edwards and Montgomery elliptic curves is introduced. EP11 supports the Edwards curves Ed25519 and Ed448 for the EdDSA signature scheme and the Montgomery curves c25519 and c448 for ECDH (needs bundle S12a installed). Both the Edwards and the Montgomery curves are used in the TLSv1.3 standard.
The EdDSA signature scheme uses different hash algorithms depending on the curve: Ed25519 uses SHA-512 while Ed448 uses SHA-3.
For key generation, the previously existing standard CKM_EC_KEYGEN mechanism is used by specifying the OID of the curve a key should be generated for. Edwards keys cannot be used for ECDH and Montgomery keys cannot be used for signature generation. Therefore, the CKA_DERIVE attribute cannot be specified for Edwards keys and CKA_SIGN (or CKA_VERIFY for the public key) cannot be specified for Montgomery keys.
Additionally, EP11 provides vendor specific raw ECDH mechanisms which allow for creating raw symmetric keys encrypted under a key encryption key (KEK), unlike the standard CKM_ECDH1_DERIVE mechanism which always delivers the key as EP11 blob. This functionality is extended for the use with X25519 and X448 with new vendor-defined mechanisms. Note that the prefix 'X' indicates the key specific ECDH mechanism. All new ECDH mechanisms can be used with the standard mechanism parameter CK_ECDH1_DERIVE_PARAMS.
The following new sign/verify mechanisms for EdDSA are available:
The following new derive mechanisms for ECDH are available:
Utilizing a protected key with EP11 to gain performance
For workloads not having the requirement for Secure Keys (e.g. key or WK resides on an HSM), but still do not want to have keys appear in the clear in the application’s (OS’s) memory, using a so-called protected key is a viable alternative. A protected key only resides in customer memory in encrypted form. It is encrypted by a wrapping key which resides in a protected area in the memory of the system firmware. Protected key operations are faster than their secure key counterparts, because CPACF can be used for cryptographic operations with a protected key. However, a protected key has a limitation in that it does not outlive an IML or an IPL of the VM or LPAR since the wrapping key in the protected area is not saved to a disk and is regenerated by the IPL process.
For protected-key use to become practicable, secure keys must be imported from an HSM into protected keys.
With the CEX7P card release, EP11 gains the ability to import EP11 AES, 2DES/3DES and EC key blobs as protected keys (needs bundle S14 installed). For EC keys, both Prime and Edwards keys are supported, which are also supported by the IBM z15 hardware.
As importing protected keys is a privileged operation, the operating system must have support for the EP11 protected key import mechanism. z/OS with ICSF supports the entire set of key types that EP11 supports. [APAR]. At the time of writing this article, Linux only supports the AES protected key type for LUKS disk encryption (see the latest manual page for the zkey tool). The first distribution to make use of this support is Ubuntu 20.04.
EP11 blobs must be marked with the CKA_IBM_PROTKEY_EXTRACTABLE attribute to be exportable as protected keys. Like CKA_EXTRACTABLE, this attribute can only be set to True at the time of key creation. It also has a sibling attribute which signifies that the key was never importable as a protected key (CKA_IBM_PROTKEY_NEVER_EXTRACTABLE). The CKA_EXTRACTABLE and CKA_IBM_PROTKEY_EXTRACTABLE attributes are mutually exclusive. Given that both attributes can only be disabled during the lifetime of a key, this ensures that a key that is importable as a protected key can never be extracted into a clear key outside of the system firmware.
For further information see the operating system manuals:
The start into the post-quantum era with Dilithium
CRYSTALS-Dilithium is one of the the round 2 submissions to NIST's post-quantum project. As such it is expected to be secure against attacks facilitating a quantum computer. As the NIST project is still in the submission phase, this feature is marked as experimental and should not be used in production, but it nevertheless is useful to explore this feature to get an understanding of the implications of using post-quantum cryptography (PQC).
Dilithium keys can be generated using the CKM_IBM_DILITHIUM mechanism (needs bundle S12a installed). The key attribute template may specify an OID (CKA_IBM_PQC_PARAMS), but since currently only one OID (XCP_PQC_DILITHIUM_65_NAME) is supported, this is optional for now. At the time of writing, EP11 only supports the Dilithium 6-5 variant. The CKM_IBM_DILITHIUM mechanism, both is used for signing and verification requests sent to EP11.
More information about the NIST submission and the algorithm can be found on the PQ-Crystals website (link resides outside of Ibm.com).
IBM EP11 Firmware Development