Building a CBOM for Quantum Migration

Two quantum algorithms threaten the security of cryptographic algorithms. Shor's algorithm targets asymmetric/public key cryptography (RSA, ECDSA, ECDH, DH, DSA), while Grover's algorithm impacts symmetric algorithms, such as AES and SHA.

The algorithms have very different impacts on cryptographic security. Shor's algorithm breaks the mathematical "hard" problems that classical public key cryptography relies on, rendering it completely insecure. In contrast, Grover's algorithm offers a quadratic speedup, effectively halving the key length of symmetric algorithms. As a result, classical public key cryptography must be replaced as part of a quantum migration, while symmetric algorithms are secure with adequate key lengths (AES-256, SHA-384 or larger).

This Report focuses on developing a CBOM to support quantum migration, focusing on replacing classical asymmetric algorithms with their post-quantum equivalents. NIST has published three post-quantum standards to date:

• FIPS 203 (ML-KEM): Key establishment
• FIPS 204 (ML-DSA): Digital signatures (general-purpose)
• FIPS 205 (SLH-DSA): Digital signatures (backup)

These standards were finalized in August 2024. Another digital signature scheme (FN-DSA / FIPS 206) is still in draft status but may be an option worth considering when finalized.

Why This Is Urgent Now

Cryptographically relevant quantum computers (CRQCs) don't currently exist, and it's unclear when they will. However, the potential for them to exist in the near future has inspired regulators to pass deadlines for quantum migration.

Several jurisdictions have already enacted legislation imposing timelines on post-quantum migration. In general, high-risk systems must be migrated by 2030/2031, and full migration must be complete by 2035 (2031 in US).

These orders are largely motivated by harvest now, decrypt later attacks, which threaten sensitive data even before CRQCs are available. While these laws are limited in their scope, they can also affect organizations not explicitly required to comply if those companies provide services to impacted organizations. Additionally, more laws are likely to be enacted as lawmakers grapple with the pending quantum threat.

The CBOM Discovery Categories

When developing a CBOM for quantum migration, the focus should be on asymmetric cryptography. While Grover's algorithm weakens symmetric algorithms, it has a much smaller impact on their security.

Cryptography is a useful tool, which means it appears in many places, some of them unexpected. When building a CBOM, consider the following categories of asymmetric cryptography.

Network and Protocol

At the network level, cryptography is used for authentication, encryption, and integrity protection. Classical public key cryptography is likely to appear in:

• TLS/SSL handshake configuration (key exchange and certificate signature sections)
• VPN key exchange (IKE/IPsec)
• SSH host key algorithms

Codebases and Dependencies

Applications commonly use cryptography for a variety of different purposes. A program might encrypt sensitive data or use digital signatures for authentication or data integrity checks.

When building a CBOM, developers can use code scanning tools and manual analysis to look for signs of cryptographic code, such as calls to algorithms associated with RSA and ECDSA. Additionally, teams should use source composition analysis (SCA) tools to look for crypto usage within application dependencies.

A CBOM listing shouldn't be limited to just the algorithm in use. Key lengths and other configuration settings should be included as well to help measure exposure of the protected data to harvest now, decrypt later attacks.

Digital Certificates

Digital certificates are used to:

• Authenticate websites (and users in mutual TLS)
• Authenticate user identity (smart cards, client certs, etc.)
• Verify email sender identity and data integrity
• Encrypt email contents
• Sign code
• Digitally sign documents
• Sign and verify authentication tokens (JWT, SAML assertions) in federated identity and SSO systems

When transitioning certificate architecture, organizations need to look at both the architecture itself and the potentially insecure keys that it creates. If an insecure algorithm is used to issue certificates, organizations need to migrate:

• Digital certificate creation
• Certificate migration
• All keys using insecure algorithms
• All data digitally signed with an insecure key

When building a CBOM for quantum migrations, organizations need to look in a variety of places for vulnerable digital certificates and their associated configurations. Examples include:

• PKI infrastructure (certificate authorities, validation code, etc.)
• Email clients/servers
• DevOps CI/CD pipelines
• Key management systems
• Hardware security modules
• Login/authentication systems
• Identity federation/SSO infrastructure (JWT, SAML, OAuth token signing configuration)
• Cloud-managed key management services (AWS KMS, Google Cloud KMS, Azure Key Vault)

Embedded, Firmware, and OT/IoT

Some of the hardest places to identify cryptographic usage are embedded software, firmware, and OT/IoT devices. Often, these systems are "out of sight, out of mind" yet process highly sensitive data.

When looking for vulnerable cryptography in these systems, some places to check include:

• Device provisioning keys
• Firmware signing keys
• Secure boot chains

Third-Party and Vendor

Not all of the cryptography that an organization uses and relies upon is under its control. Vendors and suppliers can build cryptographic code into their apps and devices. For example, email clients, IoT devices, SaaS apps, cloud KMS/HSM-as-a-Service platforms, and other tools may be using vulnerable asymmetric cryptography behind the scenes.

These third-party and vendor uses of cryptography should be identified, documented and managed as part of a quantum migration. Often this is accomplished via vendor contracts and attestations, where the organization includes language about quantum migration to contractual language as part of the acquisition or renewal process.

Bulk Data Encryption

In general, bulk data encryption is performed by symmetric cryptographic algorithms, like AES. Since Grover's algorithm doesn't break these algorithms (assuming adequate key lengths), this may be out of scope of a quantum migration.

However, bulk data encryption often involves the symmetric encryption key being established via asymmetric key exchange or stored while encrypted by an asymmetric key. In fact, this is often how ransomware works: creating an AES key, encrypting it with the attackers' public key, and sending the encrypted key back to the attacker to be decrypted and used as part of their extortion efforts.

Key exchange protocols for encrypting data in transit are likely covered by the network and protocols domain (TLS, etc.). However, organizations should also check the solutions that they use for encryption of data at rest (full disk encryption, database encryption, etc.) to see if a vulnerable asymmetric algorithm might be used to secure and store the symmetric key.

Managing the Risk to Symmetric Cryptography

In theory, symmetric cryptography should be out of scope for a quantum migration. Grover's algorithm only weakens these algorithms, not breaking them like Shor's algorithm does for public key cryptography.

However, this weakening should be taken into account when building a CBOM for quantum migration. Symmetric algorithms that should be included in the CBOM are:

• AES-128 and AES-192
• SHA variants smaller than SHA-384

Building the CBOM

Generating a complete CBOM for quantum migration can be a complex endeavor. This process can be broken up into three main stages, which should be performed regularly to ensure that the CBOM remains current and complete.

Discovery

Cryptographic code can be embedded in various parts of an organization's IT environment. Building a CBOM for post-quantum migration requires a combination of automated and manual review.

In some cases, automated tools exist for identifying the use of cryptography. Places to start include:

• Network Traffic Analysis (NTA): Passive network traffic analysis can be used to help identify the algorithms used to protect network traffic. For example, traffic can be used to filter for TLS handshakes, from which lists of supported ciphersuites can be extracted.
• Source Code Analysis: Source code analysis tools can be built into deployment pipelines or run against existing code repositories to map out the use of cryptographic algorithms. These can look for common cryptographic libraries and signs of operations like key generation or digital signatures.
• Software Composition Analysis (SCA): Cryptographic code may hide in application dependencies as well. SCA tools can help to map out an application's dependency tree, allowing the organization to perform source code analysis against this code as well or check documentation to identify the algorithms in use.

While these automated scans are a good starting point, they won't provide full visibility into an organization's use of cryptography. SaaS tools, vendored code, and IoT devices are a few examples of areas where these methods fall short.

These situations may require manual review and documentation of existing visibility gaps. A company can insert terms for post-quantum migration into contracts and have these conversations with vendors. In some cases, like IoT devices, an organization may lack any visibility and control over the systems and must document a visibility gap and the associated risks.

Report Generation and Formatting

Some regulations have requirements about the information that organizations must include in their CBOMs. However, a specific format isn't generally specified.

That said, CycloneDX introduced a standardized, open-source format for recording CBOM data in v1.6 (current version is 1.7). This information is ratified in ECMA-424 and compatible with many automated scanning tools. IBM's CBOMkit is an open-source tool for generating and viewing CBOMs, making it a great starting point for building a quantum-readiness CBOM.

Risk Assessment and Prioritization

Building a comprehensive CBOM gives an organization insight into the total amount of work that a post-quantum migration will entail. However, it doesn't provide guidance on how to develop a real plan for doing so.

Quantum migration can be prioritized based on a few different factors, including:

• Harvest Now, Decrypt Later Risk Exposure: While CRQCs aren't currently available, quantum migration is relevant today because sensitive data encrypted today may be exposed in the future when CRQCs become available. Data should be ranked based on whether it will likely still be sensitive when CRQCs do exist and its probability of exposure.
• Regulatory Deadlines: Some regulations impose different deadlines for different systems based on risk or algorithm type. For example, US EO 14412 mandates migration of key exchange algorithms a year earlier than signature algorithms because the risk that an attacker will access data encrypted today is higher than the risk that attackers will be able to forge digital signatures using a quantum computer.
• Migration Complexity: Not all quantum migrations are equally difficult, and timelines need to be taken into account. Overhauling an organization's entire PKI infrastructure to use post-quantum signature algorithms is a bigger lift than updating a computer's TLS configuration to remove vulnerable ciphersuites.

The factors that an organization considers when prioritizing their quantum migration will depend on their unique circumstances. For example, a healthcare organization should focus on the threat of harvest now, decrypt later attacks, especially when there is no regulatory pressure to migrate.

Getting Started on Post-Quantum Migration

A post-quantum migration begins with a completed CBOM. This should include information about classical asymmetric cryptography and symmetric crypto with inadequate key lengths in a CycloneDX or similar format.

For many organizations, 2030/2031 is a hard deadline for migration, either of high-risk systems (EU/UK) or all systems (US government agencies and contractors). For those not directly impacted by regulations, harvest now, decrypt later attacks pose a significant risk today.

The CBOM Finding Prioritization Tool is an Excel workbook that scores CBOM findings against HNDL exposure, regulatory deadline proximity, and migration complexity, allowing you to identify quick wins, urgent projects, and delayable tasks. Get the CBOM Finding Prioritization Tool.

Further Reading