Output Schema Based on Cryptographic Bill of Materials (CBoM) for Post-Quantum Cryptography Usage

Abstract

This document defines an output schema for inventorying cryptographic assets based on Cryptographic Bill of Materials (CBoM). It highlights key differences between an inventoring schema and CBoM, identifies gaps, and proposes a unified schema that can leverage existing CycloneDX parameters to create a usable cryptographic asset inventory.¶

1. Introduction

A CBoM or Cryptographic Bill of Materials (CBoM) is an extension of the Software Bill of Materials (SBoM). SBoM are typically used to describe various components of a software, which helps assess vulnerabilities and provenance of such components. A CBoM is an added representation on top of SBoM that further describes cryptographic components in the software. For example, a CBoM can describe the cryptographic algorithms, key sizes, modes of operation, and other relevant details of the cryptographic components used in the software. This additional information helps organizations better understand what cryptographic algorithms exist, where they are used, and make informed decisions about their deployment (e.g., whether to deprecate algorithms or not, etc.). For the purpose of this document, we follow IBM's well known CBoM schema [cbom]. As of 2025, the latest version of CBoM schema that is part of the well known SBoM standard CycloneDX v1.7 is the following:¶

<CODE BEGINS> file "cbom.json"


          component:
            type: library
            name: example-component
            version: 1.0.0
            cryptographicProperties:
              - algorithm
                - additional algorithm properties
              - certificate
                - additional certificate properties
              - protocol
                - additional protocol properties
              - related cryptomaterial
                - additional related cryptomaterial properties
            other properties...


<CODE ENDS>

Such CBoM are currently generated at a software component level, either through static or dynamic analysis. In practice, this can look like a mix of automated tools and manual processes to generate CBoM for software components.¶

2. Cryptographic Asset Inventory (CAI)

A Cryptographic Asset Inventory (CAI) is an organizational level inventory of all cryptographic assets used within an organization. This includes hardware, software, and services that utilize cryptographic algorithms for security purposes. The difference between a CBoM and CAI is that the former is an extension of SBoM while the latter is centered around cryptographic assets that goes beyond software components. The purpose of a CAI is to provide a comprehensive view of the cryptographic assets in use, their configurations, and their compliance with organizational policies and industry standards. A CAI helps organizations manage their cryptographic assets effectively, ensuring that they are up-to-date, secure, and compliant with relevant regulations. Think of it this way - CBoMs are part of SBoMs, HBoMs, and other BoMs. CAI would be one schema that encompasses all instances of CBoMs in other BoMs.¶

3. Components of a CAI

An important feature of CBoM is its ability to provide detailed cryptographic properties at the component level. this essentially makes it use case independent. By capturing the maximum information available, it can be used for a variety of use cases. For CAI, however, we typically scope information that is relevant to cryptographic compliance. For this document, the use case we focus on is the ability to provide enough information that would help an organization be compliant with existing cryptographic standards and future PQC standards. Hence, a CAI should fulfil the following functions:¶

1. Criteria 1: At some level of grouping, provide a list of cryptographic assets that are present in the overall system. This system should encompass all assets, including software, hardware, and underlying infrastructure. The grouping can be done at any feasible level, i.e., application, ownership, remediation team, etc.¶
2. Criteria 2: The inventory should provide compliance information according to current cryptographic standards. These standards can be a combination of organizational encryption policy, industry standards for secure encryption, and regulatory requirements.¶
3. Criteria 3: The inventory should provide indicators of future quantum-resistant compliance. This should include any newly standardized algorithms that are present in code, network, or infrastructure.¶
4. Criteria 4: The inventory should contain minimum information that would enable required parties to assess and manage cryptographic risks effectively. It should not contain fields unnecessary for the purpose of inventorying.¶
5. Criteria 5: The inventory should to the extent possible, be automated for accurate updates to cryptographic information.¶

4. Differences between CBoM and a Cryptographic Asset Inventory (CAI)

We looked at the CryptoProperties schema in CycloneDX which is a representation of the original CBoM format [cyclone-cbom]. Based on the necessary properties of an organization level CAI, we identified the following areas in existing CBoM standards which can be augmented with additional information for a PQC inventory:¶

1. CBoM has a larger set of infomation that is use case independent¶
2. Complex inventories to inform PQC are hard to capture in the current structure¶
3. Clarity on mandatory versus optional fields needed¶
4. Hierarchy and relationships between cryptographic components are needed for understanding downstream effect¶
5. Additional information on criticality scoring would be helpful for asset prioritization¶
6. Chance of asset duplication¶
7. Need PQC-ready-compliance information in addition to CBoM information¶

5. Data Structure for CAI

The standard CBoM structure as shown in Figure 1 (Section 5) has a total of 55 fields grouped by component type. Each algorithm is a separate component "linked" by dependency. The new structure for CAI as shown in Figure 2 (Section 5) has a total of 28 fields grouped by application. Each application contains multiple crypto-elements with their respective properties. The new structure is more compact and hierarchical, making it easier to understand and manage cryptographic assets at an application level for PQC needs.¶

<CODE BEGINS> file "og-str"


              Component (app/file/library/etc) {
                Algo properties
                Cert properties
                Proto properties
                Related cryptomaterial properties
              }


<CODE ENDS>

The new structure Figure 2 (Section 5) also makes it easier for cryptographic assets to inherit the risk properties of its parent application. The algorithm field is a sub-component wrapped inside a crypto-element, which in turn is wrapped in an application element. A noticeable change between the two is the inclusion of "Compliance_info", which specifies if certain algorithms are compliant or not.¶

<CODE BEGINS> file "new-str"


            Application {
              Application metadata {
                    Owner
                    Criticality
                    Other metadata
                }
              Crypto-elements {
                Source: code {
                      Certificates {
                        Algorithm and compliance info
                        Crypto-element metadata
                      }
                      Crypto Libraries {
                        Algorithm and compliance info
                        Related Crypto Materials (keys, IVs, nonces)
                      }
                      Cert/library/proto {
                        Algorithm and compliance info
                        Crypto-element metadata
                      }
                  }
                Source: network {
                      Protocols {
                        Algorithm and compliance info
                        Crypto-element metadata
                      }
                      Certificates {
                        Algorithm and compliance info
                        Crypto-element metadata
                      }
                    }
                  Source: infrastructure {
                        Internal {
                          Infra Type
                          (Container, OS, Hardware, Cloud services, Devices, Files)
                          {
                            Algorithm and compliance info
                            Crypto-element metadata
                          }
                        }
                        External {
                          Infra Type
                          (Container, Hardware, Cloud services, Files)
                          {
                            Algorithm and compliance info
                            Crypto-element metadata
                          }
                        }
                    }
                }
            }


<CODE ENDS>

Using the CBoM schema as the standard template and adding the additional elements, we observe the following overall structure.¶

The above table maps the proposed CAI schema fields to their equivalent CBoM schema fields. Not all fields have a direct equivalent, indicating areas where the CAI schema introduces new concepts or structures not present in the original CBoM schema.¶

6. Conclusion

In this document, we proposed an extension to the existing CBoM schema to better suit the needs of an organizational level Cryptographic Asset Inventory (CAI). By identifying gaps in the current CBoM standards and introducing a more hierarchical and use-case focused structure, we aim to provide a more effective schema for organizations to manage their cryptographic assets, ensuring compliance with current and future standards, including post-quantum cryptography requirements. Future work includes developing tools for automated generation and maintenance of CAI based on this proposed schema.¶

9. References