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.
Hashalgorithmen
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 und SHA-2-512 mithilfe von verwaltetem Code implementiert.
SHA-3
.NET 8 unterstützt jetzt SHA-3-Hashalgorithmen, einschließlich SHAKE-128 und SHAKE-256. SHA-3 wird derzeit unter Windows 11 Build 25324 oder höher unterstützt, und unter Linux mit OpenSSL 1.1.1 oder höher.
Symmetrische Verschlüsselung
Die zugrunde liegenden Verschlüsselungsverfahren und Verkettungen werden von den Systembibliotheken durchgeführt.
| Verschlüsselung + Modus | Windows | Linux | macOS | iOS, tvOS, MacCatalyst | Android |
|---|---|---|---|---|---|
| AES-CBC | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| AES-ECB | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| AES-CFB8 | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| AES-CFB128 | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| 3DES-CBC | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| 3DES-ECB | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| 3DES-CFB8 | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| 3DES-CFB64 | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| DES-CBC | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| DES-ECB | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| DES-CFB8 | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| RC2-CBC | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
| RC2-ECB | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
| RC2-CFB | ❌ | ❌ | ❌ | ❌ | ❌ |
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 Authentifizierungsverschlüsselung neuere Plattform-APIs erforderlich sind, um den Algorithmus zu unterstützen, ist die Unterstützung möglicherweise nicht auf allen Plattformen vorhanden. 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.
| Verschlüsselung + Modus | Windows | Linux | macOS | iOS, tvOS, MacCatalyst | Android | Browser |
|---|---|---|---|---|---|---|
| AES-GCM | ✔️ | ✔️ | ⚠️ | ❌ | ✔️ | ❌ |
| AES-CCM | ✔️ | ✔️ | ⚠️ | ❌ | ✔️ | ❌ |
| ChaCha20Poly1305 | Windows 10 Build 20142 und höher | OpenSSL 1.1.0 und höher | ⚠️ | ❌ | API-Ebene 28 und höher | ❌ |
AES-CCM unter macOS
Unter macOS unterstützen die Systembibliotheken AES-CCM für Code von Drittanbietern nicht, daher verwendet die Klasse AesCcm OpenSSL zur Unterstützung. macOS-Benutzer*innen müssen eine geeignete Kopie von OpenSSL (libcrypto) abrufen, damit dieser Typ funktioniert, und dieser muss sich unter einem Pfad befinden, aus dem das System standardmäßig eine Bibliothek laden würde. Es wird empfohlen, OpenSSL über einen Paket-Manager wie Homebrew zu installieren.
Die in macOS enthaltenen Bibliotheken libcrypto.0.9.7.dylib und libcrypto.0.9.8.dylib stammen aus früheren OpenSSL-Versionen und werden nicht verwendet. Die Bibliotheken libcrypto.35.dylib, libcrypto.41.dylib und libcrypto.42.dylib stammen aus LibreSSL und werden nicht verwendet.
AES-GCM und ChaCha20Poly1305 unter macOS
macOS hat AES-GCM oder ChaCha20Poly1305 bis macOS 10.15 für Drittanbietercode nicht unterstützt. Vor .NET 8 haben AesGcm und ChaCha20Poly1305 die gleiche Anforderung wie AES-CCM, und Benutzer*innen müssen OpenSSL installieren, damit diese Typen funktionieren.
Ab .NET 8 verwendet .NET unter macOS das CryptoKit-Framework von Apple für AES-GCM und ChaCha20Poly1305. Benutzer*innen müssen keine zusätzlichen Abhängigkeiten für AES-GCM oder ChaCha20Poly1305 unter macOS installieren oder konfigurieren.
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). Unter macOS ist die Taggröße aufgrund von Einschränkungen des CryptoKit-Frameworks auf 128 Bit (16 Byte) beschränkt.
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
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:
| Ein Paddingmodus | Windows (CNG) | Linux (OpenSSL) | macOS | iOS, tvOS, MacCatalyst | Android | Windows (CAPI) |
|---|---|---|---|---|---|---|
| PKCS1-Verschlüsselung | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| OAEP – SHA-1 | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| OAEP: SHA-2 | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
| OAEP: SHA-32 | Windows 11 Build 25324 und höher | OpenSSL 1.1.1 und höher | ❌ | ❌ | ❌ | ❌ |
| PKCS1-Signatur (MD5, SHA-1) | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| PKCS1-Signatur (SHA-2) | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ⚠️1 |
| PKCS1-Signatur (SHA-3)2 | Windows 11 Build 25324 und höher | OpenSSL 1.1.1 und höher | ❌ | ❌ | ❌ | ❌ |
| PSS | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
1 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.
2 Erfordert .NET 8
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.
| type | Windows | Linux | macOS | iOS, tvOS, MacCatalyst | Android |
|---|---|---|---|---|---|
| RSACryptoServiceProvider | ✔️ | ⚠️1 | ⚠️1 | ⚠️1 | ⚠️1 |
| RSACng | ✔️ | ❌ | ❌ | ❌ | ❌ |
| RSAOpenSsl | ❌ | ✔️ | ⚠️2 | ❌ | ❌ |
1 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.
2 Unter macOS kann RSAOpenSsl verwendet werden, wenn OpenSSL installiert ist und eine entsprechende libcrypto dylib über das Laden der dynamischen Bibliothek gefunden werden kann. Wenn keine geeignete Bibliothek gefunden werden kann, werden Ausnahmen ausgelöst.
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.
| Elliptische-Kurven- | Windows 10 | Windows 7–8.1 | Linux | macOS | iOS, tvOS, MacCatalyst | Android |
|---|---|---|---|---|---|---|
| NIST P-256 (secp256r1) | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| NIST P-384 (secp384r1) | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| NIST P-521 (secp521r1) | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Brainpoolkurven (als benannte Kurven) | ✔️ | ❌ | ⚠️1 | ❌ | ❌ | ⚠️4 |
| Andere benannte Kurven | ⚠️2 | ❌ | ⚠️1 | ❌ | ❌ | ⚠️4 |
| Explizite Kurven | ✔️ | ❌ | ✔️ | ❌ | ❌ | ✔️ |
| Exportieren oder Importieren als „explizit“ | ✔️ | ❌3 | ✔️ | ❌3 | ❌3 | ✔️ |
1 Nicht alle Linux-Verteilungen unterstützen die gleichen benannten Kurven.
2 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.
3 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.
4 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.
| type | Windows | Linux | macOS | iOS, tvOS, MacCatalyst | Android |
|---|---|---|---|---|---|
| ECDsaCng | ✔️ | ❌ | ❌ | ❌ | ❌ |
| ECDsaOpenSsl | ❌ | ✔️ | ⚠️* | ❌ | ❌ |
* Unter macOS kann ECDsaOpenSsl verwendet werden, wenn OpenSSL im System installiert ist und eine entsprechende libcrypto dylib über das Laden der dynamischen Bibliothek gefunden werden kann. Wenn keine geeignete Bibliothek gefunden werden kann, werden Ausnahmen ausgelöst.
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(prepend || Z || append)
- HMAC(key, Z)
- HMAC(key, prepend || Z || append)
- HMAC(Z, Z)
- HMAC(Z, prepend || Z || append)
- Tls11Prf(label, seed)
Die Ableitung des Rohschlüssels wurde in .NET 8 eingeführt.
ECDH-Schlüsselkurven werden von den Betriebssystembibliotheken definiert und unterliegen deren Einschränkungen.
| Elliptische-Kurven- | Windows 10 | Windows 7–8.1 | Linux | macOS | iOS, tvOS, MacCatalyst | Android |
|---|---|---|---|---|---|---|
| NIST P-256 (secp256r1) | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| NIST P-384 (secp384r1) | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| NIST P-521 (secp521r1) | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Brainpoolkurven (als benannte Kurven) | ✔️ | ❌ | ⚠️1 | ❌ | ❌ | ⚠️4 |
| Andere benannte Kurven | ⚠️2 | ❌ | ⚠️1 | ❌ | ❌ | ⚠️4 |
| Explizite Kurven | ✔️ | ❌ | ✔️ | ❌ | ❌ | ✔️ |
| Exportieren oder Importieren als „explizit“ | ✔️ | ❌3 | ✔️ | ❌3 | ❌3 | ✔️ |
1 Nicht alle Linux-Verteilungen unterstützen die gleichen benannten Kurven.
2 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.
3 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.
4 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.
| type | Windows | Linux | macOS | iOS, tvOS, MacCatalyst | Android |
|---|---|---|---|---|---|
| ECDiffieHellmanCng | ✔️ | ❌ | ❌ | ❌ | ❌ |
| ECDiffieHellmanOpenSsl | ❌ | ✔️ | ⚠️* | ❌ | ❌ |
* Unter macOS kann ECDiffieHellmanOpenSsl verwendet werden, wenn OpenSSL installiert ist und eine entsprechende libcrypto dylib über das Laden der dynamischen Bibliothek gefunden werden kann. Wenn keine geeignete Bibliothek gefunden werden kann, werden Ausnahmen ausgelöst.
DSA
Die DSA-Schlüsselgenerierung (Digital Signature Algorithm) erfolgt durch die Systembibliotheken und unterliegt deren Größenbeschränkungen und Leistungsmerkmalen.
| Funktion | Windows CNG | Linux | macOS | Windows CAPI | iOS, tvOS, MacCatalyst | Android |
|---|---|---|---|---|---|---|
| Schlüsselerstellung (< = 1024 Bits) | ✔️ | ✔️ | ❌ | ✔️ | ❌ | ✔️ |
| Schlüsselerstellung (> 1024 Bits) | ✔️ | ✔️ | ❌ | ❌ | ❌ | ✔️ |
| Laden von Schlüsseln (< = 1024 Bit) | ✔️ | ✔️ | ✔️ | ✔️ | ❌ | ✔️ |
| Laden von Schlüsseln (> 1024 Bit) | ✔️ | ✔️ | ⚠️* | ❌ | ❌ | ✔️ |
| FIPS 186-2 | ✔️ | ✔️ | ✔️ | ✔️ | ❌ | ✔️ |
| FIPS 186-3 (SHA-2-Signaturen) | ✔️ | ✔️ | ❌ | ❌ | ❌ | ✔️ |
* 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.
| type | Windows | Linux | macOS | iOS, tvOS, MacCatalyst | Android |
|---|---|---|---|---|---|
| DSACryptoServiceProvider | ✔️ | ⚠️1 | ⚠️1 | ❌ | ⚠️1 |
| DSACng | ✔️ | ❌ | ❌ | ❌ | ❌ |
| DSAOpenSsl | ❌ | ✔️ | ⚠️2 | ❌ | ❌ |
1 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.
2 Unter macOS kann DSAOpenSsl verwendet werden, wenn OpenSSL installiert ist und eine entsprechende libcrypto dylib über das Laden der dynamischen Bibliothek gefunden werden kann. Wenn keine geeignete Bibliothek gefunden werden kann, werden Ausnahmen ausgelöst.
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
| Szenario | Windows | Linux | macOS | iOS, tvOS, MacCatalyst | Android |
|---|---|---|---|---|---|
| Leer | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Ein Zertifikat, kein privater Schlüssel | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Ein Zertifikat, mit privatem Schlüssel | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Mehrere Zertifikate, keine privaten Schlüssel | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Mehrere Zertifikate, ein privater Schlüssel | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Mehrere Zertifikate, mehrere private Schlüssel | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
Schreiben eines PKCS12/PFX
| Szenario | Windows | Linux | macOS | iOS, tvOS, MacCatalyst | Android |
|---|---|---|---|---|---|
| Leer | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Ein Zertifikat, kein privater Schlüssel | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Ein Zertifikat, mit privatem Schlüssel | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Mehrere Zertifikate, keine privaten Schlüssel | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Mehrere Zertifikate, ein privater Schlüssel | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Mehrere Zertifikate, mehrere private Schlüssel | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Kurzlebiges Laden | ✔️ | ✔️ | ❌ | ✔️ | ✔️ |
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
| Szenario | Windows | Linux | macOS | iOS, tvOS, MacCatalyst | Android |
|---|---|---|---|---|---|
| Öffnen von CurrentUser\My (ReadOnly) | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Öffnen von CurrentUser\My (ReadWrite) | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Öffnen von CurrentUser\My (ExistingOnly) | ✔️ | ⚠️ | ✔️ | ✔️ | ✔️ |
| Öffnen von LocalMachine\My | ✔️ | ❌ | ✔️ | ✔️ | ✔️ |
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
| Szenario | Windows | Linux | macOS | iOS, tvOS, MacCatalyst | Android |
|---|---|---|---|---|---|
| Öffnen von CurrentUser\Root (ReadOnly) | ✔️ | ✔️ | ✔️ | ❌ | ✔️ |
| Öffnen von CurrentUser\Root (ReadWrite) | ✔️ | ✔️ | ❌ | ❌ | ❌ |
| Öffnen von CurrentUser\Root (ExistingOnly) | ✔️ | ⚠️ | ✔️ (wenn ReadOnly) | ❌ | ✔️ (wenn ReadOnly) |
| Öffnen von LocalMachine\Root (ReadOnly) | ✔️ | ✔️ | ✔️ | ❌ | ✔️ |
| Öffnen von LocalMachine\Root (ReadWrite) | ✔️ | ❌ | ❌ | ❌ | ❌ |
| Öffnen von LocalMachine\Root (ExistingOnly) | ✔️ | ⚠️ | ✔️ (wenn ReadOnly) | ❌ | ✔️ (wenn ReadOnly) |
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
| Szenario | Windows | Linux | macOS | iOS, tvOS, MacCatalyst | Android |
|---|---|---|---|---|---|
| Öffnen von CurrentUser\Intermediate (ReadOnly) | ✔️ | ✔️ | ✔️ | ❌ | ❌ |
| Öffnen von CurrentUser\Intermediate (ReadWrite) | ✔️ | ✔️ | ❌ | ❌ | ❌ |
| Öffnen von CurrentUser\Intermediate (ExistingOnly) | ✔️ | ⚠️ | ✔️ (wenn ReadOnly) | ❌ | ❌ |
| Öffnen von LocalMachine\Intermediate (ReadOnly) | ✔️ | ✔️ | ✔️ | ❌ | ❌ |
| Öffnen von LocalMachine\Intermediate (ReadWrite) | ✔️ | ❌ | ❌ | ❌ | ❌ |
| Öffnen von LocalMachine\Intermediate (ExistingOnly) | ✔️ | ⚠️ | ✔️ (wenn ReadOnly) | ❌ | ❌ |
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
| Szenario | Windows | Linux | macOS | iOS, tvOS, MacCatalyst | Android |
|---|---|---|---|---|---|
| Öffnen von CurrentUser\Disallowed (ReadOnly) | ✔️ | ⚠️ | ✔️ | ✔️ | ✔️ |
| Öffnen von CurrentUser\Disallowed (ReadWrite) | ✔️ | ⚠️ | ❌ | ❌ | ❌ |
| Öffnen von CurrentUser\Disallowed (ExistingOnly) | ✔️ | ⚠️ | ✔️ (wenn ReadOnly) | ✔️ (wenn ReadOnly) | ✔️ (wenn ReadOnly) |
| Öffnen von LocalMachine\Disallowed (ReadOnly) | ✔️ | ❌ | ✔️ | ✔️ | ✔️ |
| Öffnen von LocalMachine\Disallowed (ReadWrite) | ✔️ | ❌ | ❌ | ❌ | ❌ |
| Öffnen von LocalMachine\Disallowed (ExistingOnly) | ✔️ | ❌ | ✔️ (wenn ReadOnly) | ✔️ (wenn ReadOnly) | ✔️ (wenn ReadOnly) |
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
| Szenario | Windows | Linux | macOS | iOS, tvOS, MacCatalyst | Android |
|---|---|---|---|---|---|
| Öffnen eines nicht vorhandenen Speichers (ExistingOnly) | ❌ | ❌ | ❌ | ❌ | ❌ |
| Öffnen eines nicht vorhandenen CurrentUser-Speichers (ReadWrite) | ✔️ | ✔️ | ⚠️ | ❌ | ❌ |
| Öffnen eines nicht vorhandenen LocalMachine-Speichers (ReadWrite) | ✔️ | ❌ | ❌ | ❌ | ❌ |
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.
Zusätzliche Ressourcen
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Tickets als Feedbackmechanismus für Inhalte auslaufen lassen und es durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter: https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für