WvdS Crypto Service – Überblick

Vorschau: Der Dienst ist als Vorschau veröffentlicht. Protokolle, Fehlercodes und Bauoptionen können sich bis zur ersten freigegebenen Fassung ändern. Die Grenzen am Ende dieser Seite gelten für den heutigen Stand.

graph LR
    subgraph L4Re["L4Re-Mikrokern"]
        C1["Ihre Task, z. B. ein Gateway"] -- "Binärprotokoll über geteilten Speicher" --> S1["Krypto-Dienst (l4re)"]
    end
    subgraph WIN["Windows"]
        C2["Ihr Programm"] -- "JSON-Zeilen über Named Pipe" --> S2["Krypto-Dienst (win)"]
    end
    S1 --> O1["OpenSSL"]
    S2 --> O2["OpenSSL"]

Bild: Zwei Bauformen desselben Dienstes. Beide halten die Schlüssel in ihrem eigenen Prozess und rechnen mit OpenSSL; sie unterscheiden sich in Transport und Nachrichtenformat.

Der WvdS Crypto Service ist ein Dienstprozess, der anderen Programmen kryptographische Operationen anbietet: AES-256-GCM, die Post-Quanten-Signatur ML-DSA (FIPS 204), die Post-Quanten-Schlüsselkapselung ML-KEM (FIPS 203) und die Schlüsselableitung HKDF-SHA256. Er richtet sich an Teams, die auf dem Mikrokern L4Re oder unter Windows ein eingebettetes oder industrielles System bauen und die Kryptographie nicht in jede Komponente einzeln einbinden wollen. Die Anwendung schickt eine Anfrage und erhält das Ergebnis; private Schlüssel verlassen den Dienstprozess nicht.

• Zwei Bauformen: l4re für den Mikrokern L4Re auf x86_64 und aarch64, angesprochen über einen geteilten Speicherbereich mit festem Binärformat; win für Windows x86_64, angesprochen über Named Pipes mit JSON. Was beide trennt, steht unter Bauformen im Vergleich.
• Post-Quanten-Verfahren: ML-DSA-44, -65 und -87 zum Signieren und Prüfen, ML-KEM-512, -768 und -1024 zum Kapseln und Entkapseln. Beide Verfahren rechnet OpenSSL.
• Schlüssel bleiben im Dienst: Der Dienst erzeugt Schlüsselpaare selbst und gibt nur eine Kennung und den öffentlichen Schlüssel heraus. Eine Operation mit dem privaten Schlüssel benennt den Schlüssel über diese Kennung.
• Schutz vor wiederholter Nonce: Bei AES-GCM merkt sich der Dienst die zuletzt benutzten Nonces je Schlüssel und weist eine Wiederholung ab.
• Begrenzung der Last: Beide Bauformen nehmen höchstens 60 000 Anfragen je 60 Sekunden an; die L4Re-Bauform begrenzt eine Nachricht zusätzlich auf 64 KiB Nutzdaten.
• Prüfbare Zusagen für Integratoren: Für die L4Re-Bauform beschreibt die C-Headerdatei wvds_crypto.h das Binärprotokoll verbindlich; Testvektoren in crypto_test_vectors.json zeigen vollständige Anfragen und Antworten Byte für Byte.

Ein Dienst statt vieler Einbindungen. Jede Komponente, die selbst OpenSSL einbindet, bringt eigene Schlüsselablage, eigene Fehlerbehandlung und eigene Aktualisierungen mit. Der Dienst bündelt das an einer Stelle. Die anfragende Komponente braucht keine Kryptobibliothek, nur den Transport.

Kennung statt Schlüssel. Eine Schlüsselerzeugung liefert eine zufällige 32-Bit-Kennung. Folgende Anfragen nennen diese Kennung; den privaten Schlüssel sieht die anfragende Seite nie. Einzelheiten: Schlüssel und ihre Ablage.

Feste Verfahren, offene Parametersätze. Der Dienst bietet alle drei Parametersätze von ML-DSA und ML-KEM an und überlässt die Wahl der anfragenden Seite. Welche davon die Technische Richtlinie BSI TR-02102-1 empfiehlt und was der Dienst noch nicht bietet, steht unter Verfahren und Parametersätze.

• Schlüssel nur im Arbeitsspeicher. Der Dienst speichert keinen Schlüssel dauerhaft. Nach einem Neustart sind alle Schlüssel und Kennungen verloren. Für langlebige Signaturschlüssel, etwa einer Zertifizierungsstelle, ist er deshalb nicht geeignet; solche Schlüssel gehören in ein Hardware-Sicherheitsmodul.
• AES über L4Re nur mit vorhandenem Schlüssel. Das Binärprotokoll kennt keine Anfrage, die einen AES-Schlüssel erzeugt oder einspielt. Über die L4Re-Bauform sind AES-Anfragen deshalb heute nicht nutzbar; die Windows-Bauform erzeugt AES-Schlüssel mit keygen.
• Kein hybrides Verfahren. Der Dienst kombiniert ML-KEM nicht mit einem klassischen Verfahren. Wer hybrid arbeiten will, kombiniert die Geheimnisse selbst.
• L4Re-Bauform als Linux-Programm. Die mitgelieferten Bauziele erzeugen Linux-Programme für x86_64 und aarch64. Läuft ein solches Programm nicht unter L4Re, führt es eine Vorführung der Verfahren aus und nimmt keine Anfragen an. Wie die Bauziele zusammenhängen, steht unter Bauformen im Vergleich.
• Zwei verschiedene Protokolle. Die Bauformen verstehen nicht dieselben Nachrichten. Ein Programm, das beide ansprechen soll, braucht zwei Anbindungen.
• Keine Zertifizierung. Der Dienst ist weder nach FIPS 140-3 noch nach einem anderen Prüfschema zertifiziert.

• Erste Schritte
• Konzepte
• Anleitungen
• Referenz
• Fehlerbehebung