Cryptographic agility, also called cryptoagility, is the ability for a system to quickly and easily change parts of their encryption mechanism(s).  This encompasses changing encryption keys, key lengths, encryption algorithms used, and even changing the libraries used to perform the encryption.  

Zero Trust architectures feature encryption of data in transit and data at rest heavily, and systems with high Zero Trust maturity feature lots of automation, so it makes sense that cryptoagility would be part of a mature architecture.  The CMS Zero Trust Team will put out a couple articles on cryptoagility over the next few months.

Why this?

There are many reasons to strive for cryptoagility.  As computers can do more calculations in less time, we need to occasionally change encryption algorithms or key lengths to take longer to brute force the keys.  Beyond that, there are internal factors such as to make it easier to recover from incidents and external ones such as from requirements for FISMA systems.  It is a design principle that has been around for a while even if we haven’t been using that phrase.  Systems have long needed the ability to change encryption keys and update the algorithms used, and good architectures facilitate these actions happening efficiently. Encryption keys can get compromised, key lengths can need to be increased, and bugs can be found in encryption libraries.

One of the most famous bugs in an encryption library surfaced in the widely used OpenSSL library in 2014 and was called “Heartbleed” because the heartbeat function in TLS could be exploited to leak information from memory.  An update for OpenSSL was released quickly, but it required many websites to either recompile the programs that used OpenSSL or restart their servers. Additionally, there was a possibility that private keys for SSL certificates were leaked so certificates also had to be regenerated with new key pairs.  A month after the announcement, over 50% of impacted systems had not issued new SSL certificates.

NOTE: There can be tension around remediating a vulnerability in a product that has undergone a process like FIPS 140 validation.  How do we do this quickly while preserving the previous "approval"?  Hopefully cryptoagiity can help us with this in time.

Why now?

Over the last couple of years there have been Federal directives and CISA guidance that touch on cryptoagility, so it makes sense to explain cryptographic agility and what it involves.  

Cryptoagility supports OMB M-23-02 “Migrating to Post-Quantum Cryptography”.  Quantum computing may reach a stage where it can easily brute force some key lengths of modern cryptographic algorithms, so systems need the ability to change those algorithms easily. The agility needed to respond to possible quantum computing attacks on current cryptography will revolve around knowing where encryption that is not quantum-proof is located and then replacing it.  Though an actual quantum computing attack is likely in the distant future, agencies can begin identifying the use weaker algorithms, key lengths, or libraries now to allow themselves to make the changes in at a leisurely pace instead of in an emergency. 

The release of the CISA Zero Trust Maturity Model v2 added references to “cryptographic agility” to the Advanced and Optimal levels of the Traffic Encryption and Data Encryption functions.  CMS included these updates in the AWS for CMS Cloud and Microsoft Azure for Government for CMS Cloud maturity frameworks (Sorry, these are CMS internal references). 

Lastly, maintaining records of where different algorithms and implementations are used is a key part of software supply chain management, introduced to Federal Agencies in OMB M-22-18. This way when another Heartbleed is found we can more easily identify where we need to patch.

Check back next month for a second installment on cryptoagility!