WKL.System.Security.Cryptography – Überblick
Preview: Die Bibliothek ist als Vorschau veröffentlicht. Typen, Methoden und Datenformate können sich bis zur ersten freigegebenen Fassung ändern.
graph TD
APP["Ihre Anwendung: bestehender Code mit RSA, ECDSA, X509Certificate2, SignedCms, SignedXml"]
EXT["WKL-Erweiterungen: gleiche Methode, zusätzliches Argument CryptoMode"]
FW[".NET: klassischer Anteil, RSA, ECDSA, Zertifikate, CMS, XML"]
OSSL["OpenSSL ab 3.5: Post-Quanten-Anteil, ML-DSA, ML-KEM"]
APP -- "Aufruf ohne CryptoMode" --> FW
APP -- "Aufruf mit CryptoMode" --> EXT
EXT -- "klassischer Anteil" --> FW
EXT -- "PQ-Anteil" --> OSSL
Bild: Ein Aufruf ohne CryptoMode geht unverändert an .NET. Erst das zusätzliche Argument führt in die
Bibliothek, die den klassischen Anteil weiter von .NET und den Post-Quanten-Anteil von OpenSSL rechnen lässt.
WKL.System.Security.Cryptography ergänzt die Kryptografie von .NET um Post-Quanten-Verfahren (PQ): die Signatur ML-DSA (FIPS 204) und die Schlüsselkapselung ML-KEM (FIPS 203). Sie richtet sich an Teams, die Anwendungen auf .NET Framework ab 4.6.2 oder auf .NET 8 pflegen und dort Zertifikate, Signaturen und verschlüsselte Nachrichten gegen künftige Quantenrechner absichern müssen, ohne die Anwendung neu zu schreiben. Sie nehmen PQ dort auf, wo Sie es brauchen: an der einzelnen Aufrufstelle, mit einem Argument.
Wichtige Funktionen
- Voreinstellung nach BSI TR-02102-1: Ohne weitere Angabe erzeugt die Bibliothek nur Daten mit den PQ-Verfahren und Parametersätzen, die die Technische Richtlinie BSI TR-02102-1 (2026-01) empfiehlt. Alles darüber hinaus erlaubt die Anwendung ausdrücklich und erfährt jede Verwendung über ein Ereignis.
- Hybride und reine PQ-Zertifikate: Zertifikate, Sperrlisten und Zertifikatsanforderungen mit einer zusätzlichen ML-DSA-Signatur neben RSA oder ECDSA (hybrid) oder mit ML-DSA allein (nach RFC 9881).
- Kettenprüfung mit PQ-Anteil:
X509Chain.Buildprüft auf Wunsch nach der klassischen Prüfung jede ML-DSA-Signatur der Kette. - Signaturen: Rohe Signaturen als Composite ML-DSA (RSA oder ECDSA zusammen mit ML-DSA) oder als reines ML-DSA; PQ-Signaturen in CMS-Nachrichten (
SignedCms) und XML-Dokumenten (SignedXml). - Verschlüsselung: CMS-Nachrichten für Empfänger mit ML-KEM- oder Composite-ML-KEM-Schlüssel (
KemEnvelopedCms); hybride Schlüsselvereinbarung aus ECDH und ML-KEM, kombiniert mit KeyCombine nach NIST SP 800-227. - Schlüsseltransport und -ablage: PFX-Dateien tragen den PQ-Schlüssel als gewöhnliche PKCS#12-Schlüsseltasche, verschlüsselt mit AES-256; andere Programme lesen die Datei weiter. Neben dem Zertifikatsspeicher schützt der Schlüsselspeicher des Betriebssystems die PQ-Schlüssel.
- Ein Stand für alle Zielsysteme: dieselben Funktionen auf .NET Framework 4.6.2 bis 4.8, .NET Core 3.1 und .NET 8. Wo .NET Framework 4.6.2 einen Typ noch nicht kennt, etwa
CertificateRequest, übernehmen eigene Bausteine der Bibliothek; was sich je Zielsystem unterscheidet, steht unter Zielsysteme. - Blazor: Blazor Server nutzt die Bibliothek wie jede andere .NET-Anwendung. In Blazor WebAssembly stehen ML-DSA und ML-KEM über eine eigene asynchrone Schnittstelle bereit, die OpenSSL als WebAssembly im Browser ausführt.
Grundkonzepte
Ergänzen statt ersetzen. Die Bibliothek ändert keine Methode von .NET. Sie bietet Erweiterungsmethoden
mit demselben Namen und denselben Parametern wie das Original und hängt ein optionales Argument
CryptoMode? mode an. Der C#-Compiler bindet einen Aufruf ohne dieses Argument immer an die Methode von
.NET; bestehender Code verhält sich deshalb Bit für Bit wie bisher. Einzelheiten:
Betriebsarten und Aufrufbindung.
Empfehlungen als Voreinstellung. Was die Bibliothek ohne Freischaltung erzeugt, folgt BSI TR-02102-1: ML-DSA-65 und ML-DSA-87, ML-KEM-768 und ML-KEM-1024, jeweils zusammen mit einem klassischen Verfahren. Vorhandene Daten mit anderen Verfahren bleiben prüf- und lesbar. Einzelheiten: Richtlinie für Post-Quanten-Verfahren.
Gleiches Verhalten wie das Original. Mit CryptoMode behält eine Erweiterung Rückgabetyp, Ausnahmen
und Fehlermeldung der Methode von .NET; nur der Inhalt ist klassisch, hybrid oder rein PQ. Schlägt der
angeforderte PQ-Anteil fehl, scheitert der Aufruf so, wie das Original scheitern würde. Ein stiller
Rückfall auf ein rein klassisches Ergebnis ist ausgeschlossen.
Arbeitsteilung. Den klassischen Anteil (RSA, ECDSA, AES, Zertifikatsprüfung) rechnet weiterhin .NET. Den PQ-Anteil rechnet ausschließlich OpenSSL, ab Version 3.5. Die Bibliothek setzt beides zu den Datenformaten zusammen, die klassische Prüfer weiterhin lesen; welche Formate das sind, beschreibt Formate der Post-Quanten-Anteile.
Grenzen
- OpenSSL gehört zum Betrieb. Die Bibliothek liefert OpenSSL nicht mit. Sie brauchen eine Installation ab 3.5, deren Bibliotheken zur Prozessarchitektur passen und ML-DSA und ML-KEM anbieten, und spielen deren Sicherheitsupdates selbst ein.
- Nur über die Abstraktionen von .NET. Code, der Schlüssellängen fest verdrahtet,
RSAundECDsaumgeht oder Algorithmusnamen aus Zeichenketten zusammensetzt, gewinnt durch ein zusätzliches Argument keinen PQ-Schutz. - Kein TLS. Die Bibliothek enthält Algorithmen, Schlüssel, Zertifikate und Nachrichtenformate, aber keinen TLS-Handschlag. Post-Quanten-HTTPS ist Aufgabe einer eigenen Transportschicht.
- Vorläufige Kennungen. Die CMS-Attribute für PQ-Signaturen und die XML-Signaturverfahren für ML-DSA tragen vorläufige Kennungen, weil dafür noch keine Norm Kennungen vergibt. Solche Nachrichten prüfen nur Gegenstellen, die diese Bibliothek verwenden; klassische Prüfer lesen sie weiterhin.
- Schlüsselablage unter Windows und Linux. PQ-Schlüssel neben dem Zertifikatsspeicher legt die Bibliothek nur ab, wo ein Schlüsselspeicher des Betriebssystems sie schützt: unter Windows und unter Linux mit Secret Service. Auf anderen Systemen bewahren Sie die Schlüssel als PFX-Datei auf; siehe Schlüssel und ihre Ablage.
- Keine Zertifizierung. Die Voreinstellung folgt den Empfehlungen von BSI TR-02102-1. Sie ist keine Zulassung und keine Zertifizierung nach einem Prüfschema.