Does FedRAMP consider quantum vulnerable cryptography a vulnerability?

[robgil]

Greetings FedRAMP team!

I always appreciate the discussion and accessibility to the FedRAMP team to answer these questions.

Given the acceleration of Post Quantum Computers and the risks associated with harvest and decrypt later, what is FedRAMP's position on post quantum vulnerable cryptography? Does FedRAMP consider this a vulnerability?

FedRAMP has included exceptions to FIPS in regards to patching. My argument is that PQC vulnerable libraries should be considered a vulnerability and patched. There are currently no FIPS approved PQC libraries. Will FedRAMP allow the use of libraries that are in-process so we can begin the transition?

As an advisor to multiple major security focused cloud service providers, the industry needs clear direction from the Government to kick off the transition to Quantum secure cryptography. The cloud services I advise are critical to the adoption of Post Quantum Cryptography. Once they adopt PQC, the rest of the industry will follow. Usually the first to implement a significant new technology become the basis for adoption and standardization.

Thank you for your attention to this matter!
Rob

[pete-gov]

Hey Rob - Executive Order 14112 Securing the Nation Against Advanced Cryptographic Attacks established direction for the government's transition to post-quantum cryptography. Section 6 (Procurement) includes direction for coordinating efforts on the migration of cloud-based technologies to PQC and assigns work for NIST and the FAR Council related to updating the CMVP and updating acquisition regulations to require specific cryptographic implementations.

FedRAMP, like cloud service providers and the rest of government, is standing by for guidance based on the outcome of these tasks assigned to other parts of the government. More importantly, the Executive Order anticipates updated acquisition regulations that would apply to all covered systems to establish opinionated requirements. FedRAMP likely will not need to play any role in this, nor will we need to change any rules for FedRAMP Certification, because cloud services will have contractual requirements to follow that are outside the scope of FedRAMP.

Given the acceleration of Post Quantum Computers and the risks associated with harvest and decrypt later, what is FedRAMP's position on post quantum vulnerable cryptography? Does FedRAMP consider this a vulnerability?

Not at this time - FedRAMP will follow whatever guidance CISA releases on this topic.

My argument is that PQC vulnerable libraries should be considered a vulnerability and patched.

I am unaware of any quantum-resistant libraries that are patched upstream versions of existing CMVP-validated libraries. My understanding is that a migration to a different algorithm with different implementations are required. In theory, if there's a patched upstream version of a currently CMVP-validated cryptographic module then yup, you can use it under FR's rules.

There are currently no FIPS approved PQC libraries. Will FedRAMP allow the use of libraries that are in-process so we can begin the transition?

FedRAMP Class D Certified cloud service offerings are required to only use NIST CMVP validated cryptographic modules or their upstream versions to protect federal customer data - this allows individual agencies to determine if they wish to use cloud services that conform entirely to FIPS 140-3 or if they wish to log a waiver for the use of cloud services that patch security vulnerabilities.

No agency has come to FedRAMP to request waivers for use of non-CMVP-validated PQC libraries in cloud services yet, but FedRAMP would be open to allowing that after consulting with CISA and NIST.

As an advisor to multiple major security focused cloud service providers, the industry needs clear direction from the Government to kick off the transition to Quantum secure cryptography.

The Executive Order directs a number of agencies and programs to provide this direction with clear timelines for each step... As those responsible parties hit those deadlines and release that guidance you can expect FedRAMP to begin incorporating it. The next big update will probably be to some rules in the Cryptographic Module Use ruleset to align with CISA's upcoming guidance on cryptographic bills of materials.

[sunstonesecure-robert]

It is both a vulnerability and not a vulnerability until someone opens the box. Sorry couldn't resist.

As someone who has done crypto FIPS testing and generally crypto algo development in the past - best to wait for final algo choices and tests to complete as the standards will have changes (for good or bad reasons --- looking at you S-boxes). And - the clouds are going to wait because the hardware implementations are definitely going to wait for those final tests.

That said if you are concerned about later decryption - there's nothing preventing you from encrypting with FIPS crypto and then also encrypting wiht your favorite PQC algo implementation. Best case - you win. Worst case - you lose anyway, but you were compliant and keep your Gov contract.

[robgil]

Thanks @pete-gov! That's exactly what I needed. From what I'm understanding from your response, this is dependent on NIST and CISA to give the go ahead on exceptions to FIPS certified libraries and FIPS certified libraries are a non-negotiable currently. Identity, Network, and Security products need to be ahead of the curve when it comes to PQC adoption as they are the foundations to everything else.

It sounds like we should raise this with agencies and DISA to see if we can get waivers (or IATTs) the the goal of introducing this as an option to customers. The transition is going to take years, and I think CISA and NIST may not be thinking about the protocol work for things like OIDC and SAML. As an example, SAML is basically defunct and without a functioning standards body to integrate PQC in to SAML. The expectation is that customers need to transition away from SAML and move to OIDC which in and of itself a major and lengthy transition.

Would you suggest we also go through the FSCAC as well as trade groups to raise awareness of the urgency? I talk to multiple cloud service providers who are ready to move forward with PQC now that FIPS 203, 204, 205 have been finalized.

https://csrc.nist.gov/news/2024/postquantum-cryptography-fips-approved

It's been 2 years since these standards were approved.

[pete-gov]

Would you suggest we also go through the FSCAC as well as trade groups to raise awareness of the urgency? I

FR can't advise or suggest on activities that cloud service providers may or may not do to lobby the government for things. :) But pushing towards FedRAMP when NIST, CISA, etc. are the responsible parties would be weird.

[robgil]

Hah understood.

[robgil]

@pete-gov one more for ya. We've heard from Bouncy Castle that the 2.2 release is the upstream version of the current 2.0 that is currently certified. Would this constitute an "update stream" even though its adding additional algorithms in addition to the existing algorithms? It's in the review process with NIST now. Would you agree this aligns with the FedRAMP Policy for Cryptographic Module Selection as it pertains to "update stream"?

A cryptographic module may change for a number of reasons, including:
- to add new functionality
- to fix a defect in existing functionality
- to address a change required for a software dependency
- to port the software to a new architecture or environment.
In many of these situations, the cryptographic functionality tested under CMVP is not changed, so updating
the vulnerable software with FIPS-validated modules is likely to increase overall assurance, even though
the new software version might not yet be FIPS validated.

If FIPS-validated cryptographic functionality tested under CMVP is changed in the new software version,
the use of that update is generally preferable than continuing to use the validated module with known
defects. Using modules with CAVP-validated algorithms is strongly preferred over unvalidated algorithms
because of the increased assurance that CAVP validation provides.

https://www.fedramp.gov/resources/documents/FedRAMP_Policy_for_Cryptographic_Module_Selection_v1.1.0.pdf

[pete-gov]

Note that the crypto policy you linked is legacy - CR26 version is here: https://www.fedramp.gov/2026/reference/cryptographic-module-use/

We've heard from Bouncy Castle that the 2.2 release is the upstream version of the current 2.0 that is currently certified. Would this constitute an "update stream" even though its adding additional algorithms in addition to the existing algorithms?

I think I see the contortion you are trying to make here and please, no. :) A cryptographic module is a set of things including cryptographic algorithms. When that module is validated, the algorithms are validated. An upstream release of that module that includes updates of the same algorithms and key generation is an upstream version of the approved cryptographic module - but new algorithms in that upstream release would not be upstream versions of approved cryptographic modules. It's just random new code that's never been validated added in on the side, not a patched version of validated software. You can use the updated 2.2 versions of the parts of the module validated in 2.0, but not the random new stuff that was never validated.

For example:

• CRYSTALS-Kyber (KEM) is not part of the Bouncy Castle 2.0 CMVP validated cryptographic module. This algorithm appears in Bouncy Castle 2.2, but would not be considered an upstream version of a CMVP validated cryptographic module.

• AES-KWP is part of the Bouncy Castle 2.0 CMVP validated cryptographic module. An upstream version of this algorithm exists in Bouncy Castle 2.2. If you use AES-KWP in Bouncy Castle 2.2, you are using an upstream version of a CMVP validated cryptographic module.

[robgil]

Thanks @pete-gov. Fully aware of the "contortion" and needed you to put the debate to rest 😉 . Much appreciated.