Plattformübergreifend Kryptografie in .NET

Kryptografische Vorgänge in .NET werden von Betriebssystembibliotheken durchgeführt. Diese Abhängigkeit hat Vorteile:

• .NET-Apps profitieren von der Zuverlässigkeit des Betriebssystems. Kryptografiebibliotheken vor Sicherheitsrisiken zu schützen, hat für Betriebssystemhersteller eine hohe Priorität. Dazu stellen sie Updates bereit, die Systemadministratoren anwenden sollten.
• .NET-Apps haben Zugriff auf FIPS-validierte Algorithmen, wenn die Betriebssystembibliotheken FIPS-validiert sind.

Die Abhängigkeit von Betriebssystembibliotheken bedeutet auch, dass .NET-Apps nur kryptografische Features verwenden können, die vom Betriebssystem unterstützt werden. Obwohl alle Plattformen bestimmte Kernfeatures unterstützen, können einige Features, die unterstützt werden, .NET auf einigen Plattformen nicht verwendet werden. In diesem Artikel werden die Features beschrieben, die auf jeder Plattform unterstützt werden.

In diesem Artikel wird davon ausgegangen, dass Sie mit Kryptografie in .NET vertraut sind. Weitere Informationen finden Sie unter .NET-Kryptografiemodell und .NET-Kryptografiedienste.

Hash- und MAC-Algorithmen (Message Authentication)

Alle Hash-Algorithmus- und HMAC-Klassen (Hash-Based Message Authentication), einschließlich der *Managed-Klassen, verweisen auf die Betriebssystembibliotheken. Die einzige Ausnahme ist .NET in Browser WASM. In Browser WASM werden SHA-1, SHA-2-256, SHA-2-384, SHA-2-512 und deren HMAC-Äquivalente mithilfe von verwaltetem Code implementiert.

¹Ab .NET 9 verfügbar.

²Streaming extensible Output Function (XOF) ist ab .NET 9 verfügbar. Unter Linux erfordert dies OpenSSL 3.3.

Symmetrische Verschlüsselung

Die zugrunde liegenden Verschlüsselungsverfahren und Verkettungen werden von den Systembibliotheken durchgeführt.

Authentifizierte Verschlüsselung

Die Unterstützung der authentifizierten Verschlüsselung (AE) wird für AES-CCM, AES-GCM und ChaCha20Poly1305 jeweils über die Klassen System.Security.Cryptography.AesCcm, System.Security.Cryptography.AesGcm und System.Security.Cryptography.ChaCha20Poly1305 bereitgestellt.

Da für die authentifizierte Verschlüsselung neuere Plattform-APIs erforderlich sind, um den Algorithmus zu unterstützen, ist die Unterstützung möglicherweise nicht auf allen Plattformen verfügbar. Die statische Eigenschaft IsSupported der Klassen für den Algorithmus kann zur Laufzeit verwendet werden, um zu erkennen, ob die aktuelle Plattform den Algorithmus unterstützt oder nicht.

AES-CCM unter macOS

Vor .NET 10 funktionierte AES-CCM, wenn eine unterstützte Version von OpenSSL vorhanden war und das dynamische Bibliotheksladeprogramm sie finden konnte. Die OpenSSL-Unterstützung unter macOS wurde in .NET 10 entfernt.

AES-GCM und ChaCha20Poly1305 unter iOS, tvOS und MacCatalyst

Die Unterstützung für AES-GCM und ChaCha20Poly1305 steht ab .NET 9 unter iOS und tvOS 13.0 und höher sowie in allen Versionen von MacCatalyst zur Verfügung.

AES-CCM-Schlüssel, Nonces und Tags

• Schlüsselgrößen

  AES-CCM kann mit 128-, 192- und 256-Bit-Schlüsseln verwendet werden.

• Nonce-Größen

  Die Klasse AesCcm unterstützt Nonces mit 56, 64, 72, 80, 88, 96 und 104 Bit (7, 8, 9, 10, 11, 12 und 13 Byte).

• Taggrößen

  Die Klasse AesCcm unterstützt das Erstellen oder Verarbeiten von Tags mit 32, 48, 64, 80, 96, 112 und 128 Bit (4, 8, 10, 12, 14 und 16 Byte).

AES-GCM-Schlüssel, Nonces und Tags

• Schlüsselgrößen

  AES-GCM kann mit 128-, 192- und 256-Bit-Schlüsseln verwendet werden.

• Nonce-Größen

  Die Klasse AesGcm unterstützt nur Nonces mit 96 Bit (12 Byte).

• Taggrößen unter Windows und Linux: Die Klasse AesGcm unterstützt das Erstellen oder Verarbeiten von Tags mit 96, 104, 112, 120 und 128 Bit (12, 13, 14, 15 und 16 Byte). Auf Apple-Plattformen ist die Tag-Größe aufgrund von Einschränkungen des CryptoKit-Frameworks auf 128 Bit (16 Byte) begrenzt.

ChaCha20Poly1305-Schlüssel, -Nonces und -Tags

ChaCha20Poly1305 hat eine feste Größe für das Schlüssel-, Nonce- und Authentifizierungstag. ChaCha20Poly1305 verwendet immer einen 256-Bit-Schlüssel, eine 96-Bit-Nonce (12 Byte)- und ein 128-Bit-Tag (16 Byte).

Asymmetrische Kryptografie

Dieser Abschnitt enthält die folgenden Unterabschnitte:

• RSA-
• ECDSA
• ECDH
• DSA

RSA

Die RSA-Schlüsselgenerierung (Rivest–Shamir–Adleman) wird von den Betriebssystembibliotheken durchgeführt und unterliegt deren Größenbeschränkungen und Leistungsmerkmalen.

RSA-Schlüsselvorgänge werden von den Betriebssystembibliotheken ausgeführt, und die Typen von Schlüsseln, die geladen werden können, unterliegen den Betriebssystemanforderungen.

.NET macht keine "rohen" (ungespeicherten) RSA-Vorgänge verfügbar.

Die Unterstützung für Abstand und Digest variiert je nach Plattform:

¹ Windows CryptoAPI (CAPI) ist in der Lage, eine PKCS1-Signatur mit einem SHA-2-Algorithmus zu erstellen. Das einzelne RSA-Objekt kann jedoch in einen Kryptografiedienstanbieter (CSP) geladen werden, der es nicht unterstützt.

RSA unter Windows

• Windows CryptoAPI (CAPI) wird immer verwendet, wenn new RSACryptoServiceProvider() verwendet wird.
• Windows Cryptography API Next Generation (CNG) wird immer verwendet, wenn new RSACng() verwendet wird.
• Das von RSA.Create zurückgegebene Objekt wird intern von Windows CNG unterstützt. Diese Verwendung von Windows CNG ist ein Implementierungsdetail und kann geändert werden.
• Die GetRSAPublicKey-Erweiterungsmethode für X509Certificate2 gibt eine RSACng-Instanz zurück. Diese Verwendung von RSACng ist ein Implementierungsdetail und kann geändert werden.
• Die GetRSAPrivateKey-Erweiterungsmethode für X509Certificate2 bevorzugt derzeit eine RSACng-Instanz, aber wenn RSACng den Schlüssel nicht öffnen kann, wird es mit RSACryptoServiceProvider versucht. Der bevorzugte Anbieter ist ein Implementierungsdetail und kann geändert werden.

RSA-natives Interop

.NET macht Typen verfügbar, damit Programme mit den Betriebssystembibliotheken zusammenarbeiten können, die vom .NET-Kryptografiecode verwendet werden. Die beteiligten Typen werden nicht zwischen Plattformen übersetzt und sollten nur bei Bedarf direkt verwendet werden.

¹ Unter anderen Betriebssystemen als Windows kann RSACryptoServiceProvider zur Kompatibilität mit vorhandenen Programmen verwendet werden. In diesem Fall löst jede Methode, die Betriebssystem-Interop erfordert, z. B. das Öffnen eines benannten Schlüssels, eine PlatformNotSupportedException aus.

² Unter macOS funktionierte vor .NET 10, RSAOpenSsl wenn OpenSSL installiert wurde und eine entsprechende libcrypto dylib über das laden der dynamischen Bibliothek gefunden werden konnte. Diese Unterstützung wurde in .NET 10 entfernt.

ECDSA

Die ECDSA-Schlüsselgenerierung (Elliptic Curve Digital Signature Algorithm) erfolgt durch die Betriebssystembibliotheken und unterliegt deren Größenbeschränkungen und Leistungsmerkmalen.

ECDSA-Schlüsselkurven werden von den Betriebssystembibliotheken definiert und unterliegen deren Einschränkungen.

¹ Nicht alle Linux-Verteilungen unterstützen die gleichen benannten Kurven.

² Unterstützung für benannte Kurven wurde Windows CNG in Windows 10 hinzugefügt. Weitere Informationen finden Sie unter Benannte elliptische Kurven in CNG. Benannte Kurven sind in früheren Versionen von Windows nicht verfügbar, mit Ausnahme von drei Kurven in Windows 7.

³ Für den Export mit expliziten Kurvenparametern ist die Unterstützung der Betriebssystembibliothek erforderlich, die unter Apple-Plattformen oder früheren Versionen von Windows nicht verfügbar ist.

⁴ Die Android-Unterstützung für einige Kurven hängt von der Android-Version ab. Android-Vertriebspartner können auch Kurven aus ihrem Android-Build hinzufügen oder entfernen.

ECDSA-natives Interop

.NET macht Typen verfügbar, damit Programme mit den Betriebssystembibliotheken zusammenarbeiten können, die vom .NET-Kryptografiecode verwendet werden. Die betroffenen Typen werden nicht zwischen Plattformen übersetzt und sollten nur bei Bedarf und direkt verwendet werden.

Auf macOS funktionierte ECDsaOpenSsl, bevor .NET 10 erschien, wenn OpenSSL installiert war und eine entsprechende libcrypto dylib durch das dynamische Laden von Bibliotheken gefunden werden konnte. Diese Unterstützung wurde in .NET 10 entfernt.

ECDH

Die ECDH-Schlüsselgenerierung (Elliptic Curve Diffie-Hellman) erfolgt durch die Betriebssystembibliotheken und unterliegt deren Größenbeschränkungen und Leistungsmerkmalen.

Die ECDiffieHellman-Klasse unterstützt den Rohwert der ECDH-Berechnung sowie durch die folgenden Schlüsselableitungsfunktionen:

• HASH(Z)
• HASH(vorangestellt || Z || append)
• HMAC(key, Z)
• HMAC(Schlüssel, vorangestellt || Z || append)
• HMAC(Z, Z)
• HMAC(Z, vorangestellt || Z || append)
• Tls11Prf(label, seed)

ECDH-Schlüsselkurven werden von den Betriebssystembibliotheken definiert und unterliegen deren Einschränkungen.

¹ Nicht alle Linux-Verteilungen unterstützen die gleichen benannten Kurven.

² Unterstützung für benannte Kurven wurde Windows CNG in Windows 10 hinzugefügt. Weitere Informationen finden Sie unter Benannte elliptische Kurven in CNG. Benannte Kurven sind in früheren Versionen von Windows nicht verfügbar, mit Ausnahme von drei Kurven in Windows 7.

³ Für den Export mit expliziten Kurvenparametern ist die Unterstützung der Betriebssystembibliothek erforderlich, die unter Apple-Plattformen oder früheren Versionen von Windows nicht verfügbar ist.

⁴ Die Android-Unterstützung für einige Kurven hängt von der Android-Version ab. Android-Vertriebspartner können auch Kurven aus ihrem Android-Build hinzufügen oder entfernen.

ECDH-natives Interop

.NET macht Typen verfügbar, damit Programme mit den von .NET verwendeten Betriebssystembibliotheken zusammenarbeiten können. Die betroffenen Typen werden nicht zwischen Plattformen übersetzt und sollten nur bei Bedarf und direkt verwendet werden.

* Auf macOS funktionierte ECDiffieHellmanOpenSsl vor .NET 10, wenn OpenSSL installiert war und eine entsprechende libcrypto dylib über das Laden der dynamischen Bibliothek gefunden werden konnte. Diese Unterstützung wurde in .NET 10 entfernt.

DSA

Die DSA-Schlüsselgenerierung (Digital Signature Algorithm) erfolgt durch die Systembibliotheken und unterliegt deren Größenbeschränkungen und Leistungsmerkmalen.

* macOS lädt DSA-Schlüssel, die größer als 1024 Bit sind, aber das Verhalten dieser Schlüssel ist nicht definiert. Sie verhalten sich nicht gemäß FIPS 186-3.

DSA unter Windows

• Windows CryptoAPI (CAPI) wird immer verwendet, wenn new DSACryptoServiceProvider() verwendet wird.
• Windows Cryptography API Next Generation (CNG) wird immer verwendet, wenn new DSACng() verwendet wird.
• Das von DSA.Create zurückgegebene Objekt wird intern von Windows CNG unterstützt. Diese Verwendung von Windows CNG ist ein Implementierungsdetail und kann geändert werden.
• Die GetDSAPublicKey-Erweiterungsmethode für X509Certificate2 gibt eine DSACng-Instanz zurück. Diese Verwendung von DSACng ist ein Implementierungsdetail und kann geändert werden.
• Die GetDSAPrivateKey-Erweiterungsmethode für X509Certificate2 bevorzugt eine DSACng-Instanz, aber wenn DSACng den Schlüssel nicht öffnen kann, wird es mit DSACryptoServiceProvider versucht. Der bevorzugte Anbieter ist ein Implementierungsdetail und kann geändert werden.

DSA-natives Interop

.NET macht Typen verfügbar, damit Programme mit den Betriebssystembibliotheken zusammenarbeiten können, die vom .NET-Kryptografiecode verwendet werden. Die betroffenen Typen werden nicht zwischen Plattformen übersetzt und sollten nur bei Bedarf und direkt verwendet werden.

¹ Unter anderen Betriebssystemen als Windows kann DSACryptoServiceProvider zur Kompatibilität mit vorhandenen Programmen verwendet werden. In diesem Fall löst jede Methode, die System-Interop erfordert, z. B. das Öffnen eines benannten Schlüssels, eine PlatformNotSupportedException aus.

² Unter macOS funktionierte vor .NET 10, DSAOpenSsl wenn OpenSSL installiert wurde und eine entsprechende libcrypto dylib über das laden der dynamischen Bibliothek gefunden werden konnte. Diese Unterstützung wurde in .NET 10 entfernt.

Post-Quantum-Kryptografie

Post-Quantum-Algorithmen sind ab .NET 10 verfügbar. Sie sind auch für .NET Framework mit dem Microsoft.Bcl.Cryptography NuGet-Paket verfügbar. Die folgende Unterstützungstabelle zeigt die Plattformunterstützung für die integrierten kryptografischen Komponenten des Betriebssystems, wie die aus Generate oder ImportFromPem erstellten. Implementierungen, die von der Basisklasse abgeleitet werden, weisen möglicherweise unterschiedliche Unterstützungsverhalten auf.

Für die integrierten Algorithmen ist eine IsSupported statische Eigenschaft verfügbar, um festzustellen, ob die Plattform einen der Parametersätze unterstützt.

Die nativen Interoptypen für Post-Quantum-Algorithmen unterstützen die Schlüsselgenerierung oder den Import nicht. Sie sind speziell für Interoperabilitätsszenarien mit den systemeigenen Plattformtypen vorhanden, z. B. in EVP_PKEY OpenSSL oder CngKey unter Windows.

ML-KEM

Systemeigene Interoperabilitäts-ML-KEM

• MLKemOpenSsl: OpenSSL 3.5.0+
• MLKemCng: Windows 11-Insider (neueste)

ML-DSA

ML-DSA hat eine Pure-Variante und eine Prehash-Variante (HashML-DSA). Die folgende Tabelle spiegelt sowohl die reinen als auch die Prähash-Varianten wider.

¹ Externe Mu-Unterstützung ist nur für das Signieren und Verifizieren von Mu. Die Berechnung von Mu wird nicht unterstützt.

Native Interop-ML-DSA

• MLDsaOpenSsl: OpenSSL 3.5.0+
• MLDsaCng: Windows 11-Insider (neueste Version)

SLH-DSA

SLH-DSA hat eine unverfälschte und Prähash-Variante (HashSLH-DSA). Die folgende Tabelle spiegelt sowohl die reinen als auch die Prähash-Varianten wider.

Systemeigene Interoperabilitäts-SLH-DSA

• SlhDsaOpenSsl: OpenSSL 3.5.0+
• SlhDsaCng: Nicht unterstützt

Zusammengesetzte ML-DSA

Native Interop Composite ML-DSA

• CompositeMLDsaCng: Nicht unterstützt

X.509-Zertifikate

Der Großteil der Unterstützung für X.509-Zertifikate in .NET stammt von Betriebssystembibliotheken. Um ein Zertifikat in eine X509Certificate2- oder X509Certificate-Instanz in .NET zu laden, muss das Zertifikat von der zugrunde liegenden Betriebssystembibliothek geladen werden.

Lesen eines PKCS12/PFX

Schreiben eines PKCS12/PFX

macOS kann keine privaten Zertifikatschlüssel ohne ein Schlüsselbundobjekt laden, das Schreiben auf den Datenträger erfordert. Schlüsselbunde werden automatisch für das PFX-Laden erstellt und gelöscht, wenn sie nicht mehr verwendet werden. Da die Option X509KeyStorageFlags.EphemeralKeySet bedeutet, dass der private Schlüssel nicht auf den Datenträger geschrieben werden soll, führt die Angabe dieses Flags unter macOS zu einem PlatformNotSupportedException.

Schreiben einer PKCS7-Zertifikatsammlung

Sowohl Windows als auch Linux geben DER-codierte PKCS7-Blobs aus. macOS gibt CER-codierte PKCS7-Blobs mit undefinierter Länge aus.

X509Store

Unter Windows ist die Klasse X509Store eine Darstellung der Windows-Zertifikatspeicher-APIs. Diese APIs funktionieren in .NET Core und .NET 5 genauso wie in .NET Framework.

Unter anderen Betriebssystemen als Windows ist die Klasse X509Store eine Projektion der Systemvertrauensentscheidungen (schreibgeschützt), Benutzervertrauensentscheidungen (Lese-/Schreibzugriff) und Benutzerschlüsselspeicher (Lese-/Schreibzugriff).

Die folgenden Tabellen zeigen, welche Szenarien auf den einzelnen Plattformen unterstützt werden. Bei nicht unterstützten Szenarien (❌ in den Tabellen) wird eine CryptographicException ausgelöst.

Mein Speicher

Unter Linux werden Speicher beim ersten Schreibvorgang erstellt, und standardmäßig sind keine Benutzerspeicher vorhanden, sodass das Öffnen von CurrentUser\My mit ExistingOnly möglicherweise fehlschlägt.

Unter macOS ist der Standardschlüsselbund des Benutzers der CurrentUser\My-Speicher, standardmäßig also login.keychain. Der LocalMachine\My-Speicher ist System.keychain.

Stammspeicher

Unter Linux ist der LocalMachine\Root-Speicher eine Interpretation des CA-Pakets im Standardpfad für OpenSSL.

Unter macOS ist der CurrentUser\Root-Speicher eine Interpretation der SecTrustSettings-Ergebnisse für die Domäne der Benutzervertrauensstellung. Der LocalMachine\Root-Speicher ist eine Interpretation der SecTrustSettings-Ergebnisse für die Domänen der Administrator- und Systemvertrauensstellung.

Zwischenspeicher

Unter Linux wird der CurrentUser\Intermediate-Speicher als Zwischenspeicher verwendet, wenn Zwischenzertifizierungsstellen von ihren Authority Information Access-Datensätzen bei erfolgreichen X509Chain-Builds heruntergeladen werden. Der LocalMachine\Intermediate-Speicher ist eine Interpretation des CA-Pakets im Standardpfad für OpenSSL.

Unter macOS wird der CurrentUser\Intermediate-Speicher als benutzerdefinierter Speicher behandelt. Zertifikate, die diesem Speicher hinzugefügt wurden, wirken sich nicht auf das Erstellen von X.509-Ketten aus.

Unzulässiger Speicher

Unter Linux wird der Disallowed-Speicher beim Erstellen von Ketten nicht verwendet, und der Versuch, Inhalte hinzuzufügen, führt zu einer CryptographicException. Eine CryptographicException wird beim Öffnen des Disallowed-Speichers ausgelöst, wenn er bereits Inhalte erworben hat.

Unter macOS sind die Speicher „CurrentUser\Disallowed“ und „LocalMachine\Disallowed“ Interpretationen der entsprechenden SecTrustSettings-Ergebnisse für Zertifikate, deren Vertrauensstellung auf Always Deny festgelegt ist.

Nicht vorhandener Speicher

Unter macOS wird die Erstellung eines benutzerdefinierten Speichers mit der X509Store-API nur für den Standort CurrentUser unterstützt. Es wird ein neues Schlüsselbund ohne Kennwort im Schlüsselbundverzeichnis des Benutzers erstellt (~/Library/Keychains). Um ein Schlüsselbund mit Kennwort zu erstellen, kann ein „P/Invoke“ zu SecKeychainCreate verwendet werden. Auf ähnliche Weise kann SecKeychainOpen verwendet werden, um Schlüsselbunde an verschiedenen Standorten zu öffnen. Der resultierende IntPtr kann an new X509Store(IntPtr) übergeben werden, um einen lese-/schreibfähigen Speicher zu erhalten, abhängig von den Berechtigungen des aktuellen Benutzers.

X509Chain

macOS unterstützt keine Offline-CRL-Nutzung, daher X509RevocationMode.Offline wird als X509RevocationMode.Online behandelt.

macOS unterstützt kein vom Benutzer initiiertes Timeout für das Herunterladen von Zertifikatsperrlisten (Certificate Revocation List) / OCSP (Online Certificate Status Protocol) / AIA (Authority Information Access) und daher wird X509ChainPolicy.UrlRetrievalTimeout ignoriert.

Post-Quantum-Kryptografiezertifikate und PKCS12/PFX

Unterstützung von Post-Quantum-Zertifikaten erfordert auch Unterstützung durch den primitiven Algorithmus.

Zusätzliche Ressourcen

• .NET-Kryptografiemodell
• .NET Kryptografiedienste
• Verwenden der Auffüllung für die Zeitsteuerung bei Sicherheitsrisiken mit symmetrischer Entschlüsselung im CBC-Modus
• Datenschutz in ASP.NET Core