Recommandations de chiffrement pour Microsoft SDL

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 :

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 doit utiliser le mode de remplissage PKCS #1 v1.5 uniquement pour la 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

  • Utiliser BCryptGenRandom avec l’indicateur BCRYPT_USE_SYSTEM_PREFERRED_RNG

CAPI

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 (qui appelle CryptGenRandom sur Windows)

  • Rand_s() est un remplacement sûr et performant pour 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

Applications Windows Store

Non recommandé

  • Les fonctions non sécurisées liées à la génération de nombres aléatoires incluent rand,System.Random (.NET), GetTickCount et GetTickCount64

  • L’utilisation de l’algorithme double générateur de nombres aléatoires elliptiques (« 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 :

  1. La bibliothèque doit être une version actuelle bénéficiant d’un support, exempte de failles de sécurité connues.

  2. Les protocoles, algorithmes et longueurs de clé de sécurité les plus récents doivent être pris en charge.

  3. (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.

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

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 AES_128, les AES_192 et les 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 :

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

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

  • ProtectedData.Protect

  • ProtectedData.Unprotect

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

  • ProtectedMemory.Protect

  • ProtectedMemory.Unprotect

Pour les fichiers de configuration, utilisez

soit RsaProtectedConfigurationProvider, soit DpapiProtectedConfigurationProvider pour protéger votre configuration, en utilisant respectivement un chiffrement RSA ou DPAPI.

Le RSAProtectedConfigurationProvider peut être utilisé sur plusieurs ordinateurs dans un cluster. Pour plus d’informations, consultez Chiffrement des informations de configuration à l’aide de la configuration protégée.