Published: 4/17/2024
Three elements of cryptographic agility
Cryptographic agility is achieved through modern crypto, accurate inventories, and engineering in the ability to make encryption changes quickly and efficiently
What is cryptographic agility?
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.
There is not currently an official cryptoagility standard for Federal Agencies, but research into it and resources from the Cybersecurity and Infrastructure Security Agency (CISA) led the ISPG Zero Trust team to identify three elements of a Cryptographically Agile system:
- Use modern cryptography.
- Maintain an accurate cryptographic inventory.
- Engineer in the ability to make encryption changes quickly and efficiently.
This document sets out further definitions of cryptographic agility for CMS Federal Information Security Modernization Act (FISMA) Systems to strive for.
Use modern cryptography
FISMA Systems should use modern cryptographic algorithms, robust key lengths, and well-tested implementations of said algorithms. The National Institute of Standards and Technology (NIST) has written much on the topic, but a good rule of thumb is to stick with implementations that are FIPS 140-2 validated (see note below). Tools that are FedRAMP approved will be FIPS 140-2 validated.
NIST Special Publication 800-57 Part 3 has detailed information about preferred cryptographic algorithms and key lengths. They can be summarized as:
| Key Type | Algorithms and Minimum Key Sizes | |
| Public Key Infrastructure (PKI). | Digital Signature keys used for authentication (for Users or Devices) | RSA (2048 bits). ECDSA (Curve P-256) |
| Digital Signature keys used for non-repudiation (for Users or Devices) | RSA (2048 bits) ECDSA (Curves P-256 or P-384) | |
| Key Establishment keys (for Users or Devices) | RSA (2048 bits) Diffie-Hellman (2048 bits) ECDH (Curves P-256 or P-384) | |
| Encryption for Data at Rest | Symmetric key | AES (128 bits) |
| Hashing and Message Digests | One-Way Hash, unkeyed | SHA-256 |
Websites and other internet services that operate over TCP/IP shall use Transport Layer Security (TLS) version 1.3 to encrypt the network traffic. TLS 1.3 is based on PKI, and the above algorithms and key lengths are also recommended. If a system has devices that cannot use TLS 1.3, the connection may fall back to TLS 1.2. TLS 1.0 and 1.1 shall not be used as per the HHS Policy for Encryption of Computing Devices and Information in Section 6.23.
In the event that your software needs to directly perform cryptographic operations, here at CMS we prefer that you do not implement your own cryptographic algorithms and instead use a well-established library that is FIPS 140-2 approved such as OpenSSL. Wikipedia has a chart comparing different cryptography libraries and includes their FIPS 140 status.
A Note on FIPS 140: A new version of FIPS 140 has been released, version 3, and systems will be required to use only FIPS 140-3 compliant tools starting in September 2026. As of December 2023, there are few validated FIPS 14-3 implementations, but many popular services and hardware are undergoing evaluations. If selecting a new product, it would be wise to choose one that is undergoing evaluation.
Maintain an accurate cryptographic inventory
To know what to fix, we need to know what we cryptographic algorithms we are using in our various systems. This will include data in transit, data at rest, and (as the technology becomes more accessible) data in use.
While having an accurate inventory is important, it is not expected that CMS FISMA Systems will have a unified, automated solution that contains all the different encryptions just yet. Teams may need to look in different places to collect all this information. The Zero Trust program in ISPG is researching an automated solution that would be suitable for CMS.
The inventory will need to include where the encryption is being used (in transit, at rest, or in use), what algorithm is used, what key length is used, and (where available) what library or tool is providing the encryption. It is also desirable to be able to explain why a particular setup is used or note any exceptions.
Infrastructure as a Service (IaaS) providers often have a key management service for storing keys used for encrypting data at rest, and they often have a service for storing TLS certificates, but they are likely not the same service. For example, AWS provides the Key Management System for general key management, and the AWS Certificate Manager is available for your TLS certificates.
The Office of Management and Budget (OMB) requires agencies to report on their cryptographic inventories under M-23-02, though they are slowly rolling out which systems are included in their reports. The Zero Trust Program will reach out to the ISSOs of FISMA systems required to submit for 2024.
Engineer in the ability to make encryption changes quickly and efficiently
Agility in general is the “the power of moving quickly and easily.”, so cryptoagility is the ability to move quickly and easily around all things encryption.
The Key Management Handbook from ISPG recommends that systems rotate encryption keys once per year (see the “Key Rotation” section). Teams should have a documented process, whether the process is manual or automated. This includes both TLS certificates and database (or other storage) encryption keys.
Ideally, a team should be able to rotate keys and certificates in minutes not hours so that if a key compromise happens response time is low.
When using libraries to implement encryption functions in software, the software should be architected in a way to allow for the library to be updated without having to change the code (assuming that the new version of the library is backwards compatible). Where possible, key length should not be hard coded, and instead provided via a configuration file. Use of specific algorithms should be abstracted in such a way that if the team wanted to use a different algorithm or different library for the same algorithm the code can be changed in one place and used everywhere.
In “CryptoAgility in the Zeitgeist”, we talked about the 2014 Heartbleed exploit for OpenSSL. While a patch was available quickly for OpenSSL, it took months for most systems to be updated. As we seek to balance security and process, we need to contemplate the speed at which we want to mitigate and remediate such exploits.
When designing software and development processes, consider these guidelines for how long it should take for a system to make these changes:
- Minutes to update and rotate a key
- Minutes to update a library to a new version
- Hours to change key lengths
- Less than 1 sprint to change the algorithm or library
Conclusion
CryptoAgility is an integral part not just of Zero Trust, but a mature software development process. By factoring the three main elements of CryptoAgility into processes early, we can improve our ability to respond to cryptographic issues early. It may take time to add CryptoAgility into existing systems, but the Zero Trust team is here to support teams. We will be releasing specific guidance on implementation for different environments, such as AWS, via the internal CMS Cloud documentation in the coming months.
In the meantime, think about how the three elements apply to your systems:
- Use modern cryptography.
- Maintain an accurate cryptographic inventory.
- Engineer in the ability to make encryption changes quickly and efficiently.
About the publisher:
The Zero Trust Team works to help CMS implement the Executive Order that requires continuous verification of system users to promote stronger security. We introduce new tools and streamline processes to support the transition to Zero Trust throughout the enterprise.
