Why does the Shift from PCI PTS v1 to v3 and PCI PIN Security Mandate a Key Block-Oriented Architecture?

This article highlights the use of key blocks for securing cryptographic keys under the latest versions of PCI PTS and PCI PIN Security.

Since the exponential increase of digital assets in banking transactions, the requirement of cryptographic mechanisms for the protection of assets has also increased respectively. The evolving complexity of cyber-attacks and existing vulnerabilities in communication systems has made protecting cryptographic keys a huge challenge. 

The top cryptographic security control for protecting business transactions is the hardware security module (HSM). Banks and enterprises use HSMs to protect their and their clients’ transactions. 

The loss or compromise of crypto keys would lead to reputational loss, penal regulatory penalties, and loss of trust of clients and investors on the business. 

The release of the latest version 3.0 of PCI PTS HSM and version 3.0 of PCI PIN Security Requirements and Testing Procedures strongly mandates the use of key blocks.

This article highlights the importance of key blocks for the security of cryptographic keys.

The Need for Key Blocks

The reason for fortifying cryptographic keys is to provide security and reliability that targets two basic requirements:

• Key Usage Control: The usage, purpose, and type of keys should be strictly bound to ensure that the key cannot be used for unauthorized purposes.
• Key Integrity: The key cannot be modified by an unauthorized party.

ASC X9 TR 31-2018 - Interoperable Secure Key Exchange Key Block Specification addresses the requirements for key blocks and standards for key blocks.

PCI Standards that Mandate the Use of Key Blocks.

• PCI PTS HSM Version 3.0, released in June 2016, provides guidelines for HSMs for throughout their whole lifecycle (fabricating, conveyance, utilization, and decommissioning) for HSM sellers to follow under PCI PTS (PIN Transaction Security) HSM "Modular Security Requirements." PCI PTS provides operational/technical security requirements for the protection of cardholder data along with cardholder authentication, payment processing, and cryptographic key management, etc. The principal goal of these requirements is to eliminate the possibility of business fraud and decrease its likelihood and confinement of its implications. All HSM vendors and applications that store, process, or transmit cardholder data must comply with this standard.
   
• PCI PIN Security Requirements and Testing Procedures Version 3.0 released in August 2018, provides a set of comprehensive security requirements for the complete management (storage, processing, and transmission) of PIN data of offline & online payment card transactions processed by Point-of-Sale (POS) terminals and ATMs. The agenda for Implementation of Key Blocks was introduced as a new requirement for better security of encrypted keys, which greatly improves the security of symmetric keys that are shared among payment participants to protect PINs and other sensitive data.

Importance of Key Blocks

As mandated by PCI SSC & PCI DSS, the standard mechanism for protecting the integrity and usage/association of cryptographic keys is the implementation of key blocks. The payment data is protected by cryptographic keys, which are in turn protected by key blocks. Without the proper implementation of key blocks, banking solutions would be more vulnerable to attacks or breaches, resulting in potential payment data compromises.

Symmetric cryptographic algorithms use a single key for its mode of operation. However, there is a scenario of TDES (Triple DES) or TDEA where three keys are used. With TDES and TDEA, not only does the protection of keys matter but also their order because the order of the keys is critical to the strength of the resulting TDEA encryption. The order of the crypto keys cannot be assured without using key blocks.

What do key blocks successfully achieve?

Encryption keys must be used only for the purpose for which they were intended. For example, a PEK (PIN Encrypting Key) cannot be used as a KEK (Key Encrypting Key) and vice versa. Similarly, the keys for decryption and generation of digital signatures must be different. This segregation is necessary to limit the exposure of keys to maintain the strength of the overall system.

Key usage must be cryptographically bound to the key using accepted methods. Acceptable methods of implementing the integrity requirements include, but are not limited to:

• A MAC computed over the concatenation of the clear-text attributes and the enciphered portion of the key block, which includes the key itself.
• A digital signature computed over that same data.
• An integrity check that is an implicit part of the key-encryption process, such as what is used in the AES key-wrap process specified in ANSI X9.102 - Symmetric Key Cryptography for the Financial Services Industry - Wrapping of Keys and Associated Data.

Implementation Timeline of Key Blocks

The PCI PIN Security - Requirement 18-3 Key Blocks mandates that encrypted symmetric keys should be managed in key block structures. Key blocks must be used for all types of PIN security-relevant symmetric keys, including:

• PEK (PIN-Encryption Keys)
• KEK (Key-Encipherment Keys)
• ZMK (Zone Master Keys)
• BDK (Base Derivation Keys)
• TMK (Terminal Master Keys)

PCI SSC has rolled out a phase-wise implementation of three phases with each having its own effective date. The main aim to divide into three phases is to allow organizations to focus resources to address implementation tasks specific to their environment and support a smooth migration across the payments network.

The phase-wise implementation plan is as follows:

Structure of a Key Block

A key block provides confidentiality (secret data/keys cannot be disclosed) and integrity (associated data cannot be modified without detection) of the key(s). The integrity of a key block is protected as well. 

A key block contains the attributes that allow vendors and implementers to design policies for specific key types, e.g. if the HSM knows that a given key is a PIN key, it will not allow its use for non-PIN data. 

Similarly, if the HSM knows that a key is a key-encrypting key, it will not allow it to encrypt data. Vendors enforce these policies based on attributes to prevent attacks against the keys. The attacks on cryptographic keys were successful only in the scenarios where these attributes and policies were not effectively enforced.

Conclusion

HSMs are widely deployed in corporations for effective management and security of crypto keys. 

PCI PTS HSM version 1.0 was released in April 2009 and various HSMs and cryptographic modules were validated against this standard. A general public notice was issued by PCI SSC stating that the approval of devices validated using PCI PTS HSM version 1.0 expired on 30 April 2019. 

The latest versions of PCI PTS HSM and PIN Security Requirements strongly mandate the compliance of key blocks. Validations carried out older HSMs do not comply with the latest HSM security requirements and standards. They may not be able to withstand the latest generations of attacks and should, therefore, be replaced with key block-oriented, architecture-based hardware.

References

• Atalla HSM AT1000 - PCI HSM 3.0 Security Policy (August 2019), by Utimaco
• ASC X9 TR 31-2018 - Interoperable Secure Key Exchange Key Block Specification (2018), by Accredited Standards Committee X9, Incorporated Financial Industry Standards
• Payment Card Industry (PCI) PTS HSM Security Requirements -Technical FAQs for use with Version 3.0 (November 2018), by PCI Security Standards Council

Blog post by Dr. Ulrich Scholten