In our recent blog,The Countdown Has Begun: Getting Started on your PQC Journey,we discussed both Q-Day, the moment when quantum computers will be able break all decryption, and the risk of Harvest Now, Decrypt Later (HNDL) cyberattacks. We focused on addressing top priority post-quantum cryptography (PQC) capabilities, namely, how to begin the migration to quantum-safe hardware. This blog, the third in a series on post-quantum computing, takes on the important issue of U.S. government regulation and its impact on PQC product availability.
Before digging into the effects of government regulation on PQC products, it's worth taking a moment to look at the various ways the U.S. government currently certifies encryption methods for products that handle government information. There are three types of certifications:
Why do these certifications matter? They're important because a product must have certifications to be eligible for sale in certain markets. For instance, if you sell products that are part of critical infrastructure, you need to be certified under CC. If you sell products that protect NSS classified data, you need CSfC certification. Certifications are valuable to everyone else as they provide evidence that the cryptography used in the product has been tested to be secure and accurate. If your company is designing new products, you have to anticipate changes in encryption certifications, which occur regularly.
Makers of technology products are facing regulatory challenges regarding PQC. The current CC and CSFC certifications do not allow for PQC encryption algorithms. The NSA's CNSA 1.0, the current approved standard for encryption used in NSS, does not support PQC. This means products that meet the encryption standards mandated by the new CNSA 2.0 standard (which does support PQC) are not yet eligible for sale to the government. This challenge is not unexpected as the regulated entities also had to wait for the NIST PQC algorithm standards to be finalized and approved before they could complete certification requirement updates. This is an interesting situation.
Vendors and customers are both anxious to obtain and deploy quantum-safe solutions. However, they cannot be used in certain U.S. government applications until the certification requirements are updated to allow CNSA 2.0 capabilities. Unfortunately, these parallel development activities do present an element of risk to the product development teams. To ensure product teams develop products that meet the new requirements, regulated entities need to provide frequent and transparent information on their intent for the new requirements.
We expect the certification requirements to be updated to allow CNSA 2.0 by late CY 2025. Vendors can minimize certification timing issues by implementing both CNSA 1.0 and CNSA 2.0 capabilities. This would allow the products to be certified for use with existing CNSA 1.0 requirements prior to the updated CNSA 2.0 requirements.
Unfortunately, this approach may not work for PQC capabilities implemented in hardware. An example is secure boot. A product supporting both CNSA 1.0 and CNSA 2.0 image verification algorithms would not be quantum safe. A bad actor would simply need to create and sign an image using a compromised CNSA 1.0 key. Vendors with new products entering the market prior to the certification requirement updates will need to decide which is best for them: Enter the market with CNSA 1.0 compliant secure boot to meet current requirements or enter with CNSA 2.0 compliant secure boot and potentially forego sales to select customers until the certification requirements are updated.
Cisco has been working with NIST and other industry leaders to develop methods to automate the validation programs necessary for certification of the new encryption standards. For example, Cisco is using NIST's Automated Cryptographic Validation Test Systems (ACVTS), which are now operational. ACVTS allows Cisco and other vendors to verify crypto algorithms quickly and have the results posted on NIST's Computer Security Resource Center.
Cisco partnered with the CAVP and CMVP to define PQC algorithm self-test requirements and publish an updated draft of the FIPS 140-3 Implementation Guide (IG) 10.3.A.
Cisco is also helping to automate validation testing using the Cryptographic Module Validation Program (CMVP). This is a security accreditation program for cryptographic modules. When automations are ready, it should result in significant reductions in the time required to obtain FIPS certifications, which currently takes about two years.
Additionally, Cisco is engaging with CC on multiple fronts, starting with CC's User Forum. Cisco participates in CC's Network Device collaborative Protection Profile (NDcPP) work, contributing to CC's protection profile for networked devices. The latest version of the NDcPP was released in December 2023.
NDcPP is currently one of the most popular and extensively used protection profiles among network device vendors and manufacturers to get their product certified. Under the National Information Assurance Partnership (NIAP), Cisco is part of efforts to oversee a national program that evaluates commercial off-the-shelf (COTS) IT products for conformance to the Common Criteria.
Cisco's engagement with the CSfC certification process includes regular meetings with the CSfC program office administration. These cover future product specifications, clarification of component package requirements for products submitting for certification, MOAs and components listings that show that products satisfy the reference architectures and configuration information contained in published Capability Packages.
The technology industry, the government, and standards bodies like NIST are working diligently to ensure secure and interoperable PQC solutions. For instance, interoperability testing, which is the next level of PQC implementation verification, is underway. The National Cybersecurity Center of Excellence (NCCoE) and industry partners are actively promoting vendor interoperability testing to ensure customer success in the transition to PQC. Will this complete the transition to quantum-safe cryptography? Not quite. While we can address the most pressing risks today, having completely quantum safe products will take more time.
The work is taking place on parallel paths, with each solution component on its own track to quantum safe modes of encryption. Operating systems (OS), both proprietary and open source, have a process underway, as does application software. Third-party integrations must also meet certification requirements. All components must be quantum safe before the entire solution can be considered quantum safe.
No one is standing still. The government is taking action to speed up the creation of new certification requirements for CC and CSfC. Vendors like Cisco are collaborating with industry groups, standards bodies, and government agencies to gain an understanding of which standards can be used, even if the certification requirements are not ready. Success will come from productive dialogs amongst the key stakeholders. There is some risk that vendors will have to repeat product development steps if they build around a standard that changes before certification. Cisco accepts this risk and is working to meet current critical deadlines with products that are designed to enable PQC in the future.
Additional Resources
Related Blogs
We'd love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!