Communications of the ACM
Viewpoint
Where Is the Research on Cryptographic Transition and Agility?
Credit: Andrij Borys Associates, Shutterstock
As quantum computing technology continues to advance, the industry is faced with the challenge of migrating to new, quantum-safe public key cryptography standards. Based on algorithms known collectively as post-quantum cryptography, these standards are actively under development by the U.S. National Institute of Standards and Technology (NIST) in collaboration with the broader cryptography research community.4
This is not the first time a transition to new cryptography has been needed. Algorithmic vulnerabilities, more powerful hardware platforms, more efficient algorithms, amongst other reasons, have motivated prior transitions in cryptographic hash algorithms (MD5 to SHA1, SHA1 to SHA2), symmetric key algorithms (RC4 to DES to AES), and public key algorithms (RSA-1024 to -2048, RSA to ECC). In fact, cryptographic transitions include not only algorithms, but protocols applying those algorithms (SSL/TLS, KMIP, IKE) and the actual implementations (OpenSSL, Bouncy Castle) that are the workhorse for deployed solutions.
If prior cryptography transitions have taught the industry anything, it is that transitions can come on suddenly, take a decade to accomplish, and are far more difficult than the drop-in replacement challenge they look to be. Part of this is the scale at which changes need to occur; a global community of cryptography users must come together to do their part in updating software libraries and applications, various hardware features, industry best practices, and more. Part is also attributable to the complex trickledown effect in standardization whereby top-level algorithmic standards coming from organizations like NIST need to be incorporated into domain-specific standards (TLS, PKI) that then need to be implemented and adopted across a complex web of software and hardware domains before full adoption can occur. In our view, however, there is a glaring gap in the mix: our cryptography does not come with frameworks that prepare us for and facilitate transition. Without them, the manual effort to make a transition becomes an overwhelming challenge, and one that tens of thousands of organizations worldwide, even with security savvy operations teams, struggle to put into practice.
Conventional Notions of Cryptographic Agility
Given a system or application, the ability to make a transition from one cryptographic algorithm or implementation to another is referred to as cryptographic agility. The context of transitions are myriad: hardware devices like a home router or smart thermostat, software applications like a Web browser, systems software such as an operating system or file system, protocols such as TLS or IPSec, and much, much more.
Cryptographic agility is often thought of in terms of software modules. Widely used software libraries such as OpenSSL provide a modular framework for adding new algorithms and changing underlying library calls at compile time. Libraries such as JCE3 may wrap such modularity in sophisticated object hierarchies that make use of generic APIs implemented by underlying classes that instantiate the interface with specific algorithms. Modern libraries calling out cryptographic agility as a feature (for example, AgileSec Platform2) often create an abstracted API offering cryptographic functions and a dynamic linking mechanism mapping them to various certified standards, newer algorithms, and organization-specific plugins.
A second common notion is that of cipher suite negotiation in secure communication protocols such as TLS. For example, RFC 8446 (TLS 1.3) defines an interactive negotiation process between client and server that allows a flexible selection of algorithms (public key algorithms for the key exchange protocol, symmetric key algorithms for secure data transfer, cryptographic hash functions for calculating MACs and performing key derivation). RFC 7696 highlights best practices for creating algorithm identifiers, managing the transition away from weak algorithms, preserving interoperability, and more. Cipher suite negotiation offers a generalized framework which, when used carefully, can accommodate ongoing algorithmic transitions for years to come.
Industry Requirements: What Is Missing?
Our conventional notions of cryptographic agility would seem powerful enough to enable algorithmic transitions in both software and communications protocols. What could be missing? First, we believe there is an important distinction to be made between the providers of cryptography and the many enterprises and organizations that represent consumers across the industry.a The former design and standardize algorithms, and implement them in usable and standards-compliant ways. The latter deploy them in real-world contexts and are charged with maintaining and updating them in a high-stakes world where data privacy and security are not just scrutinized, they are often an absolute requirement (for example, online banking).
The implications are many. While modularized code libraries and cipher suite negotiation provide necessary primitives for low-level agility, they leave the problem of meeting an organization's need for cryptographic migration and ongoing agility as an exercise for the reader. Consider, for example, the gap between these low-level agility primitives and the complexity of modern compute infrastructures. While our conventional notion of cipher suite negotiation speaks to a single point-to-point data connection between endpoints, modern applications are cluster-to-cluster and often include a large number of connections scattered across many distributed endpoints. How should cryptographic migration work at scale—that is, when an enterprise needs endpoints within a highly distributed application to make a coordinated transition to a new algorithm or implementation?
Enterprises of today also make use of more complicated deployment architectures. Configuring cryptography is no longer just about a single application binary or software stack. Modern enterprise applications often run as tiered networked services spanning client devices, private datacenters, and public clouds. Applications themselves can be built from a complex intermingling of microservices and involve third party services, each of which represents a domain that needs the facility for cryptographic migration. Cloud hosting arrangements can also add complexity as system software stacks may be configured and supplied by providers who are distinct from the applications or services running on top. Within all of this layering, aggregation, and multiparty interactions, where are the agility mechanisms and abstractions that allow an enterprise to implement an orchestrated migration in a secure way?
Another oversight in conventional agility notions is the lack of frameworks for policy-driven configuration. Note that while conventional agility frameworks mentioned above offer the mechanism for transition, they do not provide explicit frameworks for secure configuration and ongoing control over this configuration. Because of this, enterprise security administrators lack common frameworks to manage cryptography within a distributed application, service, or infrastructure. Beyond control and orchestrated governance capabilities, such frameworks need to be protected by robust security mechanisms that apply cryptography to prevent adversarial tampering.
Importantly, the proposed post-quantum cryptography algorithms under consideration by NIST will introduce many new performance challenges. Individual algorithms differ considerably from one another and from today's public key standards (for example, RSA, ECC). Many require larger key, cipher-text, and digital signature sizes, a larger memory footprint, more computation, and sometimes additional requirements like failure handling and entropy sampling. Given NIST statements on standardizing more than one option in each algorithmic category (PKEs,KEMs, digital signatures), there is a need to understand how differing performance requirements across algorithm alternatives figure into cryptographic agility schemes for a wide range of usage contexts.
Research Challenges
We have often heard cryptography researchers argue the challenges cited previously are hardly the "stuff" of academic cryptography research, and it is industry that will need to sort out the mundane management challenges of cryptography usage at scale. In contrast, we argue the applied cryptography community is in need of redrawing the boundaries of research in this area given the dramatic evolution and advancements in our computing landscape over the past two decades. Cryptographic agility is more than a thorny detail for industry to sort out—it is a research challenge warranting the full arsenal of academic creativity, analysis, and rigor. Somehow falling in the gap between applied cryptography and systems security research, it needs to be added to the canon of active research domains.
Cryptographic agility is often thought of in terms of software modules.
At the core of this argument is the notion that industry complexities in cryptographic transition are not orthogonal to agility mechanisms. Rather, they imply the need for a larger catalog of architectural building blocks. Consider the need for policy-driven control points. Academic research could be instrumental in identifying where choices in cryptographic configuration are possible and how control points can be introduced and protected using robust cryptographic mechanisms. For example, decisions at design time, compile time, runtime, or policy update time might determine the point at which a PQC algorithm is chosen among multiple alternatives. But what are the criteria, how are decisions implemented, how might automation be approached, and how do you prevent adversarial tampering?
Abstractions borrowing from a long history of research on distributed systems could be used to transform cryptographic agility perspectives from single host and endpoint pairings to clusters, multiparty service architectures, and cloud-based frameworks where platform ownership may involve a third party. How does orchestrated agility work and what are the mechanisms that enable policy-driven control? Once again, such configuration becomes an applied cryptography topic not only in the way agility mechanisms provide robust building blocks enabling provably robust algorithmic change but also in the mechanisms required to protect such building blocks against tampering and adversarial control.
We see the recent introduction of hybrid key exchange in TLS2,5 addressing post-quantum cryptography transition as an example of cryptographic agility mechanisms that extend our conventional notions. By leveraging more than one algorithm in combination, organizations can leverage the protections of new PQC public key algorithms while still retaining FIPS compliance through use of existing standards as NIST slowly makes its way through the standardization process. However, given the complexities described in this Viewpoint, hybrids are hardly a panacea; in fact, they would seem to make industry challenges more complex as the selection of algorithm suites must now be made among a larger pool of alternatives. Appendix B of Stebila et al.5 underscores this by describing design complexities across four axes, including how multiple shared secrets should be combined.
Other areas of much-needed research in cryptography at scale include the formal analysis of security and correctness of agility mechanisms, a deeper understanding of attack surfaces, explorations in performance and optimization, approaches to transition validation and testing in real compute environments, and automated tools to facilitate code transition, policy implementation, and dynamic configuration. Another key area is that of enabling agility in hardware systems which, despite a critical role in making cryptography performant, often lack configurability and support for algorithm migration.
Illustrating Research Gaps
To better illustrate the research gap we identify in this Viewpoint, we ask readers to imagine leading an information security team overseeing PQC migration in a representative multinational company. The company manages enterprise datacenters, edge deployments, and client devices using modern IT frameworks, and makes use of both public and private cloud infrastructure in combination. Many geographic- and sector-specific regulations will soon require quantum safety, but the timeline for migrating to new cryptographic standards, the PQC algorithms to be used, and associated parameter settings vary. For example, hybrid PQC algorithms are likely to be required in region A first, with a somewhat different set of configurations in region B subsequently. Region C (a specific country) requires hybrids using indigenous national standards that are distinct in both algorithmic details and implementation.
Configuring cryptography is no longer just about a single application binary or software stack.
At a high level, your challenge is to ensure customer data within business operations is cryptographically protected wherever it moves and is stored, but also to comply with differing PQ regulations as they apply. A sampling of key problems includes:
- Data protection zones. While TLS offers endpoint-to-endpoint cipher suite configuration, it fails to address the problem of endpoints crossing regulatory domains.
- Integrated provider architectures. Many in-house application services (for example, CRM) are a complex intermingling of company applications and devices, third-party software, and services from cloud service providers.
- Data heterogeneity. Data managed by a distributed company infrastructure may have different origins and provenance, and be subject to divergent regulatory requirements (for example, GDPR)
- Service mesh. Company initiatives have been looking at the benefits of partitioning complex applications into microservices and leveraging infrastructure proxies to manage communications with a mix of internal and external parties.
As you scan the research literature, you observe that discussion of cryptographic agility seems limited to low-level mechanisms. How does ciphersuite negotiation work, not just between two communication endpoints, but between multiple parties in a cloud provider application or as data crisscrosses compliance domain boundaries? Could academic research develop data provenance approaches that bind location and encryption information to data? Could research help to better understand how policy-governed cryptographic protections can be applied to distributed architectures like service mesh, serverless computing, and container-based models? Could research help to develop new protocols that distinguish between data owners, custodians, software vendors, and platform providers? How might auditing work to demonstrate regulatory compliance?
Conclusion
Challenges facing the industry in transitioning to new PQC standards have called into question whether applied cryptography and systems research communities have done enough to understand and enable frameworks for achieving cryptographic agility. A substantial gap exists between the scaled compute infrastructures and applications of today, and the traditional agility primitives we have relied upon in the past; a gap that leaves the industry in a difficult position and inhibits future transition due to the absence of well-understood frameworks. The time has come for the research community to reach deep in updating and adding work in this important area, and in doing so, help the entire industry to prepare for PQC transition and other transitions which lie ahead.
References
1. AgileSec Platform by INFOSEC Global; https://bit.ly/3kbotWe
2. Campagna, M. and Crockett, E. Hybrid Post-Quantum Key Encapsulation Methods (PQ KEM) for Transport Layer Security 1.2 (TLS). IETF Internet Draft. March 2020.
3. Java Cryptography Extension (JCE); https://bit.ly/3lVtClC
4. NIST Post Quantum Cryptography; https://bit.ly/3XGKcmx
5. Stebila, S. et al. Hybrid Key Exchange in TLS 1.3. IETF Internet Draft. October 2020.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2023 ACM, Inc.
No entries found