Recommandations de chiffrement pour Microsoft SDL

Article
05/30/2024

Utilisez ces informations comme référence lors de la conception de produits afin d’utiliser les mêmes API, algorithmes, protocoles et longueurs de clé que ceux que Microsoft exige pour ses propres produits et services. Une grande partie de ce contenu s’appuie sur les propres normes de sécurité internes de Microsoft utilisées pour créer le cycle de vie SDL (Security Development Lifecycle).

Les développeurs sur plateformes non-Windows pourront probablement tirer parti de ces recommandations. Bien que les noms des API et des bibliothèques risquent d’être différents, les bonnes 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 TLS/SSL

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

TLS 1.3 doit être activé.
TLS 1.2 peut être activé pour améliorer la compatibilité avec les clients plus anciens.
TLS 1.1, TLS 1.0, SSL 3 et SSL 2 doivent être désactivés

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é.
Tous les autres chiffrements de blocs, y compris 3DES (Triple DES/TDEA), et RC4 doivent être remplacés s’ils sont utilisés pour le chiffrement.

Pour les algorithmes de chiffrement par blocs symétriques, une longueur de clé minimale de 128 bits est requise, mais nous recommandons de prendre en charge des clés 256 bits. 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).

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 que ceux mentionnés ci-après, présentent des écueils d’implémentation qui les exposent à des utilisations incorrectes. En particulier, le mode de chiffrement ECB (Electronic Code Book) 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 risque d’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)
Tout autre mode ne figurant pas dans la liste des modes recommandés précédente

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 ou prévisible. 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.

Les vecteurs d’initialisation ne doivent jamais être réutilisés lors de l’exécution de plusieurs opérations de chiffrement. La réutilisation peut révéler des informations sur les données chiffrées, en particulier lors de l’utilisation de modes de chiffrement en continu comme OFB (Output Feedback) ou CTR (Counter).

Recommandations sur AES-GCM et AES-CCM

AES-GCM (Galois/Counter Mode) et AES-CCM (Counter avec CBC-MAC) sont des modes de chiffrement authentifiés couramment utilisés. Ils allient confidentialité et protection de l’intégrité, ce qui les rend utiles pour les communications sécurisées. Cependant, leur fragilité réside dans la réutilisation de nonce. Lorsque le même nonce (vecteur d’initialisation) est utilisé deux fois, il peut entraîner des conséquences catastrophiques.

Nous vous recommandons de suivre les instructions relatives à nonce décrites dans NIST SP 800-38D, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC, en portant une attention particulière à la section 8.3 concernant le nombre maximal d’appels.

Une autre option serait de générer des clés AES-GCM/CCM uniques pour chaque message chiffré, limitant ainsi le nombre maximal d’appels à 1. Cette approche est recommandée pour chiffrer les données au repos, où l’utilisation d’un compteur ou la possibilité de suivre le nombre maximal d’appels pour une clé donnée seraient irréalisables.

Pour chiffrer les données au repos, vous pouvez également envisager d’utiliser AES-CBC avec un code MAC (Message Authentication Code) comme alternative à l’aide d’un schéma « Encrypt-then-MAC », en vous assurant d’utiliser des clés distinctes pour le chiffrement et pour le MAC.

Vérification de l’intégrité

On croit à tort que le chiffrement par défaut assure à la fois confidentialité et intégrité. De nombreux algorithmes de chiffrement ne fournissent aucun contrôle d’intégrité et risquent d’être vulnérables aux attaques de falsification. Il faut effectuer des étapes supplémentaires pour garantir l’intégrité des données avant des les envoyer et après les avoir reçues.

Si vous ne pouvez pas utiliser un algorithme de chiffrement authentifié avec des données associées (AEAD) comme AES-GCM, une alternative consiste à valider l’intégrité avec un code MAC à l’aide d’un schéma « Encrypt-then-MAC », en vous assurant d’utiliser des clés distinctes pour le chiffrement et pour le MAC.

L’utilisation d’une clé distincte pour le chiffrement et pour le MAC est essentielle. S’il n’est pas possible de stocker les deux clés, une alternative valide consiste à dériver deux clés de la clé principale à l’aide d’une fonction de dérivation de clés (KDF) appropriée, une pour le chiffrement et une pour le code MAC. Pour plus d’informations, consultez SP 800-108 Rev. 1, Recommendation for Key Derivation Using Pseudorandom Functions | CSRC (nist.gov).

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

RSA

L’algorithme RSA peut être utilisé 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.
Une longueur minimale de clé de 2 048 bits est recommandée, mais nous vous recommandons de prendre en charge une longueur de clé de 3 072 bits.

ECDSA et ECDH

L’échange de clés basé sur ECDH et les signatures basées sur ECDSA doivent utiliser l’une des trois courbes approuvées par NIST (P-256, P-384 ou P521).
La prise en charge de P-256 doit être considérée comme le minimum. Nous vous recommandons de prendre en charge P-384.

Integer Diffie-Hellman

La longueur de clé >= 2 048 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

Définissez une période de chiffrement (cryptoperiod) pour toutes les clés.
- Par exemple : une clé symétrique pour le chiffrement des données, souvent appelée clé de chiffrement de données ou DEK, peut avoir une période d’utilisation allant jusqu’à deux ans pour le chiffrement des données, également appelée période d’utilisation d’initiateur (« originator usage period »). Vous pouvez définir qu’elle a une période d’utilisation valide pour le déchiffrement pendant trois ans supplémentaires, également appelée période d’utilisation de destinataire (« recipient usage period »).
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.

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().
Rand() ne doit pas être utilisé pour les applications de chiffrement.

Linux/mac OS

L’appareil /dev/urandom fournit une source de données aléatoires fortement chiffrée, tout comme l’appel système getrandom(2).

Non recommandé

Les fonctions non sécurisées liées à la génération de nombres aléatoires sont : rand, System.Random (.NET), GetTickCount, GetTickCount64 et Get-Random (cmdlet PowerShell).
L’utilisation de l’algorithme du générateur de nombres aléatoires à courbe elliptique double (« DUAL_EC_DRBG ») n’est pas autorisé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 les autres plateformes, les développeurs risquent d’évaluer des bibliothèques de chiffrement autres que celles de la plateforme en vue de les utiliser. En règle générale, les bibliothèques de chiffrement de 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 d’un chiffrement de plateforme versus un autre chiffrement doit être guidée par les conditions requises suivantes :

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

Code natif

Primitives de chiffrement : si votre version est sur Windows, utilisez CNG si possible.
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é (.NET)

Primitives de chiffrement : utilisez l’API définie dans l’espace de noms System.Security.Cryptography.
Utilisez la dernière version disponible de .NET.

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 (révision 1) : 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 3) : recommandation pour les schémas d’établissement de clé Pair-Wise utilisant le chiffrement logarithmique discret.

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 du certificat

Les produits qui utilisent les protocoles TLS ou DTLS doivent vérifier entièrement les certificats X.509 des entités auxquelles ils se connectent. Ce processus comprend la vérification des parties suivantes du certificat :

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é.

N’utilisez pas de certificats « auto-signés ». 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.

Fonctions de hachage de chiffrement

Les produits doivent utiliser la famille SHA-2 des algorithmes de hachage (SHA-256, SHA-384 et SHA-512). La troncation des hachages de chiffrement pour des raisons de sécurité à moins de 128 bits n’est pas autorisée. Bien que l’utilisation de SHA-256 soit le minimum, nous vous recommandons de prendre en charge SHA-384.

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 code MAC basé sur un hachage (HMAC) ou d’un code MAC basé sur un chiffrement par blocs est recommandée tant que l’utilisation de tous les algorithmes de chiffrement symétrique ou de hachage sous-jacents est également recommandée. Actuellement, cela comprend les fonctions HMAC-SHA2 (HMAC-SHA256, HMAC-SHA384 et HMAC-SHA512). Bien que l’utilisation de HMAC-SHA256 soit le minimum, nous vous recommandons de prendre en charge HMAC-SHA384.

Une troncation des codes 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 atteignent 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. Ces métadonnées doivent inclure l’algorithme utilisé, les tailles de clé et les modes de remplissage.
- Pour plus d’informations sur l’agilité de chiffrement, consultez l’article Agilité de chiffrement.
Autant que possible, les produits doivent utiliser des protocoles de chiffrement établis et fournis par la plateforme au lieu de les réimplémenter, y compris les formats de signature (par exemple, utilisez un format standard existant).
Ne signalez pas les échecs d’opérations de chiffrement aux utilisateurs finaux. Lorsque vous retournez 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 quelques 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 ne sont pas recommandés. 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é.

Partager via