3 min read

Why Key Management Systems Must Understand ANSI X9.24/TR-31 Key Blocks

Why Key Management Systems Must Understand ANSI X9.24/TR-31 Key Blocks

The PCI Council requires most actors of payment networks to implement ANSI X9.24/TR-31-compliant key blocks to wrap and securely transmit, transfer, or translate key or PIN codes.

TR-31 is a technical report, not a norm, and so, it provides guidelines for building key blocks. Together with the ANSI X9.24 standard, TR-31 becomes a norm. This article explores the importance of TR-31 key blocks.


The Motivation behind ANSI X9.24/TR-31 Key Blocks

Key blocks are extremely important and help protect payment security. They prevent the misuse of cryptographic keys, protect the keys from malevolent hackers who could exploit weaknesses and substitute other keys, and perform similar attacks against payment systems. 3DES key bundles are one possible use of key blocks. They prevent the re-arrangement of 3DES keys that could allow an attacker to crack a 3DES cipher by attacking two separate individual DES ciphers.


Key Blocks as Described by the ANSI X9.24-1-2017

The ANSI standard defines “general” key blocks as structures that provide a key with a header field containing non-sensitive data and a payload field containing encrypted sensitive data (including the key itself). The integrity of the header, plus the payload must be checked by adding an extra field. It must not be possible to change anything in the header or payload without modifying the integrity check data. 


The header field containing the non-sensitive key attributes has a significant amount of leeway in its design. The encrypted payload's sensitive key attributes may include information such as the ciphering mode, cleartext key length, and so on.

The integrity mechanism can be a MAC (Message Authentication Code), a signature using RSA, or an integrity mechanism derived from a key wrap, for example.

A crucial restriction is that the “Electronic Code Book (ECB) mode SHALL NOT be used to encrypt this [a given] field if the field is longer than one block.” This is because of the AES-ECB known ciphertext/plaintext attack and frequency analysis in such cases that allow a possible deciphering of one block. 

According to the standard, acceptable cipher modes are:

  • Cipher Block Chaining (CBC)
  • Counter with CBC-MAC (CCM)
  • Counter with CBC-MAC (CCM)
  • AES Key Wrap

While there are numerous mechanisms for performing integrity checks, the encryption of sensitive information, including the key, must be performed only by 3DES or AES.


Key Management Systems Must Understand ANSI X9.24/TR-31 Key Blocks

The ANSI TR-31 key block format is a widely accepted format used to securely exchange keys between many devices using cryptography, especially in the context of financial transactions in the payment networks. A good key management system must obviously be able to understand that format.

Download white paperIf an organization is using a cloud-based application for its operation, the key management of cloud providers (AWS KMS, Azure Key Vault, etc.) is often unable to deal with TR-31 formats.

We recall that PCI-PTS requires financial networks and in general, all parties involved in retail financial transactions using cards from a card association brand (Visa, MasterCard, etc.) to incumbently use key blocks that are X9.24-1/TR-31 compliant before the given deadlines in 2021 and 2023, depending on the role and nature of the business.

This underlines once more the tremendous importance for banks and financial organizations in general, to use a cryptographic key management system that has established support for the TR-31 format


Read White Paper

References, Side Notes and Further Reading

Norms used by X9.24-1-2017 

  • NIST SP800-67, Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher
  • ANS X9.82, Random Number Generation, Part 3: Deterministic Random Bit Generators
  • ISO 13491 - 2016 - all parts, Financial services – Secure cryptographic devices (Retail)
  • ANS X9.24-2, Retail Financial Services Symmetric Key Management Part 2: Using Asymmetric Techniques for the Distribution of Symmetric Keys
  • FIPS 197: Advanced Encryption Standard (AES), November 26, 2001
  • NIST SP 800-38A: Recommendation for Block Cipher Modes of Operation: Methods and Techniques (December 2001)
  • NIST SP 800-38C: Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality (July 2007)
  • NIST SP 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC (November 2007)
  • ANS X9.24-3, Retail Financial Services Symmetric Key Management Part 3: Derived Unique Key Per Transaction (Ballot Note: This is to be published in 2017)
  • ANS X9.8-1, Personal Identification Number (PIN) Management and Security
  • ISO 16609, Banking – Requirements for message authentication using symmetric techniques
  • ISO 7812, Identification cards – Numbering system and registration procedure for issuer identifiers
  • ISO 8583, Bankcard Originated Messages – Interchange message specifications – Content for financial transactions
  • ISO 9797-1, Information technology – Security techniques – Message Authentication Codes (MACs) – Part 1: Mechanisms using a block cipher
  • ISO/TR 14742, Recommendations on cryptographic algorithms and their use
  • NIST SP 800-38B: Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication (October 2016)
  • ANS X9.102-2008, Symmetric Key Cryptography For the Financial Services Industry - Wrapping of Keys and Associated Data
  • ANS X9.119, Retail Financial Services - Requirements for Protection of Sensitive Payment Card Data Part 1: Using Encryption Methods
  • ISO 11568-2, Financial Services – Key management (retail) – Part 2, Symmetric ciphers, their key management and life cycle
  • NIST SP 800-57: Recommendation for Key Management – Part 1: General
  • ANS TR-31, Interoperable Secure Key Exchange Key Block Specification for Symmetric Algorithms