IBM Crypto Education Community - Group home

PCI-HSM best practices and configuration for your IBM Crypto Express HSMs with CCA

By Richard Kisley posted Wed March 31, 2021 11:36 AM



Richard Kisley
Garry Sullivan
Roan Dawkins
William C. (Craig) Johnston

Is your business audited against the Payment Card Industry Data Security Standard (PCI DSS), or in particular the PCI PIN Transaction Security (PCI PTS) PIN security requirements? 

Many teams face difficulty when validating their applications against these requirements or configuring their Hardware Security Modules (HSMs).  The IBM Crypto Express HSMs are designed to meet the PCI PTS security requirements for HSMs, often referred to as 'PCI-HSM', with the least adaptation or application impact possible. 

This article explores best practices for PCI-HSM use cases and configuration wizards for the Trusted Key Entry (TKE) administration workstation that make this daunting project much less complicated.

What Is PCI PTS HSM Certification?

While PCI DSS applies broadly for protection of cardholder data, PCI PTS PIN (known as PCI PIN) focuses on protection of customer PIN numbers through all data flows, requiring HSMs for most payment network use cases.  The PCI PTS program has a stand-alone certification regime for HSMs, known as PCI HSM.  The IBM HSMs certified under PCI-HSM are listed on the PCI website under PCI PTS approved devices.

How does the IBM HSM support PCI-HSM?

IBM HSMs implement a PCI-HSM 'compliant mode', that must be configured using the IBM Trusted Key Entry Workstation (TKE).  The 'compliant mode' is a net add to your normal run-time mode with the IBM HSM - you can even keep your normal application online and running while you configure your IBM HSM into compliant mode and bring a compliant workload online.  This is possible because the PCI-HSM compliant mode is implemented using securely tagged keys - each compliant-tagged key is only usable in compliant mode and useless otherwise.  Compliant-tagged keys live in the CKDS (IBM key storage) alongside your normal/legacy keys - while the secure tag allows you to run an audit report at any time showing which keys are used with PCI-HSM workloads.

Further note that IBM's HSM virtualization technology, known as domains for IBM Z, is PCI-HSM certified.  This means that the same physical IBM HSM is allowed to have a mix of domains: some configured in PCI-HSM compliant mode and some configured in 'normal' mode, supporting applications of both types at the same time.

Best practices

This list may serve as a starting checklist for exploiting PCI-HSM mode for the IBM HSM with CCA.

HSM Management Tool: TKE

To configure IBM Z and LinuxONE domains to run in PCI compliant mode, you must manage the domains using the TKE.  The PCI standard requires all HSM administrative settings to be managed using dual controls.  This is enforced on the HSM.  The TKE is required to provide the proper master key part protection mechanisms and enforcement of separation of administrative commands signing.  These mechanisms are provided by the TKE using smart cards.  

The IBM Z and LinuxONE HSMs may be managed at the whole module level in normal mode, or at the domain level in PCI compliance mode.  Those domains that share a common master key set would be collected into a single domain group at the TKE. For a PCI compliant domain group, a set of domain level users are created. Domain level administrators provide the support for separation of duties required by PCI-DSS by authorizing users only to the domains in the specific group. Groups for production domains and test/development domains should have different domain level users. Test/development domain users would not be permitted to manage production domains.

Prior to configuring the domain groups, it is advisable to determine which domains would share the same master keys, which would then become the PCI compliant domain groups at the TKE. Separate smart card sets are created using the Smart Card Utility Program for each PCI compliant domain group to be configured. These smart cards would contain the domain group specific command issuers, command co-signers, and key custodians with their related authority indices and signature keys.

Additionally, the System Z and LinuxONE CECs must be configured to allow TKE commands, and specific LPARs need to have control of the HSM domains to be managed. These LPARs would run the TKE host transaction programs required to connect the TKE workstation to the System Z and LinuxONE HSMs

Plan migration of current PCI-scope keys to be compliant-tagged keys

Identify the business processes that need to be managed according to PCI security requirements.  Chances are you already know these flows due to current PCI DSS and PCI PIN audit scope.

Identify current keys that will need to be compliant-tagged.  This investigation includes these tasks:

  1. identify PCI scope flows
  2. identify PCI scope applications in those flows
  3. identify the keys used by these applications
==> This is the current population of secure keys that will need to be compliant-tagged.

Plan a migration workload for a test environment for each key population that will need to transition, and then test the workload and make needed adjustments.

Notes for this migration include:

  1. Is your Main Key strong enough? TDES Main Keys should be 24 bytes long with no repeated 8-byte sections. Consider the parity bits when making this determination.  Note that the actual complete Main Key should not be known by any 1 person, however the key part control officers should be briefed on the security requirements so that a Main Key migration can be planned if their key parts are 16 bytes long.
  2. Do you have PCI scope flows that rely on single-DES (8 byte) keys? Investigate moving these to a minimum of 16 bytes in length, prefer 24 byte keys where possible.
  3. Do you rely on DATA keys? These multi-type keys are allowed to perform encryption and MAC operations - and are not PCI compliant. Consider a transition to single-type keys such as CIPHER and MAC keys.
  4. Consider labels that identify compliant-tagged keys in your key storage so that reports can be generated quickly for the appropriate key population. All compliant-tagged keys have a binary marker which also aids reporting.
  5. Note the ICSF Application Programmer's Guide (APG) section titled "Impact of compliance mode on callable services" for more important details, as well as the ICSF System Programmer's Guide (SPG) section "Migrating to PCI-HSM 2016 compliance mode".

Plan migration of PCI scope key management flows

Identify key management flows that will need to be updated for PCI compliance

There are legacy TDES key management flows that involve exchange of simple/basic 'no attributes' keys under key encrypting keys.  There are several possibilities for import/export of keys without attributes:

  1. RSA-encrypted keys in PKCS 1.5 or OAEP encoded blocks
  2. exchange of DATA keys or zero-CV keys (keys where the CV is 8 or 16 bytes of 0x00)
  3. exchange of keys encrypted by NO-CV key encrypting keys
  4. exchange of keys of a certain type, followed by a change of that type using the CSNBCVT service
  5. Entering keys as un-encrypted parts on GUI or CLI

==>These key management flows are not possible with PCI-HSM compliant tagged keys. 

Some alternatives to the above examples:

  1. Enter keys through the TKE using smartcard protection
  2. Exchange of TR-31 key blocks protected by key encrypting keys entered from the TKE connected smart cards.
  3. Elliptic Curve Diffie Hellman key negotiation using X.509 certificates for the public keys
  4. TDES DUKPT or AES DUKPT derived keys from initial keys that were exchanged or entered by a method in this list.

HSM Management Using the TKE

As stated previously, the TKE is required to configure IBM Z and LinuxONE domains to run in PCI compliant mode.  However, it is good to review basic HSM management requirements.  IBM Z and linuxONE HSMs must be managed according to the strict policies established by the client. The policies are based on client preferences that are influenced by various legal, regulator, and compliance requirements. In many cases, the final policies must include dual control management and hardware-based master key part protection to pass internal and external security audits. The TKE (Trusted Key Entry) is the only feature that allows you to manage IBM Z and LinuxONE HSMs running in Common Cryptographic Architecture (CCA) using compliant-level hardware-based key management techniques.  

To help you define your security policies, TKE provides wizards that work together to implement a comprehensive set of security policies for managing access to the TKE workstation and managing IBM Z and LinuxONE HSMS and their domains. We will only focus on a managing Common Cryptographic Architecture (CCA) IBM Z or LinuxONE HSM domains in Imprint-mode and PCI-Compliant mode.  

There are two TKE wizards that will help you on the way to managing your PCI domains.  The first wizard (the TKE Smart Card Wizard) creates all the smart cards needed for managing domains in PCI mode.  The second wizard is used to implement a management policy for your PCI domains.  

TKE Smart Card Wizard overview

 All the TKE policy implementation wizards, including the one for PCI, use smart cards. This wizard creates all the smart cards that the TKE policy implementation wizards need. You can also use this wizard to create a new TKE zone and enroll your TKE workstation in a TKE zone.

CCA Setup PCI Environment Wizard overview

The CCA Setup PCI Environment Wizard helps you create a set of domain-specific host crypto module Roles and Authorities that your administrators use when managing domain-specific settings for domains that are configured to run in PCI-Compliant mode.  The CCA Setup PCI Environment Wizard is only available when a domain is in IMPRINT MODE. This is the state that a domain must be in order to do the initial PCI-Compliant domain configuration before you can move the domain to PCI-compliant mode. The CCA Setup PCI Environment Wizard creates four roles that places host domain administrators into two categories:

  • Administrators responsible for managing all settings except master and operational keys. One role only allows the administrator to start (they issue) commands while the second role only allows the administrator to approve (they cosign) commands.
  • Administrators responsible for managing master and operational keys. One role only allows the administrator to load a first key part while the other role only allows the administrator to load additional or last key parts.

HSM Management Summary

The TKE is the only feature that allows you to manage IBM Z and LinuxONE HSMs running in Common Cryptographic Architecture (CCA) mode using compliant-level hardware-based key management techniques.

With the help of the TKE policy wizard family, setting up the management policy for the TKE workstation and the host crypto modules that you manage is simple and straightforward. The TKE wizards reduce the time you spend as well as simplify the process of setting up your policies for managing your cryptographic environment. 

Learn more

1 comment


Wed April 07, 2021 10:23 AM

This is great detail on best practices. Thank you for sharing this blog on our community!