Recommandations de chiffrement pour Microsoft SDL

Article
02/07/2024

Introduction

Ce document contient des recommandations et meilleures pratiques pour l'utilisation du chiffrement sur des plateformes Microsoft. Une grande partie de ce contenu paraphrase ou agrège des propres normes de sécurité internes de Microsoft utilisées pour le Security Development Lifecycle (SDL). Il a pour but de servir comme référence lors de la conception de produits afin d'utiliser les API, algorithmes, protocoles et longueurs de clé identiques à ceux que Microsoft exige pour ses propres produits et services.

Les développeurs sur plateformes non-Windows peuvent également tirer parti de ces recommandations. Bien que les noms d'API et de bibliothèques puissent différer, les meilleures pratiques en matière de choix d'algorithme, de longueur de clé et de protection des données sont similaires quelle que soit la plateforme.

Recommandations en matière de protocole de sécurité, d'algorithme et de longueur de clé

Versions des protocoles SSL/TLS

Les produits et services doivent utiliser des versions sécurisées par chiffrement des protocoles SSL/TLS :

Le protocole TLS 1.2 doit être activé.
Les protocoles TLS 1.1 et TLS 1.0 doivent être activés uniquement à des fins de compatibilité descendante.
Les protocoles SSL 3 et SSL 2 doivent être désactivés par défaut

Chiffrements par blocs symétriques, modes de chiffrement et vecteurs d'initialisation

Chiffrements par blocs

Pour les produits utilisant les chiffrements par bloc symétriques :

L'algorithme AES (Advanced Encryption Standard) est recommandé pour du nouveau code.
L'algorithme 3DES (Triple Data Encryption Standard) à trois clés est acceptable dans du code existant à des fins de compatibilité descendante.
Tous les autres chiffrements par blocs, à savoir RC2, DES, 3DES à 2 clés, DESX et Skipjack, ne doivent être utilisés que pour le déchiffrement de données anciennes, et doivent être remplacés en cas d'utilisation à des fins de chiffrement.

Pour les algorithmes de chiffrement par blocs symétriques, une longueur de clé minimale de 128 bits est recommandée. Le seul algorithme de chiffrement par blocs recommandé pour du nouveau code est AES (AES-128, AES-192 et AES-256 sont tous acceptables, sachant que AES-192 ne dispose pas d'optimisation sur certains processeurs). 3DES avec trois clés est actuellement acceptable s'il est déjà utilisé dans le code existant ; la transition vers AES est recommandée. DES, DESX, RC2 et Skipjack ne sont plus considérés comme sûrs. Ces algorithmes ne doivent être utilisés que pour le déchiffrement de données existantes pour des raisons de compatibilité descendante, et les données doivent être chiffrées de nouveau à l'aide d'un chiffrement par blocs recommandé.

Modes de chiffrement

Les algorithmes symétriques peuvent fonctionner dans divers modes dont la plupart lient les opérations de chiffrement sur des blocs successifs de texte en clair et de texte chiffré.

Les chiffrements par blocs symétriques doivent être utilisés avec l'un des modes de chiffrement suivants :

Cipher Block Chaining (CBC)
Ciphertext Stealing (CTS)
XEX-Based Tweaked-Codebook with Ciphertext Stealing (XTS)

D'autres modes de chiffrement, tels ceux mentionnés ci-dessous, présentent des écueils d'implémentation qui les exposent à des utilisations incorrectes. En particulier, le mode de chiffrement Electronic Code Book (ECB) doit être évité. La réutilisation du même vecteur d'initialisation avec des chiffrements par blocs dans des « modes de chiffrements en continu » tels que CTR peut entraîner la divulgation de données chiffrées. Une révision de sécurité supplémentaire est recommandée en cas d'utilisation de l'un des modes ci-dessous :

Output Feedback (OFB)
Cipher Feedback (CFB)
Counter (CTR)
Counter with CBC-MAC (CCM)
Galois/Counter Mode (GCM)
Tout autre mode ne figurant pas dans la liste des codes recommandés ci-dessus

Vecteurs d'initialisation

Tous les chiffrements par blocs symétriques doivent également être utilisés avec un nombre aléatoire fort du point de vue du chiffrement, tel un vecteur d'initialisation. Un vecteur d'initialisation ne doit jamais être une valeur constante. Pour obtenir des recommandations sur la génération de nombres aléatoires forts du point de vue du chiffrement, consultez Générateurs de nombres aléatoires.

Ne réutilisez jamais de vecteurs d'initialisation lors de l'exécution de plusieurs opérations de chiffrement, car cela peut avoir pour effet de révéler des informations sur les données chiffrées, en particulier lors de l'utilisation de modes de chiffrement en continu tels que Output Feedback (OFB) or Counter (CTR).

Algorithmes asymétriques, longueurs de clé et modes de remplissage

RSA

Utilisez RSA pour le chiffrement, l'échange de clés et les signatures.
Le chiffrement RSA doit utiliser uniquement les modes de remplissage OAEP ou RSA-KEM. Le code existant ne doit utiliser le mode de remplissage PKCS #1 v1.5 qu'à des fins de compatibilité.
L'utilisation d'un remplissage null n'est pas recommandée.
Des clés >= 2048 bits sont recommandées

ECDSA

ECDSA avec des clés >= 256 bits est recommandé
Des signatures basées sur ECDSA doivent utiliser l'une des trois courbes approuvées par NIST (P-256, P-384 ou P521).

ECDH

ECDH avec des clés >= 256 bits est recommandé
L'échange de clés ECDH doit utiliser l'une des trois courbes approuvées par NIST (P-256, P-384 ou P521).

Integer Diffie-Hellman

La longueur de clé >= 2048 bits est recommandée
Les paramètres de groupe doivent être un groupe nommé connu (par exemple, RFC 7919), ou générés par une partie de confiance, puis authentifiés avant utilisation

Durées de vie des clés

Toutes les clés asymétriques doivent avoir une durée de vie maximale de cinq ans, la durée de vie recommandée étant d'un an.
Toutes les clés symétriques doivent avoir une durée de vie maximale de trois ans, la durée de vie recommandée étant d'un an.
Vous devez fournir un mécanisme ou disposer d'un processus de remplacement des clés pour atteindre la durée de vie active limitée. À l'issue de sa durée de vie active, une clé ne doit pas être utilisée pour produire de nouvelles données (par exemple, à des fins de chiffrement ou de signature), mais peut encore être utilisée pour lire des données (par exemple, à des fins de déchiffrement ou de vérification).

Générateurs de nombres aléatoires

Tous les produits et services doivent utiliser des générateurs de nombres aléatoires sécurisés par chiffrement quand une génération aléatoire est requise.

CNG

Utilisez BCryptGenRandom avec l'indicateur BCRYPT_USE_SYSTEM_PREFERRED_RNG

CAPI

UtilisezCryptGenRandom pour générer des valeurs aléatoires.

Win32/64

Le code hérité peut utiliser RtlGenRandom en mode noyau
Le nouveau code doit utiliser BCryptGenRandom ou CryptGenRandom.
La fonction C Rand_s() est également recommandée (sur Windows, elle appelle CryptGenRandom)
La fonction Rand_s() est un remplacement sûr et performant de la fonction Rand(). La fonction Rand() ne doit pas être utilisée pour des applications de chiffrement. Elle convient uniquement pour des tests internes.
La fonction SystemPrng est recommandée pour du code en mode noyau.

.NET

Utiliser RNGCryptoServiceProvider

Applications du Windows Store

Les applications du Store peuvent utiliser CryptographicBuffer.GenerateRandom ou CryptographicBuffer.GenerateRandomNumber.

Non recommandé

Les fonctions non sécurisées liées à la génération de nombres aléatoires sont rand,System.Random (.NET), GetTickCount et GetTickCount64
L'utilisation de l'algorithme du générateur de nombres aléatoires à courbe elliptique double (« DUAL_EC_DRBG ») n'est pas recommandée.

Bibliothèques de chiffrement prises en charge par la plateforme Windows

Sur la plateforme Windows, Microsoft recommande d'utiliser les API de chiffrement intégrées dans le système d'exploitation. Sur d'autres plateformes, les développeurs peuvent évaluer des bibliothèques de chiffrement autres que celles de la plateforme en vue de leur utilisation. En règle générale, les bibliothèques de chiffrement de la plateforme sont mises à jour plus fréquemment, car elles sont livrées avec un système d'exploitation, au lieu d'être regroupées avec une application.

Toute décision quant à l'utilisation du chiffrement de la plateforme ou d'un autre chiffrement doit être guidée par les exigences suivantes :

La bibliothèque doit être une version actuelle bénéficiant d'un support, exempte de failles de sécurité connues.
Les protocoles, algorithmes et longueurs de clé de sécurité les plus récents doivent être pris en charge.
(Facultatif) La bibliothèque doit pouvoir prendre en charge des algorithmes ou protocoles de sécurité plus anciens uniquement à des fins de compatibilité descendante.

Code natif

Primitives de chiffrement : si votre mise en production est sur Windows ou Windows Phone, utilisez CNG si possible. Autrement, utilisez CryptoAPI (également appelé CAPI, qui est pris en charge en tant que composant hérité sur Windows depuis Windows Vista).
SSL/TLS/DTLS: WinINet,WinHTTP,Schannel,IXMLHTTPRequest2, ou IXMLHTTPRequest3.
- Les applications WinHTTP doivent être générées avec WinHttpSetOptionafin de prendre en charge le protocole TLS 1.2
Vérification de signature du code : WinVerifyTrust est l'API prise en charge pour la vérification des signatures de code sur les plateformes Windows.
Validation de certificat (telle qu'utilisée dans une validation de certificat restreinte pour la signature de code ou SSL/TLS/DTLS) : API CAPI2 ; par exemple, CertGetCertificateChain et CertVerifyCertificateChainPolicy

Code managé

Primitives de chiffrement : utilisez l'API définie dans l'espace de noms System.Security.Cryptography. Les classes CNG sont préférées.
Utilisez la dernière version disponible du .Net Framework. Au minimum, il doit s'agir de .Net Framework version 4.6. Si une version antérieure est requise, vérifiez que la clé de Registre (regkey) « SchUseStrongCrypto » est définie pour activer le protocole TLS 1.2 pour l'application en question.
Validation de certificat : utilisez les API définies sous l'espace de noms System.Security.Cryptography.X509Certificates.
SSL/TLS/DTLS : utilisez les API définies sous l'espace de noms System.Net (par exemple, HttpWebRequest).

Fonctions de dérivation de clés

La dérivation de clés est le processus consistant à dériver du matériel de clé de chiffrement d'un secret partagé ou d'une clé de chiffrement existante. Les produits doivent utiliser des fonctions de dérivation de clés recommandées. La dérivation de clés à partir de mots de passe choisis par l'utilisateur, ou d'un hachage de mots de passe pour stockage dans un système d'authentification, est un cas particulier non couvert par ces instructions. Les développeurs sont invités à consulter un expert.

Les normes suivantes spécifient les fonctions de dérivation de clés (KDF) dont l'utilisation est recommandée :

NIST SP 800-108 : recommandation pour la dérivation de clés à l'aide de fonctions pseudo-aléatoires. En particulier, la fonction de dérivation de clés en mode compteur, avec HMAC comme fonction pseudo-aléatoire
NIST SP 800-56A (révision 2) : recommandation pour les schémas d'établissement de clé Pair-Wise utilisant le chiffrement logarithmique discret. En particulier, la fonction de dérivation de clé en une étape décrite dans la section 5.8.1 est recommandée.

Pour dériver des clés de clés existantes, utilisez l'API BCryptKeyDerivation avec l'un des algorithmes suivants :

BCRYPT_SP800108_CTR_HMAC_ALGORITHM
BCRYPT_SP80056A_CONCAT_ALGORITHM

Pour dériver des clés d'un secret partagé (sortie d'un accord de partage de clé), utilisez l'API BCryptDeriveKey avec l'un des algorithmes suivants :

BCRYPT_KDF_SP80056A_CONCAT
BCRYPT_KDF_HMAC

Validation de certificat

Les produits qui utilisent les protocoles SSL, TLS ou DTLS doivent vérifier entièrement les certificats X.509 des entités auxquelles ils se connectent. Cela inclut la vérification des certificats concernant les points suivants :

Nom de domaine.
Dates de validité (dates de début et d'expiration).
État de révocation.
Utilisation (par exemple, « Authentification du serveur » pour les serveurs, « Authentification du client » pour les clients).
Chaîne d'approbation. Les certificats doivent être rattachés à une autorité de certification racine approuvée par la plateforme, ou explicitement configurés par l'administrateur.

Si l'un de ces tests de vérification échoue, le produit doit mettre fin à la connexion avec l'entité.

Les clients qui approuvent des certificats « auto-signés » (par exemple, un client de courrier se connectant à un serveur Exchange dans une configuration par défaut) peuvent ignorer les contrôles de vérification de certificat. Toutefois, les certificats auto-signés ne transmettent pas de manière inhérente d'approbation, de révocation de support ou de renouvellement de clé de support. Vous ne devez approuver des certificats autosignés que si vous les avez obtenus d'une autre source approuvée (par exemple, une entité approuvée fournissant le certificat sur un transport authentifié et dont l'intégrité est protégée).

Fonctions de hachage de chiffrement

Les produits doivent utiliser la famille d'algorithmes de hachage SHA-2 (SHA256, SHA384 et SHA512). La troncation des hachages de chiffrement pour des raisons de sécurité à moins de 128 bits n'est pas recommandée.

Algorithmes de hachage MAC/HMAC/à clé

Un code d'authentification de message (MAC) est un élément d'information associé à un message qui permet à son destinataire de vérifier à la fois l'authenticité de l'expéditeur et l'intégrité du message à l'aide d'une clé secrète.

L'utilisation d'un MAC basé sur un hachage (HMAC) ou d'un MAC basé sur un chiffrement par blocs est recommandée tant que tous les algorithmes de chiffrement symétrique ou de hachage sous-jacents sont également recommandés pour utilisation ; actuellement, cela inclut les fonctions HMAC-SHA2 (HMAC-SHA256, HMAC-SHA384 et HMAC-SHA512).

Une troncation des HMAC à moins de 128 bits n'est pas recommandée.

Considérations relatives à la conception et à l'exploitation

Vous devez fournir un mécanisme de remplacement des clés de chiffrement en fonction des besoins. Les clés doivent être remplacées une fois qu'elles ont atteint la fin de leur durée de vie active ou si elles sont compromises. Chaque fois que vous renouvelez un certificat, vous devez le renouveler avec une nouvelle clé.
Les produits qui utilisent des algorithmes de chiffrement pour protéger les données doivent inclure suffisamment de métadonnées, de même que ce contenu, pour prendre en charge la migration vers différents algorithmes à l'avenir. L'algorithme utilisé, les tailles de clé, les vecteurs d'initialisation et les modes de remplissage doivent être inclus.
- Pour plus d'informations sur l'agilité de chiffrement, consultez Agilité de chiffrement sur MSDN.
Autant que possible, les produits doivent utiliser des protocoles de chiffrement établis et fournis par la plateforme au lieu de les réimplémenter. Cela inclut les formats de signature (par exemple, utiliser un format standard existant).
Des chiffrements de flux symétriques tels que RC4 ne doivent pas être utilisés. Au lieu des chiffrements de flux symétriques, les produits doivent utiliser un chiffrement par bloc, en particulier AES avec une longueur de clé d'au moins 128 bits.
Ne signalez pas les échecs d'opérations de chiffrement aux utilisateurs finaux. Lorsque vous renvoyez une erreur à un appelant distant (par exemple, un client web ou un client dans un scénario client-serveur), utilisez uniquement un message d'erreur générique.
- Évitez de fournir des informations inutiles, par exemple, en signalant directement des erreurs de longueur hors plage ou non valide. Ne journalisez des erreurs détaillées que sur le serveur, et uniquement si la journalisation détaillée est activée.
Une révision de sécurité supplémentaire est fortement recommandée pour toute conception incorporant les éléments suivants :
- Un nouveau protocole principalement axé sur la sécurité (par exemple, un protocole d'authentification ou d'autorisation).
- Un nouveau protocole utilisant un chiffrement d'une manière nouvelle ou non standard. Voici des exemples de considérations :
  - Un produit qui implémente le protocole appellera-t-il des API ou méthodes de chiffrement dans le cadre de l'implémentation du protocole ?
  - Le protocole dépend-il d'un autre protocole utilisé pour l'authentification ou l'autorisation ?
  - Le protocole définira-t-il des formats de stockage pour des éléments de chiffrement tels que des clés ?
Les certificats auto-signés sont déconseillés pour les environnements de production. L'utilisation d'un certificat auto-signé, à l'instar de l'utilisation d'une clé de chiffrement brute, ne fournit pas, en elle-même, de base aux utilisateurs ou aux administrateurs pour prendre une décision d'approbation.
- En revanche, l'utilisation d'un certificat enraciné dans une autorité de certification approuvée rend claire la base justifiant de se fier à la clé privée associée, et active la révocation et les mises à jour en cas de défaillance de la sécurité.

Chiffrement des données sensibles avant stockage

DPAPI/DPAPI-NG

Pour les données qui doivent être conservées au fil des redémarrages du système :

CryptProtectData
CryptUnprotectData
NCryptProtectSecret (DPAPI CNG Windows 8)

Pour les données qui doivent pas être conservées au fil des redémarrages du système :

CryptProtectMemory
CryptUnprotectMemory

Pour les données qui doivent être conservées et utilisées par plusieurs comptes et ordinateurs de domaine :

NCryptProtectSecret (dans DPAPI CNG, disponible à partir de Windows 8)
Microsoft Azure KeyVault

TDE SQL Server

Vous pouvez utiliser la technologie Transparent Data Encryption (TDE) de SQL Server pour protéger des données sensibles.

Vous devez utiliser une clé de chiffrement de base de données TDE (DEK) répondant aux exigences d'algorithme de chiffrement SDL et de puissance de clé. Actuellement, seuls les algorithmes AES_128, AES_192 et AES_256 sont recommandés. TRIPLE_DES_3KEY n'est pas recommandé.

Il est important de garder certaines considérations à l'esprit pour l'utilisation de TDE SQL :

SQL Server ne prend pas en charge le chiffrement de données FILESTREAM, même si TDE est activé.
TDE ne fournit pas automatiquement de chiffrement pour les données en transit vers ou depuis la base de données. Vous devez également activer des connexions chiffrées à la base de données SQL Server. Pour obtenir des conseils sur l'activation des connexions chiffrées, consultez Activerdes connexions chiffrées dans le moteur de base de données (Gestionnaire de configuration SQL Server).
Si vous déplacez une base de données protégée par TDE vers une instance de SQL Server différente, vous devez également déplacer le certificat qui protège la clé de chiffrement de données TDE (DEK) et l'installer dans la base de données master de l'instance SQL Server de destination. Pour plus de détails, consultez l'article TechNet Déplacer unebase de données protégée par TDE vers une autre SQL Server.

Gestion des informations d'identification

Utilisez l'API Gestionnaire d'informations d'identification Windows ou Microsoft Azure KeyVault pour protéger les données de mot de passe et d'informations d'identification.

Applications du Windows Store

Utilisez les classes des espaces de noms Windows.Security.Cryptography et Windows.Security.Cryptography.DataProtection pour protéger les secrets et les données sensibles.

ProtectAsync
ProtectStreamAsync
UnprotectAsync
UnprotectStreamAsync

Utilisez les classes de l'espace de noms Windows.Security.Credentials pour protéger les données de mot de passe et d'informations d'identification.

.NET