Edition SC34-7730-02: Updates for openCryptoki versions 3.18 - 3.22
This edition has a new structure. There is a new topic Part 5. IBM-specific mechanisms and features for openCryptoki which lets you find IBM-specific add-ons to openCryptoki at a glance. Existing and new information is integrated into this part as applicable.
- For CCA tokens and EP11 tokens, openCryptoki ensures that all APQNs assigned to such a token are configured with the same master key. In either a CCA token or an EP11 token configuration file, you can optionally specify an expected master key or wrapping key verification pattern (MKVP or WKVP). If specified, all master or wrapping keys must match the pattern, If not specified, they just must be the same. Additionally, the openCryptoki functions that create a key or key pair, for example C_GenerateKey(), or C_DeriveKey(), now automatically check whether the resulting key or keys are created with this specified expected MKVP or WKVP. If no pattern is specified, openCryptoki checks against the verification pattern of the APQNs as determined during token initialization.
- openCryptoki is extended with a possibility to restrict usage of mechanisms and keys via a global policy. The policy is guided by the notion of cryptographic strength. The user specifies a minimal desired strength, allowed mechanisms, and a way to derive the strength for a given key. openCryptoki then blocks all keys that are not strong enough and mechanisms that are not allowed. The policy is set globally for all applications using openCryptoki.
- The usage of mechanisms is counted based on individual users
and accumulated for all users on the respective system. The usage is also counted on the basis if
slot-IDs, mechanisms, and key-sizes. Counting is applied transparently to the calling applications.
A new command line tool pkcsstats can be used to display the counter values for slot-IDs and mechanisms, based on individual users or accumulated for all users on the respective system, and also broken down to different key-size values.
- openCryptoki provides a new utility called pkcshsm_mk_change to support the changing (rolling) of master keys of cryptographic coprocessors running in CCA or EP11 mode concurrently while applications using openCryptoki workload exploiting the CCA token or the EP11 token are running. All secure keys enciphered by old master keys need to be re-enciphered with the new master key. However applications using the mentioned tokens can continue to run while the master key change procedure is performed.
- Support for the CKA_DERIVE_TEMPLATE attribute as defined by PKCS #11 version 3.1 has been added to all token types. The CKA_DERIVE_TEMPLATE attribute of a base key contains a template that is applied to the derived key in addition to the user supplied derive template. Applications can use the CKA_DERIVE_TEMPLATE attribute on base keys to control the attributes of the keys that are to be derived from that base keys.
- The EP11 token offers two new
mechanisms that can be used by crypto currency applications:
- The CKM_IBM_BTC_DERIVE mechanism allows derivation of child keys from base ECC keys, generated from a selection of elliptic curves, using the methods described in BIP-0032 and SLIP-0010.
- The CKM_IBM_ECDSA_OTHER mechanism is a multi-variant signature mechanism for algorithms used by crypto currency applications. You can use this mechanism to generate Schnorr signatures, that is, ECC-based signatures that are not produced using the ECDSA or the EDDSA digital signature algorithms.
- The openCryptoki
pkcsslotd daemon is hardened, especially against privilege escalation attacks. It
does not run as root user anymore. It can still be started as
rootuser, but will change its UID to a special, but unprivilegedpkcsslotdservice user shortly after startup. - For PKCS #11 3.0, openCryptoki supports the new C_SessionCancel() function used to terminate active session-based operations.
- New
mechanisms are provided by the CCA token, the
ICA token, the EP11 token, and the Soft token to enable AES XTS protected-key cryptographic
support for openCryptoki (encryption, decryption and key
generation). The AES XTS mechanisms and key type are new for PKCS #11 version 3.0.
Also, a new feature of the p11sak utility now supports the generation and management of AES-XTS keys.
Furthermore, for the mentioned tokens you can now import clear AES XTS keys to secure AES XTS keys, for example, using the C_CreateObject() function of openCryptoki.
- Background information about the use of protected keys in general and especially for AES XTS for the CCA and EP11 tokens is provided in the new topics How and why to exploit protected keys and How to enable AES XTS support for CCA and EP11 tokens.
- The p11sak tool now supports x.509 public key certificates as token objects. This is needed for compatibility with the use case where certificates are stored in a PKCS #11 token.
- The openCryptoki tools pkcsconf and p11sak now support the output of the unified resource identifier (URI) as defined by the RFC 7512: The PKCS #11 URI Scheme for PKCS #11 objects in PKCS #11 tokens.
- As for EP11 tokens, you can now create an optional CCA token configuration file where you can specify options to support protected key mode and to request a master key consistency check for the assigned APQNs.
- For EP11 tokens, openCryptoki offers support of quantum-safe algorithms for Dilithium Round 2 and 3 variants and Kyber Round 2. All new features are available with IBM z16® systems on a CEX8P Crypto Express EP11 coprocessor, including the latest EP11 host library and firmware code.
- Since version 3.19, openCryptoki supports several functions to perform two cryptographic operations simultaneously within a session. These functions are provided to avoid unnecessarily passing data back and forth to and from a token.
- There are attacks on RSA operations for which the timing of a computation may deliver a hint for well- or malformed input and thus, whether an attack may have a chance to be successful. Starting with version 3.21, openCryptoki itself cares for hiding the computation times, however, PKCS #11 applications must make sure to handle certain RSA decryption errors in a constant-time manner itself. In addition, the ICA token and the Soft token apply RSA message blinding to messages on all operations using the RSA private key (decryption and signature creation).
- The p11-kit utility is enhanced so that it supports IBM-specific mechanisms and attributes. The p11-kit utility can especially be used to provide remote PKCS #11 API access to openCryptoki tokens through an RPC-like communication protocol.