Chiffrement multi-plateforme dans .NET

Les opérations de chiffrement dans .NET sont effectuées par des bibliothèques de système d’exploitation. Cette dépendance présente les avantages suivants :

• Les applications .NET bénéficient de la fiabilité du système d’exploitation. La protection des bibliothèques de chiffrement contre les vulnérabilités est une priorité importante des fournisseurs de système d’exploitation. Pour cela, ils fournissent des mises à jour que les administrateurs système doivent appliquer.
• Les applications .NET ont accès aux algorithmes validés par FIPS si les bibliothèques du système d’exploitation sont validées par FIPS.

La dépendance vis-à-vis des bibliothèques de système d’exploitation signifie également que les applications .NET peuvent uniquement utiliser les fonctionnalités de chiffrement prises en charge par le système d’exploitation. Bien que toutes les plateformes prennent en charge certaines fonctionnalités de base, certaines fonctionnalités prises en charge par .NET ne peuvent pas être utilisées sur certaines plateformes. Cet article présente les fonctionnalités prises en charge sur chaque plateforme.

Cet article suppose que vous avez une connaissance pratique du chiffrement dans .NET. Pour plus d’informations, consultez Modèle de chiffrement .NET et Services de chiffrement .NET.

Algorithmes de hachage et d’authentification de message

Toutes les classes d’algorithme de hachage et HMAC (Hash-based Message Authentication Code), notamment les classes *Managed, se reportent aux bibliothèques de système d’exploitation, à l’exception de .NET sur Browser WASM. Dans Browser WASM, SHA-1, SHA-2-256, SHA-2-384, SHA-2-512 et leurs équivalents HMAC sont implémentés en utilisant du code géré.

¹Disponible à partir de .NET 9.

La fonction de sortie extensible de diffusion en continu (XOF) est disponible à partir de .NET 9. Sur Linux, cela nécessite OpenSSL 3.3.

Chiffrement symétrique

Les chiffrements et chaînages sous-jacents sont effectués par les bibliothèques système.

Chiffrement authentifié

La prise en charge du chiffrement authentifié (AE) est fournie pour AES-CCM, AES-GCM et ChaCha20Poly1305 via les classes System.Security.Cryptography.AesCcm, System.Security.Cryptography.AesGcm et System.Security.Cryptography.ChaCha20Poly1305 respectivement.

Le chiffrement authentifié nécessitant des API de plateforme plus récentes pour prendre en charge l’algorithme, la prise en charge peut ne pas être présente sur toutes les plateformes. La propriété statique IsSupported sur les classes de l’algorithme peut être utilisée pour détecter au moment de l’exécution si la plateforme actuelle prend en charge l’algorithme ou non.

AES-CCM sur macOS

Sur macOS, les bibliothèques système ne prennent pas en charge AES-CCM pour le code tiers. Par conséquent, la classe AesCcm utilise OpenSSL pour assurer la prise en charge. Les utilisateurs sur macOS doivent obtenir une copie appropriée d’OpenSSL (libcrypto) pour que ces types fonctionnent, qui doit se trouver dans le chemin d’accès par défaut du système pour charger une bibliothèque. Nous vous recommandons d’installer OpenSSL à partir d’un gestionnaire de package comme Homebrew.

Les bibliothèques libcrypto.0.9.7.dylib et libcrypto.0.9.8.dylib incluses dans macOS proviennent de versions antérieures d’OpenSSL et ne sont pas utilisées. Les bibliothèques libcrypto.35.dylib, libcrypto.41.dylib et libcrypto.42.dylib proviennent de LibreSSL et ne sont pas utilisées.

AES-GCM et ChaCha20Poly1305 sur iOS, tvOS et MacCatalyst

Le support pour AES-GCM et ChaCha20Poly1305 est disponible à partir de .NET 9 sur iOS et tvOS 13.0 et versions ultérieures, et toutes les versions de MacCatalyst.

Clés, nonces et balises AES-CCM

• Tailles de clé

  AES-CCM fonctionne avec des clés 128, 192 et 256 bits.

• Tailles des nonces

  La classe AesCcm prend en charge les nonces 56, 64, 72, 80, 88, 96 et 104 bits (7, 8, 9, 10, 11, 12 et 13 octets).

• Tailles des balises

  La classe AesCcm prend en charge la création ou le traitement des balises 32, 48, 64, 80, 96, 112 et 128 bits (4, 8, 10, 12, 14 et 16 octets).

Clés, nonces et balises AES-GCM

• Tailles de clé

  AES-GCM fonctionne avec des clés 128, 192 et 256 bits.

• Tailles des nonces

  La classe AesGcm prend uniquement en charge les nonces 96 bits (12 octets).

• Tailles d’étiquette Sur Windows et Linux, la classe AesGcm prend en charge la création ou le traitement des balises 96, 104, 112, 120 et 128 bits (12, 13, 14, 15 et 16 octets). Sur les plateformes Apple, la taille de l’étiquette est limitée à 128 bits (16 octets) en raison des limitations du framework CryptoKit.

Clés, nonces et balises ChaCha20Poly1305.

ChaCha20Poly1305 a une taille fixe pour la clé, la nonce et la balise d’authentification. ChaCha20Poly1305 utilise toujours une clé 256 bits, une nonce 96 bits (12 octets) et une balise 128 bits (16 octets).

Chiffrement asymétrique

Cette section inclut les sous-sections suivantes :

• RSA
• ECDSA
• ECDH
• DSA

RSA

La génération de clés RSA (Rivest Shamir Adleman) est effectuée par les bibliothèques de système d’exploitation. Elle est soumise à leurs limitations de taille et à leurs caractéristiques de performances.

Les opérations de clé RSA sont effectuées par les bibliothèques de système d’exploitation. Les types de clé pouvant être chargés sont soumis aux exigences du système d’exploitation.

.NET n’expose pas les opérations RSA « brutes » (non remplies).

La prise en charge des remplissages et des synthèses varie selon la plateforme :

¹ Windows CryptoAPI (CAPI) est capable de signature PKCS1 avec un algorithme SHA-2. Toutefois, l’objet RSA individuel peut être chargé dans un fournisseur de services de chiffrement (CSP) qui ne le prend pas en charge.

RSA sur Windows

• Windows CryptoAPI (CAPI) est utilisé quand new RSACryptoServiceProvider() est utilisé.
• L’API Microsoft CNG (Cryptography Next Generation) est utilisée chaque fois que new RSACng() est utilisé.
• L’objet retourné par RSA.Create est alimenté en interne par Windows CNG. Cette utilisation de Windows CNG est un détail d’implémentation et peut faire l’objet de modifications.
• La méthode d’extension GetRSAPublicKey pour X509Certificate2 retourne une instance RSACng. Cette utilisation de RSACng est un détail d’implémentation et peut faire l’objet de modifications.
• La méthode d’extension GetRSAPrivateKey pour X509Certificate2 préfère actuellement une instance RSACng. Toutefois, si RSACng ne peut pas ouvrir la clé, RSACryptoServiceProvider est tenté. Le fournisseur par défaut est un détail d’implémentation et peut faire l’objet de modifications.

Interopérabilité native RSA

.NET expose les types pour permettre aux programmes d’interagir avec les bibliothèques du système d’exploitation que le code de chiffrement .NET utilise. Les types impliqués ne translatent pas entre les différentes plateformes. Ils doivent être utilisés directement si cela est nécessaire uniquement.

¹ Sur non Windows, RSACryptoServiceProvider peut être utilisé à des fins de compatibilité avec les programmes existants. Dans ce cas, toute méthode qui nécessite l’interopérabilité du système d’exploitation, comme l’ouverture d’une clé nommée, lève une exception PlatformNotSupportedException.

² Sur macOS, RSAOpenSsl fonctionne si OpenSSL est installé et qu’un dylib libcrypto approprié peut être trouvé via le chargement dynamique de la bibliothèque. Si une bibliothèque appropriée est introuvable, des exceptions sont levées.

ECDSA

La génération de clés ECDSA (Elliptic Curve Digital Signature Algorithm) est effectuée par les bibliothèques de système d’exploitation. Elle est soumise à leurs limitations de taille et à leurs caractéristiques de performances.

Les courbes clés ECDSA sont définies par les bibliothèques de système d’exploitation et sont soumises à leurs limitations.

¹ Les distributions Linux ne prennent pas toutes en charge les mêmes courbes nommées.

² La prise en charge des courbes nommées a été ajoutée à Windows CNG dans Windows 10. Pour plus d’informations, consultez Courbes elliptiques nommées CNG. Les courbes nommées ne sont pas disponibles dans les versions antérieures de Windows, à l’exception de trois courbes dans Windows 7.

³ L’exportation avec des paramètres de courbe explicites nécessite la prise en charge de la bibliothèque de système d’exploitation, qui n’est pas disponible sur les plateformes Apple et les versions antérieures de Windows.

⁴ La prise en charge d’Android pour certaines courbes dépend de la version Android. Les distributeurs Android peuvent également choisir d’ajouter ou de supprimer des courbes de leur build Android.

Interopérabilité native ECDSA

.NET expose les types pour permettre aux programmes d’interagir avec les bibliothèques du système d’exploitation que le code de chiffrement .NET utilise. Les types impliqués ne translatent pas entre les différentes plateformes. Ils doivent être utilisés directement si cela est nécessaire uniquement.

* Sur macOS, ECDsaOpenSsl fonctionne si OpenSSL est installé sur le système et qu’un dylib libcrypto approprié peut être trouvé via le chargement dynamique de la bibliothèque. Si une bibliothèque appropriée est introuvable, des exceptions sont levées.

ECDH

La génération de clés ECDH (Elliptic Curve Diffie-Hellman) est effectuée par les bibliothèques de système d’exploitation. Elle est soumise à leurs limitations de taille et à leurs caractéristiques de performances.

La classe ECDiffieHellman prend en charge la valeur « raw » du calcul ECDH, ainsi que par le biais des fonctions de dérivation de clé suivantes :

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

Les courbes clés ECDH sont définies par les bibliothèques de système d’exploitation et sont soumises à leurs limitations.

¹ Les distributions Linux ne prennent pas toutes en charge les mêmes courbes nommées.

² La prise en charge des courbes nommées a été ajoutée à Windows CNG dans Windows 10. Pour plus d’informations, consultez Courbes elliptiques nommées CNG. Les courbes nommées ne sont pas disponibles dans les versions antérieures de Windows, à l’exception de trois courbes dans Windows 7.

³ L’exportation avec des paramètres de courbe explicites nécessite la prise en charge de la bibliothèque de système d’exploitation, qui n’est pas disponible sur les plateformes Apple et les versions antérieures de Windows.

⁴ La prise en charge d’Android pour certaines courbes dépend de la version Android. Les distributeurs Android peuvent également choisir d’ajouter ou de supprimer des courbes de leur build Android.

Interopérabilité native ECDH

.NET expose les types pour permettre aux programmes d’interagir avec les bibliothèques du système d’exploitation que .NET utilise. Les types impliqués ne translatent pas entre les différentes plateformes. Ils doivent être utilisés directement si cela est nécessaire uniquement.

* Sur macOS, ECDiffieHellmanOpenSsl fonctionne si OpenSSL est installé et qu’un dylib libcrypto approprié peut être trouvé via le chargement dynamique de la bibliothèque. Si une bibliothèque appropriée est introuvable, des exceptions sont levées.

DSA

La génération de clés DSA (Digital Signature Algorithm) est effectuée par les bibliothèques système. Elle est soumise à leurs limitations de taille et à leurs caractéristiques de performances.

* macOS charge les clés DSA supérieures à 1024 bits, mais le comportement de ces clés n’est pas défini. Elles ne se comportent pas selon FIPS 186-3.

DSA sur Windows

• Windows CryptoAPI (CAPI) est utilisé quand new DSACryptoServiceProvider() est utilisé.
• L’API Microsoft CNG (Cryptography Next Generation) est utilisée chaque fois que new DSACng() est utilisé.
• L’objet retourné par DSA.Create est alimenté en interne par Windows CNG. Cette utilisation de Windows CNG est un détail d’implémentation et peut faire l’objet de modifications.
• La méthode d’extension GetDSAPublicKey pour X509Certificate2 retourne une instance DSACng. Cette utilisation de DSACng est un détail d’implémentation et peut faire l’objet de modifications.
• La méthode d’extension GetDSAPrivateKey pour X509Certificate2 préfère une instance DSACng. Toutefois, si DSACng ne peut pas ouvrir la clé, DSACryptoServiceProvider est tenté. Le fournisseur par défaut est un détail d’implémentation et peut faire l’objet de modifications.

Interopérabilité native DSA

.NET expose les types pour permettre aux programmes d’interagir avec les bibliothèques du système d’exploitation que le code de chiffrement .NET utilise. Les types impliqués ne translatent pas entre les différentes plateformes. Ils doivent être utilisés directement si cela est nécessaire uniquement.

¹ Sur non Windows, DSACryptoServiceProvider peut être utilisé à des fins de compatibilité avec les programmes existants. Dans ce cas, toute méthode qui nécessite l’interopérabilité du système, comme l’ouverture d’une clé nommée, lève une exception PlatformNotSupportedException.

² Sur macOS, DSAOpenSsl fonctionne si OpenSSL est installé et qu’un dylib libcrypto approprié peut être trouvé via le chargement dynamique de la bibliothèque. Si une bibliothèque appropriée est introuvable, des exceptions sont levées.

Certificats X.509

La majorité de la prise en charge des certificats X.509 dans .NET provient des bibliothèques de système d’exploitation. Pour charger un certificat dans une instance X509Certificate2 ou X509Certificate dans .NET, le certificat doit être chargé par la bibliothèque de système d’exploitation sous-jacente.

Lire PKCS12/PFX

Écrire un PKCS12/PFX

macOS ne peut pas charger de clés privées de certificat sans objet keychain, ce qui nécessite d’écrire sur le disque. Les keychains sont créés automatiquement pour le chargement PFX et sont supprimés quand ils ne sont plus utilisés. Étant donné que l’option X509KeyStorageFlags.EphemeralKeySet signifie que la clé privée ne doit pas être écrite sur le disque, le fait de déclarer cet indicateur sur macOS entraîne une exception PlatformNotSupportedException.

Écrire une collection de certificats PKCS7

Windows et Linux émettent tous deux des objets blob PKCS7 encodés en DER. macOS émet des objets blob PKCS7 encodés en CER de longueur indéfinie.

X509Store

Sur Windows, la classe X509Store est une représentation des API du magasin de certificats Windows. Ces API fonctionnent de la même façon dans .NET Core et .NET 5 que dans .NET Framework.

Sur non Windows, la classe X509Store est une projection des décisions d’approbation système (lecture seule), des décisions d’approbation de l’utilisateur (lecture-écriture) et du stockage de clés utilisateur (lecture-écriture).

Les tableaux suivants indiquent les scénarios qui sont pris en charge dans chaque plateforme. Pour les scénarios non pris en charge (❌ dans les tables), une exception CryptographicException est levée.

Magasin My

Sur Linux, les magasins sont créés lors de la première écriture et aucun magasin utilisateur n’existe par défaut. L’ouverture de CurrentUser\My avec ExistingOnly peut donc échouer.

Sur macOS, le magasin CurrentUser\My est le keychain par défaut de l’utilisateur, qui est login.keychain par défaut. Le magasin LocalMachine\My est System.keychain.

Magasin Root

Sur Linux, le magasin LocalMachine\Root est une interprétation du pack de l’autorité de certification dans le chemin par défaut pour OpenSSL.

Sur macOS, le magasin CurrentUser\Root est une interprétation des résultats SecTrustSettings pour le domaine de confiance de l’utilisateur. Le magasin LocalMachine\Root est une interprétation des résultats SecTrustSettings pour le domaine de confiance de l’administrateur et du système.

Magasin Intermediate

Sur Linux, le magasin CurrentUser\Intermediate est utilisé comme cache lors du téléchargement des autorités de certification intermédiaires via leurs enregistrements d’accès aux informations d’autorité sur les builds X509Chain réussies. Le magasin LocalMachine\Intermediate est une interprétation du pack de l’autorité de certification dans le chemin par défaut pour OpenSSL.

Sur macOS, le magasin CurrentUser\Intermediate est traité comme un magasin personnalisé. Les certificats ajoutés à ce magasin n’affectent pas la construction de chaîne X.509.

Magasin Disallowed

Sur Linux, le magasin Disallowed n’est pas utilisé lors de la génération de chaînes. Si vous tentez d’y ajouter du contenu, cela entraîne une exception CryptographicException. Une exception CryptographicException est levée lors de l’ouverture du magasin Disallowed s’il a déjà acquis du contenu.

Sur macOS, les magasins CurrentUser\Disallowed et LocalMachine\Disallowed sont des interprétations des résultats SecTrustSettings appropriés pour les certificats dont l’approbation est définie sur Always Deny.

Magasin inexistant

Sur macOS, la création de magasins personnalisés avec l’API X509Store est prise en charge uniquement pour l’emplacement CurrentUser. Il crée un keychain sans mot de passe dans le répertoire keychain de l’utilisateur (~/Bibliothèque/Keychains). Pour créer un keychain avec mot de passe, vous pouvez utiliser un P/Invoke à SecKeychainCreate. De même, vous pouvez utiliser SecKeychainOpen pour ouvrir des keychains à différents emplacements. Le résultat IntPtr peut être transmis à new X509Store(IntPtr) pour obtenir un magasin compatible en lecture/écriture, conformément aux autorisations de l’utilisateur actuel.

X509Chain

macOS ne prend pas en charge l’utilisation de la liste de révocation de certificats hors connexion. X509RevocationMode.Offline est donc traité comme X509RevocationMode.Online.

macOS ne prend pas en charge un délai d’expiration initié par l’utilisateur sur le téléchargement de la liste de révocation de certificats (CRL) / OCSP (Online Certificate Status Protocol) / AIA (Authority Information Access). X509ChainPolicy.UrlRetrievalTimeout est donc ignoré.

Ressources supplémentaires

• Modèle de chiffrement .NET
• Services de chiffrement .NET
• Vulnérabilités de temporisation avec le déchiffrement symétrique en mode CBC à l’aide du remplissage
• Protection des données ASP.NET Core