Cryptographic change is a reality. Since 2006, we have seen the sunset of WEP, SSLv2, RSA-1024, SSLv3 and early TLS. We know that Triple DES and other 64-bit blocked ciphers are on the way out. RSA will likely follow, and our current pre-quantum public key cryptosystems will eventually become deprecated. These changes have impact and require widespread coordination. Old software and hardware will need to be upgraded or replaced. It will require time, effort, money, and pro-active management. Simply reacting will be risky, painful, and expensive. Industry needs to learn from past changes so that organizations can be ready. Most importantly, we need to do better than we have done in the past. But how?
Crypto-agility is simply the ability to switch cryptographic technologies quickly and effectively. It requires knowing where you use specific algorithms, protocols, what depends on them, where your keys and cryptograms are stored. The rationale for being crypto-agile should be a no-brainer even if quantum cryptanalysis never becomes practical.
Before we can improve, we need to know how we’ve performed. Looking back:
- WEP was proposed as part of 802.11 in 1997 and deprecated in that standard in 2004. Despite this, the protocol continued to be supported and many deployed devices were left without upgrade paths for years. PCI began discouraging WEP in 2006 and eventually sunset it’s use in payments between 2009 and 2010. The approach taken essentially used a light-touch and was sensitive to the large investments in new technologies. However, this was insufficient to prevent one of the largest credit card breaches in history (TJX in 2007).
- SSLv2 was the first version of SSL deployed (SSLv1 was recognized as insecure before launch) in 1995. The discovery of vulnerabilities led to SSLv3 in 1998. SSLv2 was deprecated by PCI beginning in 2006 and followed by the Internet Engineering Task Force (IETF) in 2011. The approach taken was firmer. SSLv2 would cause PCI ASV scans to fail which were expected to impact PCI DSS assessments. Despite the built-in agility of SSL implementations, many organizations pushed back on the sunset over concerns of alienating customers with out of date software and systems.
- RSA-1024 certificates were deprecated by NIST (from 2010) and sunset by the Certificate and Browser Authority (CAB) by 2014. The CAB’s sunset decision dates to 2008 and CAs started issuing 2048-bit certificates in 2010. This change failed to account for many use-cases including embedded systems/IoT and was challenged by the existence of many certificates with long lifespans. Many CA’s and organizations scrambled to complete this migration in the last 18 months of the sunset. The IoT/embedded system use cases were also unfortunately not easily updated and a number of payment terminal systems with long lived certificates failed after the sunset date.
- SSLv3 and early TLS were hit with a number of serious vulnerabilities culminating in the POODLE attack in 2014. The attack was the culmination of a succession of security research going back to 2002 and it totally destroyed the general usability of SSLv3. PCI began an aggressive program to sunset SSL and early TLS. The program required risk management and set sunset dates. Exemptions were baked in for special cases that were not vulnerable (POI devices with burst transmissions). All of this was measured in annual PCI assessment reports. And for the first time failure to plan for sunset would result in compliance failures. Despite an unanticipated extension due to lack of widespread support for newer TLS versions, the sunset was completed in 2018 (less than4 years after POODLE). By contrast, browser vendors, only removed support from new releases in 2020.
Looking back there are some important lessons:
- The success of SSL/TLS protocol cipher suites provides a good example of crypto-agility. They allow new ciphers to be introduced and preferred while old ciphers can be deemphasized and sunset. We need this kind of capability more generally for all of our cryptography.
- Legacy hardware, software, and constraints can be significant impediments to crypto-agility.
- Soft-touches are ineffective in achieving sunsets.
- Actively measuring current capabilities and managing known risks can provide an effective approach that focuses organizations, encourages feedback, and pressures vendors and service providers. The PCI requirement to measure SSL transition plans in the wake of POODLE provides a good example.
Looking ahead:
- Triple DES has some key strength issues and is subject to the SWEET32 attack which means it is no longer safe in general use-cases.
- Other 64-bit-block ciphers are also subject to SWEET32 and are unsafe in general use-cases. We expect that these should also be subject to a hybrid sunset.
- Triple DES has been flagged by NIST for deprecation in 2023 and PCI has been flagging it in ASV scans since 2017. The financial industry has a number of special purpose use-cases that will likely remain safe beyond 2023. This suggests a hybrid sunset, similar to that used with SSL and early TLS.
- Some standards have allowances for legacy implementations in order to facilitate transition to newer technology. For example, PCI PIN (but not P2PE) allows AES-128 keys to be transmitted using RSA-2048 in certain specific circumstances.
- RSA is likely to be sunset regardless of quantum computing, simply because strengthening RSA keys creates dramatically larger keys.
- Hashing is also due for change for a variety of reasons including: improvements in hashing algorithms, legacy hashing deployments, and unsuitable hashing use-cases.
- Quantum cryptanalysis has a huge potential impact on public key systems like RSA and ECC.
Cryptographic-agility will be driven by advances in cryptanalysis, improvements in software and hardware, and whatever happens with quantum computing. (We will discuss quantum cryptography in a future article).
Crypto-agility should be part of your risk management program. Fortunately, industry and standards bodies are looking into what crypto should look like in the future. They are driving the availability of standardized algorithms and protocols. Timing change is also challenging as the risk must be measured, not from the point in time of the break of a system, but from the availability of historical cryptograms after the break. Organizations only need to focus on how they use cryptography. General purpose standards and auditing processes measure what’s in-place. Crypto-agility is a measure of capability and is more forward looking. Fitting this into frameworks like PCI DSS, SOX, or a SoC audit needs a way of measuring how the capability is in-place. Cryptographic-Agility programs would need to have processes to collect and maintain inventories with details about encryption technologies and assets. Assessing completeness and accuracy could be challenging. However, we have seen how cryptographic changes can be improved with the right tools and incentives.
Learn More
Other References
- PCI DSS began discouraging WEP in v1.1 (2006) and sunset it beginning v1.2 (2008) with dates in 2009 and 2010 (archived copies of PCI standards)
- The PCI ASV program began failing SSLv2 in 2006 (archived Technical and Operational Requirements for Approved Scanning Vendors (ASVs) Version 1.1)
David Gamey : Jul 19, 2017 10:07:00 PM
Robert Spivak : Apr 15, 2015 10:07:00 PM
David Gamey