Inhaltsverzeichnis
2.3 Strategie & Technologie
Strategische Planung und Technologie-Entscheidungen für Post-Quantum-Kryptographie.
Migrationsphasen
Phase 1 Phase 2 Phase 3 Phase 4
─────── ─────── ─────── ───────
Vorbereitung Hybrid Validierung PQ-Only
Heute ──────────────────────────────────────────────────────────► Zukunft
Bibliothek Neue Certs Beide Sigs Nur PQ
installieren hybrid validieren (optional)
Phase 1: Vorbereitung
Aktivitäten:
- NuGet-Paket evaluieren
- OpenSSL 3.6 in Testumgebung bereitstellen
- Bestandsaufnahme: Welche Systeme nutzen Kryptographie?
- Risikobewertung: Welche Daten haben langen Schutzbedarf?
Ergebnis: Bibliothek installiert, im Classic-Modus (keine Änderung am Verhalten)
Phase 2: Hybrid aktivieren
Aktivitäten:
- CryptoMode.Hybrid in Pilotprojekt aktivieren
- Neue Zertifikate erstellen (automatisch hybrid)
- Kompatibilitätstests mit Legacy-Clients
- Schrittweiser Rollout auf weitere Systeme
Ergebnis: Neue Zertifikate sind PQ-geschützt, alte funktionieren weiterhin
Phase 3: Validierung
Aktivitäten:
- PQ-Signatur-Validierung aktivieren
- Monitoring für Validierungsfehler einrichten
- Legacy-Zertifikate schrittweise ersetzen
- Dokumentation und Training
Ergebnis: Vollständige hybride Validierung aktiv
Phase 4: PQ-Only (optional)
Voraussetzung: Alle Systeme PQ-fähig
Aktivitäten:
- CryptoMode.PostQuantum aktivieren
- Legacy-Unterstützung entfernen
- Volle PQ-Sicherheit
Hinweis: Für die meisten Organisationen ist Phase 3 ausreichend.
Priorisierung
| Priorität | Systeme | Begründung |
|---|---|---|
| 1 (sofort) | Langzeit-Archive, Verträge | Höchster Schutzbedarf |
| 2 (kurzfristig) | PKI, Zertifikat-Infrastruktur | Basis für andere Systeme |
| 3 (mittelfristig) | APIs, Webservices | Laufende Kommunikation |
| 4 (nachgelagert) | Interne Systeme | Geringeres Abfangrisiko |
Technologie-Entscheidungen
Warum OpenSSL 3.6?
| Kriterium | OpenSSL 3.6 | Alternativen |
|---|---|---|
| FIPS-Validierung | FIPS 140-3 validierbar | Bouncy Castle: Keine FIPS |
| PQ-Algorithmen | ML-DSA, ML-KEM nativ | liboqs: Experimentell |
| Wartung | OpenSSL Foundation, langfristig | Kleine Teams, unsicher |
| Performance | Hardware-optimiert (AES-NI, AVX) | Oft reine Software |
Warum AES-256-GCM?
| Kriterium | AES-256-GCM | ChaCha20-Poly1305 |
|---|---|---|
| FIPS-Zertifizierung | FIPS 197 (Standard) | Nicht FIPS-zertifiziert |
| Hardware-Support | AES-NI auf allen CPUs | Keine Hardware-Beschleunigung |
| PQ-Sicherheit | 128-bit post-quantum | 128-bit post-quantum |
Warum Hybrid statt PQ-Only?
| Aspekt | Hybrid (empfohlen) | PQ-Only |
|---|---|---|
| Risiko | Minimal – zwei Sicherheitsschichten | Höher – nur PQ-Algorithmen |
| Kompatibilität | Legacy-Systeme funktionieren | Bricht mit Legacy |
| NIST-Empfehlung | Empfohlen für Übergangszeit | Erst nach Migration |
Zusammenfassung für Audits
| Entscheidung | Begründung | Referenz |
|---|---|---|
| OpenSSL 3.6 | FIPS-validierbar, Industriestandard | OpenSSL Foundation |
| AES-256-GCM | FIPS 197 zertifiziert, Hardware-beschleunigt | NIST FIPS 197 |
| ML-DSA/ML-KEM | NIST-standardisiert (FIPS 203/204) | NIST PQC Project |
| Hybrid-Modus | NIST/BSI empfohlen, defensiv | NIST SP 800-227 |
Erfolgsfaktoren
- Executive Sponsorship: Unterstützung der Geschäftsleitung
- Frühzeitiger Start: Nicht auf Quantencomputer warten
- Schrittweiser Rollout: Risikominimierung durch Phasen
- Monitoring: Validierungsfehler erkennen und beheben
- Dokumentation: Für Audits und Wissenstransfer
Weiterführend
- Migration (technisch) – Detaillierte Schritte
- Compliance – Regulatorische Anforderungen
- Administrator – Operative Umsetzung
Wolfgang van der Stille @ EMSR DATA d.o.o. - Post-Quantum Cryptography Professional
Zuletzt geändert: den 29.01.2026 um 15:12
