Enterprise Cryptographic Discovery & Analysis Tool (ECDAT)

1. Executive Snapshot

The Enterprise Cryptographic Discovery & Analysis Tool (ECDAT) is a specialized security and risk governance framework designed for the National Technical Research Organisation (NTRO) [PS]. Its core purpose is to systematically scan, discover, inventory, and analyze cryptographic primitives across enterprise software repositories, compiled binaries, third-party libraries, container images, hardware security modules (HSMs), and cloud service configurations [PS]. By cataloging cryptographic assets into a standardized OWASP CycloneDX 1.6 Cryptographic Bill of Materials (CBOM) [RESEARCHED], ECDAT calculates quantum vulnerability exposure using Mosca’s Theorem ($x + y > z$) [PS] and maps quantum-vulnerable algorithms (e.g., RSA, ECC, Diffie-Hellman) [KNOWN] to NIST-standardized Post-Quantum Cryptography (PQC) alternatives (FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA) [RESEARCHED]. The system provides an interactive web-based visualization dashboard and automated report generation engine to enable strategic, prioritized PQC migration for defense and critical national infrastructure [INFERENCE].

Fundamental System Objective:
To automatically scan enterprise application source code, binaries, container images, and infrastructure configurations to generate standardized CBOM reports, perform Mosca-driven quantum risk scoring, and deliver automated, context-aware PQC/hybrid migration recommendations via an interactive dashboard [PS].

2. Problem Deconstruction

The explicit problem statement provided by NTRO decomposes into the following explicit and derived atomic requirements:

• Explicit Requirement (i) - Multi-Layer Cryptographic Artefact Discovery & Cataloging: [PS]

  • Source Text: "Identify and catalogue all cryptographic artefacts (algorithms, keys, certificates, protocols, libraries, hardware modules, cloud services) across internal and external facing applications, products and infrastructure."
  • Interpretation: Scanner must inspect source code, compiled binaries, shared libraries (.so, .dll), container manifests, TLS/X.509 certificates, cloud service configs (AWS KMS, Azure Key Vault), and HSM parameters [INFERENCE].
  • Implementation Implication: Requires multi-engine parsing: Abstract Syntax Tree (AST) scanning for source code, symbol table and string extraction for compiled binaries, X.509 ASN.1 parsing for certificates, and API adapters for cloud key management [INFERENCE].
  • Confidence Tag: [PS]

• Explicit Requirement (ii) - Quantum Risk Assessment & Threat Highlighting: [PS]

  • Source Text: "The tool should perform a comprehensive quantum risk assessment and identify systems prone to potential quantum attacks, and highlight risks to sensitive data."
  • Interpretation: Must evaluate asymmetric encryption (RSA, ECC, ECDSA, DH) as highly vulnerable to Shor's Algorithm [KNOWN], symmetric ciphers (AES-128 vs AES-256) under Grover's Algorithm [KNOWN], and highlight "Harvest Now, Decrypt Later" (HNDL) exposure [RESEARCHED].
  • Implementation Implication: Build a rules engine mapping each primitive/key size to a quantum risk score (Vulnerable, Deprecated, Safe) and data exposure threat level [INFERENCE].
  • Confidence Tag: [PS]

• Explicit Requirement (iii) - Asset Classification & Mosca Framework Application: [PS]

  • Source Text: "Classify all the artefacts by type, lifetime and business criticality. Apply structured frameworks such as Mosca’s algorithm (compare data lifetime plus migration time against expected arrival of cryptographic relevant quantum computer) to identify and categorize risks."
  • Interpretation: Implement Mosca's inequality $x + y > z$, where $x$ = data shelf-life requirement, $y$ = system migration duration, and $z$ = estimated time to Cryptographically Relevant Quantum Computer (CRQC) [RESEARCHED].
  • Implementation Implication: Require metadata tags for business criticality ($1$-$5$) and data retention period ($x$), calculating urgency $U = (x + y) - z$ to rank remediation priorities [INFERENCE].
  • Confidence Tag: [PS]

• Explicit Requirement (iv) - PQC & Hybrid Migration Recommendation Engine: [PS]

  • Source Text: "Recommend suitable alternatives (PQC/ Hybrid algorithms) for applications based on risk profile, latency, cost, etc."
  • Interpretation: Provide specific replacement recommendations (e.g., replace RSA-3072 with FIPS 203 ML-KEM-768 or ML-KEM-1024, or hybrid ECDH + ML-KEM) accounting for performance overheads like key size expansion and execution latency [RESEARCHED].
  • Implementation Implication: Multi-criteria recommendation matrix weighing latency impact, signature/ciphertext size expansion, memory overhead, and security level [INFERENCE].
  • Confidence Tag: [PS]

• Explicit Requirement (Deliverable A) - Comprehensive CBOM Analytics & Multi-Artifact Scanning: [PS]

  • Source Text: "A Comprehensive CBOM analytics tool that can scan Source code repositories, binaries, libraries and container images, for assessing risks (due to quantum computers), classifying artefacts and suggesting alternatives."
  • Interpretation: Software must support direct Git URL ingestion, static local file directory analysis, binary artifact parsing (ELF, PE, Mach-O), and container image filesystem extraction (tar / OCI layer inspection) [INFERENCE].
  • Implementation Implication: Modular scanner architecture separating source AST analyzers, binary symbol extractors, container layer unpackers, and dependency tree aggregators [INFERENCE].
  • Confidence Tag: [PS]

• Explicit Requirement (Deliverable B) - Standardized Reporting: [PS]

  • Source Text: "Produce a report displaying all cryptographic assets including versions/ modes in standardised formats."
  • Interpretation: Export results in official OWASP CycloneDX 1.6 CBOM JSON/XML format [RESEARCHED] alongside summary executive PDFs and machine-readable SARIF/CSV logs [INFERENCE].
  • Implementation Implication: Standard JSON serialization conforming strictly to CycloneDX 1.6 cryptographic-asset taxonomy [RESEARCHED].
  • Confidence Tag: [PS]

• Explicit Requirement (Deliverable C) - Interactive GUI Platform: [PS]

  • Source Text: "Interactive GUI platform to visualise the scan, risks and results."
  • Interpretation: Web dashboard providing visual risk heatmaps, dependency graph visualization, Mosca urgency timelines, filterable asset inventory tables, and interactive recommendation cards [INFERENCE].
  • Implementation Implication: Single-Page Application (React/Next.js) consuming REST/gRPC backend APIs [INFERENCE].
  • Confidence Tag: [PS]

3. Stakeholders & User Needs

4. Requirements Traceability

5. Constraints & Environment Realities

Because NTRO is a national technical intelligence agency, the operational environment introduces strict non-functional constraints:

• Air-Gapped & Restricted Networks: Defense and intelligence infrastructure operates in isolated environments [INFERENCE]. The tool cannot rely on external SaaS APIs, internet-based LLMs, or cloud-hosted database lookups [INFERENCE]. All scanning, AST parsing, and vulnerability databases must function 100% offline [INFERENCE].
• Heterogeneous Target Architecture: Target systems range from modern cloud-native microservices (Go, Rust, Python, Node.js) to legacy defense C/C++ embedded binaries (x86_64, ARM64, MIPS) [INFERENCE]. The scanner must handle both high-level source code and low-level binary artifacts [PS].
• Performance & Memory Limits: Enterprise codebases and container images can exceed several gigabytes [KNOWN]. The scanner must utilize streaming AST parsers, regex optimization, and multi-threaded file indexing to prevent out-of-memory (OOM) crashes on standard developer workstations [INFERENCE].
• Zero Code Execution Policy: Scanning must be non-intrusive (static analysis) [INFERENCE]. Executing untrusted target binaries or container scripts during scanning presents severe malware/security risks [KNOWN].
• Multi-Language & Custom Crypto: Systems often combine standard libraries (OpenSSL, BouncyCastle, PyCryptodome) with custom, wrapped, or in-house cryptographic implementations [RESEARCHED].

6. Research Questions

1. Standardization: How does OWASP CycloneDX 1.6 structure the cryptographic-asset taxonomy, including algorithms, keys, certificates, and dependencies? [RESEARCHED]
2. PQC Standards: What are the exact performance parameters, key sizes, and ciphertext expansion ratios of NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA)? [RESEARCHED]
3. Mosca Variables: What are realistic operational values for migration duration ($y$) and time-to-quantum ($z$) across enterprise government systems? [INFERENCE]
4. Binary Analysis: What static analysis techniques (symbol tables, string extraction, byte pattern matching) effectively identify compiled cryptographic routines without requiring disassembly decompilation suites like Ghidra/IDA Pro? [RESEARCHED]
5. Language AST Support: Which tree-sitter or ANTLR parsers provide cross-language AST extraction for C/C++, Java, Python, Go, Rust, and JavaScript? [RESEARCHED]

7. Data Requirements & Sources

Categorization of Required Data

• A. Data Explicitly Mentioned: Source code repositories, binaries, libraries, container images [PS].
• B. Data Required by Inference: NIST PQC algorithm specifications (FIPS 203/204/205), CycloneDX 1.6 CBOM schema, Mosca equation parameters ($x, y, z$) [INFERENCE].
• C. Data That Must Be Collected: Static pattern definitions for major crypto libraries across C, Java, Python, Go, Node.js, and C# [ASSUMPTION].
• D. Data That Can Be Synthetically Generated: Vulnerable test codebases, synthetic X.509 test certificates, pre-built mock container .tar files [ASSUMPTION].
• E. Data That Still Needs Validation: Real-world enterprise latency overhead benchmarks for hybrid PQC primitives under high network load [NEEDS VALIDATION].

8. Existing Solutions & Gap Analysis

9. Candidate Solution Approaches

Approach 1: Lightweight Regex & Shell Script Rule Engine

• Mechanism: CLI tool using optimized regular expressions (ripgrep / grep rules) to search source code files and binary text strings for cryptographic keywords (e.g., RSA_generate_key, AES_cbc_encrypt, SHA1_Init).
• Required Data: JSON file containing ~200 regex rules for crypto functions.
• Architecture: Scriptable Python CLI producing static HTML reports.
• Evaluation:
  • Problem Fit: Low. Misses semantic context, leading to massive false positives (e.g., comments, variable names, non-crypto functions) [INFERENCE].
  • Complexity: Very Low.
  • Cost: Zero.
  • Hackathon Feasibility: High (Can be built in 1 day).
  • Production Feasibility: Poor (Cannot handle complex enterprise binaries, container layers, or structured ASTs).

Approach 2: Multi-Engine Static Analyzer + CBOM Builder + Mosca Engine + Web Dashboard (RECOMMENDED)

• Mechanism: Combined static analyzer using Tree-Sitter AST parsing for source code, PE/ELF/Mach-O symbol & string extraction for binaries, Docker layer unpacking for containers, and an offline Mosca Risk & PQC Optimization Engine.
• Required Data: AST tree patterns for 6 major languages, binary symbol signatures (OpenSSL, Libsodium, CNG), NIST PQC lookup table, CycloneDX 1.6 schema.
• Architecture:
  1. Modular Core Engine in Rust/Go or Python (multi-threaded file crawler & AST analyzer).
  2. Analytical Risk Layer applying Mosca's Equation ($x + y > z$) and NIST PQC mapping.
  3. Export Layer producing OWASP CycloneDX 1.6 JSON & PDF reports.
  4. Frontend GUI in React/Next.js with interactive dependency graphs and risk heatmaps.
• Evaluation:
  • Problem Fit: Excellent. Fully satisfies requirements (i), (ii), (iii), (iv), and deliverables A, B, C [PS].
  • Complexity: Medium-High.
  • Cost: Low (Open-source stack).
  • Hackathon Feasibility: High for a 4-6 student team dividing backend/frontend responsibilities.
  • Production Feasibility: Excellent (Scalable, air-gappable, deterministic).

Approach 3: Deep LLM Code Analysis + Dynamic Runtime Agent Sniffing

• Mechanism: Embeds a local Large Language Model (e.g., Llama-3-8B) to read source code lines and infer cryptographic usage, combined with eBPF runtime tracing on live Linux containers.
• Required Data: Massive fine-tuning dataset of code snippets and eBPF kernel probes.
• Architecture: Heavy Python backend requiring high-end GPU hardware (e.g., NVIDIA RTX 4090 / A100) for local LLM inference.
• Evaluation:
  • Problem Fit: Moderate, but overly complex and non-deterministic [INFERENCE].
  • Complexity: Extremely High.
  • Cost: High (Requires expensive GPU hardware for offline execution).
  • Hackathon Feasibility: Very Low (LLM fine-tuning and eBPF kernel instrumentation are unreliable in short hackathons).
  • Production Feasibility: Poor (High latency, high memory requirement, risk of LLM hallucinations in security reports) [INFERENCE].

10. Recommended Approach & Why

We select Approach 2 (Multi-Engine Static AST/Binary Scanner + CycloneDX 1.6 CBOM + Mosca Risk Engine + Interactive GUI Dashboard).

Why Alternatives Were Rejected:

• Approach 1 (Regex Scripting) was rejected because simple pattern matching produces high false-positive rates (flagging comments, dead code, test mocks) and cannot parse container image layers or structured AST semantics [INFERENCE].
• Approach 3 (LLM + eBPF) was rejected because defense agencies require 100% deterministic, auditable, and reproducible static scanning [INFERENCE]. LLMs introduce non-deterministic hallucination risks (e.g., misidentifying key lengths or inventing non-existent algorithms) [INFERENCE]. Furthermore, dynamic eBPF tracing requires active code execution, violating the zero-execution safety constraint for untrusted binaries [INFERENCE].

11. Technical Architecture

Layered Architecture Diagram

+-----------------------------------------------------------------------------------+
|                            INTERACTIVE GUI DASHBOARD                              |
|   (React / Next.js / TailwindCSS / Lucide Icons / Recharts / React Flow Graphs)  |
|   - Executive Heatmap | Mosca Urgency Timeline | CBOM Viewer | Migration Cards |
+-----------------------------------------------------------------------------------+
                                         ^
                                         | REST APIs / JSON WS
                                         v
+-----------------------------------------------------------------------------------+
|                               API & ORCHESTRATION LAYER                           |
|   (FastAPI / Python 3.12 - Async Task Queue / SQLite Storage / PDF Generator)     |
+-----------------------------------------------------------------------------------+
        |                                |                                  |
        v                                v                                  v
+------------------+    +----------------------------------+    +-------------------+
| MOSCA RISK ENGINE|    | PQC RECOMMENDATION MATRIX ENGINE |    |  CBOM FORMATTER   |
| Urgency =        |    | - NIST FIPS 203/204/205 Mapping  |    | - CycloneDX 1.6   |
|  (x + y) - z     |    | - Latency vs Key Size Tradeoff   |    |   JSON Schema     |
+------------------+    +----------------------------------+    +-------------------+
        ^                                ^                                  ^
        +--------------------------------+----------------------------------+
                                         | Normalized Asset Stream
+-----------------------------------------------------------------------------------+
|                        MULTI-ARTIFACT DISCOVERY SCAN ENGINE                       |
|                                                                                   |
|  +--------------------+  +--------------------+  +-----------------------------+  |
|  | Source Code AST    |  | Binary & Library   |  | Container & Certificate     |  |
|  | Parser             |  | Inspector          |  | Extractor                   |  |
|  | (Tree-Sitter /     |  | (pyelftools /      |  | (tarfile / OCI Inspector /  |  |
|  |  Python AST)       |  |  pefile / strings) |  |  cryptography ASN.1 cert)   |  |
|  +--------------------+  +--------------------+  +-----------------------------+  |
|           |                        |                            |                 |
+-----------+------------------------+----------------------------+-----------------+
                                         ^
                                         | File Systems / Git Clones
+-----------------------------------------------------------------------------------+
|                              TARGET ARTIFACT SOURCES                              |
|  - Git Repositories (.git) | Source Directories (C/C++, Java, Py, Go, JS, Rust)  |
|  - Compiled Binaries (.elf, .exe, .so, .dll) | Container TARs (Docker/OCI)        |
|  - Certificate Bundles (.pem, .crt) | Cloud/HSM Configs (Terraform, YAML)          |
+-----------------------------------------------------------------------------------+

Data-Flow Narrative

1. Target Ingestion: The user submits a target via the GUI or CLI (e.g., local directory path, Git repository URL, container .tar file, or .so/.dll binary).
2. Multi-Artifact Discovery:
   • Source Code: The Tree-Sitter AST engine parses syntax trees for function calls (e.g., RSA_public_encrypt, Cipher.getInstance("AES/CBC/PKCS5Padding")).
   • Binaries: pyelftools/pefile inspect import tables, dynamic symbol tables, and embedded string constants for cryptographic signatures.
   • Containers: Unpacks OCI/Docker filesystem layers in memory, running binary and certificate extractors on contained binaries.
   • Certificates: Parses X.509 ASN.1 structure to extract public key type, key size, signature algorithm, and expiration date.
3. Normalization & Metadata Enrichment: Scanned findings are converted into a standardized CryptoAsset object containing primitive type, implementation library, file location, key length, and operational context.
4. Mosca Risk Assessment Engine: Computes $U = (x + y) - z$.
   • $x$ (Data Lifetime): Extracted from metadata tags or default policy (e.g., Top Secret = 25 years).
   • $y$ (Migration Time): Calculated based on system complexity score (e.g., 3 years).
   • $z$ (Time to CRQC): Fixed baseline standard estimate (e.g., 10 years / ~2035) [ASSUMPTION].
5. PQC Recommendation Matrix Engine: Maps vulnerable primitives to FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), or FIPS 205 (SLH-DSA). Evaluates latency and key size trade-offs.
6. Output Generation: Formats the dataset into OWASP CycloneDX 1.6 CBOM JSON schema [RESEARCHED], generates executive PDF summaries, and streams data to the React GUI.

12. Technology Stack

13. AI/ML Justification

Deterministic Rule Engine vs. AI/ML Analysis

• Core Scanning & CBOM Generation (NO AI NEEDED):
  Deterministic AST parsing and binary symbol matching MUST NOT use LLMs or machine learning models [INFERENCE]. Static regex/AST rule evaluation is 100% accurate, fast, deterministic, and leaves zero room for model hallucinations [INFERENCE].

• Where Machine Learning / Heuristics ADD VALUE (OPTIONAL ENHANCEMENT):

  1. Contextual Custom Crypto Classifier: A lightweight Random Forest or Naive Bayes classifier trained on code N-grams to detect custom/wrapped cryptographic routines in un-annotated C/C++ source files (e.g., custom bit-shift XOR schedules or proprietary mathematical loops) [INFERENCE].
  2. PQC Multi-Criteria Decision Optimizer: A linear programming / fuzzy decision matrix algorithm that ranks alternative PQC algorithms based on application constraints (minimizing key size expansion vs. minimizing signing latency) [INFERENCE].

Detailed AI Component Evaluation (Custom Crypto Classifier)

1. Purpose: Identify custom/proprietary cryptographic implementations that do not invoke standard library APIs [INFERENCE].
2. Model Type: Scikit-Learn TF-IDF + Random Forest Classifier (offline execution) [ASSUMPTION].
3. Input: Source code token sequences (function blocks).
4. Output: Probability score that the function contains custom cryptographic math ($0.0 - 1.0$).
5. Data Required: Open-source code samples of standard math vs cryptographic math implementations.
6. Why AI is Preferable: Hand-written rules struggle to catch obfuscated or non-standard custom arithmetic loops [INFERENCE].
7. Evaluation: Precision, Recall, and F1-score on benchmark cryptographic implementations.
8. Failure Mode Handling: If probability is between $0.4$ and $0.7$, tag as "Potential Custom Crypto - Requires Manual Verification" [INFERENCE].
9. Human Oversight: Security analyst must manually review flagged custom crypto instances [PS].

14. Data Architecture & Offline/Low-Network Design

Database Schema (SQLite / Relational Model)

-- Target Scan Jobs
CREATE TABLE scan_jobs (
    id TEXT PRIMARY KEY,
    target_name TEXT NOT NULL,
    target_type TEXT CHECK(target_type IN ('SOURCE_REPO', 'BINARY', 'CONTAINER', 'CERTIFICATE')),
    status TEXT NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    mosca_x_years INTEGER DEFAULT 10,
    mosca_y_years INTEGER DEFAULT 3,
    mosca_z_years INTEGER DEFAULT 10
);

-- Discovered Cryptographic Assets (CBOM Elements)
CREATE TABLE crypto_assets (
    id TEXT PRIMARY KEY,
    scan_job_id TEXT FOREIGN KEY REFERENCES scan_jobs(id),
    asset_name TEXT NOT NULL,          -- e.g., "RSA-2048", "AES-128-CBC"
    asset_type TEXT NOT NULL,          -- ALGORITHM, KEY, CERTIFICATE, PROTOCOL, LIBRARY
    primitive_family TEXT,             -- ASYMMETRIC_ENCRYPTION, SYMMETRIC_ENCRYPTION, HASH
    implementation_library TEXT,       -- e.g., "OpenSSL 1.1.1k", "Java Cipher"
    file_path TEXT NOT NULL,
    line_number INTEGER,
    key_length INTEGER,
    quantum_risk_level TEXT CHECK(quantum_risk_level IN ('CRITICAL', 'HIGH', 'MEDIUM', 'SAFE')),
    mosca_urgency_score REAL,
    pqc_recommendation TEXT
);

Offline & Low-Network Strategy

• Zero External Network Calls: The engine ships with all AST patterns, NIST benchmark databases, and CycloneDX validation schemas embedded locally in assets/rules/ [INFERENCE].
• Local Caching: Target repositories and unpacked container layers are cached in /tmp/ecdat_cache and purged after scan completion to ensure data privacy [INFERENCE].
• Bandwidth Reduction: Remote Git repositories can be scanned using shallow clones (git clone --depth 1) to minimize bandwidth consumption during high-latency connections [INFERENCE].

15. Security, Privacy & Governance

• Data Isolation & Air-Gap Compliance: The scanner runs completely on local host resources [INFERENCE]. No source code snippets, file names, or vulnerability metrics are ever transmitted across external networks [INFERENCE].
• Credential & Secret Safety: The scanner specifically ignores cleartext secret values (e.g., private key bytes) during report generation [INFERENCE]. CBOM reports catalog key types, sizes, and metadata—NEVER raw private key material [RESEARCHED].
• False Positive / False Negative Handling:
  • False Positives: Test mocks or documentation comments flagging crypto APIs are filtered out by AST node validation (ensuring the pattern resides inside an executable Call Expression, not a Comment node) [INFERENCE].
  • False Negatives: Static analysis cannot resolve runtime dynamic reflection (e.g., Java Class.forName()). The report explicitly flags dynamic reflection instances as [NEEDS MANUAL AUDIT] [INFERENCE].
• Regulatory Alignment: Aligns with NIST SP 800-208, NIST FIPS 203/204/205 standards, and OWASP CycloneDX 1.6 CBOM requirements [RESEARCHED].

16. MVP Scope (Hackathon Build)

In Scope (MUST BUILD & DEMO)

• Static AST Source Code Scanner: Supports Python, C/C++, Java, and Go source files [ASSUMPTION].
• Binary & Certificate Inspector: ELF binary string/symbol scanner and X.509 certificate file parser [ASSUMPTION].
• Mosca Quantum Risk Engine: Implementation of $U = (x + y) - z$ with configurable slider parameters [PS].
• NIST PQC Mapper: Automatic lookup mapping RSA/ECC/DH to FIPS 203 ML-KEM and FIPS 204 ML-DSA [PS].
• CycloneDX 1.6 Exporter: Direct export of scan results to valid CycloneDX 1.6 CBOM JSON [Deliverable B].
• Interactive Web Dashboard: React GUI showing total assets, quantum risk score, filterable asset table, and export buttons [Deliverable C].

Described Only / Out of Scope (PRODUCTION FUTURE)

• Dynamic eBPF runtime kernel tracing [INFERENCE].
• Live AWS KMS / Azure Key Vault / Cloud HSM API network discovery adapters [INFERENCE].
• Automated pull-request generation for refactoring legacy crypto calls [INFERENCE].
• Scanning obscure legacy assembly language binaries (e.g., 16-bit x86 or mainframe code) [INFERENCE].

17. Live Demo Simulation Plan

To deliver a compelling 10-minute SIH live evaluation demo without relying on external cloud APIs or classified government code, the team will present three simulated target environments:

1. Target 1: Legacy Vulnerable Enterprise Backend (/demo/vulnerable-app)

   • Content: Synthetic Java/Spring + C++ codebase containing hardcoded RSA-2048 key generation, SHA-1 hashing, AES-128-ECB mode, and expired X.509 certificates.
   • Demo Outcome: Real-time scan completes in <3 seconds. Dashboard highlights CRITICAL QUANTUM RISK, displays Mosca urgency threshold violation, and generates replacement cards recommending ML-KEM-768 and SHA-256/SHA-3 [INFERENCE].

2. Target 2: Modern PQC-Ready Microservice (/demo/pqc-app)

   • Content: Synthetic Go/Rust application utilizing liboqs bindings with ML-KEM-768 key encapsulation and ML-DSA-65 digital signatures [RESEARCHED].
   • Demo Outcome: Scanner classifies assets as QUANTUM SAFE, showing zero Mosca risk alerts [INFERENCE].

3. Target 3: Container Image TAR Archive (/demo/app-container.tar)

   • Content: Packed OCI tar archive containing an old Ubuntu base image with legacy OpenSSL 1.0.2 dynamic shared libraries (libcrypto.so.1.0.0) [RESEARCHED].
   • Demo Outcome: Binary engine unpacks layers, detects compiled symbol signatures, and catalogs outdated dynamic library dependencies in the CycloneDX 1.6 CBOM output [INFERENCE].

18. Implementation Roadmap

Target Deadline: 30 September 2026 [PS].

+-----------------------------------------------------------------------------------+
| AUG 15 - AUG 25 | PHASE 1: CORE PARSING & RULES ENGINE                            |
| - Build Tree-Sitter AST parsers for Python, C/C++, Java, Go                      |
| - Build ELF/PE binary string inspector & X.509 cert parser                        |
| - Define JSON crypto signature database (~150 patterns)                           |
+-----------------------------------------------------------------------------------+
                                         |
                                         v
+-----------------------------------------------------------------------------------+
| AUG 26 - SEP 05 | PHASE 2: MOSCA & PQC RECOMMENDATION ENGINE                      |
| - Implement Mosca equation U = (x + y) - z logic with parameter config            |
| - Implement NIST FIPS 203/204/205 recommendation matrix                           |
| - Implement OWASP CycloneDX v1.6 CBOM JSON serializer                             |
+-----------------------------------------------------------------------------------+
                                         |
                                         v
+-----------------------------------------------------------------------------------+
| SEP 06 - SEP 15 | PHASE 3: FASTAPI BACKEND & REACT GUI DASHBOARD                  |
| - Develop REST API endpoints (/scan, /reports, /cbom, /config)                    |
| - Build React/Next.js UI: Asset Table, Risk Gauges, Dependency Graph              |
| - Integrate PDF report generation engine (ReportLab)                              |
+-----------------------------------------------------------------------------------+
                                         |
                                         v
+-----------------------------------------------------------------------------------+
| SEP 16 - SEP 25 | PHASE 4: SYSTEM INTEGRATION, DEMO PREP & TESTING                |
| - Run synthetic target testing (vulnerable vs PQC codebases, binary .so files)    |
| - Execute false positive reduction tuning                                         |
| - Validate CycloneDX 1.6 JSON against official OWASP schema                       |
+-----------------------------------------------------------------------------------+
                                         |
                                         v
+-----------------------------------------------------------------------------------+
| SEP 26 - SEP 30 | PHASE 5: FINAL PACKAGING, HARDENING & JUDGING PRESENTATION    |
| - Freeze code, build single-executable installer / Docker bundle                  |
| - Practice 10-minute SIH live pitch and interactive demo                          |
+-----------------------------------------------------------------------------------+

19. Testing & Validation Plan

• Functional Testing:
  • Verify AST parser correctly detects RSA_private_decrypt across C/C++ source files.
  • Verify binary inspector uncovers hidden string/symbol signatures in compiled .so files.
  • Verify CycloneDX 1.6 JSON output validates against official OWASP JSON Schema [RESEARCHED].
• False Positive / False Negative Validation:
  • Test Set: 20 open-source repositories (e.g., OpenSSL, Flask, Redis) mixed with test mock files containing commented-out crypto code.
  • Target Accuracy: $>90%$ precision (minimal false positives on comment nodes) [ASSUMPTION].
• Performance Testing:
  • Scan 100,000 lines of code (LOC) in under 10 seconds on a standard dual-core laptop [ASSUMPTION].
• Offline Validation:
  • Disable all network interfaces (airplane mode) and execute full scan, report generation, and GUI rendering to guarantee air-gap compliance [INFERENCE].

20. Risk Register

21. Cost & Scalability

Hackathon Environment Cost: ₹0 / $0

• Uses 100% open-source libraries (FastAPI, Tree-Sitter, pyelftools, React, SQLite).
• Runs locally on student laptops without requiring paid cloud infrastructure or paid AI API keys [INFERENCE].

Production Enterprise Deployment

• Infrastructure: Air-gapped enterprise server (8-core CPU, 32GB RAM, 500GB NVMe SSD) estimated at ~$3,000 one-time hardware cost [ASSUMPTION].
• Software Licensing: $0 (Fully open-source core stack).
• Scalability: Multi-worker task processing architecture using Celery/Redis queue can scale horizontally across multiple enterprise build pipelines and CI/CD agents [INFERENCE].

22. Differentiation

23. Future Scope

1. Automated Code Refactoring (Auto-Remediation): Generate automated Git Pull Requests with code patches replacing legacy OpenSSL/Java crypto calls with PQC wrapper libraries [INFERENCE].
2. IDE Extensions (VS Code / JetBrains): Real-time inline cryptographic linting that warns developers as soon as they write insecure asymmetric crypto calls [INFERENCE].
3. Hardware Security Module (HSM) Live Discovery: Integration with PKCS#11 interfaces to query physical HSM slot configurations and active key inventories [INFERENCE].

24. Assumptions & Open Items Log

Consolidated [ASSUMPTION] Items

1. Assumed tree-sitter AST parsers for C/C++, Java, Python, and Go cover $>90%$ of enterprise codebases [ASSUMPTION].
2. Assumed default Mosca parameters: Data Lifetime $x = 10$ years, Migration Time $y = 3$ years, Time to CRQC $z = 10$ years (~2035) [ASSUMPTION].
3. Assumed SQLite is sufficient for single-host desktop/CLI scan persistence during the hackathon phase [ASSUMPTION].

Consolidated [NEEDS VALIDATION] Items

1. Real-world execution latency overhead of hybrid ML-KEM + ECDH key exchange under high throughput enterprise network traffic [NEEDS VALIDATION].
2. Specific internal HSM PKCS#11 API versions used across NTRO operational infrastructure [NEEDS VALIDATION].

Final Recommendation

Build Approach 2: A hybrid static multi-layer scanner (Tree-Sitter AST for source code + pyelftools/pefile for binaries + container TAR unpacker) coupled with an offline Mosca Quantum Risk Engine, NIST FIPS 203/204/205 recommendation matrix, OWASP CycloneDX 1.6 CBOM serializer, and a modern React web dashboard.

Recommended Stack

• Frontend: React 18 / Next.js, Tailwind CSS, React Flow, Recharts.
• Backend: FastAPI (Python 3.12), SQLAlchemy, SQLite.
• Scanners: Tree-Sitter (AST), pyelftools (ELF), pefile (PE), cryptography (X.509).
• Standards: OWASP CycloneDX 1.6 CBOM Schema (ECMA-424).

Biggest Dependency

Accurate, comprehensive AST and binary signature rules for standard cryptographic libraries (OpenSSL, Libsodium, Java Cryptography Architecture, PyCryptodome, Go crypto/*).

Biggest Risk

High false-positive rates caused by finding cryptographic terms in non-executable code (e.g., test mocks, documentation comments, non-crypto variable names).

Biggest Technical Challenge

Unpacking and parsing stripped binary files and nested container image layers without executing target code or using heavy decompiler suites like Ghidra.

First 5 Actions

1. Initialize Git repository with FastAPI backend structure and React/Next.js frontend template.
2. Download and validate the OWASP CycloneDX v1.6 CBOM JSON Schema.
3. Build the static Tree-Sitter AST parser module for Python, Java, and C/C++.
4. Implement the Mosca Inequality calculation script ($U = (x + y) - z$) and NIST FIPS 203/204 lookup table.
5. Assemble synthetic test repositories containing known vulnerable crypto (RSA-2048, SHA-1) and safe PQC code (ML-KEM) for benchmarking.

Validation Before Coding

Verify that the local Python environment successfully compiles tree-sitter language grammars for C, C++, Java, and Python without C-compiler runtime missing errors.

Buildability Score /100

92 / 100
(Highly buildable by a 4-6 student team in the available timeframe using Python static analysis libraries and React UI components).

Confidence

HIGH — The problem statement is well-defined, standard specs (CycloneDX 1.6, NIST FIPS 203/204/205) are fully public, and all required tools are available as open-source libraries.

Research Sources

1. OWASP CycloneDX 1.6 Cryptographic Bill of Materials (CBOM) Specification
   URL: https://cyclonedx.org/capabilities/cbom/ [1.3]
   Type: Official Security Standard
   Supported Claim: CycloneDX 1.6 (ECMA-424) defines the standardized schema for cataloging cryptographic assets (cryptographic-asset).
   Reliability: Authoritative / Official Standard.

2. NIST Post-Quantum Cryptography Finalized Standards (FIPS 203, 204, 205)
   URL: https://csrc.nist.gov/news/2024/postquantum-cryptography-fips-approved [2.1]
   Type: Government Standards Body
   Supported Claim: Finalized PQC standards published in August 2024 specify ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205).
   Reliability: Authoritative Government Source.

3. Mosca's Theorem & Post-Quantum Readiness Framework
   URL: https://postquantum.com/post-quantum/moscas-theorem/ [3.2]
   Type: Industry Cybersecurity Research
   Supported Claim: Defines Mosca's inequality $x + y > z$ comparing data lifetime ($x$) plus migration time ($y$) against time to quantum computing ($z$).
   Reliability: Well-established Industry Standard.

4. PQCA CBOMkit & Sonar-cryptography Project
   URL: https://pqca.org/blog/2025/pqca-announces-cbomkit-advanced-tools-for-generating-and-analyzing-cryptographic-bills-of-materials/ [4.7]
   Type: Open Source Foundation Announcement
   Supported Claim: Validates existing open-source approaches and tools for CBOM generation from source repositories.
   Reliability: Reputable Open Source Foundation.

5. CryptoScan Open-Source Cryptographic Scanner
   URL: https://github.com/csnp/cryptoscan [4.2]
   Type: Open Source Software Repository
   Supported Claim: Demonstrates pattern-matching approach for detecting crypto primitives and mapping quantum risk across repositories.
   Reliability: Public Open Source Project.