Ein Drohnenpilot fliegt eine Aufklärungsmission über umkämpftem Terrain. Der H.264-Video-Stream wird über eine Satellitenverbindung übertragen, verschlüsselt mit DTLS/SRTP unter Verwendung eines ECDHE-Schlüsselaustauschs. Am Boden fängt ein Gegner den Chiffretext ab und speichert ihn – nicht um ihn heute zu entschlüsseln, sondern um ihn 2032 zu entschlüsseln, wenn ein kryptografisch relevanter Quantencomputer verfügbar ist. Bis dahin enthüllt das Filmmaterial Sensorabdeckungslücken, Abzielgeometrie und die Patrouillenmuster befreundeter Kräfte. Der Geheimdienstwert dieses gespeicherten Videos wird durch die Jahre, die es verschlüsselt verbracht hat, nicht gemindert.
Dies ist das Harvest-now-decrypt-later-Problem (HNDL), angewandt auf militärisches Echtzeit-Video. Es ist keine Hypothese. Gegner, die den Quantenzeitplan verstehen, sammeln und archivieren bereits verschlüsselte ISR-Feeds, Drohnenvideo und Kommando-Sprachverkehr. Die angemessene Reaktion ist nicht, auf das Eintreffen von Quantencomputern zu warten, bevor man zur Post-Quanten-Kryptografie migriert – das Fenster zum Schutz von Daten im Transit ist jetzt, bevor die Sammlung stattfindet.
Warum Drohnen- und ISR-Video das wertvollste HNDL-Ziel ist
Kommunikationsaufklärung (COMINT) hat offensichtlichen HNDL-Wert, aber ISR-Video trägt eine andere Klasse von Informationen. Das Drohnenvideo einer einzigen Mission kann enthüllen: die exakten Sichtfelder der Sensoren (und damit blinde Flecken), die präzise zeitliche Abfolge und Geometrie von Abzielentscheidungen, den Standort und die Bewegung befreundeter Kräfte im Bild sowie die operativen Muster, die das Verhalten von Einheiten im Laufe der Zeit definieren. Im Gegensatz zu einer einzelnen verschlüsselten Nachricht kodiert Video persistente Kontextinformationen – räumlich, zeitlich und verhaltensbasiert – die langfristige Sammlung und Analyse lohnend machen.
Die Aufbewahrungsdauer von ISR-Video verstärkt dieses Risiko. Viele Verteidigungsprogramme archivieren rohe Drohnenaufnahmen jahrelang – für die Nachbesprechung, für die Einhaltung gesetzlicher Vorschriften, für die Geheimdienstauswertung. Ein Gegner, der 2026 verschlüsseltes ISR-Video sammelt und es 2032 entschlüsselt, liest keine veralteten Daten; er liest einen strukturierten historischen Bericht über Operationen befreundeter Kräfte. Die Sensitivität dieses Berichts nimmt mit der Zeit nicht ab.
Um die Sammelfläche zu quantifizieren: eine einzelne MALE-Drohne auf einer 20-Stunden-Mission bei Standard-ISR-Bitraten (4–8 Mbps H.264) produziert 36–72 GB komprimiertes Video pro Einsatz. Eine Flotte, die über einer umkämpften Region operiert, erzeugt täglich Terabytes. Dies ist ein äußerst attraktives Sammelziel für einen Gegner, der bereit ist, in langfristige Speicherung und zukünftige Entschlüsselungsfähigkeit zu investieren.
Aktueller Stand: DTLS/SRTP und TLS sind klassisch sicher, aber quantenanfällig
Die meisten militärischen Drohnen-Video-Pipelines verwenden eines von zwei Transportsicherheitsmodellen. Das erste ist DTLS/SRTP: das von WebRTC abgeleitete Modell, bei dem DTLS 1.3 Sitzungsschlüssel über UDP aushandelt und SRTP diese Schlüssel zur Verschlüsselung jedes RTP-Pakets verwendet. Das zweite ist ein TLS-gesicherter Schlüsselverteilungsserver (KDS): ein zentralisierter Dienst, der SRTP-Hauptschlüssel an Sender und Empfänger über eine TLS-geschützte API ausgibt, wobei SRTP die Paketebenenverschlüsselung übernimmt. Beide Modelle hängen letztendlich von einem klassischen Diffie-Hellman- oder Elliptic-Curve-Diffie-Hellman-Schlüsselaustausch für die Sitzungsschlüsselaushandlungsphase ab.
ECDHE mit X25519 (die aktuelle Best Practice für DTLS/TLS-Schlüsselaustausch) bietet starke klassische Sicherheit. Gegen einen Quanten-Angreifer, der Shors Algorithmus ausführt, bietet es keine Sicherheit. Dies ist keine Schwäche in der Algorithmusimplementierung – es ist eine grundlegende Eigenschaft des zugrunde liegenden mathematischen Problems (diskreter Logarithmus auf einer elliptischen Kurve), das Shors Algorithmus in Polynomialzeit löst. Das Ersetzen von X25519 durch eine größere Kurve (z. B. P-521) hilft nicht; Shors Algorithmus skaliert effizient über alle elliptischen Kurvenparametergr ößen.
AES-256-Symmetrieverschlüsselung (verwendet für die eigentliche SRTP-Paketnutzlast) wird von Quantencomputern nicht ähnlich gebrochen. Grovers Algorithmus reduziert die effektive Sicherheit von AES-256 gegen einen Quanten-Angreifer auf 128 Bit – immer noch rechnerisch nicht durch Brute-Force zu brechen. Die Dringlichkeit liegt im Schlüsselaustausch, nicht im Bulk-Chiffrierer.
ML-KEM für Video-Schlüsselaustausch: Integration von Post-Quanten-KEMs mit SRTP
ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism), standardisiert als FIPS 203 durch NIST und basierend auf dem CRYSTALS-Kyber-Algorithmus, ist der Post-Quanten-Ersatz für die Schlüsselaustauschphase von DTLS und TLS. Ein KEM funktioniert anders als Diffie-Hellman: Der Empfänger generiert ein öffentlich/privates Schlüsselpaar und veröffentlicht den öffentlichen Schlüssel; der Sender kapselt ein zufälliges gemeinsames Geheimnis mit dem öffentlichen Schlüssel ein; der Empfänger entkapselt, um dasselbe gemeinsame Geheimnis wiederherzustellen. Keine Seite überträgt das gemeinsame Geheimnis im Klartext, und ein Angreifer, der den Chiffretext abfängt, kann das gemeinsame Geheimnis ohne den privaten Schlüssel des Empfängers nicht wiederherstellen – ein Problem, das auch für Quantencomputer als schwer gilt.
Die Integration mit SRTP ist auf API-Ebene unkompliziert. Der DTLS-Handshake (oder KDS-API-Aufruf) erzeugt wie zuvor ein gemeinsames Geheimnis; die einzige Änderung besteht darin, dass das gemeinsame Geheimnis nun aus einer ML-KEM-Einkapselung statt aus einem ECDHE-Austausch abgeleitet wird. Das gemeinsame Geheimnis wird in HKDF-SHA-384 eingespeist, um den SRTP-Hauptschlüssel und Salt abzuleiten, wobei derselbe Schlüsselableitungspfad wie beim klassischen Protokoll verwendet wird. Das SRTP-Paketformat, die Sequenznummernverwaltung, die Authentifizierungs-Tag-Berechnung und die AES-256-GCM-Bulk-Verschlüsselung sind unverändert. Aus der Perspektive des RTP-Stacks hat sich nichts verändert, außer der Herkunft des Hauptschlüssels.
Parametersatzauswahl: ML-KEM-768 vs. ML-KEM-1024
Drei ML-KEM-Parametersätze sind definiert: ML-KEM-512 (Sicherheitsniveau äquivalent zu AES-128), ML-KEM-768 (AES-192) und ML-KEM-1024 (AES-256). Für ISR-Anwendungen liegt die Wahl zwischen ML-KEM-768 und ML-KEM-1024. Das CNSA-2.0-Mandat der NSA spezifiziert ML-KEM-1024 für National Security Systems. ML-KEM-1024 erzeugt einen 1.568-Byte-öffentlichen Schlüssel und einen 1.568-Byte-Chiffretext – beide größer als X25519s 32-Byte-Schlüsselanteile, aber problemlos im DTLS-Handshake oder einer HTTPS-API-Antwort unterzubringen. Die Leistungskosten gegenüber ML-KEM-768 sind marginal; für eine Entscheidung, die die Datensicherheit für ein Jahrzehnt bestimmt, ist ML-KEM-1024 die richtige Wahl für klassifizierte ISR-Anwendungen.
Latenzbudget: PQC-Overhead beim Echtzeit-Streaming
Der häufigste Einwand gegen PQC in Echtzeit-Video-Pipelines ist Latenz. Die Sorge ist verständlich, aber fehl am Platz, wenn die tatsächlichen Zahlen untersucht werden.
ML-KEM-1024-Schlüsselgenerierung auf einem modernen x86-64-Prozessor (AVX2-optimierte Implementierung, z. B. liboqs oder BoringSSLs eingebaute Version) dauert etwa 0,3–0,5 ms. Einkapselung und Entkapselung dauern jeweils unter 0,5 ms. Der gesamte Round-Trip-Overhead für einen PQC-Schlüsselaustausch beträgt daher unter 2 ms, einschließlich der Netzwerk-Round-Trip-Zeit in einem Niedriglatenz-LAN. Für Video-Streams, die bereits 100–300 ms Codec-Pipeline- und Netzwerkverzögerung tragen (typisch für taktische Satellitenverbindungen), ist dieser Overhead in der Praxis nicht messbar.
Der Schlüsselaustausch ist ein einmaliger Vorgang pro Sitzung, kein Pro-Paket-Vorgang. Eine Drohnen-Video-Sitzung, die 20 Stunden läuft, führt zu Beginn eine ML-KEM-Einkapselung durch (und eine kleine Anzahl periodischer Re-Keys). Die Pro-Paket-Kosten sind null – SRTP-Paketverschlüsselung bleibt AES-256-GCM mit Hardware-Beschleunigungsgeschwindigkeit (mehrere Gbps auf modernen Prozessoren). Post-Quanten-Video-Streaming ist kein Leistungsproblem. Es ist ein Integrationsproblem.
Hybrid-Modus-Deployment: ECDHE + ML-KEM parallel
Während des Übergangszeitraums – wenn einige Endpunkte ML-KEM unterstützen und andere nicht – sind hybride Cipher-Suites der standardkonforme Ansatz. Im Hybrid-Modus enthält der DTLS- oder TLS-Handshake sowohl einen ECDHE-Schlüsselanteil (X25519) als auch eine ML-KEM-Schlüsselkapselung (ML-KEM-1024). Der Sitzungsschlüssel wird aus beiden über HKDF abgeleitet, mit der Formel: session_key = HKDF(X25519_shared_secret || ML-KEM_shared_secret, "hybrid-srtp-key"). Beide Geheimnisse müssen erfolgreich abgeleitet werden, damit die Sitzung fortgesetzt werden kann.
Diese Konstruktion bietet das, was Kryptografen „duale Sicherheit" nennen: Die Sitzung ist quantensicher, wenn ML-KEM sicher ist, und klassisch sicher, wenn X25519 sicher ist. Ein Angreifer muss beides brechen, um den Sitzungsschlüssel wiederherzustellen. Die NSA befürwortet den Hybrid-Modus für den Übergangszeitraum in ihrer CNSA-2.0-Richtlinie; er reduziert die klassische Sicherheit in keiner Weise.
Der praktische Vorteil für ISR-Systeme besteht darin, dass der Hybrid-Modus flottenweit eingesetzt werden kann, bevor alle Bodenstationen aufgerüstet sind. Aufgerüstete Bodenstationen handeln die hybride Cipher-Suite aus; Legacy-Bodenstationen fallen auf reines ECDHE zurück. Die hochwertigen Streams – diejenigen, die post-quanten-fähige C2-Knoten verbinden – erhalten sofort Quantenschutz, während die Rückwärtskompatibilität aufrechterhalten wird. Siehe unsere umfassendere Diskussion des CNSA-2.0-Migrationsansatzes für Verteidigungssysteme für das vollständige Algorithmus-Inventar und den Übergangszeitplan.
Apache Kafka als Streaming-Rückgrat für die ISR-Verteilung
Punkt-zu-Punkt-SRTP funktioniert für einzelne Drohne-zu-C2-Verbindungen, aber die operative ISR-Verteilung ist ein Fan-out-Problem. Ein einzelner Drohnen-Feed muss gleichzeitig von folgenden Stellen konsumiert werden: der primären C2-Workstation, der Abzielzelle, dem Geheimdienstauswertungsteam, dem Aufzeichnungsknoten, der die Mission archiviert, und möglicherweise übergeordneten Kommandos, die die Operation überwachen. Die Verwaltung von N gleichzeitigen SRTP-Sitzungen vom Encoder zu jedem Konsumenten ist operativ fragil und kryptografisch unübersichtlich – jede Sitzung hat unabhängiges Schlüsselmaterial, und die Verwaltung von Schlüsselverteilung und -rotation über N Peers gleichzeitig erzeugt Fehlerszenarien.
Apache Kafka löst dieses Architekturproblem. Jede ISR-Quelle veröffentlicht in einem dedizierten Kafka-Topic (z. B. isr.drone.alpha-01.video, isr.sensor.ground.bravo). Konsumentengruppen – eine pro Rolle (c2-display, targeting, exploitation, archive) – abonnieren unabhängig und pflegen ihre eigenen Offsets. Das Hinzufügen eines neuen Konsumenten erfordert keine erneute Aushandlung mit dem Produzenten; er abonniert einfach das bestehende Topic. Die Wiedergabe für spät hinzukommende Konsumenten (ein Abzielanalyst, der während der Mission online kommt) ist eine eingebaute Kafka-Fähigkeit, keine spezielle Funktion.
Das Post-Quanten-Sicherheitsmodell passt sauber auf diese Architektur. Jeder Produzent authentifiziert sich beim Kafka-Broker über gegenseitiges TLS mit hybriden ML-KEM-Cipher-Suites und richtet einen quantensicheren Kanal für den Stream ein. Jeder Konsument verbindet sich ebenso über TLS mit hybridem ML-KEM mit dem Broker. Der Broker hält die verschlüsselten Topic-Daten auf der Festplatte unter AES-256-Ruheverschlüsselung. Die Schlüsselhierarchie – ML-KEM-Sitzungsschlüssel schützt die TLS-Verbindung, die SRTP-verschlüsselte Video-Frames trägt, die in AES-256-verschlüsselten Kafka-Protokollsegmenten gespeichert sind – bietet Defense-in-Depth auf jeder Ebene.
Topic-Partitionierung und Konsumentengruppen-Design
Für Multi-Sensor-ISR-Deployments bietet die Partitionierung innerhalb eines Topics Skalierbarkeit. Ein hochbandbreitiger Sensor (Full-Motion-Video mit 8 Mbps) profitiert von einer einzigen Partition pro Quelle, um die Frame-Reihenfolge zu erhalten. Mehrere niedrigbandbreitige Sensoren (Telemetrie, Audio, Schmalfeld-Bildgebung) können ein Topic mit Partitionierung nach Sensorkennung teilen. Konsumentengruppen sollten auf operative Rollen statt auf einzelne Workstations beschränkt werden – dies ermöglicht Workstation-Failover innerhalb einer Rolle, ohne die Offset-Kontinuität zu verlieren. Jede Konsumentengruppe pflegt unabhängigen Entschlüsselungszustand; die Schlüsselrotation einer Gruppe betrifft andere nicht.
Corvus.Quantum: Post-Quanten-Streaming für den operativen Verteidigungseinsatz
Corvus.Quantum ist die Corvus Intelligence-Plattform für quantensichere Audio- und Videoverteilung in Verteidigungsumgebungen. Sie implementiert die in diesem Artikel beschriebene Architektur – ML-KEM-1024-Schlüsselaustausch im Hybrid-Modus, SRTP-Paketverschlüsselung, Apache-Kafka-Fan-out für mehrstufige Verteilung – als gehärtetes, operativ getestetes System statt als Forschungsprototyp.
Die Plattform wurde unter aktiven Kampfbedingungen in der Ukraine eingesetzt, wo sie die Echtzeit-ISR-Videoverteilung für Kommandoposten verwaltet, die unter elektronischem Kriegsdruck operieren. Die Designprioritäten, die durch diese Umgebung geprägt wurden – Glas-zu-Glas-Latenz unter 200 ms trotz umkämpfter Verbindungen, graceful Degradation bei Trennung von Konsumenten während des Streams, automatische Schlüsselrotation ohne Stream-Unterbrechung und air-gap-fähiges Deployment für klassifizierte Netzwerke – sind produktionsvalidiert, nicht im Labor simuliert.
Corvus.Quantum integriert sich über eine Plugin-Schnittstelle in bestehende ATAK-basierte C2-Infrastruktur und ermöglicht den Fluss von ISR-Video in das gemeinsame Lagebild neben Cursor-on-Target-Daten. Das Kafka-Rückgrat unterstützt sowohl cloud-gehostete als auch air-gapped On-Premise-Deployments. Post-Quanten-Schlüsselaustausch ist standardmäßig aktiviert; klassischer Fallback ist für Legacy-Endpunkte während hybrider Übergangszeiträume verfügbar. Für Organisationen, die Zero-Trust-Netzwerkanforderungen für militärische Umgebungen erfüllen müssen, erfüllt die gegenseitige TLS-Authentifizierung von Corvus.Quantum für jeden Produzenten und Konsumenten die Gerätidentitätsverifizierung auf der Streaming-Ebene ohne zusätzliche Middleware.
Der Beschaffungsweg für Corvus.Quantum ist über den Brave1-Verteidigungstechnologiemarktplatz und den Direktvertrag mit Corvus Intelligence verfügbar. Technische Integrationsdokumentation ist unter NDA für qualifizierte Verteidigungsorganisationen und Hauptauftragnehmer erhältlich.
Kernaussage: Der Latenz-Overhead von ML-KEM-1024 in einer realen Streaming-Pipeline beträgt unter 2 ms pro Sitzungsaufbau – nicht messbar gegenüber den 100–300 ms Latenz, die bereits in taktischen Satelliten-Video-Links vorhanden sind. Die Engineering-Herausforderung ist keine Leistung; es sind Bibliotheksauswahl, Änderungen des Schlüsselableitungspfads und hybride Cipher-Suite-Aushandlung. Das sind Wochen Integrationsarbeit, keine Monate Leistungsoptimierung.
Corvus.Quantum liefert post-quanten-verschlüsselte Video- und Audioverteilung für ISR und C2 – Kafka-gestützt, SRTP-kompatibel, kampferprobt in der Ukraine. Wenn Ihr Programm quantensicheres Streaming vor der CNSA-2.0-Frist benötigt, helfen wir Ihnen, dorthin zu gelangen, ohne Ihre Pipeline von Grund auf neu aufzubauen.
Corvus.Quantum entdecken →