PCI SSC Cryptography Expert on Triple DEA

This article is intended to provide awareness and guidance on the use of Triple DEA (also known as TDEA, TDES, or 3DES).

TDEA is widely used in the payment ecosystem as a method for protecting account data during transmission and storage. In July 2017, the National Institute of Standards and Technology (NIST) proposed that the TDEA protocol be deprecated. Upon deprecation, NIST would no longer consider TDEA to be a strong ciphersuite. This article discusses potential impacts and considerations related to this development. Further information on the NIST terms “deprecate” and “disallow” is also provided at the end of the article.

Background

NIST withdrew support for two-key TDEA in 2015, and subsequent academic papers have demonstrated that two-key TDEA provides less than 80 bits of effective key strength[i] even when keys are frequently changed.[ii]   As the PCI SSC definition of strong cryptography includes a minimum of 112-bits of effective key strength, two-key TDEA is no longer considered strong cryptography.[iii] Three-key TDEA, however, was still thought to provide about 112-bits of effective key strength.  This has now changed due to more recent research and the discovery of “Sweet32”,[iv] which is an exploit of a known vulnerability in cipher suites that use 64-bit block length ciphers (for example, TDEA and blowfish) in CBC mode.[v]  This attack impacts TDEA used in protocols like TLS, IPSec, and SSH, and has resulted in NIST proposing the deprecation of TDEA in all forms.[vi] 

Considerations for use of TDEA

TDEA ciphersuites are commonly used by older operating systems (for example, Windows XP) and older protocols (for example, SSL and early TLS).  Additionally, up-to-date operating systems and modern protocols could be using fallback or legacy configurations to support older applications. TDEA therefore has the potential to exist, either actively or passively, in many types of environments. For more information on TLS transitions, refer to PCI DSS v3.2 Appendix A2: Additional PCI DSS Requirements for Entities using SSL/early TLS.  There are also a number of PCI SSC guidance documents, blog articles, and FAQs to assist with these transitions.

Because the “Sweet32” exploit is ranked by the Common Vulnerability Scoring System (CVSS) as a medium risk, the presence of TDEA will typically be reported as a “fail” during ASV scans. Entities that have implemented compensating or mitigating factors to reduce the risk of the exploit may follow processes defined in the ASV Program Guide to document how the risk has been reduced and the subsequent impact on scan results. 

Additionally, the concept of “strong cryptography” in PCI DSS and other PCI standards is based on acceptance by authoritative bodies including NIST.  Once TDEA is fully disallowed by such authorities, it will no longer be considered “strong cryptography” by PCI SSC.

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

Recommendations for reducing the risk

The recommended approach is to disallow use of TDEA ciphersuites and transition to AES, or a regional equivalent with a block size of at least 128 bits and a key length of at least 128 bits (for example, Camellia or SEED). Interim measures should be taken to reduce the risk posed by TDEA until transition can be completed. Some short-term measures that may reduce the risk to existing TDEA implementations include:

• Disabling the session configuration parameter KeepAlive and forcing new session keys well before the threshold of 32 GB of data is transmitted. Note: While this alternative mitigates the “Sweet32” vulnerability, it does not strengthen the underlying cryptographic algorithm or fix other issues with the protocol. 
• Encrypting data at the application layer using a stronger ciphersuite–for example, AES 256–rather than relying on TDEA for data protection.
• Changing TDEA keys regularly (e.g., every 256 transactions or daily, whichever is more frequent).

These recommendations reflect protocol considerations where key exchanges or key negotiation occurs—for example, TLS, SSH, and IPSec.  However, the use of TDEA for storage of data is also not without risk.  Entities should consider the value of the data they are protecting, the duration of protection (as longer protection periods may require stronger algorithms and longer key sizes), and any mitigating controls in place.

What’s next with TDEA? 

As with all cryptographic algorithms, the lifespan of TDEA is impacted by the evolution of technologies, vulnerabilities, and threats. Entities using TDEA should be aware of how and where it is implemented in their environment so they can identify the applicable risk and determine mitigation and transition options as appropriate. Where the presence of TDEA impacts a payment environment, the entity should be able to demonstrate how they have mitigated the known risks in their TDEA implementation.

While PCI SSC continues to monitor the status of 3-key TDEA as “strong cryptography,” all entities using TDEA should also be actively monitoring their use of the protocol and the impact of evolving threats to the security of their environment. Entities are also encouraged to contact their acquirer or payment card brand directly for any requirements they may have related to their specific use of TDEA and whether it requires mitigation or remediation.

Understanding NIST terminology

The terms “deprecate” and “disallow” are defined by NIST as follows:[vii]

Deprecated means that the use of the algorithm and key length is allowed [by NIST], but the user must accept some risk. The term is used when discussing the key lengths or algorithms that may be used to apply cryptographic protection to data (e.g., encrypting or generating a digital signature). Deprecation is typically the first step to an eventual status of “disallowed.”

Disallowed means that the algorithm or key length is no longer allowed [by NIST] for the indicated use.

[i] Effective Key Strength is measured in bits and represents the effort required for solving for the actual key given the best available cryptanalysis and computation facilities.  Effective key strength is not the actual key length.  Rather it serves as a measure of the upper bound of the security provided by the key.  Since attacks and technology only improve over time, this value will likely decrease as the algorithm ages.  The highest this value can ever be is the actual key length in bits (which, for 2-key TDEA would be 112); however, that assumes that the best attack is key-space exhaustion, i.e., trying every possible key).  For TDEA, much more efficient attacks exist.  Additionally, for block ciphers like TDEA, plaintext recovery attacks exist that do not require solving for the underlying key (e.g., the birthday attack).  Such attacks further weaken the algorithm since the block size (in this case 64-bits) becomes an additional limiting factor

[ii] Mitchell, Chris J. On the security of 2-key triple DES, 02/19/2016 https://arxiv.org/abs/1602.06229v2

[iii] https://www.pcisecuritystandards.org/pci_security/glossary

[iv] CVE-2016-2183

[v] For an in-depth explanation, see https://sweet32.info/

[vi] https://beta.csrc.nist.gov/News/2017/Update-to-Current-Use-and-Deprecation-of-TDEA

[vii] NIST Special Publication 800-131A Revision 1, Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths