IBM Crypto Education Community - Group home

Quantum Safe Cryptography and other updates with IBM CEX8S on IBM z16

By Richard Kisley posted Thu August 18, 2022 08:58 PM

Authors: Richard Kisley, Michael Miele, Jimmy Hill, Jim Cox, Gregg Arquero, Eric Rossman

This article introduces the updates for the Common Cryptographic Architecture (CCA) in ICSF on IBM z16 with APAR
OA61609 for exploitation on ICSF FMIDs HCR77D1/HCR77D2 .
Audience: Users of CCA for payment or cryptography applications on 
  • ICSF for IBM Z, 
  • IBM z16, as well as the IBM z14 and IBM z15, which receive function updates as applicable when new firmware is applied and the new ICSF software or Linux for IBM Z library is used.
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, IBM POWER/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?
The last update for ICSF and CCA firmware on IBM Z was: CCA 7.4 for CEX7S with CCA and ICSF on IBM z15.
This update adds support for the following features, described in more detail below:
  • QSA Hybrid System Key Negotiation
  • QSA and Dual Signature Support
  • Wrap Enhanced Method 3 (WRAPENH3) Configuration Management
  • 24KB Message Size Support
  • Relaxed KEK Strength for CKM-RAKW
QSA Hybrid System Key Negotiation
The Protected Key solution is secured by an AES-256 transport key negotiated between the CEX8S and the CPACF system component. Protected Key transport key negotiation now makes use of Crystals-Dilithium 8,7 r2 signature validation in addition to ECC P521 signature validation. Protected key transport key negotiation also makes use of Crystals-Kyber-1024 round 2 key encapsulation in addition to ECDH P521 key encapsulation.
QSA and Dual Signature Support 
For QSA support the Crystals-Kyber and Crystals-Dilithium key types were added.
Replies to Trusted Key Entry (TKE) workstation requests will be signed twice, with ECC and with Dilithium. The TKE reply control block structure has been updated to contain the additional QSA signature.
  • QSA Token
    • The token is a PKA token, with the same header as the RSA and ECC tokens.
    • 0x50 New private section id for QSA
    • 0x51 New public section id for QSA
  • QSA Programming Interface Changes
      • The only external change is to increase the certificate_length parameter to 8000 bytes.
      • Internally the service will loop until the entire certificate has been obtained.
      • The SIGNSTAT and STATOAHL rules are deprecated.
      • New rules: SIG2STAT and STATOAH2
      • SIG2STAT causes the STATOAH2, GETCOMPA, GETCOMPD replies to be dual signed with the same method as TKE replies, with ECC and Dilithium signatures.
      • STATOAH2 returns from CCA the same data as would be returned from a secure bootloader: QUERY HEATH command, which on IBM Z is only available to system firmware.
      • New rules QSA-PAIR and QSA-PUBL for QSA token creation.
      • New key values structures have been defined to indicate the type of QSA key skeleton to produce.
      • QSA key tokens will be generated when a QSA skeleton is provided.
      • Note: no support for encrypted external QSA tokens.
      • QSA key tokens will be imported when a QSA token is provided.
      • Note: no support for encrypted external QSA tokens.
      • QSA public tokens will be created from provided QSA public/private key tokens.
      • QSA tokens will be processed. 
    • CSNBKTB2
      • New key usage wrapping control, WR-QSA, for AES IMPORTER/EXPORTER keys used for exporting an internal QSA token to AESKW key format.
      • New rule: QSA-AES1 will export a QSA internal token to the AESKW key format wrapped by an AES KEK.
      • New Hashing-method rule: CRDLHASH
      • New Signature-algorithm rule: CRDL-DSA
      • These rules used to generate a Dilithium signature using a Dilithium key.
      • Maximum message size to be signed using a Dilithium key was increased from 5k to 15k bytes.
      • New Hashing-method rule: CRDLHASH
      • New Signature-algorithm rule: CRDL-DSA
      • These rules are used to verify a Dilithium signature using a Dilithium key.
      • Maximum message size to be verified using a Dilithium key was increased from 5k to 15k bytes.
      • Updated to accept Kyber keys. Input data is fixed at 32 bytes.
      • New rule: RANDOM will generate random 32 byte value and return encrypted by provided Kyber and AES key tokens.
      • Part of Hybrid Quantum Safe Algorithm Key Exchange System.
      • Updated to accept Kyber keys. Input data is fixed at 1568 bytes.
      • Part of Hybrid Quantum Safe Algorithm Key Exchange System.
      • New Rule group: Scheme
        • ECDH ( default ) follow existing scheme ( ECDH ).
        • QSA-ECDH: Follows Hybrid QSA Key Exchange Scheme
      • New rule group: Hybrid Scheme Encrypted Key Type:
        • IHKEYKYB: Kyber key
        • IHKEYAES: AES Key
Wrap Enhanced Method 3 (WRAPENH3) Configuration Management 
The WRAPENH3 method, introduced in the CCA 7.3, 6.6, 5.7 releases, is a Payment Card Industry (PCI) PIN compliant wrapping method that has been independently reviewed for compliance.  The WRAPENH3 method is based on the enhanced wrapping method using SHA-256 with the addition of a message authentication code(MAC). The wrapping and MAC keys are derived using the NIST KDF with SHA-256 HMAC. A TDES-CMAC authentication code is generated over the complete key token. The authentication code is stored in the token where the right control vector was stored. There will always be three key parts encrypted and placed in the key token to obfuscate the key length. WRAPENH3 adds several important security features to the IBM fixed-length TDES key block:
  1. An 8 Byte TDES-CMAC is calculated over the clear key and attributes as a new integrity protection and carried in the secure key block.
  2. Independent derivation of the encryption key and the integrity key, giving these properties: Compromise of one key used in the wrapping process does not compromise other keys.
    1. Legacy (non-updated) systems will not be able to unwrap the updated token or decrypt the key material, even with a shared wrapping key.
  3. The length of the key is obfuscated - a 24 byte encrypted payload is used for all key lengths and no indication of length is carried in the un-encrypted attributes (CV1) visible in the key block. This keeps attackers from attacking the shorter (easier to guess) keys from a key population.
  4. Enhanced wrapping method 3 does not use legacy 'variant' processing methods such as XOR of the key attributes bit string into the wrapping key value.
IBM fixed-length TDES key blocks with WRAPENH3 are supported in all (non-deprecated) CCA services where TDES keys are used.
In the CEX8S CCA 8.0 release, the Configuration Management was updated to support the configuration and querying of WRAPENH3 support. New support is added in the TKE and CEX8S firmware to allow the TKE user to specify WRAPENH3 as the default key-wrapping methods for internal and external DES/TDES key tokens.
New Access Control Points were added:
    • Access Control offset (0x0143):  Wrap Internal Key with WRAPENH3 (required when the default key-wrapping method for Internal DES/TDES key tokens is WRAPENH3).
    • Access Control offset (0x0145):  Wrap External Key with WRAPENH3 (required when the the default key-wrapping method for External DES/TDES key tokens is WRAPENH3).
A new value has been added for the keyword, WRAPMTHD, in the Rule Array for the CSUACFQ verb to report when WRAPENH3 is the default key-wrapping methods for internal and external key tokens. A value of "3" indicates the default wrapping method is WRAPENH3.
If WRAPENH3 is set as the default wrapping method, when tokens are built using SET Block Decompose (CSNDSBD) or PCF/CSUP Key Conversion (CSUAPCV) and the output wrap type is forced to WRAP_TKB_DEFAULT, then the resulting token will be wrapped using WRAPENH3.
24KB Message Size Support
System Firmware increased the maximum allowed message size from 12KB to 24KB. This change increases the message size available for the control blocks and data. Only the CEX8S with CCA 8.0 and newer releases will support the 24KB message size.
Relaxed KEK Strength for CKM-RAKW 
In Release 7.4, the RSA AES key wrap mechanism was introduced to support the Azure Key Exchange. The CKM_RSA_AES_KEY_WRAP mechanism is available in CSNDPKT and CSNDSYX using the CKM-RAKW keyword. When specified, CKM-RAKW will generate an ephemeral AES-256 key, format/wrap the external RSA, ECC, or AES private key with an ephemeral AES-256 key, format/wrap the ephemeral AES-256 key with the RSA public Key Encrypting Key (KEK), and return the resulting structure which corresponds to the output from PKCS#11 mechanism CKM_RSA_AES_KEY_WRAP.
The RSA KEK must be an RSA-public key with a modulus length of 4096-bits, 3072-bits, or 2048-bits. However, with the "Prohibit weak wrapping - Transport keys" (0x0328) or "Warn when weak wrap - Transport keys" (0x032C) Access Control Points (ACP) set to binary '1', the usable RSA keys are limited, thus impacting the usefulness of CKM-RAKW. This can be overcome by turning off the access control points, but that leads to a less secure environment.
To address this issue, a new ACP, "CKM_RAKW - Allow RSA2048 to wrap stronger keys (e.g., AES-128, 192, 256)" (0x033E) has been added which allows for a relaxed RSA KEK strength when used with CKM-RAKW. That is, if (0x0328) is binary '1' and (0x033E) is binary '1' and the caller supplies a 2048-bit (or larger) RSA key, the CSNDPKT or CSNDSYX operation using CKM-RAKW will complete without error. If (0x033E) is binary '0', the same operation will fail with return code 8/reason code 2145.

To learn more:
1 comment


Sun August 21, 2022 07:43 AM

Thank you very much for keeping us updated.