Triple DES (TDEA) obsolescence and its impact on PCI SSC standards

January 1, 2024 marked a milestone in the history of modern cryptography: The Triple DES algorithm (3DES/TDES or TDEA) was listed as "obsolete" by NIST. This news is part of the migration efforts towards safer algorithms in the race to post-quantum cryptography (PQC), but it will affect multiple environments that made use of this algorithm, mainly in the financial industry. This article analyzes its impact on security and compliance with PCI SSC standards.

Introduction

The use of cryptography is intended to protect a confidential message using an algorithm and a key. However, not all algorithms and not all keys offer the same levels of security. The search for the weaknesses of these elements is known as ‘crypto-analysis’.

In practical terms, the strength of an encryption system is expressed in a value known asworking factor» which can be measured in hours of computational time or the economic cost of resources invested to break encryption. If the working factor is high enough, the encryption system is considered to be "invulnerable". Obviously, this statement is only valid for a particular period of time, since it must take into account the technological evolution, the cheapening of hardware resources and the vulnerabilities of the algorithms that make the "invulnerability" of a cryptosystem today make it vulnerable in the near future. Clear Examples Are Breaking Machine Encryption ENIGMA, , Brute force attacks on Netscape's 40-bit RC4 algorithm, the "DES Breaking Machine» of the EFF, Crack.sh: The World’s Fastest DES Cracker, among others.

That is why, in order to effectively protect the confidentiality and integrity of an organization's information assets, the use of robust algorithms and sufficiently long key lengths is indispensable, in conjunction with a periodic vulnerability assessment to ensure that a tolerable level of security is in place for the organisation based on the criticality levels of the protected data.

History of Triple DES (TDEA)

One of the encryption algorithms of Block Encryption that was most used in the financial field throughout the last century was the algorithm Data Encryption Standard (DES), also known as Data Encryption Algorithm (DEA). DES, in conjunction with Lucifer, were originally developed by Horst Feistel when I worked in the lab Yorktown Heights IBM. Years later, these algorithms were patented by IBM DES was published as standard in 1975.

DES Patent (H. Feistel, 1974)

DES used a 64-bit key length (56 real key bits and 8 parity bits) with 64-bit data blocks, which, after a while, would make it vulnerable to different attacks.

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.

Double DES (K1 ≠ K2)

• Triple-DES (3DES or TDEA) uses three instances of DES in the same clear text, divided into 64-bit blocks each. Triple DES operates in three steps: Encrypt-Decrypt-Encrypt (EDE). It works by taking three 56-bit keys (K1, K2, and K3) known as key bundle and encrypting first with K1, then decrypting with K2 and encrypting one last time with K3 (tripple-length or three-key TDEA). There is a two-key version of Triple DES (double-length or two-key TDEA), in which the same algorithm is run three times but K1 is used for the first and last step.

Double-length TDEA (K1 ≠ K2)

Triple-length TDEA (K1 ≠ K2 ≠ K3)

Given its ease of implementation, Triple DES became the standard de facto for block data encryption. One of the elements that most contributed to the use and massification of this algorithm was the development of hardware security devices (Hardware Security Modules – HSMs), which facilitated key management and encryption/decryption activities in secure environments, mainly in the financial sector.

Vulnerabilities in Triple DES (TDEA)

When using Triple DES with three independent keys you have a key length of 168 bits (three 56-bit DES keys ((64-bit – 8-bit parity) x 3 keys = 168 independent key bits). However, due to the attacksmeet-in-the-middle‘, the effective security provided by 3TDEA is only 112 bits. In addition, the size of the data block used (64 bits) makes it vulnerable to Block Collision Attacks when used to encrypt large amounts of data with the same key, such as an HTTPS session.

The security of a block encryption is usually reduced to the size of the key k: the best attack should be the exhaustive search of the key, with a complexity 2^k. However, the block size n It is also an important security parameter, as it defines the amount of data that can be encrypted with the same key. When the amount of data encrypted with a fixed key approaches this limit, the security guarantees of the mode of operation begin to degrade.

The DES and Triple DES encryptions have a limit of approximately four billion blocks (approximately 32 GB), which makes it easier for remote attackers to obtain data in clear text through a Birthday Attack (birthday attack) against a long-lasting encrypted session, such as an HTTPS/TLS, SSH, or IPSEC session.

In 2016 several researchers managed to exploit this vulnerability associated with block size in the Triple DES and Blowfish algorithms, which affected security solutions that implemented these algorithms, including VPN platforms, HTTPS/TLS, 3G telephony channels (UMTS), SSH, etc.Sweet 32» (catalogued under the CVE-2016-2183) and, as a result of the feasibility check, the National Institute of Standards and Technology (NIST) restricted the use of Triple DES in 2017 to only 2²⁰ 64-bit blocks of data using a single set of keys (key bundle) in the document NIST SP 800-67 Rev. 2 – Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher. This meant that it could no longer be used effectively for TLS, IPsec, SSH or large file encryption. Similar restrictions on the boundaries of produced data blocks had already been published by NIST in previous years:

• 2²⁰ blocks when two of the three keys are the same (2TDEA) in 2012
• 2³² blocks when the three keys are unique (3TDEA) in 2012, and
• 2²⁰ blocks for 3TDEA in 2017.

Due in large part to this vulnerability, and to give it the final boost it needed Advanced Encryption Standard (AES) to become the replacement for Triple DES, in 2018 the NIST established a date for the Triple DES obsolescence: end of 2023.

DES (64-bit blocks) vs. AES (variable blocks from 128 bits) – source: Techtarget

Triple DES Obsolescence (TDEA)

The National Institute of Standards and Technology (NIST) has catalogued encryption algorithms and their key lengths into 6 groups (NIST Special Publication 800-57 Part 1: Recommendation for Key Management -Part 1: General):

• Approved (Approved): The algorithm is specified in the NIST documents or is part of the FIPS-accredited algorithms (Federal Information Processing Standard) and can be used without restrictions.
  
• Acceptable (Acceptable): The algorithm and its key lengths are safe for use and no security risks are known at the time
• Obsolete (Deprecated): The use of the algorithm and key length is allowed but the user must accept some risks.
• Restricted (Restricted): The use of the algorithm or key length is obsolete and there are additional restrictions required for cryptographic data protection processes. Since 2015 this category is no longer used.
• Legacy use (Legacy-use): The algorithm or key length can be used to process previously protected data (decrypt data or verify a digital signature) but there may be risks in this process.
• Not allowed (Disallowed): The algorithm or key length is not accepted due to the associated risks.

NIST Encryption Algorithm Approval Statuses

Recurrently, NIST publishes changes in the categorization of algorithms based on these groups. In March 2019, NIST published the document NIST Special Publication 800-131A Revision 2 – Transitioning the Use of Cryptographic Algorithms and Key Lengths where it announced the category changes of different cryptographic elements (symmetric block encryption, digital signatures, random number generators, hash functions, etc.), including the obsolescence dates for the TDEA algorithm:

Approval status of symmetric algorithms used for encryption and decryption (NIST SP-800-131Ar2)

Use restrictions for double and triple key TDEA are:

Two-key TDEA

• Encryption of data using two-key TDEA not allowed (Disallowed).
• Decryption of data using two-key TDEA is permitted as an inherited use (legacy-use), for example to decrypt in the future backups or stored data protected with that algorithm.

Three-key TDEA

• From 31 December 2023 three-key TDEA is not allowed (Disallowed) for data encryption unless permitted by other NIST guidelines.
• Decryption of data using three-key TDEA is permitted as an inherited use (legacy-use), for example to decrypt in the future backups or stored data that were protected with that algorithm before its withdrawal date.

Implications and Impact of Triple DES Obsolescence (TDEA) on FIPS

Although the scope of operation of the National Institute of Standards and Technology (NIST) is restricted to the United States, the announcement of the obsolescence of TDEA affects many other areas, including the certification of products in the FIPS standard (Federal Information Processing Standards), employed by non-military government agencies and contractors in the United States and Canada.

One of FIPS' flagship standards is FIPS 140, which defines security requirements for cryptographic hardware and software components that must be used by federal government departments and agencies in the United States and Canada, cataloging products at four levels of security, from the lowest (1) to the highest (4). A list of products validated in this standard under the program is maintained on the NIST website Cryptographic Module Validation Program (CMVP).

The FIPS 140-2 and FIPS 140-3 standards are currently active and the following dates for the withdrawal of FIPS 140-2 have been defined:

Status of FIPS 140-2 and FIPS 140-3

These dates are important, as FIPS 140-2 and FIPS 140-3 include a list of supported algorithms. As of 31 December 2023, FIPS 140-3 assessments will no longer be able to include TDEA, while FIPS 140-2 validated devices using TDEA will only be able to use it for decryption. Likewise, from September 2026 all modules certified in FIPS 140-2 will be classified as "historic", only used under special restrictions.

In essence, if cryptography is required, it should be validated periodically. The NIST considers that unvalidated cryptography does not provide protection for information or data or, in other words, data would be considered unprotected plain text. If an agency specifies that its information must be cryptographically protected, FIPS 140-2 or FIPS 140-3 standards must apply. If the cryptographic module used is revoked, the security provided by that module will be considered irrelevant.

Implications and Impact of Triple DES Obsolescence (TDEA) on PCI SSC Standards

As indicated above, the scope of the NIST considerations and its FIPS standards is restricted to the United States and Canada. However, the PCI SSC (Payment Card Industry Security Standards Council) has traditionally used references to NIST publications as guidelines for implementing its security controls, including cryptography.

In fact, the concept of robust cryptography (strong cryptography) used in all PCI SSC standards (including PCI DSS) makes explicit reference to the document NIST Special Publication 800-57 Part 1:

Meaning of "strong cryptography" according to PCI SSC

However, this same standard (NIST 800-57) indicates that TDEA is an outdated algorithm as of 1 January 2024:

Obsolescence of TDEA in NIST Special Publication 800-57 Part 1 (p. 54)

On the other hand, the PCI SSC also uses FIPS 140-2 and FIPS 140-3 as a validation element to use security cryptographic hardware (Hardware Security Module – HSM) in their environments:

PCI PIN:

FIPS 140-2/FIPS 140-3 in PCI PIN v3.1

PCI P2PE:

FIPS 140-2/FIPS 140-3 in P2PE v3.1

PCI 3DS:

FIPS 140-2 in PCI 3DS v1.0

PCI TSP:

FIPS 140-2 in PCI TSP v1.0

Given this, if an entity uses an HSM device validated in FIPS 140 the following restrictions should apply:

• If the device is FIPS 140-2, TDEA should only be used for decryption.
• If the device is FIPS 140-3, the use of TDEA is obsolete. In fact, it could not be used by not being within the list of approved algorithms.

However, the PCI SSC has been flexible (to this day) with the use of TDEA, allowing its implementation in the protection of sensitive data in payment transactions as long as the following restrictions apply, as described in the articlePCI SSC Cryptography Expert on Triple DEA» from his blog:

• Disable the KeepAlive session configuration parameter and force new session keys long before the 32GB data threshold is transmitted. Note: Although this alternative mitigates the "Sweet32" vulnerability, it does not reinforce the underlying cryptographic algorithm or fix other protocol issues.
• Encrypt data at the application layer using more powerful encryption-for example, AES 256-rather than relying on TDEA for data protection.
• Change TDEA keys regularly (e.g. every 256 transactions or daily, whichever is more frequent).

Similarly, the same article states:

In addition, the concept of ‘robust cryptography’ in PCI DSS and other PCI standards is based on acceptance by authorised bodies, including NIST. Once TDEA is fully disallowed by these authorities, it will no longer be considered "strong cryptography" by the PCI SSC.

While legacy exceptions for PIN hardware deployments are likely to be phased out over a longer period of time, organizations should consider transition planning for all other TDEA implementations.

In addition, the PCI SSC published the FAQ #1570 (Does TDEA meet the requirements of “strong cryptography” as defined in PCI DSS?) indicating the following:

In late 2023, NIST bans the use of three-key TDEAs to protect security-sensitive data in U.S. federal information systems. However, according to NIST SP800-57 part 1, TDEA using three keys can still provide an effective 112-bit force when applied using appropriate key management and modes of operation.

The definition of ‘robust cryptography’ was updated in PCI DSS v4.0 to refer to the effective key size of the algorithm/key combination rather than to specific algorithms; Specifically, the effective force of the key is a minimum of 112 bits, with the recommendation to use systems that provide an effective force of 128 bits. In addition, "strong cryptography" requires the use of industry-proven and accepted algorithms and proper key management practices.

In conclusion, confirmation of the obsolescence of TDEA by the PCI SSC is inevitable, although no formal dates have yet been set.

QSA Advisor Recommendations

David Acosta (qualified advisor for PCI DSS, PCI PIN, PCI 3DS, P2PE and PCI TSP), author of this article, recommends in a personal capacity to all entities using TDEA or FIPS-validated HSM devices in their compliance environments that implement the following proactive actions BEFORE the PCI SSC sets mandatory dates for TDEA withdrawal:

For PCI PIN/P2PE:

• In PIN processing environments subject to PCI PIN standard compliance, start ASAP with PCI PIN support. ISO 4 format for PIN block (ISO 4 PIN block format) in order to use the AES algorithm for PIN encryption. In fact, the PCI SSC published a few years ago a Information Supplement It describes all the activities to be taken into account before, during and after this process: Information Supplement: Implementing ISO Format 4 PIN Blocks.
• If used Derived Unique Key Per Transaction (DUKPT) based on ANSI X9.24 part 1, the risk of exposure of data protected by a TDEA key is minimised due to the use of unique keys per transaction. For this reason DUKPT allows the use of double and triple key TDEA. However, it is highly recommended to start using AES as an algorithm in DUKPT (AES DUKPT) and proceed with the replacement of the derivation base keys (Derivation Key Base – BDK).
• Migration from TDEA to AES also affects the format of key blocks (key blocks). In this case, instead of using ANSI X9.143 (TR-31) that applies to TDEA, you should employ an integrity verification process that is implicitly part of the key encryption process, as specified in ANSI X9.102 ‘Symmetric Key Cryptography for the Financial Services Industry – Wrapping of Keys and Associated Data‘.
• It is also important to remember that PCI PIN prohibits the use of TDEA Fixed Keys for PIN encryption on point-of-interaction devices (Point-of-Interaction) and communications host-to-host since January 2023.

For PCI DSS:

• If TDEA is used as part of the TLS Encryption Sets, it is recommended to replace them with AES to avoid inconvenience during internal scans and ASV scans (see FAQ #1452: How does Triple DEA (TDEA) impact ASV Scan results?). The same recommendation applies to other protocols such as IPSEC or SSH.
• Confirm with the different manufacturers of hardware and software solutions that include cryptographic routines if they support AES. If so, implement the migration from TDEA to AES and update the secure configuration guides (req. 2.2.1 of PCI DSS v4.0).
• Even though the PCI DSS requirement 12.3.3 v4.0 enters into force as of 31 March 2025, it is recommended to implement it as soon as possible to identify assets using TDEA and establish a proactive action plan for their migration:

Requirement 12.3.3 of PCI DSS v4.

In general:

• If HSM devices are used, it is highly recommended to check if the device is validated under PCI HSM other than under FIPS 140. If this is the case, configure the device to operate in PCI HSM mode (or PCI mode) instead of FIPS, since under that mode it will be aligned with the PCI SSC's own restrictions regarding the use of TDEA.
• As a general rule, use AES (at least 128 bits, 256 bits recommended) instead of TDEA for any software deployment that is deployed in production, whether for data protection in transit or in storage.

As can be concluded, the implementation of the above recommendations will allow the entity to advance the migration work of TDEA before a deadline is defined by the PCI SSC, which will surely be in the short term. All this in order to minimize the impact of this migration on the operation and integration with other technological systems and / or service providers.

Do you have questions about migrating from TDEA to AES? Leave your concerns in the feedback form.