The Ultimate Guide to Cryptographic Key Blocks

With the entry into force of the PCI PIN v2.0 standard in 2014, all encrypted symmetric keys (cryptograms) must be handled in structures called key blocks, which allow the integrity of those cryptographic keys to be protected in a standardised manner and unequivocally associated with a particular use in order to avoid unauthorised modifications or substitutions. This article describes in a general way the history and the need for the use of key blocks, as well as the dates stipulated for the global implementation of this security mechanism.

Update January 2023: All references to ASC X9 TR 31: Interoperable Secure Key Exchange Key Block Specification have been replaced by X9.143 Retail Financial Services: Interoperable Secure Key Block Specification.

Introduction

One of the encryption algorithms of Block Encryption that was most used in the financial field was the algorithm Data Encryption Standard (DES), also known as Data Encryption Algorithm (DEA). This algorithm was originally chosen as a FIPS standard in 1976 and is currently considered insecure, because the size of its key length (56 real key bits and 8 parity bits) is very short and can be easily compromised with current computational techniques (examples of which are the DES Breaking Machine of the EFF, Cost-Optimized Parallel COde Breaker (COPACABANA) and  Crack.sh: The World’s Fastest DES Cracker, among others).

Figure 1. Structure of a DES key: 64 bits, of which the last bit of each octet is used as parity bit

In response to this problem, two algorithms were used that used the same DES base but added new complexity to the process using iterations and additional keys:

• Double-DES (2DES or 2DEA) uses two instances of DES in the same clear text block. In each instance it uses different encryption keys. Currently, this algorithm is obsolete.

Figure 2. Double DES (K1 ≠ K2)

• Triple-DES (3DES or TDEA) uses three instances of DES in the same clear text, being able to use two keys (Double-length TDEA) or three different encryption keys (Triple-length TDEA).

Figure 3. Double-length TDEA (K1 ≠ K2)

Figure 4. Triple-length TDEA (K1 ≠ K2 ≠ K3)

The set of keys used in 2DES and 3DES and their specific order is called Key Bundle, a concept introduced in the 1990s. As you can see, when making use of several keys must be established the Order of such keys or, otherwise, the decryption process will not be correct. Additionally, the use of key bundles helps protect against attacks from Meet-in-the-middle, aimed at obtaining cryptographic keys in ciphers that use two or more keys in multiple rounds of encryption with the same algorithm.

However, the use of key bundles no ensures the complete security of the cryptosystem. One of the main problems lies in the security during the process of exchanging and storing symmetric keys in hostile environments. These keys are usually shared or stored by encrypting them with another key (key-encrypting key – KEK). If a KEK is transmitted or stored without any attributes restricting its use to specific processes (encryption of another key), an attacker could exploit this vulnerability as part of an attack on the cryptosystem (cryptanalysis).

One of the most widely used alternatives to manage this problem is through the use of variants (Key Variants). Variants are created by combining a binary mask with the original key, depending on the type of implementation (Atalla variant, Thales variant, IBM variant o Control Vectors, etc.). However, this method does not provide any functionality for verifying the integrity or authentication of the key.

To solve this problem, another additional concept of cryptographic protection for keys called Key Wrapping, which can be used interchangeably for TDEA (Triple DEA Key Wrap – TKW) as for AES (AES Key Wrap – AESKW or AES Key Wrap With Padding – KWP). The purpose of the key wrapping is to unmistakably link the key (AES or all keys of a Key Bundle from TDEA) to additional information (metadata), establishing specific use policies for each key. Generally speaking, the use of key wrapping allows:

1. Associate the type/purpose of a cryptographic key to ensure that this key is not used for any purpose other than the designated one, for example, as a key encryption key (KEK) or as a PIN encryption key.
2. Protect the integrity of the key, including the order of the parts of the key in the case of algorithms that require multiple keys, for example, TDEA.

In this way, the functionalities provided by the key bundles and variants (key variants) can be deployed using only key wrapping. Technically, the concept of key wrapping gave rise to what is now known as Key Blocks.

Structure of the Key Blocks

According to requirements 18-3 of PCI PIN v3.0 and P2PE v3.0, some of the acceptable methods for the implementation of key blocks are:

• Using a MAC function (Message Authentication Code) applied on the concatenation of the attributes in clear text and the encrypted part of the Key Block, which includes the key (example: ANSI X9.143 e ISO 20038),
• A digital signature computed on all this data (example: ASC X9 TR 34), or
• An integrity check function that is an implicit part of the key encryption process such as the one used in the key-wrapping in AES keys, specified in ANSI X9.102.

There are multiple proprietary implementations of these methods of key blocks, including Atalla Key Blocks (AKB) and Thales Key Blocks (TKB). In order to avoid compatibility issues and ensure consistency with ANSI X9.24, ANSI developed the technical report in 2017. ASC X9 TR-31: Interoperable Secure Key Exchange Key Block Specification.  This report was updated in 2021 and finally renamed in 2022 to ANSI X9.143-2022: Retail Financial Services Interoperable Secure Key Block Specification which, today, is the method de facto for the implementation of key blocks.

In X9.143, each key block contains a protected key, the information of its limitations of use and other metadata that is protected by a mechanism of key wrapping, as follows:

Figure 5. Key Block Structure using ANSI X9.143

This model involves the generation of a new encryption key (Key-Block Protection Key – KBPK) from which two additional keys will be derived:

• Key-Block Encryption Key (KBEK), used to encrypt the section containing the cryptogram of the key and its length; and
• Key-Block Authentication Key (KBAK), used to generate a message authentication code (Message Authentication Code – MAC) of the entire content of the Key Block. This key is also known as Key-Block MAC Key (KBMK).

Key Block Header Structure (ANSI X9.143)

By using these structures it is ensured that the change or replacement of any bit in the attributes or encryption key can be detected effectively.

Figure 6. Example of decoding a Key Block, including the description of the header, using EFTlab BP-Tools (https://www.eftlab.com/bp-tools/)

Using Key Blocks

Generally, encryption keys can be stored or transmitted by any of the following methods:

1. At least in two key shares Separate or in components
2. Contents within a secure cryptographic device (Secure Cryptographic Device – SCD)
3. Encrypted with a key of equal or greater strength than the protected key

Traditionally, when keys are stored or transmitted by encrypting them with other keys (called Key-encrypting (encipherment or exchange) keys –  KEK) cannot be guaranteed that the KEK can only be used for the encryption or decryption of other keys nor can its integrity be validated. In that case, the use of Key Blocks is indispensable and applicable at any time when a cryptographic key exists outside the boundaries of a cryptographic security device (SCD).

What kind of keys should be protected using Key Blocks?

The concept of key wrapping / key blocks is applicable to any encrypted symmetric key that has to be stored outside the security limits of an SCD or transferred to an external entity.

From the perspective of PCI PIN and P2PE, the use of key blocks is mandatory for all symmetric keys exchanged or stored under another symmetric key under fixed key scenarios (fixed key) and master key/session key (e.g. Zone Master Keys (ZMK), Key-Encipherment Keys (KEKs), Terminal Master Keys (TMKs) and PIN-Encryption Keys (PEKs)).

Likewise, in the case of DUKPT, the use of Key Blocks is applicable to Derivation Keys Base (BDKs) and initial DUKPT keys (initial DUKPT keys).

It is also important to note that all Hardware Security Modules (HSMs) certified as PCI HSM and all PIN acceptance devices (Point-of-Interaction – POI) from version 2 of PCI PTS POI (published in 2007) support TR-31 or equivalent methods.

Key Blocks Implementation Periods

In order to allow a coordinated and staggered migration towards the Key Blocks, in July 2020 (for PCI PIN) and in August 2020 (for P2PE) the ICP SSC defined the following phases and their related dates (amended due to the impact of COVID-19):

• Phase 1: Must be implemented Key Blocks for all internal connections and key storage within the Service Provider environment. This may include applications and databases connected to Hardware Security Modules (HSMs). Date of entry into force: 1 June 2019 (completed).
• Phase 2: Must be implemented Key Blocks for external connections to associations and networks. Date of entry into force: 1 January 2023 (completed).
• Phase 3: Extension of the implementation of Key Blocks to all merchant hosts, point-of-sale terminals and electronic tellers. Date of entry into force: 1 January 2025.

It's important to note that payment brands (mainly Visa entered your program) Visa PIN) have also emphasized migration to Key Blocks.

What needs to be done in each of the migration phases to meet Key Blocks deployment dates?

Migration from traditional keys to keys in key block format for transmission and storage requires planning and time, as well as support from external entities such as HSM manufacturers, manufacturers of interaction point devices (POIs) and companies with which there are connections with encrypted data from the entity (KIFs, issuers, etc.). The tasks to be performed in each of the phases are described in a general way below:

Phase I: Internal connections and storage within the entity

• All cryptographic repositories (cryptographic keys encrypted with other keys) that are outside the safe limits of an HSM must be migrated to key blocks. This includes cryptograms stored in databases, files, etc. Depending on the hierarchy of keys in the organization, keys outside of an HSM may be encrypted by the master key of the HSM (Master File Key / Local Master Key) or by other encryption keys (Key-Encrypting Keys – KEK), so these keys (MFK/LMK/KEK) must be migrated to generate Key Block Protection Keys (KBPK) and be able to encrypt other keys using key blocks.

Phase II: External connections to associations and networks

• All KEK (Zone Master Keys – ZMK) used for the transmission of PIN encryption keys with external entities (Acquirer Working Key (AWK), Issuer Working Key (IWK), etc.) should be replaced by KBPKs.
• This key migration affects not only the purchasing environment but also the issuing environment, so issuers and authorizing centers are required to migrate their keys. Similarly, if the entity shares keys with key injection services (Key Injection Facilities (KIF), CA/RAs, etc.), transport keys must be migrated to format key block.

Phase III: Hosts of merchants, point-of-sale terminals and electronic tellers

• All KEK (Terminal Master Key – TMK) used for the transmission of PIN encryption keys on merchant hosts, point-of-sale terminals and ATMs (Terminal PIN KeyTPK), Initial PIN Encryption Key (IPEK)) should be replaced by KBPKs.

How can you check if a cryptographic key is in key block format?

One of the advantages of standardization provided by key blocks (key blocks) is that it can be identified by simple direct observation whether a cryptographic key is in key block format or not.header) of a key block indicates the version used. There are four key block version identifiers:

• Version A: Key block protected using Key Variant Binding Method
• Version B: Key block protected using TDEA Key Derivation Binding Method
• Version C: Key block protected using TDEA Key Variant Binding Method
• Version D: Key block protected using AES Key Derivation Binding Method

From the perspective of PCI PIN and PCI P2PE, only versions B (TDEA) and D (AES) are acceptable, since they use derivation instead of variants for key diversification. A variant is significantly weaker because it is reversible, while derivation is not. Using this criterion, below are two TDEA cryptographic keys protected by key blocks:

A0136V0TN00S0200102CIBMC012400227E000341000000227E0003210000PB047F5787857B413A01A880461CB19203B0F2D9E3E5326133B9D29036D35BEC873C95F22E81

B0144P0TE00S0200102CIBMC012400247700034100000024770003210000PB04C71F199CC5A13FECEAAF94EC3CC4C3025787E709BC8101236F51736F93421D65CABAD5E97A7FD11B

Of these two keys, only the second (the one that uses the B identifier) is valid to be used in the PCI PIN/PCI P2PE environment.

References

• PCI Perspectives: Key Blocks 101, Key Blocks 102, Key Blocks 103 y Key Blocks 104
• PCI SSC Information Supplement: Cryptographic Key Blocks (June 2017)
• PCI SSC Information Supplement: PIN Security Requirement 18-3 -Key Blocks (July 2022)
• PCI SSC PCI Security Standards Council Bulletin: Revisions to the Implementation Dates for PCI P2PE Security Requirement 18-3
• PCI SSC PCI Security Standards Council Bulletin: Revisions to the Implementation Date for PCI PIN Security Requirement 18-3
• Geobridge: Implementing Key Blocks Guide
• SANS: 3DES and Secure PIN-based Electronic Transaction Processing
• Cryptomathic: Introduction to Cryptographic Key Blocks – FAQs https://www.cryptomathic.com/news-events/blog/introduction-to-cryptographic-key-blocks-faqs
• Cryptomathic: An Overview of the Different Key Block Formats https://www.cryptomathic.com/news-events/blog/an-overview-of-the-different-key-block-formats
• Utimaco: A Panorama of the key blocks https://utimaco.com/current-topics/blog/panorama-key-blocks
• ANSI X9.24 Part 1-2009 Retail Financial Services Symmetric Key Management Part 1: Using Symmetric Techniques
• ANSI X9.24 Part 2-2006 Retail Financial Services Symmetric Key Management Part 2: Using Asymmetric Techniques for Distribution of Symmetric Keys
• ANSI X9 TR-31, Interoperable Secure Key Exchange Key Block Specification
• ANSI ANSI X9.143-2022 Retail Financial Services Interoperable Secure Key Block Specification
• ISO 20038: Banking and related financial services — Key wrap using AES