Kryptografie pro různé platformy v .NET

Kryptografické operace v .NET se provádějí knihovnami operačního systému (OS). Tato závislost má výhody:

• Aplikace .NET využívají spolehlivost operačního systému. Zajištění zabezpečení kryptografických knihoven před ohroženími zabezpečení je pro dodavatele operačního systému vysokou prioritou. Za tímto účelem poskytují aktualizace, které by měli použít správci systému.
• Aplikace .NET mají přístup k algoritmům ověřeným rozhraním FIPS, pokud jsou knihovny operačního systému ověřeny.

Závislost na knihovnách operačního systému také znamená, že aplikace .NET můžou používat jenom kryptografické funkce, které operační systém podporuje. I když všechny platformy podporují určité základní funkce, některé funkce, které .NET podporuje, se na některých platformách nedají použít. Tento článek identifikuje funkce, které jsou podporovány na jednotlivých platformách.

Tento článek předpokládá, že máte funkční znalost kryptografie v .NET. Další informace naleznete v tématu .NET Kryptografický model a kryptografické služby .NET.

Algoritmy hash a ověřování zpráv

Všechny třídy ověřování zpráv založených na hodnotě hash (HMAC), včetně *Managed tříd, odkládají do knihoven operačního systému s výjimkou .NET v prohlížeči WASM. V prohlížeči WASM, SHA-1, SHA-2-256, SHA-2-384, SHA-2-512 a ekvivalenty HMAC se implementují pomocí spravovaného kódu.

¹. K dispozici od verze .NET 8.

². K dispozici od .NET 9.

³Streaming extensible output function (XOF) je k dispozici od .NET 9. V Linuxu to vyžaduje OpenSSL 3.3.

Symetrické šifrování

Základní šifry a řetězení provádí systémové knihovny.

Ověřené šifrování

Podpora ověřeného šifrování (AE) je k dispozici pro AES-CCM, AES-GCM a ChaCha20Poly1305 prostřednictvím System.Security.Cryptography.AesCcmtřídy , System.Security.Cryptography.AesGcma System.Security.Cryptography.ChaCha20Poly1305 třídy.

Vzhledem k tomu, že ověřené šifrování vyžaduje novější rozhraní API platformy pro podporu algoritmu, nemusí být podpora k dispozici na všech platformách. IsSupported Statickou vlastnost třídy pro algoritmus lze použít k detekci za běhu, pokud aktuální platforma podporuje algoritmus nebo ne.

AES-CCM v systému macOS

Systémové knihovny v systému macOS nepodporují AES-CCM pro kód třetích stran, takže AesCcm třída k podpoře používá OpenSSL. Uživatelé v systému macOS musí získat odpovídající kopii OpenSSL (libcrypto) pro tento typ, a to musí být v cestě, ze které by systém načetl knihovnu ve výchozím nastavení. Doporučujeme nainstalovat OpenSSL ze správce balíčků, jako je Homebrew.

libcrypto.0.9.8.dylib Knihovnylibcrypto.0.9.7.dylib, které jsou součástí macOS, pocházejí ze starších verzí OpenSSL a nebudou použity. libcrypto.35.dylibKnihovny a knihovny libcrypto.42.dylib jsou libcrypto.41.dylibz LibreSSL a nebudou použity.

AES-GCM a ChaCha20Poly1305 v macOS

macOS nepodporuje AES-GCM ani ChaCha20Poly1305, dokud macOS 10.15 pro kód třetí strany. Před .NET 8 AesGcm a ChaCha20Poly1305 mají stejný požadavek jako AES-CCM a uživatelé musí nainstalovat OpenSSL, aby tyto typy fungovaly.

Od verze .NET 8 bude .NET v systému macOS používat rozhraní CryptoKit společnosti Apple pro AES-GCM a ChaCha20Poly1305. Uživatelé nebudou muset instalovat ani konfigurovat žádné další závislosti pro AES-GCM nebo ChaCha20Poly1305 v systému macOS.

AES-GCM a ChaCha20Poly1305 v systémech iOS, tvOS a MacCatalyst

Podpora pro AES-GCM a ChaCha20Poly1305 je dostupná od .NET 9 v systémech iOS a tvOS 13.0 a novějších a všech verzích MacCatalyst.

Klíče AES-CCM, nesouvisejí a značky

• Velikosti klíčů

  AES-CCM funguje s 128, 192 a 256bitovými klíči.

• Jiné velikosti

  Třída AesCcm podporuje 56, 64, 72, 80, 88, 96 a 104bitovou (7, 8, 9, 10, 11, 12 a 13bajtů).

• Velikosti značek

  Třída AesCcm podporuje vytváření nebo zpracování značek 32, 48, 64, 80, 96, 112 a 128bitových (4, 8, 10, 12, 14 a 16 bajtů).

Klíče AES-GCM, nesouvisejí a značky

• Velikosti klíčů

  AES-GCM funguje s 128, 192 a 256bitovými klíči.

• Jiné velikosti

  Třída AesGcm podporuje pouze 96bitové (12bajtů) neces.

• Značky Velikosti ve Windows a Linuxu AesGcm podporují vytváření nebo zpracování značek 96, 104, 112, 120 a 128bitových (12, 13, 14, 15 a 16 bajtů). Na platformách Apple je velikost značky omezená na 128bitový (16bajtů) kvůli omezením rozhraní CryptoKit.

Klíče ChaCha20Poly1305, nonces a značky.

ChaCha20Poly1305 má pevnou velikost pro klíč, nece a ověřovací značku. ChaCha20Poly1305 vždy používá 256bitový klíč, 96bitovou (12bajtů) nonce a 128bitovou (16bajtů).

Asymetrická kryptografie

Tato část obsahuje následující pododdíly:

• RSA
• ECDSA
• ECDH
• DSA

RSA

Generování klíčů RSA (Rivest–Shamir–Adleman) provádí knihovny operačního systému a podléhá omezením velikosti a charakteristikám výkonu.

Operace klíče RSA se provádějí knihovnami operačního systému a typy klíče, které je možné načíst, podléhají požadavkům operačního systému.

.NET nezpřístupňuje operace RSA nezpracované (nepaddované).

Podpora odsazení a hodnoty hash se liší podle platformy:

¹ Windows CryptoAPI (CAPI) je schopný podpis PKCS1 s algoritmem SHA-2. Jednotlivé objekty RSA se ale můžou načíst ve zprostředkovateli kryptografických služeb (CSP), který ho nepodporuje.

² Vyžaduje .NET 8.

RSA ve Windows

• Rozhraní CAPI (Windows CryptoAPI) se používá při každém new RSACryptoServiceProvider() použití.
• Rozhraní WINDOWS Cryptography API Next Generation (CNG) se používá při každém new RSACng() použití.
• Objekt vrácený RSA.Create interně používá systém Windows CNG. Toto použití CNG systému Windows je podrobnosti implementace a může se změnit.
• Rozšiřující GetRSAPublicKey metoda pro X509Certificate2 vrací RSACng instanci. Toto použití RSACng je podrobnosti implementace a může se změnit.
• Metoda GetRSAPrivateKey rozšíření pro X509Certificate2 aktuálně preferuje RSACng instanci, ale pokud RSACng klíč nejde otevřít, RSACryptoServiceProvider pokusí se o to. Preferovaný poskytovatel je podrobnosti implementace a může se změnit.

Nativní interoperabilita RSA

.NET zveřejňuje typy, které umožňují programům spolupracovat s knihovnami operačního systému, které kryptografický kód .NET používá. Zahrnuté typy se nepřekládají mezi platformami a měly by být použity pouze v případě potřeby.

¹ V jiných systémech než RSACryptoServiceProvider Windows lze použít k zajištění kompatibility se stávajícími programy. V takovém případě každá metoda, která vyžaduje interoperabilitu operačního systému, například otevření pojmenovaného klíče, vyvolá PlatformNotSupportedExceptionchybu .

² V systému macOS funguje, RSAOpenSsl pokud je nainstalovaný OpenSSL a lze najít odpovídající knihovnu libcrypto dylib prostřednictvím dynamického načítání knihovny. Pokud nelze najít příslušnou knihovnu, vyvolá se výjimky.

ECDSA

Generování klíčů ECDSA (Elliptic Curve Digital Signature Algorithm) provádí knihovny operačního systému a podléhá omezením velikosti a charakteristikám výkonu.

Klíčové křivky ECDSA jsou definovány knihovnami operačního systému a podléhají jejich omezením.

¹ Linuxové distribuce nemají podporu pro stejné pojmenované křivky.

² Podpora pojmenovaných křivek byla přidána do windows CNG ve Windows 10. Další informace naleznete v tématu CNG Pojmenované elliptické křivky. Pojmenované křivky nejsou v dřívějších verzích Windows k dispozici, s výjimkou tří křivek ve Windows 7.

³ Export s explicitními parametry křivky vyžaduje podporu knihovny operačního systému, která není k dispozici na platformách Apple nebo starších verzích Windows.

^{Podpora 4} Androidu pro některé křivky závisí na verzi Androidu. Distributoři Androidu se také mohou rozhodnout přidat nebo odebrat křivky z buildu Androidu.

Nativní interoperabilita ECDSA

.NET zveřejňuje typy, které umožňují programům spolupracovat s knihovnami operačního systému, které kryptografický kód .NET používá. Zahrnuté typy se nepřekládají mezi platformami a měly by být použity pouze v případě potřeby.

* V systému macOS funguje, ECDsaOpenSsl pokud je v systému nainstalovaný OpenSSL a lze najít odpovídající knihovnu libcrypto dylib prostřednictvím dynamického načítání knihovny. Pokud nelze najít příslušnou knihovnu, vyvolá se výjimky.

ECDH

Generování klíčů ECDH (Elliptic Curve Diffie-Hellman) provádí knihovny operačního systému a podléhá omezením velikosti a charakteristikám výkonu.

Třída ECDiffieHellman podporuje "nezpracovanou" hodnotu výpočtu ECDH a také prostřednictvím následujících klíčových odvozených funkcí:

• HASH(Z)
• HASH(předpend || Z || append)
• HMAC(klíč, Z)
• HMAC(klíč, předpend || Z || append)
• HMAC(Z, Z)
• HMAC(Z, předpend || Z || append)
• Tls11Prf(label, počáteční)

Odvození nezpracovaných klíčů bylo zavedeno v .NET 8.

Klíčové křivky ECDH jsou definovány knihovnami operačního systému a podléhají jejich omezením.

¹ Linuxové distribuce nemají podporu pro stejné pojmenované křivky.

² Podpora pojmenovaných křivek byla přidána do windows CNG ve Windows 10. Další informace naleznete v tématu CNG Pojmenované elliptické křivky. Pojmenované křivky nejsou v dřívějších verzích Windows k dispozici, s výjimkou tří křivek ve Windows 7.

³ Export s explicitními parametry křivky vyžaduje podporu knihovny operačního systému, která není k dispozici na platformách Apple nebo starších verzích Windows.

^{Podpora 4} Androidu pro některé křivky závisí na verzi Androidu. Distributoři Androidu se také mohou rozhodnout přidat nebo odebrat křivky z buildu Androidu.

Nativní interoperabilita ECDH

.NET zveřejňuje typy, které umožňují programům spolupracovat s knihovnami operačního systému, které .NET používá. Zahrnuté typy se nepřekládají mezi platformami a měly by být použity pouze v případě potřeby.

* V systému macOS funguje, ECDiffieHellmanOpenSsl pokud je nainstalovaný OpenSSL a lze najít odpovídající knihovnu libcrypto dylib prostřednictvím dynamického načítání knihovny. Pokud nelze najít příslušnou knihovnu, vyvolá se výjimky.

DSA

Generování klíčů DSA (Digital Signature Algorithm) provádí systémové knihovny a podléhá omezením velikosti a charakteristikám výkonu.

* macOS načte klíče DSA větší než 1024 bitů, ale chování těchto klíčů není definováno. Nechovají se podle FIPS 186-3.

DSA ve Windows

• Rozhraní CAPI (Windows CryptoAPI) se používá při každém new DSACryptoServiceProvider() použití.
• Rozhraní WINDOWS Cryptography API Next Generation (CNG) se používá při každém new DSACng() použití.
• Objekt vrácený DSA.Create interně používá systém Windows CNG. Toto použití CNG systému Windows je podrobnosti implementace a může se změnit.
• Rozšiřující GetDSAPublicKey metoda pro X509Certificate2 vrací DSACng instanci. Toto použití DSACng je podrobnosti implementace a může se změnit.
• Metoda GetDSAPrivateKey rozšíření pro X509Certificate2 preferuje DSACng instanci, ale pokud DSACng klíč nejde otevřít, DSACryptoServiceProvider pokusí se o to. Preferovaný poskytovatel je podrobnosti implementace a může se změnit.

Nativní interoperabilita DSA

.NET zveřejňuje typy, které umožňují programům spolupracovat s knihovnami operačního systému, které kryptografický kód .NET používá. Zahrnuté typy se nepřekládají mezi platformami a měly by být použity pouze v případě potřeby.

¹ V jiných systémech než DSACryptoServiceProvider Windows lze použít k zajištění kompatibility se stávajícími programy. V takovém případě jakákoli metoda, která vyžaduje systémovou interoperabilitu, například otevření pojmenovaného klíče, vyvolá PlatformNotSupportedExceptionchybu .

² V systému macOS funguje, DSAOpenSsl pokud je nainstalovaný OpenSSL a lze najít odpovídající knihovnu libcrypto dylib prostřednictvím dynamického načítání knihovny. Pokud nelze najít příslušnou knihovnu, vyvolá se výjimky.

Certifikáty X.509

Většina podpory certifikátů X.509 v .NET pochází z knihoven operačního systému. Pokud chcete načíst certifikát do X509Certificate2 instance nebo X509Certificate instance v .NET, musí být certifikát načten podkladovou knihovnou operačního systému.

Čtení PKCS12/PFX

Zápis PKCS12/PFX

macOS nemůže načíst privátní klíče certifikátu bez objektu řetězce klíčů, který vyžaduje zápis na disk. Klíčenky se vytvoří automaticky pro načítání PFX a odstraní se, když už se nepoužívají. Vzhledem k tomu, že tato X509KeyStorageFlags.EphemeralKeySet možnost znamená, že privátní klíč by neměl být zapsán na disk, výsledkem toho, že příznak v systému macOS má za PlatformNotSupportedExceptionnásledek .

Zápis kolekce certifikátů PKCS7

Windows i Linux generují objekty blob PKCS7 s kódováním DER. MacOS generuje objekty blob PKCS7 s neomezenou délkou s kódováním CER.

X509Store

Ve X509Store Windows je třída reprezentací rozhraní API služby Windows Certificate Store. Tato rozhraní API fungují stejně jako v .NET Core a .NET 5 jako v rozhraní .NET Framework.

V jiných systémech než X509Store Windows je třída projekce rozhodnutí o důvěryhodnosti systému (jen pro čtení), rozhodnutí o důvěryhodnosti uživatelů (čtení i zápis) a úložiště uživatelských klíčů (čtení i zápis).

Následující tabulky ukazují, které scénáře jsou podporovány v jednotlivých platformách. Pro nepodporované scénáře (❌ v tabulkách) CryptographicException se vyvolá.

The My store

V Linuxu se úložiště vytvářejí při prvním zápisu a ve výchozím nastavení neexistují žádná uživatelská úložiště, takže otevření CurrentUser\My s chybou ExistingOnly může selhat.

V macOS CurrentUser\My je úložiště výchozí řetězce klíčů uživatele, což je login.keychain ve výchozím nastavení. Obchod LocalMachine\My je System.keychain.

Kořenové úložiště

V Linuxu LocalMachine\Root je úložiště interpretací sady certifikační autority ve výchozí cestě pro OpenSSL.

V systému macOS CurrentUser\Root je úložiště interpretací SecTrustSettings výsledků pro doménu důvěryhodnosti uživatele. Úložiště LocalMachine\Root je interpretace SecTrustSettings výsledků domén důvěryhodnosti správce a systému.

Zprostředkující úložiště

V Linuxu CurrentUser\Intermediate se úložiště používá jako mezipaměť při stahování zprostředkujících certifikačních autorit záznamy přístupu k informacím o autoritě při úspěšných buildech X509Chain. Úložiště LocalMachine\Intermediate je interpretace sady certifikační autority ve výchozí cestě pro OpenSSL.

V systému macOS CurrentUser\Intermediate se obchod považuje za vlastní úložiště. Certifikáty přidané do tohoto úložiště nemají vliv na vytváření řetězového řetězce X.509.

Nepovolené úložiště

V Linuxu Disallowed se úložiště nepoužívá při vytváření řetězu a pokus o přidání obsahu do něj vede k chybě CryptographicException. A CryptographicException je vyvolán při otevření Disallowed úložiště, pokud už získal obsah.

V systému macOS jsou úložiště CurrentUser\Disallowed a LocalMachine\Disallowed interpretací odpovídajících výsledků secTrustSettings pro certifikáty, jejichž vztah důvěryhodnosti je nastaven na Always Deny.

Neexistující úložiště

V systému macOS se vlastní úložiště s rozhraním API X509Store podporuje jenom pro CurrentUser umístění. Vytvoří novou řetězce klíčů bez hesla v adresáři řetězce klíčů uživatele (~/Library/Klíčenky). K vytvoření řetězce klíčů s heslem je možné použít volání nespravovaného SecKeychainCreate kódu. SecKeychainOpen Podobně se dá použít k otevření klíčů v různých umístěních. Výsledek IntPtr se dá předat, aby new X509Store(IntPtr) bylo možné získat úložiště podporující čtení a zápis, a to v závislosti na oprávněních aktuálního uživatele.

X509Chain

macOS nepodporuje využití seznamu CRL offline, takže X509RevocationMode.Offline se považuje za X509RevocationMode.Online.

MacOS nepodporuje stahování časového limitu iniciovaného uživatelem v seznamu odvolaných certifikátů (CRL) / OCSP (Online certificate Status Protocol) / AIA (Přístup k informacím o autoritě), takže X509ChainPolicy.UrlRetrievalTimeout se ignoruje.

Další materiály

• Kryptografický model .NET
• Kryptografické služby .NET
• Ohrožení zabezpečení časování u symetrického dešifrování pomocí odsazení v režimu CBC
• ASP.NET Základní ochrana dat