Datenverschlüsselung während der Übertragung ist ein gelöstes Problem — bis der Angreifer einen Quantencomputer besitzt. Symmetrische Chiffren wie AES-256 überstehen die Quantenbedrohung. RSA und elliptische Kurven-Schlüsselvereinbarung hingegen nicht: Shors Algorithmus, der auf einem ausreichend großen fehlertoleranten Quantenprozessor läuft, faktorisiert RSA-Schlüssel und löst das Problem des diskreten Logarithmus in Polynomialzeit, wodurch jeder mit klassischer Public-Key-Kryptographie ausgehandelte Sitzungsschlüssel nachträglich lesbar wird. Die praktische Bedrohung ist keine zukünftige, sondern eine gegenwärtige: Angreifer fangen verschlüsselten Defense-Datenverkehr heute ab und speichern ihn in der Erwartung, dass Quantenhardware es ihnen schließlich ermöglichen wird, ihn zu entschlüsseln. Der Harvest-Now-Decrypt-Later-Angriff hat keine Abwehr außer Post-Quanten-Kryptographie, die beim initialen Schlüsselaustausch angewendet wird.
Corvus.Quantum ist eine quantenresistente Streaming-Plattform, die für klassifizierte Defense-Kommunikation entwickelt wurde. Sie kombiniert Apache Kafkas verteiltes Streaming-Backbone mit gitterbasierter Post-Quanten-Kryptographie — speziell NTRUEncrypt und CRYSTALS-Kyber — und legt eine vollständige Zero-Trust-Architektur über die gesamte Topologie. Dieser Artikel analysiert, wie diese Komponenten interagieren, wie der duale Schlüsselverteilungsmechanismus funktioniert und wie ein Defense-Engineering-Team das Python SDK in eine bestehende Streaming-Pipeline integriert.
Warum gitterbasierte Kryptographie
Post-Quanten-Kryptographie umfasst mehrere Algorithmenfamilien: gitterbasierte, hashbasierte, codebasierte und Isogenie-basierte. Corvus.Quantum verwendet gitterbasierte Algorithmen, weil sie das beste Verhältnis von Leistung zu Sicherheit für Hochdurchsatz-Streaming-Workloads bieten. Das zugrundeliegende schwierige Problem — das Shortest Vector Problem (SVP) und das Learning With Errors (LWE)-Problem — hat keinen bekannten Polynomialzeit-Quantenalgorithmus. NIST schloss seinen Post-Quanten-Standardisierungsprozess im Jahr 2024 ab und wählte CRYSTALS-Kyber (jetzt als ML-KEM unter FIPS 203 standardisiert) als primären Key-Encapsulation-Mechanismus aus. NTRUEncrypt, ein länger etabliertes Gittersystem, wird als sekundärer Algorithmus für die Schlüsselkapselung in Szenarien beibehalten, die FIPS 203-Alternativen erfordern.
Der Schlüsselkapselungsprozess in Corvus.Quantum funktioniert wie folgt: Der Producer-Knoten generiert pro Sitzung ein ephemeres ML-KEM-Schlüsselpaar. Er sendet den öffentlichen Schlüssel (Kapselungsschlüssel) über einen QKD-geschützten oder mTLS-geschützten Kanal an den Schlüsselverwaltungsserver. Der Server kapselt einen symmetrischen Sitzungsseed mit dem öffentlichen Schlüssel und gibt den Chiffretext zurück. Beide Seiten leiten aus dem Seed mittels HKDF einen identischen AES-256-Sitzungsschlüssel ab. Dieser Sitzungsschlüssel verschlüsselt die Kafka-Nachrichten-Payload — klassisches Diffie-Hellman oder RSA ist an keinem Punkt der Schlüsselvereinbarung beteiligt.
Schlüsselerkenntnis: Die CRYSTALS-Kyber-Schlüsselkapselung auf dem 128-Bit-Quantensicherheitsniveau (Kyber-768) fügt pro Sitzungsaufbau etwa 1,1 KB Overhead hinzu und wird in unter 1 Millisekunde auf handelsüblicher Server-Hardware abgeschlossen. Für Streaming-Workloads, bei denen Sitzungen Minuten oder Stunden andauern, ist dieser Overhead vernachlässigbar. Der Engpass beim quantensicheren Schlüsselaustausch ist nicht die Algorithmusleistung — es sind die Schlüsselverwaltungsinfrastruktur und die Netzwerklatenz zum Schlüsselserver.
Zero Trust für Streaming-Kommunikation
Ein Kafka-Cluster ohne Zugriffskontrollen ist ein flaches Broadcast-Medium: Jeder Knoten, der den Broker erreichen kann, kann jedes Topic produzieren oder konsumieren. Zero Trust beseitigt diese Annahme impliziten Vertrauens, indem es an jedem Punkt in der Streaming-Topologie eine kontinuierliche Entitätsverifizierung erfordert — Producer, Consumer, Broker und der Schlüsselverwaltungsserver nehmen alle an einer gegenseitigen Authentifizierungs- und Autorisierungskette teil.
Die Zero-Trust-Kontrollebene in Corvus.Quantum folgt dem NIST SP 800-207-Modell mit drei Komponenten. Die Policy-Engine bewertet jede Zugriffsanfrage — ein Producer, der in ein Topic schreiben möchte, ein Consumer, der abonnieren möchte, ein Broker, der einen Schlüssel vom Schlüsselverwaltungsserver anfordert — anhand eines Regelwerks, das Klassifizierungsetiketten, organisatorische Einheitenzugehörigkeit und Zeitbeschränkungen kodiert. Der Policy-Administrator übersetzt Policy-Entscheidungen in kurzlebige Anmeldeinformationen: Kafka-ACL-Gewährungen, Schlüsselzugriffs-Token mit begrenzter TTL und mTLS-Zertifikate mit eingebetteten Autorisierungsansprüchen. Der Policy-Enforcement-Point befindet sich im Kafka-Broker und dem SDK-Client — er validiert jede eingehende Verbindung anhand der präsentierten Anmeldeinformation und lehnt Verbindungen ab, die abgelaufene oder Policy-inkompatible Anmeldeinformationen tragen.
Kein Knoten in der Topologie vertraut einem anderen aufgrund seiner Netzwerkposition. Ein Producer-Knoten im selben Rechenzentrum wie der Broker präsentiert sein mTLS-Zertifikat bei jeder Verbindung; der Broker validiert die Zertifikatskette, extrahiert die Autorisierungsansprüche und prüft sie anhand der Policy-Engine, bevor er eine Produce-Anfrage akzeptiert. Ein kompromittierter Broker kann den Schlüsselverwaltungsserver nicht imitieren, da der Schlüsselserver das Zertifikat des Brokers unabhängig validiert. Das Ost-West-Vertrauen zwischen Streaming-Knoten ist null — der Zugriff jedes Knotens ist auf genau die Topics und Schlüssel-IDs beschränkt, für die er explizit autorisiert wurde.
Schlüsselerkenntnis: Zero Trust in Streaming-Architekturen schließt einen spezifischen Angriffsvektor, den Perimetersicherheit übersieht: einen kompromittierten Consumer-Knoten. In einem perimeter-gesicherten Kafka-Cluster kann ein kompromittierter Knoten, der sich bereits im Netzwerk befindet, jedes Topic abonnieren, das er routen kann. Im Zero-Trust-Modell von Corvus.Quantum wird das Zertifikat eines kompromittierten Knotens bei der Policy-Engine widerrufen, und alle broker-seitigen ACLs für dieses Zertifikat werden innerhalb der TTL der zwischengespeicherten Policy-Entscheidung ungültig gemacht — typischerweise unter 60 Sekunden. Der Angreifer verliert den Streaming-Zugriff, bevor er die Daten einer vollständigen Sitzung exfiltrieren kann.
Apache Kafka-Topologie: On-Premises vs. Azure Event Hubs
Corvus.Quantum unterstützt zwei Broker-Konfigurationen. Bei der On-Premises-Bereitstellung läuft Apache Kafka innerhalb der physischen Anlage des Betreibers — einem gesicherten Serverraum, einem taktischen Operationszentrum oder einem Air-Gapped-Klassifizierungsnetzwerk. Alle Broker-Knoten, ZooKeeper- (oder KRaft-) Koordinatoren und der Schlüsselverwaltungsserver betreiben sich innerhalb der Anlagengrenze. Der Netzwerkverkehr zwischen Knoten verläuft über ein physisch kontrolliertes Medium. Dies ist die Konfiguration, die in aktiven ukrainischen Kampfzonen-Einsätzen verwendet wird, wo klassifizierte Audio- und Videostreams durch umkämpftes Gebiet geleitet werden.
Bei der Azure Event Hubs-Bereitstellung ist das Streaming-Backbone der verwaltete Azure Event Hubs-Dienst, der eine Kafka-kompatible Protokolloberfläche bereitstellt. Die Broker-Abstraktion des SDK bedeutet, dass der Client-Code in beiden Konfigurationen identisch ist — nur die Bootstrap-Server-Adresse und Authentifizierungsparameter unterscheiden sich. Azure Event Hubs im Government Community Cloud (GCC High)-Mandanten bietet FedRAMP High-Konformität und ist damit für US-amerikanische föderale Defense-Programme geeignet. In dieser Konfiguration stellt die Post-Quanten-Verschlüsselung von Corvus.Quantum sicher, dass selbst bei Kompromittierung der TLS-Schicht von Azure der abgefangene Chiffretext ohne die gitterbasierten Sitzungsschlüssel des Corvus-Schlüsselverwaltungsservers undurchsichtig bleibt.
Die Wahl zwischen den beiden Topologien wird durch Konnektivitäts- und Compliance-Anforderungen bestimmt, nicht durch Sicherheit — die Verschlüsselungs- und Zero-Trust-Schichten bieten in beiden Konfigurationen gleichwertigen Schutz. Organisationen, die für ihre sensibelsten Workloads keine Cloud-Abhängigkeit akzeptieren können, verwenden On-Premises. Organisationen, die klassifizierte, aber nicht Air-Gapped-Workloads auf staatlicher Cloud-Infrastruktur betreiben, verwenden Event Hubs, um den Betriebsaufwand zu reduzieren.
Duale Schlüsselverteilung: QKD und Physical Unclonable Functions
Sitzungsschlüssel in Corvus.Quantum werden nicht aus einer einzigen Quelle abgeleitet. Die Plattform verwendet zwei komplementäre Mechanismen, und der endgültige Sitzungsschlüssel ist eine Kombination aus beiden — sodass die Kompromittierung eines Kanals den Sitzungsschlüssel nicht gefährdet.
Quantum Key Distribution (QKD) verwendet quantenoptische Kanäle — typischerweise polarisierte Photonen, die über dedizierte Glasfaser übertragen werden — um symmetrisches Schlüsselmaterial mit informationstheoretischer Sicherheit auszutauschen. Jeder Versuch, den Quantenkanal abzufangen oder zu messen, stört die Photonenzustände und führt zu nachweisbaren Fehlern; das Protokoll bricht ab und verhandelt neu, wenn die Fehlerrate einen Schwellenwert überschreitet. QKD ist daher der einzige Schlüsselaustauschwechanismus mit einem physischen Erkennungsmechanismus für Man-in-the-Middle-Abfangversuche. Seine Einschränkung liegt in der Infrastruktur: QKD erfordert dedizierte Glasfaser und ist derzeit auf Punkt-zu-Punkt-Verbindungen von bis zu mehreren hundert Kilometern ohne Quantenrepeater beschränkt. In Corvus.Quantum-Deployments mit QKD-fähiger Infrastruktur liefert QKD den primären Schlüssel-Entropiebeitrag.
Physical Unclonable Functions (PUFs) leiten kryptographisches Schlüsselmaterial aus den intrinsischen physischen Fertigungsvariationen eines Siliziumgeräts ab — Variationen in Transistor-Schwellspannungen, Leitungsverzögerungen und Speicherzellverhalten, die für jedes Gerät einzigartig sind und nicht geklont oder per Software extrahiert werden können. Ein PUF-fähiges Hardware-Sicherheitsmodul bietet eine Challenge-Response-Schnittstelle: Bei einer Challenge-Eingabe produziert das Gerät eine physikalisch determinierte Antwort, die über Einschaltzyklen stabil, aber für dieses physische Gerät einzigartig ist. Corvus.Quantum verwendet PUF-Antworten als zweite Schlüssel-Entropiequelle, XOR-verknüpft mit dem QKD-abgeleiteten Material (oder, wo QKD nicht verfügbar ist, mit dem CRYSTALS-Kyber-abgeleiteten Seed), um den Sitzungsschlüssel zu erzeugen. Da PUF-Material an physische Hardware gebunden ist, erfordert das Klonen eines Sitzungsschlüssels das physische Klonen der Hardware — eine erheblich höhere Hürde als die Kompromittierung eines Software-Schlüsselspeichers.
AES-256 für ruhende Daten
Post-Quanten-Verschlüsselung schützt Daten während der Übertragung. AES-256 schützt ruhende Daten auf dem Broker-Speicher. Corvus.Quantum implementiert Envelope-Verschlüsselung für Broker-Log-Segmente: Jedes Kafka-Log-Segment wird mit einem eindeutigen Data Encryption Key (DEK) verschlüsselt, der pro Segment generiert wird. Der DEK wird dann mit dem Key Encryption Key (KEK) des Mandanten unter Verwendung von AES-256-GCM umhüllt und neben dem Segment gespeichert. Der KEK befindet sich im Schlüsselverwaltungsserver, nicht auf dem Broker-Knoten — ein Angreifer, der physischen Zugriff auf den Broker-Speicher erhält, erhält verschlüsselte Log-Segmente und eingehüllte DEKs, kann die DEKs jedoch ohne Zugriff auf den Schlüsselverwaltungsserver nicht entpacken.
Für klassifizierte Streaming-Workloads bildet diese Trennung der Zuständigkeiten die CIA-Triade-Anforderungen direkt ab: Vertraulichkeit wird durch AES-256-DEK-Verschlüsselung im Ruhezustand und Post-Quanten-Verschlüsselung während der Übertragung gewährleistet; Integrität wird durch GCM-Authentifizierungs-Tags auf jedem verschlüsselten Segment garantiert, die Manipulationen erkennen; Verfügbarkeit wird durch den Kafka-Replikationsfaktor und die Fähigkeit des Brokers aufrechterhalten, Segmente aus Replikaten bereitzustellen, wenn ein primärer Knoten ausfällt. Der Schlüsselverwaltungsserver ist der einzelne Vertrauenspunkt, aber nicht der Single Point of Failure — er betreibt sich in einer replizierten Konfiguration mit Hardware Security Module (HSM)-Unterstützung.
Integration von Corvus.Quantum in eine Defense-Streaming-Pipeline: Python SDK-Walkthrough
Die folgenden Schritte behandeln die Integration mit dem Python SDK. Das Java SDK bietet eine identische API-Oberfläche. Die Schritte beziehen sich auf das HowTo-Schema, das in den strukturierten Daten dieser Seite eingebettet ist.
Schritt 1: Installieren und Anmeldedaten konfigurieren. Das SDK authentifiziert sich über mTLS. Ihr Zero-Trust-Identitätsanbieter stellt ein Client-Zertifikat aus, das sowohl als TLS-Anmeldeinformation als auch als Autorisierungsidentität dient. Konfigurieren Sie den QuantumClient mit dem Zertifikatspfad, dem Schlüsselpfad, dem CA-Bundle für die Zertifikatskette des Brokers und dem Schlüsselverwaltungsserver-Endpunkt. Es werden keine API-Schlüssel oder gemeinsame Geheimnisse verwendet — das Zertifikat ist die Anmeldeinformation.
Schritt 2: Bei der Policy-Engine registrieren. Bei der Initialisierung führt das SDK einen Policy-Engine-Registrierungsaufruf durch, der das Zertifikat validiert, Topic-ACLs prüft und ein kurzlebiges Zugriffstoken zurückgibt. Dies geschieht transparent bei der ersten Client-Verwendung. Wenn die Registrierung fehlschlägt — ungültiges Zertifikat, abgelaufene ACL, Policy-Änderung — löst das SDK einen AuthorizationError aus, bevor ein Streaming-Vorgang fortgesetzt wird. Dies stellt ein Fail-Closed-Verhalten sicher: Unkonfigurierte oder falsch konfigurierte Clients können nicht versehentlich unverschlüsselte Daten streamen.
Schritt 3: Schlüsselverteilungsprofil wählen. Drei Profile sind verfügbar. KD_QKD_PRIMARY verwendet QKD für den initialen Schlüsselaustausch und fällt auf ML-KEM auf Nicht-QKD-Links zurück. KD_PUF_PRIMARY verwendet PUF-Hardware als primäre Entropiequelle und erfordert ein PUF-fähiges HSM. KD_KYBER_ONLY ist nur-Software und geeignet für Umgebungen ohne QKD-Infrastruktur. Legen Sie die Sitzungsschlüssel-TTL und das Fail-Secure-Verhalten (FAIL_CLOSED oder CONTINUE_WITH_CACHED_KEY) für das Konnektivitätsverlust-Szenario fest.
Schritt 4: Verschlüsselte Nachrichten senden. Umhüllen Sie den Standard-Kafka-Producer mit QuantumProducer. Die Send-Schnittstelle ist identisch mit dem Standard-Kafka-Producer — Topic-Name, Schlüssel, Wert, Header. Das SDK verschlüsselt den Wert mit AES-256-GCM unter Verwendung des Sitzungsschlüssels, bettet die Schlüssel-ID in ein reserviertes Header-Feld ein und liefert den verschlüsselten Payload an den Broker. Es sind keine Schemaänderungen erforderlich. Komprimierung wird vor der Verschlüsselung angewendet, um zu verhindern, dass die Chiffretext-Expansion die Komprimierungsgewinne zunichte macht.
Schritt 5: Konsumieren und entschlüsseln. Umhüllen Sie den Standard-Kafka-Consumer mit QuantumConsumer. Der Consumer ruft die Schlüssel-ID aus dem Nachrichten-Header ab, ruft den entsprechenden Sitzungsschlüssel aus dem lokalen Schlüssel-Cache ab (oder holt ihn erneut vom Schlüsselverwaltungsserver, wenn er abgelaufen ist) und entschlüsselt den Payload. Consumer-Gruppen, Offset-Commits und Partition-Rebalancing funktionieren identisch zum Standard-Kafka. Der Nachrichten-Verarbeitungscode der Anwendung empfängt Klartext — die Entschlüsselung ist transparent.
Schritt 6: Ruhezustand-Verschlüsselung aktivieren. Setzen Sie at_rest_key_id in der Client-Konfiguration, um die broker-seitige Log-Verschlüsselung zu aktivieren. Das SDK stellt die DEK/KEK-Hierarchie automatisch bereit. Dieser Schritt erfordert, dass die Broker-Knoten das Corvus.Quantum-Speicher-Plugin installiert haben — einen Kafka-Speicherschicht-Interceptor, der die Ver-/Entschlüsselung von Log-Segmenten vor der Festplatten-E/A übernimmt.
Schritt 7: Überwachen und rotieren. Aktivieren Sie den Telemetrie-Exporter, um Zugriffsereignisse, Policy-Entscheidungen und Schlüsselabrufereignisse an Ihr SIEM weiterzuleiten. Konfigurieren Sie Alerts für Entschlüsselungsfehler (potenzieller Schlüsselkonflikt oder Replay-Angriff), Policy-Prüfungsfehler (potenzieller nicht autorisierter Zugriff) und Schlüsselabruflatenz, die den TTL-Schwellenwert überschreitet (Konnektivitätsdegradierungswarnung). Planen Sie Schlüsselrotation auf einer 24-Stunden-Grenze oder bei Missionsphasenübergängen.
Schlüsselerkenntnis: Die sieben Integrationsschritte oben können in einem einzigen Engineering-Sprint für ein Team mit vorhandener Kafka-Erfahrung abgeschlossen werden. Die Designphilosophie des SDK ist API-Kompatibilität mit den Standard-Kafka-Client-Bibliotheken — QuantumProducer und QuantumConsumer sind Drop-in-Ersatz für KafkaProducer und KafkaConsumer. Die Post-Quanten- und Zero-Trust-Schichten sind Infrastrukturbelange, keine Anwendungsbelange. Anwendungsentwickler müssen Gitterkryptographie nicht verstehen, um das SDK zu integrieren — sie konfigurieren das Profil, behandeln den AuthorizationError und schreiben Standard-Kafka-Code.
Verhalten unter degradierten Netzwerkbedingungen
Defense-Streaming operiert nicht unter idealen Netzwerkbedingungen. Corvus.Quantum ist speziell für umkämpfte und degradierte Netzwerkumgebungen konzipiert — eine Anforderung, die durch seinen operativen Einsatz in ukrainischen Kampfzonen validiert wird, wo Drohnenkommunikation über gestörte und zeitweise verfügbare Links übertragen wird.
Wenn die Verbindung zum Schlüsselverwaltungsserver unterbrochen wird, funktionieren zwischengespeicherte Sitzungsschlüssel für die Dauer ihrer TTL weiterhin. Eine 30-minütige TTL bedeutet ein 30-minütiges Trennungsfenster, in dem die Streaming-Pipeline normal weiterarbeitet. Wenn die TTL ohne Wiederverbindung abläuft, wird das Verhalten durch die Fail-Secure-Policy gesteuert: FAIL_CLOSED hält das Streaming an, um einen unverschlüsselten Fallback zu verhindern; CONTINUE_WITH_CACHED_KEY verlängert die Schlüsselgültigkeit unter Verwendung des PUF-abgeleiteten Materials (verfügbar auf PUF-fähiger Hardware) als Offline-Schlüsselableitungseingabe und setzt verschlüsseltes Streaming ohne Schlüsselserverkontakt fort. Bei Wiederverbindung erfolgt der Schlüsselaustausch automatisch — das SDK erkennt die Wiederverbindung, führt eine neue ML-KEM-Schlüsselkapselung mit dem Schlüsselserver durch und nimmt das Streaming mit einem neuen Sitzungsschlüssel wieder auf.
Weitere Informationen zu Air-Gapped- und Offline-Bereitstellungsmustern für klassifizierte Workloads, einschließlich Offline-Schlüsselverwaltungsansätzen, finden Sie in unserer dedizierten Behandlung dieser Architektur. Der Artikel Zero Trust für militärische Netzwerke behandelt das vollständige Policy-Engine- und Säulenmodell eingehend, einschließlich Anpassungen für Offline-Netzwerke, die das Fail-Secure-Design von Corvus.Quantum ergänzen.
Häufig gestellte Fragen
+Was macht Corvus.Quantum widerstandsfähig gegen Quantencomputerangriffe?
Corvus.Quantum verwendet gitterbasierte kryptographische Algorithmen — speziell NTRUEncrypt und CRYSTALS-Kyber — die mathematisch immun gegen Shors Algorithmus sind, der den Quantenalgorithmus darstellt, der RSA und elliptische Kurven-Kryptographie brechen kann. Gitterprobleme (Shortest Vector Problem, Learning With Errors) haben keinen bekannten Quanten-Beschleunigungsansatz, wodurch die Verschlüsselung sowohl gegen klassische als auch Quantenangreifer sicher ist. NIST standardisierte CRYSTALS-Kyber als ML-KEM im Jahr 2024 und bietet damit eine zusätzliche Ebene der Standardkonformität.
+Wie interagiert Zero Trust mit der Post-Quanten-Verschlüsselungsschicht in Corvus.Quantum?
Zero Trust übernimmt Identitäts- und Zugriffskontrolle — es beantwortet die Frage, wer berechtigt ist, ein bestimmtes Kafka-Topic zu produzieren oder zu konsumieren. Post-Quanten-Kryptographie übernimmt die Vertraulichkeit — sie stellt sicher, dass abgefangener Chiffretext nicht einmal von einem zukünftigen Quantenangreifer entschlüsselt werden kann. Die beiden Schichten ergänzen sich: Zero Trust verhindert, dass nicht autorisierte Knoten der Streaming-Topologie beitreten, während Post-Quanten-Verschlüsselung Daten während der Übertragung vor Harvest-Now-Decrypt-Later-Angriffen schützt, unabhängig davon, ob ein Angreifer die TLS-Sitzung abgefangen hat.
+Was passiert mit Corvus.Quantum-Streams, wenn die Verbindung zum Schlüsselserver unterbrochen wird?
Corvus.Quantum ist für degradierte Netzwerkumgebungen ausgelegt. Die Plattform speichert Sitzungsschlüssel lokal mit einer konfigurierbaren Time-to-Live (TTL). Während eines Konnektivitätsausfalls werden laufende Nachrichten weiterhin mit zwischengespeicherten Schlüsseln verschlüsselt und entschlüsselt, bis die TTL abläuft. Wenn die TTL ohne Wiederverbindung abläuft, wechselt die Plattform entweder auf vorbereitete Notfallschlüssel (für Plattformen mit Physical Unclonable Function-Hardware) oder fällt in einen konfigurierbaren Fail-Secure-Modus. Der Schlüsselaustausch erfolgt bei Wiederverbindung automatisch.
+Kann Corvus.Quantum On-Premises ohne Cloud-Abhängigkeit betrieben werden?
Ja. Corvus.Quantum stellt Apache Kafka On-Premises bereit, ohne obligatorische Cloud-Komponente. Der Schlüsselverwaltungsserver, die Policy-Engine und alle Streaming-Broker können vollständig innerhalb einer Air-Gapped-Anlage betrieben werden. Azure Event Hubs wird als alternativer Broker für Organisationen unterstützt, die einen verwalteten Cloud-Backbone bevorzugen, ist aber nicht erforderlich. Die Python- und Java-SDKs abstrahieren die Broker-Wahl, sodass der Client-Code in beiden Deployment-Modellen identisch ist.
+Wie funktioniert die duale Schlüsselverteilung — was sind Physical Unclonable Keys?
Corvus.Quantum verwendet zwei komplementäre Schlüsselverteilungsmechanismen. Quantum Key Distribution (QKD) nutzt quantenoptische Kanäle (typischerweise Glasfaser), um symmetrische Schlüssel mit informationstheoretischer Sicherheit auszutauschen — jede Abfangung stört physisch den Quantenzustand und ist nachweisbar. Physical Unclonable Function (PUF)-Schlüssel leiten kryptographisches Material aus den Fertigungsvariationen des Siliziums eines Hardware-Geräts ab und erzeugen einen Fingerabdruck, der nicht geklont oder extrahiert werden kann. Für jede Sitzung tragen beide Mechanismen zur Sitzungsschlüsselableitung bei, sodass die Kompromittierung eines Kanals den Sitzungsschlüssel nicht gefährdet.