Statement
QuantumShield SDK

Verschlüsselung, die auch einem Quantenrechner standhält

Wer heute Ihren verschlüsselten Datenverkehr mitschneidet, kann ihn in einigen Jahren mit einem Quantenrechner öffnen. QuantumShield verschlüsselt Ihre Daten schon jetzt so, dass dieser Plan nicht aufgeht.

Hybrid aus X25519 und ML-KEM-768 (NIST FIPS 203): Solange eines der beiden Verfahren ungebrochen ist, bleibt Ihr Geheimnis geschützt.
Live-Diagnose ansehen Lizenz anfragen
NIST FIPS 203 Hybrid: klassisch und post-quantum Im Produktivbetrieb von FriendsTime im Einsatz

Das Problem heißt „heute mitschneiden, später entschlüsseln“

Verschlüsselte Daten, die heute abgefangen und weggespeichert werden, lassen sich später öffnen – sobald ein ausreichend großer Quantenrechner existiert. Alles, was länger geheim bleiben muss, als diese Technik zum Reifen braucht, ist damit heute schon angreifbar: Verträge, Personalakten, Konstruktionsdaten, Backups, Archive.

Die Antwort in einem Satz

QuantumShield verschlüsselt mit zwei voneinander unabhängigen Schlüsselaustauschverfahren gleichzeitig – dem etablierten X25519 und dem quantenresistenten ML-KEM-768. Ein Angreifer muss beide brechen; ein Quantenrechner allein genügt nicht.

Kein Umbau Ihrer Infrastruktur: QuantumShield ist ein Baustein, der in Ihre Anwendung eingebunden wird. Die Verschlüsselung passiert dort, wo Ihre Daten entstehen.

Der Verfahrensstapel

Vier Bausteine, jeder mit klar benannter Herkunft. Alle Größen sind Vorgaben der Standards, keine Schätzungen.

Baustein Aufgabe Herkunft Größen
X25519 Klassischer Schlüsselaustausch (ECDH) Web Crypto
Web Crypto API des Browsers		 öffentlicher Schlüssel 32 Byte, gemeinsames Geheimnis 32 Byte
ML-KEM-768
FIPS 203		 Quantenresistenter Schlüsselaustausch (KEM) Bibliothek
Eigene Umsetzung von INX System Solution (in Entwicklung) – NICHT Web Crypto		 öffentlich 1.184 Byte, privat 2.400 Byte, Chiffrat 1.088 Byte, Geheimnis 32 Byte
HKDF-SHA256 Mischt beide Geheimnisse zu einem Schlüssel Web Crypto
Web Crypto API des Browsers		 Eingabe 64 Byte (32 + 32), Ausgabe 32 Byte, Salz leer
AES-256-GCM Verschlüsselt die Nutzdaten und schützt sie gegen Veränderung Web Crypto
Web Crypto API des Browsers		 Schlüssel 32 Byte, Initialisierungsvektor 12 Byte, Prüfwert 16 Byte

Wichtig – und anderswo oft falsch dargestellt

ML-KEM ist in der Web Crypto API nicht enthalten. Kein Browser bietet es an. Wer „Post-Quantum über Web Crypto“ verspricht, sagt etwas Falsches. Aus Web Crypto kommen hier ausschließlich X25519, HKDF und AES-GCM. ML-KEM-768 muss deshalb als eigener Baustein dazukommen. INX System Solution entwickelt diesen Baustein selbst, nach der Spezifikation NIST FIPS 203. Geprüft ist er bisher byteweise gegen die Vektoren einer etablierten Umsetzung (@noble/post-quantum); die offiziellen Prüfvektoren des NIST-Programms (ACVP) hat er noch nicht durchlaufen, und eine CAVP-Validierung gibt es nicht. Bis dieser Nachweis vorliegt, meldet die Live-Diagnose für diesen Schritt keinen Erfolg und sagt den Grund offen an.

Die Ableitung in einer Zeile

IKM        = x25519_shared (32 Byte)  ||  mlkem_shared (32 Byte)
Schluessel = HKDF-SHA256(IKM, info, L = 32 Byte)
Nutzdaten  = AES-256-GCM(Schluessel, IV 12 Byte, Klartext)

Das Ergebnis ist ein 32-Byte-Schlüssel für AES-256-GCM. Fällt eine der beiden Hälften weg, bleibt die andere wirksam – deshalb Hybrid.

Live-Diagnose

Kein Video, keine Animation: Hier läuft das echte Verfahren auf unserem Server – mit gemessenen Größen und gemessenen Zeiten. Schlägt ein Schritt fehl, sehen Sie die tatsächliche Fehlermeldung.

Gerechnet wird auf unserem Server – Ihre Testnachricht wird dorthin übertragen

Damit Sie es genau wissen: Ihre Testnachricht wird an diesen Server geschickt, dort ver- und wieder entschlüsselt und danach verworfen. Sie wird nicht gespeichert und nicht protokolliert. Die Schlüssel entstehen für diesen einen Durchlauf im Arbeitsspeicher und werden anschließend gelöscht. Der Grund für diesen Weg: liefe die Diagnose in Ihrem Browser, müssten wir das SDK und die ML-KEM-Umsetzung an jeden Besucher ausliefern. Genau das wollen wir nicht. Schreiben Sie trotzdem bitte nichts wirklich Vertrauliches in das Feld.

Der vollständige Selbsttest hängt an die fünf Schritte noch einen Wiederholungslauf an: fünf komplette Durchgänge aus Verschlüsseln und Entschlüsseln, mit gemessener schnellster, langsamster und durchschnittlicher Dauer. Die Werte gelten für unseren Server im Moment der Messung – sie sind eine Momentaufnahme, keine zugesicherte Leistung.

Noch nicht gestartet. Es läuft nichts im Hintergrund.

    Einsatz auf Ihren Servern

    Vier Fälle, in denen die Aufbewahrungsdauer länger ist als die Haltbarkeit heutiger Verschlüsselung.

    Verschlüsselte Backups

    Backups liegen jahrelang – oft an Orten mit anderer Zugriffskontrolle als das Produktivsystem. Wird eine Sicherung kopiert, bleibt der Inhalt geschützt, auch dann noch, wenn der klassische Teil der Verschlüsselung eines Tages nicht mehr genügt.

    Konfigurations- und Geheimnisablage

    Zugangsdaten, Schlüssel und Konfigurationen werden für den Zielserver verschlüsselt und nur dort geöffnet. Der private Schlüssel verlässt diesen Server nie. Wo er liegt und wie er geschützt wird, entscheidet Ihre Umgebung – das SDK nimmt Ihnen diese Entscheidung nicht ab.

    Datenübergabe zwischen Standorten

    Der Absender braucht nur den öffentlichen Schlüssel des Ziels. Der Umschlag kann über beliebige Wege reisen – Objektspeicher, Anhang, Datenträger – und ist unterwegs unlesbar. HTTPS bleibt trotzdem Pflicht: das SDK verschlüsselt Inhalte, nicht Verbindungen.

    Archivierung mit langer Aufbewahrungsfrist

    Steuerunterlagen zehn Jahre, Personalunterlagen länger, Konstruktions- und Patentdaten oft Jahrzehnte. Genau hier zählt, dass ein Mitschnitt von heute später nicht auf einmal lesbar wird.

    Lizenzmodelle

    QuantumShield wird als Quellcode geliefert und in Ihre Anwendung eingebunden. Die Stufe richtet sich nach dem Umfang der Nutzung – die Technik ist in allen Stufen dieselbe.

    Einzelserver
    Ein Produktivsystem, eine Anwendung.
    Preis auf Anfrage
    Wir nennen Ihnen den Preis nach einem kurzen Gespräch über Umfang und Einsatzzweck.
    • Einsatz auf einem Produktivsystem
    • Vollständiger Quellcode, unminifiziert und kommentiert
    • Technische Dokumentation auf Deutsch, einschließlich der Grenzen des Verfahrens
    • Eingebauter Selbsttest und Platzhalter-Erkennung
    • Heute im Lieferumfang: die Bibliothek @noble/post-quantum unter MIT-Lizenz, deren Lizenztext jedem Download beiliegt. Integration, Lizenzsystem und Dokumentation sind vollständig eigener Code; sobald der eigene ML-KEM-Baustein den Prüfnachweis besteht, ersetzt er die Fremdbibliothek
    • Umfang der Unterstützung, Laufzeit und Aktualisierungen nach Absprache
    Angebot anfragen
    Serverfarm
    Beliebig viele eigene Systeme innerhalb Ihres Unternehmens.
    Preis auf Anfrage
    Wir nennen Ihnen den Preis nach einem kurzen Gespräch über Umfang und Einsatzzweck.
    • Beliebig viele eigene Systeme, auch Test- und Abnahmeumgebungen
    • Vollständiger Quellcode, unminifiziert und kommentiert
    • Technische Dokumentation auf Deutsch, einschließlich der Grenzen des Verfahrens
    • Eingebauter Selbsttest und Platzhalter-Erkennung
    • Heute im Lieferumfang: die Bibliothek @noble/post-quantum unter MIT-Lizenz, deren Lizenztext jedem Download beiliegt. Integration, Lizenzsystem und Dokumentation sind vollständig eigener Code; sobald der eigene ML-KEM-Baustein den Prüfnachweis besteht, ersetzt er die Fremdbibliothek
    • Umfang der Unterstützung, Laufzeit und Aktualisierungen nach Absprache
    Angebot anfragen
    Weiterverkauf / OEM
    Einbau in ein Produkt, das Sie selbst an Ihre Kunden ausliefern.
    Preis auf Anfrage
    Wir nennen Ihnen den Preis nach einem kurzen Gespräch über Umfang und Einsatzzweck.
    • Weitergabe an Ihre Kunden als Teil Ihres Produkts
    • Vollständiger Quellcode, unminifiziert und kommentiert
    • Technische Dokumentation auf Deutsch, einschließlich der Grenzen des Verfahrens
    • Eingebauter Selbsttest und Platzhalter-Erkennung
    • Weitergabe an Ihre Kunden; solange die Fremdbibliothek im Lieferumfang ist, muss ihr MIT-Lizenztext mitgehen – der Download bringt ihn automatisch mit
    • Umfang der Unterstützung, Laufzeit und Aktualisierungen nach Absprache
    Angebot anfragen

    Alle Stufen enthalten dieselbe Technik. Es gibt keine abgespeckte Verschlüsselung für die kleinere Lizenz.

    Zum Stand der Entwicklung, offen gesagt: der post-quantum Baustein (ML-KEM-768 nach der Spezifikation NIST FIPS 203) entsteht als Eigenentwicklung von INX System Solution. Geprüft ist er byteweise gegen die Vektoren einer etablierten Umsetzung (@noble/post-quantum); die offiziellen Prüfvektoren des NIST-Programms (ACVP) hat er noch nicht durchlaufen, eine CAVP-Validierung gibt es nicht. Bis dieser Nachweis vorliegt, wird er nicht ausgeliefert und die Live-Diagnose meldet für diesen Schritt keinen Erfolg. Wir liefern lieber später als mit einer Zusage, die wir noch nicht halten können.

    Grenzen und Voraussetzungen

    Was dieses Verfahren nicht leistet. Diese Liste gehört in jedes Gespräch: wer sie verschweigt, verkauft etwas anderes als beschrieben.

    1 ML-KEM steckt nicht in Web Crypto – der Baustein muss mit

    Die Web Crypto API enthält kein ML-KEM und wird es auf absehbare Zeit nicht enthalten. Der post-quantum Anteil kommt ausschließlich aus der mitgelieferten Datei von INX System Solution. Fehlt sie, gibt es keinen post-quantum Schutz – und das SDK sagt das dann klar, statt weiterzuarbeiten.

    2 Kein Ersatz für Transportverschlüsselung

    Das SDK verschlüsselt Inhalte, nicht Verbindungen. HTTPS bleibt Pflicht – schon deshalb, weil Web Crypto ohne sicheren Kontext gar nicht bereitsteht. Wer das SDK selbst über eine manipulierbare Verbindung ausliefert, kann sich alles Weitere sparen: dann tauscht ein Angreifer einfach das Skript aus.

    3 Keine Signaturen, keine Absenderprüfung

    ML-DSA und SLH-DSA sind nicht Teil des Pakets. Jeder, der den öffentlichen Schlüssel kennt, kann einen gültigen Umschlag erzeugen. Ein Umschlag beweist, dass ihn jemand für diesen Empfänger erstellt hat – nicht, wer. Wer Absenderechtheit braucht, muss sie zusätzlich bauen.

    4 Kein Vertrauensmodell, keine Schlüsselverteilung

    Das SDK sagt nichts darüber, ob ein öffentlicher Schlüssel wirklich dem gewünschten Gegenüber gehört. Wird er auf dem Weg ausgetauscht, verschlüsselt der Absender einwandfrei – an den Angreifer. Fingerabdrücke, Vergleich über einen zweiten Kanal oder Zertifikate sind Aufgabe der einbindenden Anwendung.

    5 Schlüsselverwaltung bleibt bei Ihrer Anwendung

    Wo private Schlüssel liegen, wie lange und wie sie gewechselt werden, entscheidet das SDK nicht. Ausgegeben werden sie im Klartext; sie danach zu schützen ist Ihre Aufgabe. In JavaScript gibt es außerdem keinen sicheren Speicher, und gegen Schadcode auf derselben Seite schützt kein Verschlüsselungsverfahren.

    6 Keine dauerhafte Vorwärtssicherheit

    Der X25519-Anteil des Absenders ist flüchtig, der Schlüssel des Empfängers ist langlebig. Wird der private Empfängerschlüssel später bekannt, sind alle zuvor an ihn gerichteten Umschläge lesbar. Echte Vorwärtssicherheit braucht regelmäßigen Schlüsselwechsel oder ein Ratschenverfahren – beides ist hier nicht enthalten.

    7 Kein Schutz gegen Wiedereinspielen, der Zeitstempel beweist nichts

    Geschützt sind nur die Nutzdaten. Kennung, Version und Zeitstempel liegen außerhalb des Prüfwerts und können unbemerkt verändert werden. Ein unverändert erneut eingespielter Umschlag entschlüsselt klaglos ein zweites Mal. Wer Reihenfolge oder Einmaligkeit braucht, legt einen Zähler in die Nutzdaten.

    8 Metadaten bleiben sichtbar

    Die Länge der Nutzdaten ist am Umschlag ablesbar, ebenso Zeitpunkt und Umstände der Übertragung. Wer das verbergen muss, füllt die Nutzdaten auf feste Größen auf.

    9 Keine Zusagen zu Seitenkanälen

    Vergleiche laufen ohne frühen Abbruch, und die Umsetzung bemüht sich um laufzeitkonstante Verarbeitung. In JavaScript ist Konstanzeit aber nicht garantiert. Gegen einen Angreifer mit feiner Zeitmessung auf demselben Gerät ist keine Zusage möglich.

    10 Keine Zertifizierung, kein externer Prüfbericht

    Es liegt keine BSI-Zertifizierung vor und kein externer Kryptoaudit. ML-KEM-768 ist von der NIST standardisiert (FIPS 203) – das betrifft das Verfahren, nicht diese Umsetzung. Wer eine bescheinigte Umsetzung braucht, braucht eine Zertifizierung; dieses SDK ist keine.

    11 Was bleibt

    Nach allen Abstrichen bleibt ein belastbarer Kern: ein hybrides Schlüsselgeheimnis aus X25519 und NIST-standardisiertem ML-KEM-768, das nur fällt, wenn beide Verfahren fallen – und damit wirksamer Schutz gegen „heute mitschneiden, später entschlüsseln“. Das ist eine ehrliche und starke Aussage. Mehr braucht es nicht.

    Voraussetzungen

    Der begrenzende Baustein ist X25519 in der Web Crypto API. ML-KEM-768 stellt keine Anforderung an den Browser – es läuft als JavaScript aus der mitgelieferten Datei.

    Browser ab Version
    Chrome, Edge121
    Firefox130
    Safari17.4

    HTTPS

    Zusätzlich Pflicht: Auslieferung über HTTPS. Ohne sicheren Kontext stellt der Browser die Web Crypto API nicht bereit. Fehlt X25519, bricht das SDK ab – es gibt bewusst keinen Notbehelf auf ein schwächeres Verfahren, weil das die Zusage des Hybrids aushebeln würde, ohne dass es jemand merkt.

    Lizenz oder technische Rückfrage

    Nutzen Sie das Kontaktformular von INX System Solution. Bitte im Betreff „QuantumShield SDK“ angeben – dann landet Ihre Anfrage direkt bei der technischen Bearbeitung.

    Betreff: QuantumShield SDK
    Zum Kontaktformular

    Oder direkt per E-Mail: info@inxsystemsolution.com