Plattformübergreifende Kryptografie in .NET Core und .NET 5

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

  • .NET-Apps profitieren von der Zuverlässigkeit des Betriebssystems. Die Sicherheit von Kryptografiebibliotheken vor Sicherheitsrisiken hat für Betriebssystemanbieter eine hohe Priorität. Dazu stellen sie Updates bereit, die Systemadministratoren anwenden sollten.
  • .NET-Apps haben Zugriff auf FIPS-überprüfte Algorithmen, wenn die Betriebssystembibliotheken FIPS-überprüft sind.

Die Abhängigkeit von Betriebssystembibliotheken bedeutet auch, dass .NET-Apps nur kryptografische Features verwenden können, die das Betriebssystem unterstützt. Während alle Plattformen bestimmte Kernfeatures unterstützen, können einige Features, die von .NET unterstützt werden, 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 kryptografischen Daten in .NET vertraut sind. Weitere Informationen finden Sie unter .NET Cryptography Model und .NET Cryptographic Services.

Hashalgorithmen

Alle Hashalgorithmus- und HMAC-Klassen (Hash-Based Message Authentication, hashbasierte Nachrichtenauthentifizierung), einschließlich der -Klassen, werden *Managed auf die Betriebssystembibliotheken zurückstellungen. Die verschiedenen Betriebssystembibliotheken unterscheiden sich zwar in der Leistung, sollten jedoch kompatibel sein.

Symmetrische Verschlüsselung

Die zugrunde liegenden Verschlüsselungen und Verkettungen werden von den Systembibliotheken durchgeführt, und alle werden von allen Plattformen unterstützt.

Verschlüsselung + Modus Windows Linux macOS
AES-CBC ✔️ ✔️ ✔️
AES-2016 ✔️ ✔️ ✔️
3DES-CBC ✔️ ✔️ ✔️
3DES-VERERBUNG ✔️ ✔️ ✔️
DES-CBC ✔️ ✔️ ✔️
DES-UNGNUNGSVERENDUNG ✔️ ✔️ ✔️

Authentifizierte Verschlüsselung

Unterstützung für authentifizierte Verschlüsselung (Authenticated Encryption, AE) wird für AES-CCM und AES-GCM über die System.Security.Cryptography.AesCcm Klassen und System.Security.Cryptography.AesGcm bereitgestellt.

Unter Windows Linux werden die Implementierungen von AES-CCM und AES-GCM von den Betriebssystembibliotheken bereitgestellt.

AES-CCM und AES-GCM unter macOS

Unter macOS unterstützen die Systembibliotheken AES-CCM oder AES-GCM für Drittanbietercode nicht, sodass die Klassen und AesCcm OpenSSL zur Unterstützung AesGcm verwenden. Benutzer unter macOS müssen eine geeignete Kopie von OpenSSL (libcrypto) abrufen, damit diese Typen funktionieren, und sie müssen sich in einem Pfad befingen, aus dem das System standardmäßig eine Bibliothek laden würde. Es wird empfohlen, OpenSSL über einen Paket-Manager wie Homebrew.

Die in macOS enthaltenen Bibliotheken und sind aus früheren Versionen von libcrypto.0.9.7.dylib libcrypto.0.9.8.dylib OpenSSL und werden nicht verwendet. Die libcrypto.35.dylib Bibliotheken , und werden nicht libcrypto.41.dylib libcrypto.42.dylib verwendet.

AES-CCM-Schlüssel, Nonces und Tags

  • Schlüsselgrößen

    AES-CCM funktioniert mit 128-, 192- und 256-Bit-Schlüsseln.

  • Nonce-Größen

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

  • Taggrößen

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

AES-GCM-Schlüssel, Nonces und Tags

  • Schlüsselgrößen

    AES-GCM funktioniert mit 128-, 192- und 256-Bit-Schlüsseln.

  • Nonce-Größen

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

  • Taggrößen

    Die -Klasse unterstützt das Erstellen oder Verarbeiten von AesGcm 96-, 104-, 112-, 120- und 128-Bit-Tags (12, 13, 14, 15 und 16 Byte).

Asymmetrische Kryptografie

Dieser Abschnitt enthält die folgenden Unterabschnitte:

RSA

Die Rsa-Schlüsselgenerierung (Rsaest–Shamir-Adleman) wird von den Betriebssystembibliotheken durchgeführt und unterliegt ihren 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 "unformatierten" (nicht gepadierten) RSA-Vorgänge verfügbar.

Die Betriebssystembibliotheken werden für die Ver- und Entschlüsselungsauf padding verwendet. Nicht alle Plattformen unterstützen die gleichen Auf padding-Optionen:

Padding Mode Windows (CNG) Linux (OpenSSL) macOS Windows (CAPI)
PKCS1-Verschlüsselung ✔️ ✔️ ✔️ ✔️
OAEP – SHA-1 ✔️ ✔️ ✔️ ✔️
OAEP – SHA-2 (SHA256, SHA384, SHA512) ✔️ ✔️ ✔️
PKCS1-Signatur (MD5, SHA-1) ✔️ ✔️ ✔️ ✔️
PKCS1-Signatur (SHA-2) ✔️ ✔️ ✔️ ⚠️*
PSS ✔️ ✔️ ✔️

*Windows CryptoAPI (CAPI) kann PKCS1-Signaturen mit einem SHA-2-Algorithmus verwenden. Das einzelne RSA-Objekt kann jedoch in einen Kryptografiedienstanbieter (Cryptographic Service Provider, CSP) geladen werden, der es nicht unterstützt.

RSA auf Windows

  • Windows CryptoAPI (CAPI) wird immer dann verwendet, wenn new RSACryptoServiceProvider() verwendet wird.
  • Windows Cryptography API Next Generation (CNG) wird immer dann 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 RSACryptoServiceProvider versucht. Der bevorzugte Anbieter ist ein Implementierungsdetail und kann geändert werden.

Native RSA-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
RSACryptoServiceProvider ✔️ ⚠️1 ⚠️1
RSACng ✔️
RSAOpenSsl ✔️ ⚠️2

1 Unter macOS und Linux RSACryptoServiceProvider kann 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 Funktioniert unter macOS, RSAOpenSsl wenn OpenSSL installiert ist und eine entsprechende libcrypto dylib über das dynamische Laden von Bibliotheken gefunden werden kann. Wenn keine geeignete Bibliothek gefunden wird, werden Ausnahmen ausgelöst.

ECDSA

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

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

Elliptische-Kurven- Windows 10 Windows 7 bis 8.1 Linux macOS
NIST P-256 (secp256r1) ✔️ ✔️ ✔️ ✔️
NIST P-384 (secp384r1) ✔️ ✔️ ✔️ ✔️
NIST P-521 (secp521r1) ✔️ ✔️ ✔️ ✔️
Brainpoolkurven (als benannte Kurven) ✔️ ⚠️1
Andere benannte Kurven ⚠️2 ⚠️1
Explizite Kurven ✔️ ✔️
Exportieren oder Importieren als explizit ✔️ 3 ✔️ 3

1 Linux-Distributionen unterstützen nicht alle dieselben benannten Kurven.

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

3 Für das Exportieren mit expliziten Kurvenparametern ist die Unterstützung der Betriebssystembibliothek erforderlich, die unter macOS oder früheren Versionen von Windows nicht verfügbar ist.

ECDSA Native 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
ECDsaCng ✔️
ECDsaOpenSsl ✔️ ⚠️*

* Unter macOS funktioniert , ECDsaOpenSsl wenn OpenSSL im System installiert ist und eine entsprechende libcrypto dylib über das dynamische Laden von Bibliotheken gefunden werden kann. Wenn keine geeignete Bibliothek gefunden wird, werden Ausnahmen ausgelöst.

ECDH

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

Die ECDiffieHellman -Klasse gibt den "rohen" Wert der ECDH-Berechnung nicht zurück. Alle zurückgegebenen Daten werden in Bezug auf Schlüsselableitungsfunktionen zurückgegeben:

  • 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)

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

Elliptische-Kurven- Windows 10 Windows 7 bis 8.1 Linux macOS
NIST P-256 (secp256r1) ✔️ ✔️ ✔️ ✔️
NIST P-384 (secp384r1) ✔️ ✔️ ✔️ ✔️
NIST P-521 (secp521r1) ✔️ ✔️ ✔️ ✔️
Brainpoolkurven (als benannte Kurven) ✔️ ⚠️1
Andere benannte Kurven ⚠️2 ⚠️1
Explizite Kurven ✔️ ✔️
Exportieren oder Importieren als explizit ✔️ 3 ✔️ 3

1 Linux-Distributionen unterstützen nicht alle die gleichen benannten Kurven.

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

3 Für das Exportieren mit expliziten Kurvenparametern ist betriebssystembibliotheksunterstützung erforderlich, die unter macOS oder früheren Versionen von Windows.

Native ECDH-Interop

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

type Windows Linux macOS
ECDiffieHellmanCng ✔️
ECDiffieHellmanOpenSsl ✔️ ⚠️*

* Funktioniert unter macOS, wenn OpenSSL installiert ist und eine entsprechende libcrypto dylib über das ECDiffieHellmanOpenSsl laden der dynamischen Bibliothek gefunden werden kann. Wenn keine geeignete Bibliothek gefunden werden kann, werden Ausnahmen ausgelöst.

DSA

Die Generierung von DSA-Schlüsseln (Digital Signature Algorithm) wird von den Systembibliotheken durchgeführt und unterliegt ihren Größenbeschränkungen und Leistungsmerkmalen.

Funktion Windows CNG Linux macOS Windows CAPI
Schlüsselerstellung (<= 1024 Bit) ✔️ ✔️ ✔️
Schlüsselerstellung (> 1024 Bit) ✔️ ✔️
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 Bits sind, aber das Verhalten dieser Schlüssel ist nicht definiert. Sie verhalten sich nicht gemäß FIPS 186-3.

DSA on Windows

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

Native DSA-Interop

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

type Windows Linux macOS
DSACryptoServiceProvider ✔️ ⚠️1 ⚠️1
DSACng ✔️
DSAOpenSsl ✔️ ⚠️2

1 Unter macOS und Linux DSACryptoServiceProvider kann 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 Funktioniert unter macOS, DSAOpenSsl wenn OpenSSL installiert ist und eine entsprechende libcrypto dylib über das dynamische Laden von Bibliotheken gefunden werden kann. Wenn keine geeignete Bibliothek gefunden wird, werden Ausnahmen ausgelöst.

X.509-Zertifikate

Der Großteil der Unterstützung für X.509-Zertifikate in .NET stammt aus 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
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 ✔️ ⚠️* ✔️

* Verfügbar in .NET 5 und mehr.

Schreiben eines PKCS12/PFX

Szenario Windows Linux macOS
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 ✔️ ✔️ ⚠️*

* Verfügbar in .NET 5 und mehr.

macOS kann private Zertifikatschlüssel nicht ohne ein Keychainobjekt laden, das auf den Datenträger geschrieben werden muss. Keychains werden automatisch für das LADEN von PFX erstellt und gelöscht, wenn sie nicht mehr verwendet werden. Da die X509KeyStorageFlags.EphemeralKeySet Option bedeutet, dass der private Schlüssel nicht auf den Datenträger geschrieben werden soll, führt die Bestätigung dieses Flags unter macOS zu einem PlatformNotSupportedException .

Schreiben einer PKCS7-Zertifikatsammlung

Windows und Linux geben jeweils DER-codierte PKCS7-Blobs aus. macOS gibt CER-codierte PKCS7-Blobs mit unbestimmter Länge aus.

X509store

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

Unter Linux ist die X509Store -Klasse eine Projektion von Entscheidungen zur Systemvertrauensstellung (schreibgeschützt), Entscheidungen zur Benutzervertrauensstellung (Lese-/Schreibzugriff) und Benutzerschlüsselspeicher (Lese-/Schreibzugriff).

Unter macOS ist die X509Store -Klasse eine Projektion von Entscheidungen zur Systemvertrauensstellung (schreibgeschützt), Entscheidungen zur Benutzervertrauensstellung (schreibgeschützt) und zur Speicherung von Benutzerschlüsseln (Lese-/Schreibzugriff).

Die folgenden Tabellen zeigen, welche Szenarien auf jeder Plattform unterstützt werden. Für nicht unterstützte Szenarien ( ❌ in den CryptographicException Tabellen) wird eine ausgelöst.

My store (Mein Speicher)

Szenario Windows Linux macOS
Öffnen Sie CurrentUser\My (ReadOnly). ✔️ ✔️ ✔️
Öffnen Sie CurrentUser\My (ReadWrite). ✔️ ✔️ ✔️
Öffnen Sie CurrentUser\My (ExistingOnly). ✔️ ⚠️ ✔️
Öffnen Sie LocalMachine\My. ✔️ ✔️

Unter Linux werden Speicher beim ersten Schreiben erstellt, und standardmäßig sind keine Benutzerspeicher vorhanden, sodass das Öffnen CurrentUser\My mit ExistingOnly fehlschlagen kann.

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

Der Stammspeicher

Szenario Windows Linux macOS
Öffnen Sie CurrentUser\Root (ReadOnly). ✔️ ✔️ ✔️
Öffnen Sie CurrentUser\Root (ReadWrite). ✔️ ✔️
Öffnen Sie CurrentUser\Root (ExistingOnly). ✔️ ⚠️ ✔️ (bei ReadOnly)
Öffnen Sie LocalMachine\Root (ReadOnly). ✔️ ✔️ ✔️
Öffnen Sie LocalMachine\Root (ReadWrite). ✔️
Öffnen Sie LocalMachine\Root (ExistingOnly). ✔️ ⚠️ ✔️ (bei 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 Ergebnisse für die SecTrustSettings Benutzervertrauensdomäne. Der LocalMachine\Root Speicher ist eine Interpretation der Ergebnisse für die SecTrustSettings Administrator- und Systemvertrauensdomänen.

Der Zwischenspeicher

Szenario Windows Linux macOS
Öffnen Sie CurrentUser\Intermediate (ReadOnly). ✔️ ✔️ ✔️
Öffnen Sie CurrentUser\Intermediate (ReadWrite). ✔️ ✔️
Öffnen Sie CurrentUser\Intermediate (ExistingOnly). ✔️ ⚠️ ✔️ (bei ReadOnly)
Öffnen Sie LocalMachine\Intermediate (ReadOnly). ✔️ ✔️ ✔️
Öffnen Sie LocalMachine\Intermediate (ReadWrite). ✔️
Öffnen Sie LocalMachine\Intermediate (ExistingOnly). ✔️ ⚠️ ✔️ (bei ReadOnly)

Unter Linux wird der CurrentUser\Intermediate Speicher als Cache verwendet, wenn zwischengeschaltete ZS von den Authority Information Access-Datensätzen bei erfolgreichen X509Chain-Builds heruntergeladen werden. Der LocalMachine\Intermediate Speicher ist eine Interpretation des Zertifizierungsstellenpakets im Standardpfad für OpenSSL.

Der unzulässige Speicher

Szenario Windows Linux macOS
Öffnen Sie CurrentUser\Disallowed (ReadOnly). ✔️ ⚠️ ✔️
Öffnen Sie CurrentUser\Disallowed (ReadWrite). ✔️ ⚠️
Öffnen Sie CurrentUser\Disallowed (ExistingOnly). ✔️ ⚠️ ✔️ (bei ReadOnly)
Öffnen Sie LocalMachine\Disallowed (ReadOnly). ✔️ ✔️
Öffnen Sie LocalMachine\Disallowed (ReadWrite). ✔️
Öffnen Sie LocalMachine\Disallowed (ExistingOnly). ✔️ ✔️ (bei ReadOnly)

Unter Linux wird der Speicher nicht beim Erstellen von Disallowed Ketten verwendet, und der Versuch, ihm Inhalt hinzuzufügen, führt zu einem CryptographicException . Eine CryptographicException wird beim Öffnen des Disallowed Speichers ausgelöst, wenn sie bereits Inhalte erhalten hat.

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

Nicht vorhandener Speicher

Szenario Windows Linux macOS
Nicht vorhandenen Speicher öffnen (ExistingOnly)
Nicht vorhandener CurrentUser-Speicher öffnen (ReadWrite) ✔️ ✔️ ⚠️
Nicht vorhandener LocalMachine-Speicher öffnen (ReadWrite) ✔️

Unter macOS wird die Erstellung benutzerdefinierter Speicher mit der X509Store-API nur für CurrentUser Speicherorte unterstützt. Er erstellt einen neuen Schlüsselbund ohne Kennwort im Schlüsselbundverzeichnis des Benutzers (~/Library/Keychains). Um einen Schlüsselbund mit Kennwort zu erstellen, kann ein P/Invoke für SecKeychainCreate verwendet werden. Auf ähnliche Weise SecKeychainOpen kann verwendet werden, um Keychains an verschiedenen Speicherorten zu öffnen. Die resultierende IntPtr kann an übergeben new X509Store(IntPtr) werden, um einen lese-/schreibfähigen Speicher zu erhalten, der den Berechtigungen des aktuellen Benutzers unterliegt.

X509chain

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

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

Zusätzliche Ressourcen