Cryptographic Observability for the Quantum Era¶

Modern organizations operate in an environment where cryptographic transparency, algorithm safety, and software supply-chain security are no longer optional. Regulatory bodies, international standards organizations, and sector-specific authorities now require a clear understanding of what cryptography is used within systems, how secure it is, and how organizations plan to transition to quantum-resistant alternatives.

CipherIQ is an open-source cryptographic observability platform that combines static asset discovery with runtime network monitoring to provide complete visibility into enterprise cryptographic posture.

As organizations face mandatory post-quantum cryptography (PQC) migration deadlines and the harvest now, decrypt later threat, CipherIQ solves the fundamental problem: you cannot migrate what you cannot see.

The Quantum Timeline Problem¶

2024-2025: NIST finalizes PQC standards (ML-KEM, ML-DSA, SLH-DSA)
2025-2030: Adversaries harvest encrypted data now for future decryption
2027-2033: NSA CNSA 2.0 mandates phased PQC migration for national security systems
2030-2035: Cryptographically relevant quantum computers potentially viable

Critical insight: Data encrypted with RSA-2048 today and captured by adversaries will be vulnerable in 10-15 years which is well within the confidentiality requirements of:

IoT/OT devices (20-30 year operational lifespans)
Medical records (HIPAA: 50+ year retention)
Financial transactions (SOX: 7+ year retention)
Government classified data (decades of sensitivity)
Intellectual property (patent terms: 20 years)

Organizations with long-lived data or devices cannot afford to wait. They need visibility into their cryptographic attack surface now.

Relevant PQC-Specific Frameworks & Standards¶

The Solution: Complete Cryptographic Observability¶

CipherIQ provides dual-layer visibility that closes the gap between configuration and reality:

Layer 1: Static Discovery (Build Time)¶

What cryptography COULD be used based on configuration

Scan firmware, containers, and filesystems to inventory:

Cryptographic libraries and their versions
Embedded certificates and key materials
Configuration files (TLS, SSH, VPN, IPsec)
Binary dependencies and linked crypto modules

CipherIQ Tools: cbom-generator and cbom-explorer

Output: Cryptographic Bill of Material (CBOM) in JSON CycloneDX format documenting the complete cryptographic supply chain

Layer 2: Runtime Monitoring (Production)¶

What cryptography IS actually being used in production

Monitor live systems to observe:

Actual cipher suite negotiations
Key exchanges and certificate validations
Protocol versions and algorithm selections
Fallback behavior under real-world conditions

CipherIQ Tools: crypto-tracer and pqc-flow

Output: Runtime telemetry showing production cryptographic behavior

What You Configure ≠ What Runs in Production¶

Modern infrastructure has a dangerous gap between declared cryptographic policy and actual runtime behavior:

Static configuration files say "TLS 1.3 only with quantum-safe ciphers"
Production reality shows TLS 1.2 fallback with RSA-2048 still accepting connections
Certificate inventory lists SHA-256 certificates
Network traffic reveals SHA-1 still being negotiated with legacy clients
Security policies mandate AES-256-GCM
Running systems use weaker algorithms due to compatibility layers

The result: Organizations believe they're quantum-ready based on configuration audits, while their production infrastructure remains vulnerable to "harvest now, decrypt later" attacks.

The Power of Correlation¶

Compare static inventory against runtime behavior to detect:

Configuration drift: TLS 1.3 configured → TLS 1.2 negotiated
Unexpected fallbacks: Modern ciphers available → Weak ciphers still in use
Certificate mismatches: SHA-256 certs deployed → SHA-1 still accepted
Compliance violations: Policy requires quantum-safe → Production uses vulnerable crypto
Shadow crypto: Undocumented libraries → Discovered in runtime traces

This dual-layer approach transforms cryptographic security from "we think we're safe" to "we can prove we're safe" with verifiable evidence.

Our Tools¶

1) cbom-generator¶

Static cryptographic asset discovery with PQC readiness assessment

Scans Linux filesystems, firmware images, and containers to generate comprehensive Cryptographic Bills of Materials (CBOMs) in CycloneDX format.

Key capabilities:

Deep discovery: Finds cryptographic libraries, certificates, keys, and configuration files
PQC classifier: Evaluates 48+ NIST algorithms against quantum threat timeline
Relationship mapping: Tracks SERVICE → PROTOCOL → CIPHER → ALGORITHM chains
Embedded system support: Optimized for resource-constrained IoT/OT devices
Privacy-preserving: Hashes sensitive key material, never exposes secrets
Standards-based: CycloneDX 1.6/1.7 CBOM output for tool ecosystem integration

Perfect for:

IoT/OT manufacturers generating CBOMs for FDA/UN R155/IEC 62443 compliance
DevSecOps teams integrating crypto inventory into CI/CD pipelines
Security teams conducting quantum readiness assessments
Compliance officers documenting cryptographic controls

Learn more → | GitHub →

2) cbom-explorer¶

Web-based CBOM visualization and navigation

Lightweight, browser-based tool for exploring Cryptographic Bills of Materials. No installation required—runs entirely in your browser.

Key capabilities:

Interactive visualization: Navigate cryptographic dependencies as graphs
PQC dashboard: Visual readiness scoring with quantum vulnerability heat maps
Algorithm analysis: Drill down into cipher suite compositions and primitives
Certificate chains: Visualize trust paths and expiration timelines
Diff view: Compare CBOMs across firmware versions to track changes
Export reports: Generate compliance summaries for stakeholders

Perfect for:

Security teams reviewing cryptographic inventory results
Compliance officers presenting audit evidence
Engineering managers tracking PQC migration progress
Executives understanding quantum risk exposure

Learn more → | GitHub →

3) crypto-tracer¶

kernel-based runtime cryptographic operation monitoring

Standalone command-line tool that uses Extended Berkeley Packet Filter (eBPF) to trace cryptographic operations on Linux systems in the kernel without modifying applications or requiring restarts.

Key capabilities:

Zero-overhead tracing: eBPF kernel probes with minimal performance impact
OpenSSL/libcrypto monitoring: Captures cipher negotiations, key exchanges, certificate usage
Real-time insights: Observe actual algorithm selections as they happen
Correlation ready: Output format designed for comparison with static CBOMs
Production-safe: Read-only monitoring with no application changes required
Filtering support: Focus on specific processes, connections, or crypto operations

Perfect for:

Validating that static CBOM configurations match runtime behavior
Detecting unexpected cryptographic fallbacks in production
Investigating cryptographic incidents and anomalies
Continuous compliance monitoring with runtime evidence
Security research and cryptographic protocol analysis

Learn more → | GitHub →

4) pqc-flow¶

Passive network traffic analyzer for PQC detection

Analyzes encrypted network flows to detect post-quantum cryptography support and negotiation in TLS 1.3, SSH, IKEv2, and QUIC protocols.

Key capabilities:

Passive inspection: Analyzes first-flight packets without payload decryption
PQC detection: Identifies ML-KEM, ML-DSA, and hybrid key exchange offers
Protocol support: TLS 1.3, DTLS, SSH, IKEv2, QUIC
Minimal data capture: Records handshake metadata only, not payload content
Real-time analysis: Stream processing for live network monitoring
Pcap integration: Works with existing packet capture infrastructure

Perfect for:

Assessing PQC adoption across enterprise network infrastructure
Monitoring quantum-safe migration progress at scale
Identifying devices still using quantum-vulnerable key exchange
Network security operations teams detecting cryptographic anomalies
Incident response teams investigating TLS/SSH connection issues

Learn more → | GitHub →

How They Work Together¶

Complete Cryptographic Visibility Workflow¶

Phase	Description
Phase 1: STATIC INVENTORY (Build/Deployment Time)	cbom-generator scans firmware, containers, VM images → Output: firmware-v2.1.cbom.json → Contains: All crypto libraries, certs, keys, configs → PQC Score: 35/100 (HIGH RISK) → Shows what COULD be used
Phase 2: VISUALIZATION & ANALYSIS	cbom-explorer loads firmware-v2.1.cbom.json → Interactive graph: Shows nginx → TLS 1.3 → AES-256-GCM → Dashboard: 47 quantum-vulnerable assets flagged → Report: Generated for compliance team → Identifies: Priority remediation targets
Phase 3: RUNTIME MONITORING (Production)	crypto-tracer monitors device for 24 hours → Captures: Actual OpenSSL function calls → Discovers: TLS 1.2 negotiated despite TLS 1.3 config pqc-flow analyzes network traffic → Detects: ClientHello offers ML-KEM, but server negotiates RSA → Records: 4,723 connections, 96% quantum-vulnerable
Phase 4: DRIFT DETECTION & REMEDIATION	Compare: firmware-v2.1.cbom.json (static) vs: runtime-observations.json (actual behavior) Finding: Configuration drift detected - nginx.conf: TLS 1.3 required (SSLProtocol TLSv1.3) - Runtime: 23% of connections negotiate TLS 1.2 - Root cause: Legacy load balancer allows protocol downgrade Action: Update load balancer config, verify with pqc-flow

Real-World Example: Automotive Tier-1 Supplier¶

Context: Manufacturing ECU firmware for 15-year vehicle lifespan

Step 1 - Build Phase: Generate CBOM during firmware compilation

cbom-generator \
    --cross-arch --discover-services --plugin-dir plugins/embedded  \
    --crypto-registry registry/crypto-registry-yocto.yaml \
    --format cyclonedx --cyclonedx-spec=1.7  \
    --output ecu-v3.2.cbom..json  --rootfs-prefix $ROOTFS\
        $ROOTFS/usr/bin $ROOTFS/usr/sbin $ROOTFS/usr/lib $ROOTFS/etc

Result: CBOM shows OpenSSL 3.0.2 with RSA-2048 and ECDHE-P256 configured

Step 2 - Pre-Release Review: Visualize cryptographic architecture

xdg-open visualizer/cbom-viz.html

in the browser open: ecu-v3.2.cbom.json

Insight: Dashboard shows PQC readiness score: 40/100 (HIGH RISK for 15-year lifespan)

Step 3 - Production Validation: Monitor deployed test fleet

# On test vehicle gateway
crypto-tracer --duration 7days --output fleet-crypto.json

# On test lab network
pqc-flow -i eth0 --filter "host ecu-gateway" --duration 7days

Discovery: Despite TLS 1.3 configuration: - 15% of dealer diagnostic connections still use TLS 1.2 - Root cause: Legacy scan tools from 2015 don't support TLS 1.3

Action: Document exception, plan dealer equipment upgrades, demonstrate compliance with runtime evidence

Why CipherIQ?¶

1. Built for Long-Lived Systems¶

Unlike general-purpose security scanners, CipherIQ is purpose-built for organizations managing infrastructure with decade-plus lifespans:

IoT/OT devices: 20-30 year operational lifetimes in the field
Medical devices: 10-15 year FDA-approved service periods
Automotive ECUs: 15-20 year vehicle lifespans
Industrial control systems: 25-30 year production equipment cycles
Critical infrastructure: 30+ year utility and telecommunications deployments

These systems cannot be easily updated and must be designed for quantum-resistance from day one.

2. Standards-Based, Ecosystem-Friendly¶

CipherIQ uses open standards to integrate seamlessly into existing workflows:

CycloneDX CBOM: Industry-standard format compatible with SBOM ecosystems
JSON output: Easy integration with SIEM, GRC, and vulnerability management tools
CI/CD plugins: Native Yocto, Buildroot, OpenWrt, Docker, and Kubernetes integrations

3. Privacy by Default¶

CipherIQ is designed for security teams who respect user privacy:

Never exposes secrets: Keys and passwords are hashed, not captured in plain text
Minimal data collection: Only cryptographic metadata, not payload content
GDPR/CCPA compliant: No personal data in CBOMs or runtime traces
On-premises deployment: All tools run locally, no data sent to cloud services

4. Open Source, Commercially Supported¶

GPL 3.0 licensed - All four tools are free and open source

Full-featured, production-ready code
No proprietary "enterprise-only" limitations
Community-driven development on GitHub
Transparent roadmap and feature requests

Commercial support available - For organizations requiring:

Professional SLA-backed support (email/Slack)
Custom scanner development and integration services
Compliance report templates (FDA, UN R155, IEC 62443, NIST)
Priority feature requests and bug fixes
Legal indemnification and warranties

Get Started¶

Try the Tools¶

Each tool has its own documentation with installation guides, tutorials, and examples:

Join the Community¶

GitHub Discussions: Ask questions, share use cases at github.com/orgs/CipherIQ/discussions
Issue Trackers: Report bugs or request features in individual repos as issues
Email: team@cipheriq.com

Commercial Support¶

For IoT/OT manufacturers and enterprises requiring professional support:

Email: sales@cipheriq.com

License¶

All CipherIQ tools are dual-licensed:

GPL 3.0 - Free for open-source and commercial use
Commercial license - Available with support, custom development, and compliance templates

See individual repositories for license details.