Scanner-Architektur
Scanner-Architektur
Der DuoKey PQC Scanner ist ein natives Rust-CLI-Tool, das auf Tokio, Clap und Rustls aufbaut. Er wird als einzelne Binärdatei mit 10 Scan-Befehlen ausgeliefert, mit paralleler Ausführung über Rayon und Ausgabe in den Formaten JSON, YAML, HTML, ANSI-Terminal und CycloneDX CBOM.
PQC-Scanner-Architektur
Hochleistungsfähige Rust-CLI für die Erkennung und Risikobewertung post-quantenkryptografischer Verfahren
Infrastruktur-Scanner
Async I/OErweiterte Scanner
ErweiterbarPQC-Bereitschaftsbewertung
Vollständiges kryptografisches Inventar mit Quantenanfälligkeits-Bewertung und Migrationsfahrplan
Übergeordneter Datenfluss
Jeder Scan durchläuft dieselbe fünfstufige Pipeline, vom CLI-Aufruf bis zur Berichtsausgabe.
CLI-Parsing (clap 4.5)
Der Benutzer ruft einen von 10 Unterbefehlen auf (filesystem, domain, agent, network, serve, ci, sourcecode, compliance, servicenow, cbom). Clap parst Argumente, validiert Eingaben und leitet an den entsprechenden Scanner weiter.
Scanner-Ausführung
Der ausgewählte Scanner erfasst rohe kryptografische Daten – TLS-Handshakes, Zertifikatsdateien, Quellcodemuster, Cloud-KMS-Metadaten oder SSH-Hostschlüssel. Scanner verwenden Tokio für asynchrone I/O und Rayon für CPU-parallele Dateidurchläufe.
Parser-Schicht (PEM / DER / PKCS#12)
Rohdaten werden formatspezifischen Parsern für PEM, DER, PKCS#12, den Windows-Zertifikatspeicher und CBOM zugeführt, die Zertifikatsmetadaten, Schlüsselalgorithmen und Signaturschemata mithilfe der Crates x509-parser und schannel extrahieren.
Risikobewertung (0-10)
Jeder geparste Fund durchläuft die Risikobewertungs-Engine, die eine Quantum-Risikobewertung von 0 bis 10 zuweist, sie einem Schweregrad (Critical bis Info) zuordnet, eine Priorität (P0 bis P4) vergibt und menschenlesbare Begründungen und Empfehlungen generiert.
Ausgabeformatierung
Das bewertete ScanResult wird vom gewählten Ausgabeformatter serialisiert – JSON, YAML, HTML, ANSI-Terminal oder CycloneDX 1.7 CBOM – und in eine Datei oder nach stdout geschrieben.
Der Binär-Einstiegspunkt initialisiert eine asynchrone Tokio-Laufzeit mit dem tracing-Subscriber für strukturierte Protokollierung. Alle Scanner-Operationen sind async-first, wobei CPU-gebundenes Parsing an Rayon-Thread-Pools ausgelagert wird.
Modulhierarchie
Der Scanner ist in eine Reihe fokussierter funktionaler Bereiche gegliedert, jeder mit einer einzigen Verantwortung.
| Bereich | Verantwortung |
|---|---|
| CLI | 10 Clap-Unterbefehle – filesystem, domain, agent, network, serve, ci, sourcecode, compliance, servicenow, cbom |
| Core | Zentrale Datenstrukturen (Finding, ScanResult, RiskAssessment) und Quantum-Risikobewertungs-Engine |
| Scanner | Datensammler für Filesystem, Domain/TLS, Agent, Netzwerk, Quellcode, Cloud KMS, SSH, Fortinet, Paketerfassung, Subdomain |
| Parser | Formatparser für PEM, DER, PKCS#12, Windows-Zertifikatspeicher (schannel), CycloneDX CBOM |
| Output | Berichtsgeneratoren – JSON, YAML, ANSI-Terminal, HTML, CycloneDX-1.7-CBOM-Export |
| Server | Axum-0.7-Webserver mit REST-API, WebSocket-Unterstützung und Authentifizierung (OIDC / API-Schlüssel) |
| Compliance | 8+ Compliance-Frameworks, Gap-Analyse und Berichtserstellung (HTML/PDF/JSON) |
| Integrationen | ServiceNow-REST-API mit automatischen Incidents und CMDB-Synchronisierung; JFrog-Artifactory-Integration |
| Konfiguration | Authentifizierungsmodi, CORS, Ratenbegrenzung und Eingabevalidierung |
| Entrypoint | Asynchroner Tokio-Einstiegspunkt, Tracing-Initialisierung, CLI-Weiterleitung |
CLI-Befehle
Die CLI ist mit Clap-4.5-Derive-Makros aufgebaut. Jeder Unterbefehl ist einem dedizierten Scanner oder Dienst zugeordnet.
| Befehl | Beschreibung |
|---|---|
| filesystem | Lokale Pfade nach Zertifikaten und Keystores durchsuchen (PEM, DER, PKCS#12, JKS) |
| domain | Über Rustls mit TLS-Endpunkten verbinden und Handshakes, Cipher-Suites und Zertifikate untersuchen |
| agent | Systemweites kryptografisches Inventar – Zertifikate, Keystores, SSH-Schlüssel, Cloud KMS |
| network | Passive Netzwerkaufzeichnung für kryptografischen Datenverkehr (noch nicht implementiert) |
| serve | Den Axum-Webserver starten, der REST-API- und WebSocket-Endpunkte bereitstellt |
| ci | CI/CD-Pipeline-Modus mit SARIF-Ausgabe für GitHub Actions, GitLab CI und Azure DevOps |
| sourcecode | Statische Analyse mit 150+ Erkennungsregeln in 8 Programmiersprachen |
| compliance | Compliance-Prüfungen gegen 8+ regulatorische Frameworks durchführen und Gap-Analyse erstellen |
| servicenow | Funde an ServiceNow übertragen – Incidents automatisch erstellen und mit CMDB synchronisieren |
| cbom | CycloneDX-1.7-Cryptographic-Bill-of-Materials parsen oder generieren |
Zentrale Datenstrukturen
Alle Scan-Ergebnisse teilen sich dasselbe Datenmodell. Dies gewährleistet eine einheitliche Ausgabe unabhängig davon, welcher Scanner die Daten erzeugt hat.
Ein Finding repräsentiert ein einzelnes kryptografisches Asset, das während eines Scans entdeckt wurde.
| Feld | Typ | Beschreibung |
|---|---|---|
| id | String | Eindeutiger Bezeichner für den Fund |
| finding_type | Enum | Certificate, Keystore, Key, ConfigFile oder SshKey |
| source | String | Welcher Scanner diesen Fund erzeugt hat |
| location | String | Dateipfad, URL oder Hostname, an dem das Asset gefunden wurde |
| certificate | Option<CertificateInfo> | Geparste Zertifikatsmetadaten (Subject, Issuer, Algorithmus, Schlüsselgröße, Gültigkeit) |
| keystore | Option<KeystoreInfo> | Keystore-Format und enthaltene Einträge |
| risk_assessment | RiskAssessment | Quantum-Anfälligkeitsbewertung und Empfehlungen |
| tls_info | Option<TlsInfo> | TLS-Protokollversion, Cipher-Suite und Handshake-Details |
Jeder Fund wird von der Risikobewertungs-Engine auf Quantum-Anfälligkeit bewertet.
| Feld | Typ | Beschreibung |
|---|---|---|
| quantum_vulnerable | bool | Ob das Asset Algorithmen verwendet, die von Quantencomputern gebrochen werden können |
| quantum_risk_score | f64 (0-10) | 0 = kein Risiko (reines PQC), 10 = maximales Risiko (RSA-1024, DSA-1024) |
| severity | Enum | Critical, High, Medium, Low oder Info |
| priority | Enum | P0 (sofort), P1 (dringend), P2 (geplant), P3 (überwachen), P4 (informativ) |
| reasons | Vec<String> | Menschenlesbare Erklärungen für die zugewiesene Bewertung |
| recommendations | Vec<String> | Umsetzbare Schritte zur Behebung der Schwachstelle |
Risikobewertungen werden Prioritäten zugeordnet: P0 (Bewertung 9-10, z. B. RSA-1024, MD5-Signaturen), P1 (7-8, z. B. RSA-2048, SHA-1), P2 (5-6, z. B. RSA-3072), P3 (2-4, z. B. RSA-4096, ECDSA P-384), P4 (0-1, z. B. hybride oder reine PQC-Algorithmen).
Die übergeordnete Ausgabestruktur, die von jeder Scan-Operation zurückgegeben wird.
| Feld | Typ | Beschreibung |
|---|---|---|
| scan_metadata | ScanMetadata | Scanner-Version, Scan-Modus, Datum, Hostname, Dauer in Sekunden |
| findings | Vec<Finding> | Alle während des Scans entdeckten kryptografischen Assets |
| summary | ScanSummary | Aggregierte Zählungen nach Schweregrad, Fund-Typ und Algorithmus |
| recommendations | Vec<String> | Übergeordnete Sanierungsempfehlungen auf Basis aller Funde |
Scanner-Module
Jeder Scanner ist eine eigenständige Komponente, die rohe kryptografische Daten aus einer bestimmten Quelle erfasst. Scanner sind asynchron (tokio) und verwenden rayon für parallele Dateidurchläufe, wo anwendbar.
Durchläuft Verzeichnisse rekursiv mit dem Crate walkdir und erkennt Zertifikats- und Keystore-Dateien anhand der Erweiterung und der Magic Bytes. Unterstützt die Formate PEM, DER, PKCS#12 und JKS. Dateien werden vom entsprechenden Formatparser behandelt.
Erkennungsstrategie:
- Abgleich der Dateierweiterung (
.pem,.crt,.cer,.der,.p12,.pfx,.jks,.key) - Magic-Byte-Signaturerkennung für Binärformate
- Konfigurierbare Verzeichnistiefe und Ausschlussmuster
- Parallele Datei-I/O über Rayon-Thread-Pool
Verbindet sich mit TLS-Endpunkten über einen auf rustls 0.23 basierenden Client. Erfasst den vollständigen TLS-Handshake einschließlich Protokollversion, Cipher-Suite-Aushandlung, Serverzertifikatskette und Schlüsselaustauschparametern. Unterstützt die Subdomain-Enumeration über die WhoisXML-API-Integration.
Führt ein systemweites kryptografisches Inventar durch, das Ergebnisse mehrerer Unter-Scanner kombiniert: Filesystem-Zertifikate, den Windows-Zertifikatspeicher (über das Crate schannel), SSH-Hostschlüssel und Cloud-KMS-Metadaten (für AWS KMS, Azure Key Vault und GCP Cloud KMS).
Engine für statische Analyse mit 150+ Erkennungsregeln, die 8 Programmiersprachen abdecken. Sie durchläuft Quellcodebäume und wendet Regex-basierten Musterabgleich an, um anfällige kryptografische Funktionsaufrufe (z. B. RSA_generate_key, ECDSA_sign, fest codierte Schlüssel) zu erkennen.
Fähigkeiten:
- Definitionen von Erkennungsmustern (Algorithmus, Funktionsname, Schweregrad)
- Engine für Dateidurchlauf und Regelabgleich
- SARIF-Ausgabeformat für die CI/CD-Integration
- Konnektoren für GitHub-, GitLab- und Azure-DevOps-Repositorys
Parser-Schicht
Parser konvertieren rohe Binär- oder Textdaten in strukturierte CertificateInfo- und KeystoreInfo-Objekte. Sie werden von Scannern aufgerufen und sind formatspezifisch.
| Parser | Crate | Behandelte Formate |
|---|---|---|
| PEM | x509-parser | Base64-codierte Zertifikate, private Schlüssel, CSRs |
| DER | x509-parser | Binär codierte X.509-Zertifikate (.der, .cer) |
| PKCS#12 | x509-parser | Passwortgeschützte Zertifikats-/Schlüsselbündel (.p12, .pfx) |
| Windows-Zertifikatspeicher | schannel | LocalMachine- und CurrentUser-Zertifikatspeicher unter Windows |
| CBOM | serde | CycloneDX Cryptographic Bill of Materials (JSON-Eingabe) |
Risikobewertungs-Engine
Die Risikobewertungs-Engine bewertet jeden Fund auf einer Quantum-Anfälligkeitsskala von 0 bis 10. Die Bewertung berücksichtigt die Algorithmusfamilie, die Schlüsselgröße, das Signaturschema und kontextbezogene Faktoren.
| Bewertungsbereich | Priorität | Schweregrad | Beispielalgorithmen |
|---|---|---|---|
| 9 - 10 | P0 (Sofort) | Critical | RSA-1024, DSA-1024, MD5-Signaturen, DES, 3DES |
| 7 - 8 | P1 (Dringend) | High | RSA-2048, ECDSA P-256, SHA-1-Signaturen |
| 5 - 6 | P2 (Geplant) | Medium | RSA-3072, Diffie-Hellman 2048-Bit |
| 2 - 4 | P3 (Überwachen) | Low | RSA-4096, ECDSA P-384, ECDSA P-521 |
| 0 - 1 | P4 (Informativ) | Info | ML-KEM, ML-DSA, SLH-DSA, hybride PQC-Algorithmen |
Ausgabeformatter
Der Scanner bietet fünf Ausgabe-Backends. Das CLI-Flag --format wählt aus, welcher Formatter das ScanResult rendert.
| Format | Anwendungsfall |
|---|---|
| JSON | Maschinenlesbare Ausgabe für Pipelines, APIs und Integrationen |
| YAML | Menschenlesbare strukturierte Ausgabe für das Konfigurationsmanagement |
| Terminal (ANSI) | Farbcodierte Konsolenausgabe mit Schweregrad-Hervorhebung für die interaktive Nutzung |
| HTML | Eigenständige HTML-Berichte zum Teilen mit Stakeholdern |
| CycloneDX CBOM | CycloneDX-1.7-Cryptographic-Bill-of-Materials-Export |
Der CI-Modus (Befehl ci) erzeugt SARIF-Ausgabe, die sich von den standardmäßigen Ausgabeformattern unterscheidet. SARIF lässt sich direkt in GitHub Code Scanning, GitLab SAST und Azure DevOps integrieren.
Axum-Webserver
Der Befehl serve startet einen Axum-0.7-Webserver.
- REST-API – Endpunkte zum Auslösen von Scans, Abrufen von Ergebnissen und Verwalten der Konfiguration
- WebSocket – Echtzeit-Streaming des Scan-Fortschritts an verbundene Clients
- Authentifizierung – OIDC- und API-Schlüssel-Modi
- CORS – Konfigurierbare Cross-Origin-Richtlinie für browserbasierte Dashboards
- Ratenbegrenzung – Anforderungsdrosselung zur Missbrauchsverhinderung
Compliance-Engine
Die Compliance-Engine bewertet Scan-Funde gegen 8+ regulatorische und branchenübliche Frameworks.
| Komponente | Zweck |
|---|---|
| Checker | Bewertet Funde gegen framework-spezifische Regeln |
| Frameworks | Framework-Definitionen – NIST, BSI TR-02102, CNSA 2.0, PCI DSS, FIPS 140-3, ETSI, ISO 27001, SOC 2 |
| Gap-Analyzer | Identifiziert Lücken zwischen aktueller Sicherheitslage und angestrebtem Compliance-Zustand |
| Berichtsgenerator | Erstellt Compliance-Berichte in den Formaten HTML, PDF und JSON |
| PDF-Parser | Extrahiert Anforderungen aus benutzerdefinierten organisatorischen Richtlinien-PDFs |
Integrationen
Überträgt Scan-Funde über die REST-API an ServiceNow. Unterstützt die automatische Incident-Erstellung für P0/P1-Funde, die CMDB-Synchronisierung für entdeckte kryptografische Assets und geplante Synchronisierungs-Workflows. Der CLI-Befehl servicenow löst einen vollständigen Scan-und-Übertragungs-Zyklus aus.
Fähigkeiten:
- REST-API-Integration zur Übertragung von Schwachstellendaten
- Automatische Incident-Erstellung basierend auf Schweregrad-Schwellenwerten
- CMDB-Synchronisierung für das Inventar kryptografischer Assets
- Konfigurierbare Synchronisierungsfrequenz (kontinuierlich, geplant, bedarfsgesteuert)
Das ServiceNow-Dashboard zeigt quantenanfällige Assets nach Schweregrad, Compliance-Status und Sanierungsfortschritt an.
Wichtige Abhängigkeiten
| Crate | Version | Zweck |
|---|---|---|
| tokio | 1.x | Asynchrone Laufzeit für nebenläufige I/O-Operationen |
| clap | 4.5 | CLI-Argumentparsing mit Derive-Makros |
| serde / serde_json / serde_yaml | 1.x | Serialisierung und Deserialisierung für JSON, YAML und Konfigurationsdateien |
| rustls | 0.23 | TLS-Client-Implementierung für das Domain-Scanning (keine OpenSSL-Abhängigkeit) |
| x509-parser | 0.16+ | Parsing von X.509-Zertifikaten und CRLs |
| walkdir | 2.x | Rekursiver Verzeichnisdurchlauf für das Filesystem-Scanning |
| rayon | 1.x | Datenparallele CPU-gebundene Verarbeitung (Datei-Parsing, Regelabgleich) |
| reqwest | 0.12+ | HTTP-Client für Cloud-KMS-APIs, ServiceNow und Git-Provider-Integrationen |
| axum | 0.7 | Asynchrones Web-Framework für den serve-Befehl (REST + WebSocket) |
| tracing | 0.1 | Strukturierte Protokollierung und Diagnose |
| schannel | 0.1 | Zugriff auf den Windows-Zertifikatspeicher über die SChannel-API |
Der Scanner hat keinerlei Abhängigkeit von OpenSSL. TLS-Operationen verwenden rustls, und das Zertifikatsparsing verwendet x509-parser. Dies eliminiert eine ganze Klasse von Supply-Chain-Schwachstellen und vereinfacht plattformübergreifende Builds.
Architekturprinzipien
Einzelne Binärdatei
Wird als eine native ausführbare Datei pro Plattform ausgeliefert. Keine Laufzeitabhängigkeiten, keine JVM, kein Python-Interpreter. Einfach kopieren und ausführen.
Async-First
Alle Netzwerk-I/O verwenden Tokio-async. CPU-gebundene Arbeit (Datei-Parsing, Regelabgleich) wird für maximalen Durchsatz an Rayon-Thread-Pools ausgelagert.
Kein OpenSSL
Reines Rust-TLS über Rustls und x509-parser. Keine C-Bibliotheksabhängigkeiten für kryptografische Operationen.
Modulare Scanner
Jeder Scan-Befehl ist ein eigenständiges Modul. Neue Scanner können ohne Änderung des bestehenden Codes hinzugefügt werden.