Dokumentenklassifikation: Öffentliche technische Spezifikation
Geltungsbereich: Kryptografische Transportarchitektur
Revisionsrichtlinie: Aktualisierung bei Entwicklung kryptografischer Standards
Formales Sicherheits-Whitepaper
Post-Quanten-Segmentierte
Transportarchitektur
Architekturübersicht
Abb. 1 — Segmentierte Post-Quanten-Transport-Enklave. Klassische Kompatibilität am Rand; strenge Nur-PQ-Durchsetzung innerhalb der Grenze.
1.Terminologie und normative Sprache
Die Schlüsselwörter MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT und MAY in diesem Dokument sind wie in RFC 2119 beschrieben zu interpretieren.
Normative Abschnitte
Verbindliche Architekturanforderungen
Informative Abschnitte
Design-Begründung und operative Kommentare
2.Architekturklassifikation
3.Normative Anforderungen
3.1Transportprotokoll
3.1.1Öffentliche Kante
- ▸MUST nur TLS 1.3 unterstützen
- ▸MUST NOT TLS 1.2 oder älter unterstützen
- ▸MUST NOT Legacy-Chiffren aktivieren
- ▸MAY klassische Schlüsselaustauschmechanismen zur Kompatibilität unterstützen
Begründung: Aktuelle Browser-Ökosysteme schließen Nur-PQ-Extern-Endpunkte aus.
3.1.2Internes Post-Quanten-Segment
- ▸MUST ausschließlich mit TLS 1.3 betrieben werden
- ▸MUST ML-KEM (mlkem768) als einzige erlaubte Schlüsselaustauschgruppe erzwingen
- ▸MUST NOT X25519, P-256 oder klassische Gruppen erlauben
- ▸MUST ML-DSA-basierte Signaturverifikation verlangen
- ▸MUST Handshake bei Gruppen-Mismatch beenden
- ▸MUST Handshake bei Signatur-Mismatch beenden
- ▸MUST Handshake bei Downgrade-Versuch beenden
3.2Downgrade-Resistenz
Innerhalb der PQ-Enklave:
- ▸Klassischer Schlüsselaustausch-Fallback MUST NOT existieren
- ▸Chiffren-Suite-Aushandlung MUST NOT klassische Alternativen einschließen
- ▸Protokollversions-Aushandlung MUST jede andere Version als TLS 1.3 ablehnen
- ▸Handshake-Fehler MUST protokolliert und als Sicherheitsereignis behandelt werden
3.3Kryptografische Grenze
Die kryptografische Grenze SHALL wird zwischen Edge (nginx) und PQ Gate definiert. Alle Transporte über diese Grenze MUST der Nur-PQ-Durchsetzungsrichtlinie entsprechen.
4.Bedrohungsmodell (formalisiert)
Fähigkeiten
- •Passive Abfangen
- •Verkehrsarchivierung
- •Zukünftiger Versuch quantenbasierter Entschlüsselung
Minderungsziel
Interner Transport MUST mit ML-KEM geschützt werden für quantenresistente Vorwärtsverschlüsselung.
Fähigkeiten
- •TLS-Aushandlungs-Störung
- •Chiffren-Manipulation
- •Gruppen-Substitution
Minderungsziel
Downgrade-Versuche MUST zur Handshake-Beendigung führen.
Fähigkeiten
- •Passives Sniffing
- •Teilweiser Netzwerkzugriff
Minderungsziel
Alle inter-Komponenten-Verkehre über die Grenze MUST unter Nur-PQ-Transport verschlüsselt bleiben.
5.Informativer Abschnitt — Design-Begründung
5.1Warum Segmentierung statt Voll-PQ
Stand 2026 unterstützen Mainstream-Browser ML-KEM nicht, und Ökosystem-Komponenten (Datenbanken, Caches, Service-Mesh) haben kein PQ-natives TLS. Ein reiner PQ-Extern-Endpunkt würde totale Kompatibilitätsverluste bedeuten.
Operative PQ-Durchsetzung
Rückwärtskompatibilität
Reale Leistungsbewertung
Kontrollierter kryptografischer Übergang
6.Leistungsmetriken (beobachtet)
Werte repräsentieren gemessenes Verhalten im aktuellen Einsatz; periodisch aktualisiert.
6.1Handshake-Overhead
~8–15%
Latenzanstieg vs. X25519
~2–4×
Zertifikatsgrößenanstieg (ML-DSA vs. ECDSA)
Keine beobachtet
Service-Degradation unter Last
6.2Durchsatzauswirkung
- ▸Massenübertragung unverändert (symmetrisches AES-GCM unverändert)
- ▸Overhead auf Handshake-Phase beschränkt
- ▸PQ-Transport-Overhead vorab und über persistente Verbindungen amortisiert
6.3Fehlerverhalten
- ▸Explizite Handshake-Ablehnung bei klassischem Gruppenversuch
- ▸Expliziter Fehler bei Signaturalgorithmus-Mismatch
- ▸Kein stiller Fallback beobachtet
7.Kryptografische Konfigurations-Anhang
7.1Interne PQ-Segment-Konfiguration
Aktiviert
Deaktiviert
7.2Edge-Konfigurationsübersicht
Aktiviert
Deaktiviert
8.Migrationsstrategie (formalisiert)
Phase 1AKTUELL
Hybride öffentliche Kante + strikte interne PQ-Enklave
Aktueller Betriebszustand.
Phase 2
Hybride externe Unterstützung
Wenn Browser hybrides KEM implementieren:
Externe Kante SHOULD hybrides KEM aktivieren.
Interne PQ-Durchsetzung SHALL strikt bleiben.
Phase 3
Optionaler Nur-PQ-Endpunkt
Wenn sich das Browser-Ökosystem stabilisiert:
Nur-PQ-Extern-Endpunkt MAY eingeführt werden.
Kompatibilitäts-Endpunkt MAY vorübergehend bleiben.
Phase 4
Erweiterte PQ-Adoption
Wenn vom Ökosystem unterstützt:
Service-zu-Service-PQ-Transport.
PQ-fähige Datenbankverbindungen.
PQ-fähiges Service-Mesh.
9.Sicherheits-Governance-Prinzipien
Keine übertriebenen Quanten-Immunitäts-Behauptungen
Keine stillen Fallback-Mechanismen
Keine undokumentierten Hybrid-Ausnahmen
Explizite Downgrade-Richtlinie
Explizite Vertrauensgrenzen-Definition
Messbare kryptografische Durchsetzung
10.Architektur-Positionierungsaussage
Dieses System beansprucht keine vollständige Post-Quanten-Internet-Exposition.
Es betreibt eine produktionsseitig durchgesetzte, downgrade-resistente Post-Quanten-Transport-Enklave innerhalb eines kompatibilitätsbeschränkten externen Ökosystems.
Die Architektur spiegelt bewusste kryptografische Übergangsstrategie statt Marketing-Ausrichtung wider.
Versionsverlauf
Download
Gleicher Inhalt wie diese Seite, im PDF-Format.
Das PDF ist nur auf Englisch verfügbar.