Authors: Richard Kisley, Jimmy Hill, Rumeel Jessamy, Jim Cox, Mike Miele
This article introduces the updates for the Common Cryptographic Architecture (CCA) 8.2 for Linux on IBM Z.
Audience:
Users of CCA for payment or cryptography applications on
What is CCA?
CCA is both an Architecture and a set of APIs. It provides:
-
Crypto algorithms and secure key management
-
Specialized functions for banking and payment network interoperability
-
A common API and architecture for all IBM z, Cognitive and x64/x86 server platforms
-
Over 156 APIs with more than 1000 options, from ASC X9 TR-31 key support to ASC X9 TR-34 mutually authenticated RSA/certificate based TDES and AES key exchange, as well as traditional PIN-secured transaction processing and other support for core banking functions and major payment network key derivation and cryptograms.
What are the updates?
This update, CCA 8.2, adds support for the following features, described in more detail below:
-
New CCA Services: Multi-Mac Scheme (CSNBMMS)
-
Algorithm updates for Import/Export of AES K0-B and K1-B key blocks
-
Updates for Importing RSA AES Key Wrapped Objects
-
DKYGENKY KMF-MBE/P Support
-
MGN and MVR added support for 3-key TDES EMVMACD/X9.19OPT
-
CCA Service Quantum Safe Algorithms R2/R3 Updates:
-
CRYSTALS-Kyber(1024), Round 3
-
CRYSTALS-Kyber(768), Round 3
-
CRYSTALS-Kyber(768), Round 2
-
New Enhanced zLinux Package Security
CCA Service Quantum Safe Algorithms R2/R3 Updates
Key label support for CRYSTALS-Kyber expanded round 2 and round 3 keys requires a large common record (KDSRL) format PKDS.
Note that CRYSTALS-Dilithium Round 3 and Round 2 (with hardware acceleration) is available from prior releases of CCA for CEX8S on IBM Z16.
X9 TR-31 Import/Export of AES K0-B and K1-B Key Blocks
The CCA releases 8.2, 7.5, 6.7, and 5.7 add the ability to import, via the TR-31 Key Import (CSNBT31I) service, TR-31 key blocks with algorithm ‘A’, mode of use ‘B’ , and key usage ‘K0’ or ‘K1’. The result is a CCA variable-length symmetric IMPORTER or EXPORTER AES token. The Key Export to TR-31 (CSNBT31X) service can be also be used to export a CCA variable-length symmetric IMPORTER or EXPORTER AES token to a TR-31 key block with algorithm ‘A’, mode of use ‘B’ , and key usage ‘K0’ or ‘K1’.
ENCDEC("B")
Specifies both encrypt and decrypt of data, or wrap and unwrap keys. Sets the byte at offset 8 of the header to ASCII "B". Only valid with ENC, KEK, KEK-WRAP, KEKWRK4.
KEK ("K0")
Specifies to export a key encryption or wrapping key. Sets the bytes at offset 5 – 6 of the header to ASCII "K0". Only valid with a DES EXPORTER, OKEYXLAT, IMPORTER,
or IKEYXLAT source key or, beginning with Release 5.4, AES EXPORTER or IMPORTER source key. Requires mode of use value keyword ENC-DEC, DEC-ONLY or ENC-ONLY.
KEK‑WRAP("K1")
Specifies to export a TR-31 key block protection key. Sets the bytes at offset 5 – 6 of the header to ASCII "K1". Not valid with VARXOR-A. Only valid with a DES EXPORTER, OKEYXLAT, IMPORTER, or IKEYXLAT source key or, beginning with Release 5.4, AES EXPORTER or IMPORTER source key. Requires mode of use value keyword ENC-DEC, DEC-ONLY or ENC-ONLY.
Importing RSA AES Key Wrapped Objects
Beginning with Release 8.2, CCA supports importing external keys that have been previously formatted using the RSA AES key wrap mechanism. The RSA AES key wrap mechanism, denoted CKM_RSA_AES_KEY_WRAP, is a PKCS#11 mechanism based on the RSA public-key cryptosystem and the AES key wrap mechanism. It supports single-part key wrapping and key unwrapping. The RSA AES key wrap mechanism can wrap and unwrap a single-part target key of any length and type using an RSA key. Note: Since just the key-material is wrapped and not the key-usage, compliance tagged key tokens are not supported.
For importing (unwrapping), the RSA AES key wrap mechanism:
-
unwraps the temporary AES key from the first part of the object with the private RSA key using CKM_RSA_PKCS_OAEP (PKOAEP2),
-
unwraps the target key from the second part with the temporary AES key using CKM_AES_KEY_WRAP_KWP (RFC5649),
-
returns the newly unwrapped target key as a CCA token.
Symmetric Key Import2 (CSNDSYI2) can be used to import an AES token from a CKM_RSA_AES_KEY_WRAP-wrapped object. A new ACP was added to control CKM_RSA_AES_KEY_WRAP support in CSNDSYI2:
PKA Key Import (CSNDPKI) can be used to import RSA and ECC tokens from CKM_RSA_AES_KEY_WRAP-wrapped objects. For RSA keys, private section types X’30’, X’31’, and X’08’ are supported. For ECC keys, private section type X’20’ is supported. Two new ACPS were added to control CKM_RSA_AES_KEY_WRAP support in CNSDPKI:
DKYGENKY KMF-MBE/P
Beginning with Release 8.2, CCA supports 2 new key management field bits in AES DKYGENKY key tokens. These new bits affect the way the key management fields (KMF) are applied to the generated_key_identifier in the Diversified Key Generate2 (CSNBDKG2) service when the generated_key_identifier is a skeleton token and the generating_key_identifier is an AES DKYGENKY key with one of these new bits on. The KMF-MBP and KMF-MBE bits may be set in an AES DKYGENKY skeleton token when it is created with the Key Token Build2 (CSNBKTB2) service. The bits may also be set in an existing AES DKYGENKY key using the Restrict Key Attribute (CSNBRKA) service.
-
KMF-MBP: The key management fields (KMF) of the key to be generated must be permissible based on the key management fields of the generating key. The KMF
of the key to be generated must have an equal or lower value for each of the KMF.
-
KMF-MBE: The key management fields (KMF) of the key to be generated must be equal to the key management fields of the generating key.
The Key Token Build2 (CSNBKTB2), Key Token Parse2 (CSNBKTP2), and Restrict Key Attribute (CSNBRKA) services have new rule array keywords to support this new function.
The KMF-MBP and KMF-MBE bits are viewed as conflicting, only 1 may be on.
In Diversified Key Generate2 (CSNBDKG2 only the first KMF field, containing export bits, will be subject to the KMF-MBE and KMF-MBP processing. The other KMF fields are not security relevant and will be set as follows:
-
The second KMF field containing key part and history will be set to zeros, indicating a complete key with no security history.
-
The third KMF field containing pedigree will be set to 0x06 indication the key was derived.
3-key TDES support for the EMVMACD/X9.19OPT
EMVMAC and EMVMACD
EMV message authentication processes. See the EMV 4.0 Book 2, Annex A1.2 for information about this form of MAC generation. The verb extends the text provided with one byte of X'80' followed by the minimum number (0…7) bytes of X'00' for the extended message to be a multiple of 8 bytes in length. The MAC is computed based on ISO/IEC 9797-1, MAC Algorithm 1 or MAC Algorithm 3, depending on key length. When specifying a single-length DES key, use EMVMAC. When specifying a double-length or, beginning with Release 5.4, triple-length Triple-DES key, use EMVMACD.
X9.19OPT
ANS X9.19 Optional Procedure, by default when a double-length or, beginning with Release 5.4, triple-length Triple-DES key is provided. This is the same as ISO/IEC 9797-1, MAC Algorithm 3.
The MAC Generate (CSNBMGN) and MAC Verify (CSNBMVR) will now accept 3-key TDES tokens when either the ‘ENVMACD’ or ‘X9.19OPT’ rule array keywords are specified.
CSNBMMS (Multi-Mac Scheme)
This release includes a new service, CSNBMMS, that is part of a comprehensive M of N MAC scheme:
-
Use case example: consider a business need to change the personal account number (PAN) associated with a customer personal identification number (PIN). For security reasons the service needs to verify certain input data before allowing the PAN change to occur. Consider further that the data verification must happen at multiple parties that are separate business entities and cryptographic trust and verification is needed. For performance and security strength a PKI solution is not desirable.
-
Solution: An M of N multi-MAC scheme where derivation of the MAC generation keys is tightly controlled through a Key Management System (KMS) and the M of N scheme parameters are input parameters to the key derivation process - binding the keys to the parameters.
-
The Multi-MAC Scheme (CSNBMMS) callable service is used to derive M of N MAC verification keys, validate M of N possible MACs over the input data, derive a final MAC key, then generate and return a final MAC.
-
Since the values of M, N, and the MAC identifier counter c are used in derivation processing, the values of the keys used for creating the input MACs directly depend on using the correct values when computing the individual MACs, binding the derived keys to the scheme parameters.
-
Later when the service where the PAN change is requested, the final MAC verification key is passed along with the input data. At this point the PAN change is allowed or disallowed based on the final MAC verification.
New Enhanced zLinux Package Security
-
Security: The SCS (Supply Chain Security) Code Signing Service (CSS) is new to our zLinux packages. CSS is the process of digitally signing compiled executable and scripts to confirm the software author's identity, and to guarantee the code has not been altered or corrupted since signing. The process employs the use of a cryptographic hash to validate packages integrity.
-
Validation: As a customer you can additionally validate with the certificate authority and check if the certificate is active, using OCSP verification during the certificate's validity period.
For more info, please see the following