Introduction

One of the most widely used block ciphers in the financial world was the Data Encryption Standard (DES) algorithm, also known as the Data Encryption Algorithm (DEA). This algorithm was originally chosen as a FIPS standard in 1976 and is currently considered insecure because its key length (56 real key bits and 8 parity bits) is now short enough to be easily compromised with current computing techniques (For example, the EFF DES Breaker, the Cost-Optimized Parallel Code Breaker (COPACABANA) and Crack.sh: The World's Fastest DES Cracker, among others).

Advantio_CryptographicKeyBlocks_diagrams_1-1

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

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

  • Double-DES (2DES or 2DEA) uses two instances of DES in the same block of plain text and each instance uses different encryption keys. This algorithm is now outdated.

Advantio_CryptographicKeyBlocks_diagrams_2-1

Figure 2.  Double DES (K1 ≠ K2)

  • Triple-DES (3DES or TDEA) uses three instances of DES in the same plain text and can employ either two keys (Double-length TDEA) or three different encryption keys (Triple-length TDEA).

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

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

The set of keys used in 2DES and 3DES and their specific order is called a Key Bundle, a concept introduced in the 1990s. When using several keys, the order of keys must be established or the decryption process will be incorrect. Additionally, the use of key bundles helps protect against any meet-in-the-middle attacks. These types of attacks are programmed to obtain cryptographic keys in ciphers that use two or more keys in multiple encryption rounds with the same algorithm.

However, the use of key bundles does not guarantee the complete security of the cryptosystem. One of the main problems lies in the security during the process of exchange and storage of symmetric keys in hostile environments. Usually, these keys are 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 a cryptosystem attack (cryptanalysis).

One of the most popular solutions to manage this problem is 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 or Control Vectors, etc.). However, this method does not provide any functionality for key integrity verification or authentication.

Key Wrapping solves this problem. Key wrapping is an additional cryptographic protection concept which can be used for both TDEA (Triple DEA Key Wrap - TKW) and AES (AES Key Wrap - AESKW or AES Key Wrap With Padding - KWP). The purpose of key wrapping is to unequivocally link the key (AES or all keys in a TDEA Key Bundle) to additional information (metadata), establishing specific usage policies for each key. In general terms, the use of key wrapping allows you to:

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

In this way, the functionalities provided by the key bundles and variants can be deployed using only key wrapping. Technically, the concept of key wrapping is also known as key blocks.

Structure of the Key Blocks

To maintain compliance with the requirements 18-3 of PCI PIN v3.0 and P2PE v3.0, some of the acceptable methods for implementing key blocks are:

  1. A MAC computed over the concatenation of the clear-text attributes and the enciphered portion of the key block, which includes the key itself.
  2. A digital signature computed over that same data.
  3. An integrity check that is an implicit part of the key-encryption process. For example, the use of the AES key-wrap process specified in ANSI X9.102.

There are multiple proprietary implementations of these key block methods, including Atalla Key Blocks  (AKB) and Thales Key Blocks (TKB). To avoid compatibility issues and ensure consistency with ANSI X9.24, in 2017 ANSI developed the ASC X9 TR-31: Interoperable Secure Key Exchange Key Block Specification  technical report, which is now the de facto method for implementing key blocks.

In X9 TR-31, each key block contains a protected key, the information of its use limitations, and other metadata that are protected by a key wrapping mechanism.

Advantio_CryptographicKeyBlocks_diagrams_5-3Figure 5. Key Block Structure using ANSI X9.24 

(source: www.pcihispano.com)

This model involves the generation of a new encryption key (Key-Block Protection Key - KBPK) from which two additional keys will be derived. One to encrypt the section containing the cryptogram of the key and its length, called Key-Block Encryption Key (KBEK), and another to generate a message authentication code (Message Authentication Code - MAC) of the entire content of the key block. The use of these structures ensures the change or replacement of any bit in the attributes or the encryption key can be effectively detected.

Screen Shot 2020-11-04 at 4.28.13 PMFigure 6.  Example of decoding a Key Block, including the header description, using EFTlab BP-Tools (https://www.eftlab.com/bp-tools/)

Use of Key Blocks

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

  • At least two separate key shares (secret or private) or full-length components (secret)
  • Encrypted with a key of equal or greater strength as delineated in Annex C
  • Contained within a secure cryptographic device

Traditionally, when keys are stored or transmitted by encrypting them with other keys (called Key-encrypting (encipherment or exchange) keys - KEK) it 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 essential and is applicable anytime a cryptographic key exists outside the boundaries of a security cryptographic device (SCD).

What Kind of Keys Should be Protected using Key Blocks?

The concept of key wrapping / key blocks applies to any symmetrical encrypted key.

  1. 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 the fixed key and master key/session key scenarios (e.g. Zone Master Keys (ZMK), Key-Encipherment Keys (KEKs), Terminal Master Keys (TMKs) and PIN-Encryption Keys (PEKs)).
  2. Likewise, in the case of DUKPT, the use of Key Blocks applies to Base Derivation Keys (BDKs) and initial DUKPT keys.
  3. It is also important to note that all Hardware Security Modules (HSM) certified as PCI HSM and all Point-of-Interaction (POI) devices from PCI PTS POI version 2 (published in 2007) support TR-31 or equivalent methods.

Key Blocks Implementation Phases

Finally, to enable a coordinated and phased migration to key blocks (July 2020 for PCI PIN and August 2020 for P2PE) the PCI SSC defined the following phases and their related dates (modified due to the impact of the COVID-19):

  • Phase 1 - Implement key blocks for internal connections and key storage within Service Provider Environments - this would include all applications and databases connected to hardware security modules (HSM). Effective date: 1 June 2019. (Complete)
  • Phase 2 - Implement key blocks for external connections to Associations and Networks. New Effective Date: January 1, 2023. (replaces previous effective date of 1 June 2021)
  • Phase 3 - Implement key blocks to extend to all merchant hosts, point-of-sale (POS) devices, and ATMs. New effective Date: January 1, 2025. (replaces previous effective date of 1 June 2023)

Summary

With the release of the PCI PIN v2.0 standard in 2014, all encrypted symmetric keys must now be managed in structures known as key blocks.  Key blocks allow the integrity of cryptographic keys to be protected in a standardized manner with an unambiguous association to a particular use. This safeguard helps prevent unauthorized modification or substitution.

This article has delved into the history and necessity of using key blocks, as well as the key dates stipulated for the global implementation of this security mechanism.

References

PCI Security Standards Council Bulletin: Revisions to the Implementation Date for PCI PIN Security Requirement 18-3
PCI Security Standards Council Bulletin: Revisions to the Implementation Dates for PCI P2PE Security Requirement 18-3
PCI Perspectives: Key Blocks 101, Key Blocks 102, Key Blocks 103 and Key Blocks 104
PCI SSC Guidance: PIN Security Requirement 18-3 Key Blocks
PCI SSC Information Supplement: Cryptographic Key Blocks (Junio 2017)
PCI SSC Information Supplement: PIN Security Requirement 18-3 -Key Blocks (Junio 2019)
Geobridge: Implementing Key Blocks Guide
SANS: 3DES and Secure PIN-based Electronic Transaction Processing
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
ISO 20038: Banking and related financial services - Key wrap using AES

Column Header Text Column Header Text Column Header Text

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Performing a review of the media inventories at least annually

Performing a review of the media inventories at least annually

Performing a review of the media inventories at least annually

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Discover More

Advantio_Blog_DNS_Diagram_V1 Image caption goes here. This is HTML text.

I am the Senior Security Consultant in Advantio. I have more than 15 years of experience, working both in South America and Europe. My information security background includes consultancy and audit, training, implementation of security technologies and design and policy development among others.

Certifications: CISSP, CISM, CISA, CRISC, CEH, CHFI, PCI QSA, QSA (P2PE), 3DS Assessor

WHAT OUR EXPERTS HAVE TO SAY