Cryptography Bill of Materials (CBOM)↑
A cryptographic bill of materials (CBOM) is a cybersecurity asset that lists all software and hardware components within a system, including their dependencies, vulnerabilities, and security risks. CBOMs extend software bill of materials (SBOM) by defining an object model to describe cryptographic assets and their dependencies.
When integrated into reporting and software development practices, CBOMs enable organizations to manage and report usage of cryptography such as enforcing a secure cryptographic policy across IT infrastructure, reacting quickly to security issues, efficiently carrying out strategic transformations (for example, migrating cryptography services to the cloud, or deploying post-quantum cryptography.
Cryptography inventories↑
A cryptography inventory is a comprehensive catalog of all cryptographic components used within an organization. It provides a detailed map of:
- Which applications utilize cryptography
- The purpose of each cryptographic implementation
- Technical details, including:
- Algorithms and usage modes
- Keys and key storage solutions
- Certificates
- Protocol versions
- Library versions
- Non-technical information, such as:
- Data classification
- Business purpose
- Responsible personnel
The following sections will outline key layers of cryptographic inventories
Application cryptography↑
In a typical enterprise, applications use cryptography to:
- Encrypt sensitive data at rest or in transit.
- Sign or verify documents and files.
- Protect passwords and credentials.
- Secure access sensitive resources.
- Participate in other protocols such as single sign-on, TLS, SSH, or Kerberos.
- Perform business-specific cryptography such as authorising payments.
These cryptographic operations involve a range of technical components, including:
- Specific algorithms and keys.
- Modes of operation.
- Protocol versions.
- Cryptographic libraries.
To access and manage these components, applications typically retrieve keys and certificates from a variety of sources such as filesystem keystores or hardware security modules (HSMs).
Infrastructure cryptography↑
Enterprise infrastructure typically makes extensive use of network cryptography protocols such as TLS, IPSec, and SSH. Each of these requires an infrastructure of keys and certificates. To ensure effective management and security, these components must be included in a comprehensive cryptographic inventory.
Additionally, various hardware devices including HSMs, VPN appliances, firewalls, and intrusion detection systems all contain cryptographic artifacts and support specific algorithms. Often these systems control the most sensitive and business-critical cryptography in the organization, such as the secret keys used to protect high value data and assets.
Cryptographic assets↑
The following list represents a selection of common cryptographic assets, categorized into two main groups: executable and non-executable file objects. Executables are components of runnable software, and non executables are filesystem objects referenced by executables. Non-executables include keystores and other formats that may contain both public and private asymmetric keys.
Executable file objects↑
These are components of runnable software that may utilize or interact with cryptographic assets:
- Application binaries - Compiled programs that execute on a system.
- Cryptographic libraries - Software libraries that provide cryptographic functionality.
- Software archives - Packages that contain executable code, such as JAR (Java Archive) files.
Non-executable file objects↑
- Keystores
- PKCS#12
- Java Keystores
- Key Data Sets
- Other key formats:
- OpenPGP Keys
- X.509 Certificates
- OpenSSH Keys
- PKCS#1
- PKCS#8
CBOMs↑
A CBOM typically includes a cryptography inventory tailored to specific goals. For example:
- Crypto-agility planning - The report should distinguish between algorithms used for cryptographic and non-cryptographic purposes, enabling planning and decision making during migration.
- Cryptographic policy control - The CBOM must be as detailed as the policy itself, providing a thorough understanding of the cryptographic landscape.
Benefits of an up-to-date CBOM↑
An updated CBOM can help identify and prioritize actions to remediate availability and security issues related to cryptographic objects. For example, a regularly generated CBOM can:
- Detecting expiring certificates - Allow for timely renewal and minimizing potential disruptions.
- Prioritize critical certificates - Identify the most frequently used certificates that are approaching expiration and should be addressed first.
- Identify vulnerable cryptographic components - Detect issues such as:
- ECDSA signing certificates using the SHA-1 hash function that are vulnerable to collision attacks.
- ECDSA certificates with insufficient key length, or other weak keys, that need to be renewed.
CBOM in AQtive Guard↑
AQtive Guard provides a single, unified repository for storing and managing all your CBOM scans, ensuring centralized visibility into your cryptographic assets. With support for the Cryptographic Bill of Materials (CBOM) format, AQtive Guard seamlessly ingests CBOM files (JSON format) to catalog cryptographic components, identify vulnerabilities, and assess risks across software supply chains.
This integration gives organizations a real-time, structured view of their cryptographic inventories, enhancing security posture and compliance efforts. For more details on using CBOM with AQtive Guard, refer to the user guide.
Recommendations for implementing CBOM↑
Using CBOMs has recently become more mainstream due to recommendations from standards bodies and industry analysts, and the need for visibility into deployed cryptography to facilitate the post-quantum migration.
Preparing a CBOM should leverage automated tools to identify the cryptographic algorithms used in hardware and software modules, libraries, and embedded code (as recommended in NIST Special Publication 800-128 or NCCoE), as well as data at rest, in transit, and in use.
After vulnerable cryptography components and associated assets are identified, the next objective is to prioritize initial remediation efforts using a risk management methodology informed by the sensitivity and criticality of the information being protected over time.
Post-Quantum cryptography migration↑
CBOMs play a particularly important role when tackling the migration from classical asymmetric cryptography to post-quantum cryptography. An updated and detailed CBOM allows organizations to find vulnerable algorithms such as:
- Signature algorithms used in TLS certificates.
- Key agreement algorithms, such as elliptic curve and finite field Diffie-Hellman.
- Public key encryption algorithms, such as RSA.
Although not all protocols and schemes have post-quantum options available, knowing which vulnerable algorithms are currently deployed, and how frequently they are used is a crucial first step in migrating away from them. As noted in NIST SP 1800-38B, this initial step can be taken now. A regularly updated CBOM will help prioritize which classical cryptography can and must be upgraded to post-quantum options as they become available.
Sources↑
- NIST SP 1800-38B, “Migration to Post-Quantum Cryptography Quantum Readiness: Cryptographic Discovery: Approach, Architecture, and Security Characteristics of Public Key Application Discovery Tools”, December 2023
- NIST SP 800-57 Part 1 Rev. 5 - “Recommendation for Key Management: Part 1 – General”, May 2020
- NIST Special Publication 800-128
- Gartner report, Better Safe than Sorry: Preparing for Crypto-Agility
- Knowledge base: RSA algorithm
- Knowledge base: Elliptic curve cryptography
- Knowledge base: Certificates
- Knowledge base: Weak cryptography keys
- Knowledge base: TLS
- Knowledge base: Quantum threat