Kryptografie · Post-Quanten-Verfahren
Post-Quanten-Kryptografie für bestehende Software: ML-DSA und ML-KEM
Neue Verfahren in vorhandene Systeme bringen – ohne sie neu zu schreiben. Im eigenen Prozess oder als eigener Prozess.
Zwei Produkte: eine .NET-Bibliothek ergänzt vorhandenen Code an der einzelnen Aufrufstelle um die Signatur ML-DSA und die Schlüsselkapselung ML-KEM. Ein Krypto-Dienst bietet dieselben Verfahren als eigener Prozess an, für eingebettete und industrielle Systeme auf L4Re oder Windows. Beide sind als Vorschau veröffentlicht.
- Ihre Anwendung oder Komponente
- Bibliothek oder Krypto-Dienst
- OpenSSL ab 3.5
Den Post-Quanten-Anteil rechnet in beiden Fällen OpenSSL. Die Produkte unterscheiden sich darin, wo die Kryptografie läuft und wer die Schlüssel hält.
Ausgangslage
Der Wechsel beginnt in Software, die heute mit RSA und ECDSA arbeitet
Warum schon jetzt? Wegen „Store now, decrypt later“: Wer heute verschlüsselte Daten mitschneidet, kann sie entschlüsseln, sobald es einen ausreichend leistungsfähigen Quantencomputer gibt. Die EU-Roadmap zur Post-Quanten-Kryptografie sieht deshalb vor, Anwendungen mit hohem Risiko spätestens bis Ende 2030 umzustellen. Welche weiteren Fristen gelten und woher sie stammen, steht unter BSI TR-02102 und Post-Quanten-Fristen.
Welches Verfahren in Ihren Systemen wo steckt, ist die erste Frage jedes Wechsels zu Post-Quanten-Verfahren. Die zweite: Wie kommt das neue Verfahren hinein? Dabei treffen meist mehrere Bedingungen zusammen:
- Zertifikate, Signaturen und verschlüsselte Nachrichten sollen auch gegen künftige Quantenrechner halten.
- Die Anwendung neu zu schreiben, kommt nicht in Frage.
- Gegenstellen kennen nur klassische Verfahren und müssen die Daten trotzdem weiter lesen können.
- In eingebetteten Systemen bringt jede Komponente, die selbst eine Kryptobibliothek einbindet, eigene Schlüsselablage, eigene Fehlerbehandlung und eigene Aktualisierungen mit.
Welches Produkt?
Was möchten Sie tun?
- Eine .NET-Anwendung um Post-Quanten-Verfahren ergänzenZertifikate, Signaturen und verschlüsselte Nachrichten auf .NET Framework ab 4.6.2, .NET Core 3.1 oder .NET 8 – Aufruf für Aufruf. Die Bibliothek WKL.System.Security.Cryptography.
- Die erste hybride Zertifikatskette erstellenRSA oder ECDSA und zusätzlich ML-DSA: Zertifikate, die klassische Prüfer weiter lesen.
- Nachrichten und Dokumente signieren oder verschlüsselnDaten, CMS-Nachrichten und XML-Dokumente signieren, CMS verschlüsseln, einen hybriden Schlüssel vereinbaren, Blazor.
- Kryptografie als eigenen Prozess betreibenKomponenten schicken eine Anfrage und erhalten das Ergebnis; private Schlüssel verlassen den Dienst nicht. Der WvdS Crypto Service.
- Den Dienst aus einem Programm ansprechenÜber das Binärprotokoll unter L4Re oder über JSON-Zeilen an einer Named Pipe unter Windows.
- Eine eigene Anbindung prüfenTestvektoren zeigen vollständige Anfragen und Antworten Byte für Byte.
- Verbindungen zu Partnerorganisationen absichernVertrauen je Partner vereinbaren, zweckgebunden und widerrufbar, und TLS 1.3 um ein zusätzliches Post-Quanten-Geheimnis ergänzen. TrustBridge, in Entwicklung.
Wann keines von beiden hilft: Post-Quanten-HTTPS ist Aufgabe einer eigenen Transportschicht; die Bibliothek enthält keinen TLS-Handschlag. Für Verbindungen zwischen Organisationen ergänzt TrustBridge TLS 1.3 um ein zusätzliches Post-Quanten-Geheimnis. Langlebige Signaturschlüssel, etwa einer Zertifizierungsstelle, gehören in ein Hardware-Sicherheitsmodul. Und Code, der Schlüssellängen fest verdrahtet oder die Abstraktionen von .NET umgeht, gewinnt durch ein zusätzliches Argument keinen Schutz.
Zwei Wege
Im eigenen Prozess oder als eigener Prozess
Beide lassen den Post-Quanten-Anteil von OpenSSL rechnen. Sie unterscheiden sich darin, wo die Kryptografie läuft und wer die Schlüssel hält.
Die Bibliothek: im Prozess Ihrer .NET-Anwendung
Ihre .NET-Anwendung
- Zertifikate
- CMS-Nachrichten
- XML-Signaturen
ein Aufruf ohne CryptoMode geht unverändert an .NET
derselbe Aufruf mit dem Argument CryptoMode
WKL.
- klassischer Anteil: .NET
- Post-Quanten-Anteil: OpenSSL ab 3.5
- Formate, die klassische Prüfer lesen
Schlüssel im Schlüsselspeicher des Betriebssystems oder als PFX-Datei
Der Krypto-Dienst: als eigener Prozess
Ihre Komponente
- eine Task unter L4Re, etwa ein Gateway
- ein Programm unter Windows
keine Kryptobibliothek; statt des privaten Schlüssels nur eine Kennung
L4Re: Binärprotokoll über geteilten Speicher · Windows: JSON-Zeilen über eine Named Pipe
WvdS Crypto Service
- AES-256-GCM
- ML-DSA
- ML-KEM
- HKDF-SHA256
Schlüssel nur im Arbeitsspeicher; nach einem Neustart verloren
Was „ohne neu zu schreiben“ bei der Bibliothek heißt: Ihre Erweiterungsmethoden tragen denselben Namen und dieselben Parameter wie in .NET und hängen ein Argument an.
Der C#-Compiler bindet einen Aufruf ohne dieses Argument immer an .NET; bestehender Code verhält sich Bit für Bit wie bisher. So lässt sich eine Anwendung Aufruf für Aufruf ergänzen. Betriebsarten und Aufrufbindung
// Bindet an .NET – unverändert.request.CreateSelfSigned( notBefore, notAfter); // Bindet an die Bibliothek:// klassisch plus ML-DSA.request.CreateSelfSigned( notBefore, notAfter, CryptoMode.Hybrid);
CryptoMode führt in die Bibliothek.Bibliothek und Dienst im Vergleich
| Gesichtspunkt | Bibliothek WKL. | WvdS Crypto Service |
|---|---|---|
| gedacht für | .NET-Anwendungen: .NET Framework 4.6.2 bis 4.8, .NET Core 3.1, .NET 8, Blazor | eingebettete und industrielle Systeme auf dem Mikrokern L4Re (x86_64, aarch64) oder unter Windows x86_64 |
| angesprochen über | Erweiterungsmethoden mit demselben Namen wie in .NET und dem zusätzlichen Argument CryptoMode | L4Re: Binärprotokoll über geteilten Speicher · Windows: JSON-Zeilen über eine Named Pipe |
| Verfahren | ML-DSA und ML-KEM, verbunden mit RSA, ECDSA oder ECDH; für Zertifikate, Sperrlisten, CMS, XML-Signaturen und PFX | AES-256-GCM, ML-DSA-44, -65 und -87, ML-KEM-512, -768 und -1024, HKDF-SHA256 |
| hybrid | ja; die Voreinstellung folgt BSI TR-02102-1 und erzeugt PQ nur zusammen mit einem klassischen Verfahren | nein; wer hybrid arbeiten will, kombiniert die Geheimnisse selbst |
| Schlüssel | im Schlüsselspeicher des Betriebssystems (Windows, Linux mit Secret Service) oder als PFX-Datei | nur im Arbeitsspeicher des Dienstes; nach einem Neustart verloren |
| OpenSSL | ab 3.5, nicht mitgeliefert; Installation und Sicherheitsupdates gehören zu Ihrem Betrieb | ab 3.5; die L4Re-Bauform baut OpenSSL beim Übersetzen mit |
Zur Bibliothek · Zum Krypto-Dienst · Die Bauformen des Dienstes im Vergleich
Was Sie vor dem Einsatz wissen sollten
Vorschau
Beide Produkte sind als Vorschau veröffentlicht. Schnittstellen, Protokolle und Datenformate können sich bis zur ersten freigegebenen Fassung ändern.
- Keine Zertifizierung. Weder die Bibliothek noch der Dienst ist nach FIPS 140-3 oder einem anderen Prüfschema zertifiziert. Dass die Voreinstellung der Bibliothek BSI TR-02102-1 folgt, ist keine Zulassung.
- Kein stiller Rückfall. Fordert ein Aufruf der Bibliothek einen Post-Quanten-Anteil an und kann ihn nicht erzeugen, scheitert er – ein rein klassisches Ergebnis liefert er nie.
- OpenSSL gehört zum Betrieb. Die Bibliothek liefert OpenSSL nicht mit; Installation ab 3.5 und Sicherheitsupdates spielen Sie selbst ein.
- Vorläufige Kennungen. Für PQ-Signaturen in CMS und XML vergibt noch keine Norm Kennungen. Solche Nachrichten prüfen nur Gegenstellen mit dieser Bibliothek; klassische Prüfer lesen sie weiterhin.
- Zwei Protokolle beim Dienst. Die Bauformen für L4Re und Windows verstehen nicht dieselben Nachrichten; ein Programm, das beide ansprechen soll, braucht zwei Anbindungen.
Alle Grenzen stehen auf den Übersichtsseiten: Bibliothek · Krypto-Dienst
In die Dokumentation einsteigen
| Sie möchten … | Bibliothek | Krypto-Dienst |
|---|---|---|
| prüfen, was Sie brauchen | Voraussetzungen | Voraussetzungen |
| zum ersten Ergebnis | Die erste hybride Zertifikatskette | Bauen und testen |
| verstehen, wie es arbeitet | Betriebsarten und Aufrufbindung | Schlüssel und ihre Ablage |
| Verfahren und Parameter wählen | Richtlinie für Post-Quanten-Verfahren | Verfahren und Parametersätze |
| nachschlagen | Referenz | Referenz |
| einen Fehler beheben | Fehlerbehebung | Fehlerbehebung |
Zwischen Organisationen
TrustBridge: Vertrauen je Partner, geschützt mit einem zusätzlichen Post-Quanten-Geheimnis
Für Unternehmen einer Lieferkette, deren Systeme miteinander arbeiten müssen – ohne gemeinsames Netz, zentrale Konten oder Zertifikate unklarer Herkunft. Jede Organisation behält ihre eigenen Identitäten, Schlüssel und Regeln; Vertrauen wird je Partner vereinbart, für einen Zweck und jederzeit widerrufbar. Die Verbindung läuft über TLS 1.3; Schlüsselagenten beider Seiten vereinbaren zusätzlich ein Post-Quanten-Geheimnis mit ML-KEM, das in den Handschlag eingeht. Wer die Verbindung heute aufzeichnet, müsste später beides brechen.
In Entwicklung
Die Dokumentation beschreibt den vollen Funktionsumfang.
Überblick · PQ-Schlüsselaustausch für TLS · Föderation · Betriebsmodelle
Welches Verfahren in Ihren Systemen wo steckt, ist die erste Frage jedes Wechsels. Die Bibliothek steht mit Voraussetzungen und Grenzen im Shop.
Die Bibliothek im Shop