Cryptographic Asset Discovery and Inventory

4.1.1. Cryptographic Bill of Materials (CBOM) and Auxiliary Methods

CBOM-based identification is to empower cryptographic asset owners or vendors to explicitly declare cryptographic usage within their products, components, or services. Usually CBOM declaration is achieved through static code scanning and/or CI/CD integration, so we keep them in the same section.¶

Scanning Methods:¶

• Static Code Scanning:¶

  • SCA (Software Composition Analysis): Scan manifest files (like package.json, requirements.txt, or pom.xml) from the codebase to create CBOMS, usually for analyzing third-party libraries dependency.¶

  • SAST (Static Application Security Testing): Builds a Abstract Syntax Tree (AST) with parsed syntax and data flow of the target source code. It then uses AST to track call chain to end crypto library, track variables (data flow) from source to destination, do reference matching, etc.¶

    • SCA and SAST is used by IBM CBOMKit-Hyperion.¶

• Binary / Image Scanning:¶

  • Scan for algorithmic constants, signatures; Extract from OS trust stores and runtime configurations... The process details are omitted in this document due to complexity.¶

    • Binary / Image Scanning is used by IBM CBOMKit-Theia and CycloneDX Cdxgen.¶

Tools and Modelling:¶

• IBM CBOMkit, Static code level scanning (Hyperion) and Artifact level scanning (Theia) [IBMCBOM]: uses implements and uses relationship to create dependency diagram.¶

  • implements: Describes the list of protocols or algorithms this module implements.¶

  • uses: Describes what modules are used by this service.¶

  • For example, Application Nginx uses Library libssl.so that uses Protocol TLS v1.3/v1.2 that uses libcrypto.so that implements Algorithm MD5, SHA256, AES-128-GCM.¶

• CycloneDX Cdxgen, Artifact level scanning [CDXGEN]: uses dependsOn and provides relationship to create dependency diagram.¶

  • dependsOn: Describes other modules or services this module depends on.¶

  • provides: Describes all capabilities this module provides.¶

  • For example, Application Nginx dependsOn Library libssl.so , which provides TLS 1.2.¶

After scanning, the result will be recorded as a CBOM object.¶

CBOM data specification: A standardized cryptographic asset object includes cryptographic algorithms, digital certificates, protocols, private keys, public keys, cryptographic keys, ciphertext information, digital signatures, digests (the output values of hash functions), initialization vectors (input parameters for encryption algorithms), seeds, salts, shared secrets, authentication tags, passwords, credentials, and tokens. For a detailed specification, see CycloneDX SBOM v1.6 https://cyclonedx.org/news/cyclonedx-v1.6-released/¶

"components": [
 {
  "name": "google.com",
  "type": "cryptographic-asset",
  "bom-ref": "crypto/certificate/google.com@sha256:1e15e0fbd3ce9...",
  "cryptoProperties": {
    "assetType": "certificate",
    "certificateProperties": {
      "subjectName": "CN = www.google.com",
      "issuerName": "C = US, O = Google Trust ... LLC, CN = GTS CA 1C3",
      "notValidBefore": "2016-11-21T08:00:00Z",
      "notValidAfter": "2017-11-22T07:59:59Z",
      "signatureAlgorithmRef": "crypto/algorithm/sha-512-rsa@1.2.840..",
      "subjectPublicKeyRef": "crypto/key/rsa-2048@1.2.840.113549.1.1.1",
      "certificateFormat": "X.509",
      "certificateExtension": "crt"
    }
  }

Figure 1: Example CBOM¶

Gaps: Obviously, this does not help with identifying the mass legacy devices, components or services.¶

4.2.1. Simulated Handshakes

Simulated handshake is a network-probing technique where a discovery tool acts as a client and intentionally initiates cryptographic protocol negotiations (e.g., TLS, SSH, IPsec) with enterprise network endpoints without completing the full data session. During the negotiation process, the discovery tool determines the specific cryptographic protocol versions, negotiation mechanisms, and ciphersuites supported by the endpoint. This is also known as Active Probing.¶

Steps of simulated handshake include:¶

1. Port Scan: The tool scans for typical ports for specific secure communication protocols (443 for HTTPS, 22 for SSH, etc)¶

2. Probing: The tool generates a RFC-compliant connection initialization packet, including all currently standardized ciphersuites, and examine the response.¶

3. Response Extraction: The target object respond with supported ciphersuites, following its own internal priority rules.¶

4. Parsing: The tool intercepts this raw response and decodes it as cryptographic assets.¶

This works for most secure protocols that includes negotiation:¶

• IPSEC¶

• TLS¶

• SSH¶

Pros and Cons/Gaps:¶

• Strengths:¶

  • This kind of method does not require complex engineering refactoring. Since it is agnostic to the design of the target, it works best for the case where the manager operates vast heteogenous devices from different vendors, versions and locations, hence telecommunications case.¶

  • This probing is one-time, thus it will not create unhandleable amount of probing packets.¶

• The limitation of this method is that¶

  • Some masking mechanism will stop the probing (firewalls, load balancers, port-concealing protocols like Single Packet Authorization that enforce a default drop for unexpected packets), leaving a hidden security posture inside of the system.¶

  • Network management cannot know local application components that rests internally in the device and are not exposed over a socket.¶

Tools:¶

• Cisco Mercury project [MERCURY] provides an open source packet capture and analysis tool. It can read network packets, identify metadata of interest, and write out the metadata (including cryptographic-related) in JSON format.¶

4.2.2. Traffic Pattern Analysis

Unlike simulated handshakes that actively query an endpoint, Traffic Pattern Analysis listens passively to live network traffic at strategic aggregation points. It infers cryptographic asset usage from protocol metadata, statistical characteristics, and behaviors without decrypting the underlying data payload.¶

Methods of Traffic Pattern Analysis includes:¶

• Listen to unencrypted negotiations like clientHello/serverHello, Server Name Indication (SNI), response of an unencrypted server digital certificate request, etc.¶

• Listen to handshake fingerprints and compare them to existing patterns, as protocol implementations and behaviors are often rigid.¶

• Listen to packet length and arrival time, do statistical pattern recognition.¶

Pros and Cons/Gaps:¶

• Strengths:¶

  • Similar to Simulated Handshakes, this kind of method is not intrusive and is agnostic to the design of the target.¶

• The limitation of this method is that¶

  • Negotiation information like clientHello [RFC9849] and SNI are tending to be encrypted.¶

  • Protocols tend to have constant size packets [RFC9347].¶

  • Alternative routing: network requests/responses could exit through a different routing path.¶

4.2.3. Process Identification

Process Identification requires Endpoint Detection and Response (EDR) installed to have cryptographic visibility inside of a system.¶

Methods of Process Identification includes:¶

• Kernel-Level System Call Auditing by deploying eBPF programs into the kernal space. These filters can capture kernel events to determine exactly which process (down to PID) have initiated an encrypted network communication.¶

• Shared Library and Binary Hooking, by monitoring process load table to see if cryptographic dynamic libraries are loaded into the memory space.¶

• Live Memory Scanning, by periodically scanning volatile memory for indication of creation of keys or signatures (as high-entropy memory segments), and then compare them with known patterns.¶

Pros and Cons/Gaps:¶

• Strengths:¶

  • Have deeper visibility for cryptographic assets within devices.¶

• The limitation of this method is that¶

  • Requires loading new software (at least EDR/RDR) to legacy devices.¶

  • Potential blind spots due to lower pattern coverage.¶

4.2.4. Configuration Extraction

The Configuration Extraction is a bit similar to the source code scanning. This section focuses more on the runtime configurations. In different use cases, the configuration extraction methods differs significantly. This section is to be extended.¶

Methods of Configuration Extraction includes:¶

• In network device management, NETCONF and YANG provide a standardized, model-driven management interface that enables programmable configuration and state validation. The network managing platform can define a YANG model and extract configurations from a device.¶

• In cloud-native development, general .yaml configuration files, .env environment variables files, Kubernetes secret manifest, etc, can be extracted by administrative scripts or through management interfaces (e.g., AWS CloudControl, Kubernetes API).¶