Authors:   Richard Kisley, Bob Petti

The Payment Card Industry (PCI) Security Standards Council (SSC) updated the published requirements for key block implementations in PCI PTS HSM FAQs dated 2020-Sep-30. The change impacted all HSM devices certified under PCI PTS HSM after that date, as well as all installations of HSMs audited under PCI PIN security requirements.  The deadline for implementation in existing installations was then set to 2023-Jan-1, through a clarification bulletin dated 2020-Dec-17 and PCI PIN FAQs dated 2021-Jan-27. Further details of the changes in PCI requirements are given below.

IBM introduced on 2021-May-05 a new wrapping method for the IBM TDES key block that is compliant with requirements published by PCI.  IBM strongly supports the move to stronger protections of user keys and security measures across industries.  This update is consistent with IBM previously obtaining PCI PTS HSM (known as PCI-HSM) certification of the CEX6S (2018, 2019) HSM with Common Cryptographic Architecture (CCA) firmware and the CEX7S (2021) with CCA 7.0.*z, 7.1.*z, 7.2.*z firmware and our commitment to PCI compliance going forward.

The new IBM TDES key block enhanced wrapping method 3 was independently reviewed along with the existing wrapping method for the IBM variable length AES key block.  Both IBM key blocks have been found to use wrapping methods and security measures equivalent to those required by PCI in the PCI PTS HSM FAQs dated 2020-Sep-30.

Full Details

What is a key block or key token?
A 'key block' in PCI literature is equivalent to a 'key token' as described in IBM literature.  IBM key tokens are defined in the IBM Common Cryptographic Architecture (CCA) publications for Linux, AIX and Windows, and IBM z/OS ICSF publications.  The rest of this document uses the term 'key block', noting here that 'key block' and 'key token' may be used interchangeably.  A 'key block' is simply a data structure carrying key material and attributes, with these important properties:

1. the attributes control key usage inside an HSM
2. encryption of the key material ensures the key is not usable outside the HSM, meaning the key block may be stored outside an HSM with no loss of security,
3. the key material is bound to the attributes, so that if the attributes are changed by an attacker when the key is outside the HSM, the key cannot be mis-used later in HSM services.

In recent years a further attribute is added for most key blocks:

4. integrity protection, so that any change to the attributes is immediately noticed when the key block is unwrapped.

The wrapping method of the key block is the implementation inside the HSM of properties 2, 3 and 4.  The HSM firmware executes the wrapping method over a data structure containing the clear key material and the key attributes, resulting in the secure key block that may be stored outside the HSM.

What is IBM introducing?

IBM CCA is introducing the IBM TDES fixed-length key block with enhanced wrapping method 3 (WRAPENH3).  The updated TDES key block is backwards compatible with existing applications and key storage (CKDS).  Host and application support for the updated TDES key block is implemented with:

• z/OS level 2.4, ICSF FMID 77D1 and exploitation APAR OA60318. 

IBM HSM firmware support for the updated TDES key block is now available for:

• IBM Z15 with driver D41C:S39a, supporting the Crypto Express 5S (CEX5S) with CCA, Crypto Express 6S (CEX6S) with CCA and Crypto Express 7S (CEX7S) with CCA.

More releases of CCA for IBM Z, IBM Cognitive (IBM POWER systems and IBM I), x86, legacy platforms and for key management solutions are planned soon, allowing complete ecosystem support.

Enhanced Wrapping Method 3

Enhanced wrapping method 3 (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:
   1. Compromise of one key used in the wrapping process does not compromise other keys.
   2. 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.

ICSF exploitation
From an ICSF perspective, exploitation of WRAPENH3 tokens was added to FMID HCR77D1 with APAR OA60318. This allows the creation of key blocks using the WRAPENH3 wrapping method and the use of those key blocks as operational keys in callable services. OA60318 also allows these key blocks to be stored in the CKDS. Services where a wrapping method can be specified in the rule array parameter have been updated to allow a WRAPENH3 rule to indicate the new wrapping method. Of course, for exploitation, the above referenced drivers must be installed on the IBM Z server. Management of the WRAPENH3 keys and a CKDS that contains WRAPENH3 keys must be done on an HCR77D1 system.

ICSF APAR OA60813 has been released for FMIDs HCR77C0, HCR77C1, and HCR77D0 to tolerate a CKDS that has a population of WRAPENH3 key blocks. These FMIDs will ignore the new WRAPENH3 key blocks when reading the CKDS and will disallow management of the CKDS such as a re-encipher operation.

What migration assistance will be available, and how do I use it?

With ICSF APAR OA60318, a WRAPENH3 feature has been added to the CSFCNV2 utility enabling the migration of all TDES keys in a CKDS to WRAPENH3 wrapping method. Also, a new SAF resource in the XFACILITY class, CSF.WRAPENH3.OVERRIDE, will provide a way to for applications to exploit the WRAPENH3 wrapping method without an application change. Applications running under a userid that has READ access to the CSF.WRAPENH3.OVERRIDE resource will have all their wrapping method rules replaced with WRAPENH3. In other words, if the application specifies WRAP-ECB in the rule array, ICSF will replace that with WRAPENH3 before making the request to the CCA coprocessor. If the application did not specify a rule and used the default wrapping method, ICSF would also specify WRAPENH3 rule when sending the request to the coprocessor. This way, customers can selectively enable WRAPENH3 operation for specific applications without requiring an application change. New message CSFM727I is issued to the console during ICSF initialization to indicate the existence of the WRAPENH3 override.

What is covered in the independent review of the IBM key blocks?

The PCI PIN security requirements focus on data protected by symmetric keys, such as customer PINs and account numbers, and the keys that protect those symmetric keys - which may be symmetric and/or asymmetric key wrapping keys.  There are new PCI PIN key block requirements (covered in detail below) which focus on symmetric key protection and require an evolution in IBM support.  IBM is in favor of and supports the enhanced security afforded by meeting these requirements and the extra protection of customer data that results.  The independent review of IBM key blocks is therefore focused on two key blocks used to protect symmetric keys in IBM HSMs:

1. IBM fixed-length TDES key block with enhanced wrapping method 3 (WRAPENH3)
   1. This is a new wrapping method applied to an existing key block: the IBM fixed-length TDES key block.
   2. Delivery of enhanced wrapping method 3 is discussed below.
2. IBM Variable Length Symmetric key block with an AES key
   1. This existing IBM key block was introduced in 2011 for protection of AES keys with fine-grained key attributes, key usage, and key management controls.
   2. While software or firmware update may be needed in certain legacy environments to fully exploit this key block, no new IBM delivery of function is needed to meet PCI PIN key block requirements.

Context of the update

What changed in the PCI PIN and PCI PTS HSM criteria for key blocks?

For the complete PCI PIN and PCI PTS HSM requirements for key blocks one must look in multiple places:

1. The documentation starts with "PCI PIN Security Requirements and Testing Procedures v3.0" (Aug 2018), requirement 18-3, which says that cryptographic keys must be managed in key blocks implemented with acceptable methods of attribute binding and integrity protection.  The document does not define 'acceptable methods', which allows industry innovation, security research and improvement - but leaves open questions for auditors.
2. PCI key block requirements are further specified in a "Frequently Asked Question" (FAQ) document that apply to the PCI PIN Security Requirements, with "PIN Security Requirement 18" as updated in Q34 (July 2019) to add criteria for an independent review of proprietary key blocks to establish that acceptable methods were used. 
3. On September 30, 2020, PCI key block requirements were clarified in an FAQ document that applies to the PCI PTS HSM Security Requirements - applicable to devices reviewed under PCI PTS HSM.  The FAQ updates HSM requirement B11 with FAQ 18 to give specific security requirements for key blocks. These set an auditable baseline for an independent review of a proprietary key block and clearly establish attribute 4 (explicit integrity protection) as a requirement.
4. On December 17, 2020, PCI issued a bulletin which further clarified (3) to add a date for the requirements to be met: January 1, 2023.  This bulletin was added as an FAQ update to PCI PIN on January 27, 2021. 
   
   

Is a proprietary key block better for financial services?  

This is a trick question: all current customers of financial/payment HSMs are using a proprietary key block.   The first attempt at a standard operational key block was published March 26, 2021, known as ANSI X9.143-2021.  The ANSI X9.143-2021 standard defines a simple operational key block for use in financial applications.  While standardization does have its value, there are cases where this is limiting compared to a full function proprietary implementation: the key block is missing fine-grained attributes that allow detailed key controls and key usage limitations. 

A main attraction of the IBM TDES key block with enhanced wrapping method 3 is that the key block works in existing applications that use CCA and has independently reviewed equivalent security protections to the key block in this new standard.  There are other strong reasons to use the IBM key block such the IBM CCA uni-directional key types:  A CCA PIN encryption key may only be used for encryption or decryption, it cannot - by definition - be used for both.  The direction of encryption is built into the key type when the key is created, in fact you must create a PIN encryption 'key' as a pair: one that is under a key-encrypting-key for use by a different node and one that is meant for use local to the generating node. This is also true for key encrypting keys: they must be generated as an IMPORTER/EXPORTER pair, where one of the pair is external.  

The detailed IBM CCA key controls also carry the PCI-HSM compliance-tag, so a customer can tell by visual inspection or by running a report on their key store which keys are meant for PCI compliant workloads run against an HSM in PCI-HSM mode.

A further example of the CCA key controls is the multi-level and fine-grained key derivation control.  Very complex and deep key derivation schemes may be built on top of the CCA key controls - which are enforced by the HSM.

To Learn More...

See this link for the independent review report:

                  (https://public.dhe.ibm.com/security/cryptocards/pciecc4/docs/).

Watch the CCA news page for any updates:

                  (https://www.ibm.com/security/cryptocards/cryptonews).

ICSF Publications:

                  (https://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSICSFFmidHCR77D1Publications?OpenDocument)

                  (https://www.pcisecuritystandards.org/assessors_and_solutions/pin_transaction_devices?agree=true)