Utiliser uniquement les chiffrements de blocs symétriques approuvés et les longueurs de clé
Titre
Détails
Composant
Application web
Phase SDL
Construire
Technologies applicables
Générique
Attributs
N/A
Informations de référence
N/A
Étapes
Les produits doivent utiliser uniquement les chiffrements de blocs symétriques et les longueurs de clé associées qui ont été explicitement approuvées par l’Advisor Crypto dans votre organisation. Les algorithmes symétriques approuvés chez Microsoft incluent les chiffrements de bloc suivants :
Pour le nouveau code AES-128, AES-192 et AES-256 sont acceptables
Pour la compatibilité descendante avec le code existant, trois clés 3DES sont acceptables
Pour les produits utilisant des chiffrements de blocs symétriques :
Advanced Encryption Standard (AES) est requis pour le nouveau code
La norme 3DES (Triple Data Encryption Standard) à trois clés est autorisée dans le code existant pour la compatibilité descendante
Tous les autres chiffrements de bloc, y compris RC2, DES, 2 Key 3DES, DESX et Skipjack, peuvent uniquement être utilisés pour déchiffrer les anciennes données et doivent être remplacés s’ils sont utilisés pour le chiffrement
Pour les algorithmes de chiffrement de bloc symétrique, une longueur de clé minimale de 128 bits est requise. Le seul algorithme de chiffrement de bloc recommandé pour le nouveau code est AES (AES-128, AES-192 et AES-256 sont tous acceptables)
Trois clés 3DES sont actuellement acceptables si déjà utilisés dans le code existant ; la transition vers AES est recommandée. DES, DESX, RC2 et Skipjack ne sont plus considérés comme sécurisés. Ces algorithmes peuvent uniquement être utilisés pour déchiffrer les données existantes pour la compatibilité descendante, et les données doivent être rechiffrées à l’aide d’un chiffrement de bloc recommandé
Notez que tous les chiffrements de blocs symétriques doivent être utilisés avec un mode de chiffrement approuvé, ce qui nécessite l’utilisation d’un vecteur d’initialisation approprié (IV). Un IV approprié, est généralement un nombre aléatoire et jamais une valeur constante
L’utilisation d’algorithmes de chiffrement hérités ou non approuvés et de longueurs de clé plus petites pour la lecture des données existantes (par opposition à l’écriture de nouvelles données) peut être autorisée après la révision du Comité de chiffrement de votre organisation. Toutefois, vous devez déposer une exception contre cette exigence. En outre, dans les déploiements d'entreprise, les produits devraient envisager d'avertir les administrateurs lorsque le chiffrement faible est utilisé pour lire les données. Ces avertissements doivent être explicatifs et actionnables. Dans certains cas, il peut être approprié que la stratégie de groupe contrôle l’utilisation du chiffrement faible
Algorithmes .NET autorisés pour l’agilité du chiffrement managé (par ordre de préférence)
AesCng (conforme FIPS)
AuthenticatedAesCng (conforme FIPS)
AESCryptoServiceProvider (conforme FIPS)
AESManaged (non conforme FIPS)
Notez qu'aucun de ces algorithmes ne peut être spécifié via les méthodes SymmetricAlgorithm.Create ou CryptoConfig.CreateFromName sans apporter de modifications au fichier machine.config. Notez également que AES dans les versions de .NET antérieures à .NET 3.5 est nommée RijndaelManagedet AesCngAuthenticatedAesCng est >disponible via CodePlex et nécessite le CNG dans le système d’exploitation sous-jacent
Utiliser les modes de chiffrement de bloc approuvés et les vecteurs d’initialisation pour les chiffrements symétriques
Titre
Détails
Composant
Application web
Phase SDL
Construire
Technologies applicables
Générique
Attributs
N/A
Informations de référence
N/A
Étapes
Tous les chiffrements de blocs symétriques doivent être utilisés avec un mode de chiffrement symétrique approuvé. Les seuls modes approuvés sont CBC et CTS. En particulier, le mode de fonctionnement du carnet de code électronique (BCE) doit être évité ; l’utilisation de BCE nécessite l’examen du Conseil de chiffrement de votre organisation. Toutes les utilisations d’OFB, CFB, CTR, CCM et GCM ou tout autre mode de chiffrement doivent être examinées par le Conseil de chiffrement de votre organisation. La réutilisation du même vecteur d’initialisation (IV) avec des chiffrements de bloc dans les « modes de chiffrement de streaming », comme CTR, peut entraîner la révélation des données chiffrées. Tous les chiffrements de blocs symétriques doivent également être utilisés avec un vecteur d’initialisation approprié (IV). Un IV approprié est un nombre aléatoire et fort par chiffrement et n’est jamais une valeur constante.
Utiliser les algorithmes asymétriques, les longueurs de clé et le remplissage approuvés
Titre
Détails
Composant
Application web
Phase SDL
Construire
Technologies applicables
Générique
Attributs
N/A
Informations de référence
N/A
Étapes
L’utilisation d’algorithmes de chiffrement interdits présente un risque important pour la sécurité des produits et doit être évitée. Les produits doivent utiliser uniquement ces algorithmes de chiffrement et les longueurs de clé associées et le remplissage qui ont été explicitement approuvés par le conseil de chiffrement de votre organisation.
RSA peut être utilisé pour le chiffrement, l’échange de clés et la signature. Le chiffrement RSA doit utiliser uniquement les modes de remplissage OAEP ou RSA-KEM. Le code existant peut utiliser le mode de remplissage PKCS #1 v1.5 uniquement par souci de compatibilité. L’utilisation du remplissage nul est explicitement interdite. Clés >= 2048 bits sont requises pour le nouveau code. Le code existant peut prendre en charge les clés < 2048 bits uniquement à des fins de compatibilité rétroactive après une révision par la Commission de cryptographie de votre organisation. Les clés < 1024 bits peuvent uniquement être utilisées pour déchiffrer/vérifier les anciennes données et doivent être remplacées si elles sont utilisées pour les opérations de chiffrement ou de signature
ECDSA peut être utilisé uniquement pour la signature. ECDSA avec des clés >= 256 bits est requis pour le nouveau code. Les signatures ECDSA doivent utiliser l’une des trois courbes approuvées par NIST (P-256, P-384 ou P521). Les courbes qui ont été soigneusement analysées peuvent être utilisées uniquement après une révision avec le conseil de chiffrement de votre organisation.
ECDH - peut être utilisé uniquement pour l’échange de clés. ECDH avec des clés >= 256 bits est requis pour le nouveau code. L’échange de clés basé sur ECDH doit utiliser l’une des trois courbes approuvées par NIST (P-256, P-384 ou P521). Les courbes qui ont été soigneusement analysées peuvent être utilisées uniquement après une révision avec le conseil de chiffrement de votre organisation.
DSA- peut être acceptable après examen et approbation du comité responsable du chiffrement de votre organisation. Contactez votre conseiller de sécurité pour planifier l’examen du conseil de chiffrement de votre organisation. Si votre utilisation de DSA est approuvée, notez que vous devez interdire l’utilisation de clés inférieures à 2048 bits de longueur. CNG prend en charge les longueurs de clé 2048 bits et supérieures à partir de Windows 8.
Diffie-Hellman - peut être utilisé uniquement pour la gestion des clés de session.
>Longueur de clé = 2048 bits est requise pour le nouveau code. Le code existant peut prendre en charge des longueurs de clé < 2048 bits uniquement à des fins de compatibilité descendante après un examen par le comité responsable du chiffrement de votre organisation. Les clés < 1024 bits peuvent ne pas être utilisées.
Utiliser des générateurs de nombres aléatoires approuvés
Titre
Détails
Composant
Application web
Phase SDL
Construire
Technologies applicables
Générique
Attributs
N/A
Informations de référence
N/A
Étapes
Les produits doivent utiliser des générateurs de nombres aléatoires approuvés. Les fonctions pseudorandom telles que la fonction runtime C rand, la classe .NET Framework System.Random ou les fonctions système telles que GetTickCount doivent donc ne jamais être utilisées dans ce code. L’utilisation de l’algorithme de générateur de nombres aléatoires à courbe elliptique double (DUAL_EC_DRBG) est interdite
CNG- BCryptGenRandom (utilisation de l’indicateur BCRYPT_USE_SYSTEM_PREFERRED_RNG recommandé, sauf si l’appelant peut s’exécuter sur n’importe quel IRQL supérieur à 0 [c.-à-d. PASSIVE_LEVEL]).
CAPI - cryptGenRandom
Win32/64- RtlGenRandom (nouvelles implémentations doivent utiliser BCryptGenRandom ou CryptGenRandom) * rand_s * SystemPrng (pour le mode noyau)
. NET - RNGCryptoServiceProvider ou RNGCng
Applications du Windows Store - Windows.Security.Cryptography.CryptographicBuffer.GenerateRandom ou . GenerateRandomNumber
Apple OS X (10.7+)/iOS(2.0+)- int SecRandomCopyBytes (SecRandomRef aléatoire, size_t compte, uint8_t *octets )
Apple OS X (<10.7)- Utiliser /dev/random pour récupérer des nombres aléatoires
Java(y compris le code Java Google Android)- classe java.security.SecureRandom. Notez que pour Android 4.3 (Jelly Bean), les développeurs doivent suivre la solution de contournement recommandée par Android et mettre à jour leurs applications pour initialiser explicitement le PRNG avec l’entropie à partir de /dev/urandom ou /dev/random
N’utilisez pas de chiffrements de flux symétriques
Titre
Détails
Composant
Application web
Phase SDL
Construire
Technologies applicables
Générique
Attributs
N/A
Informations de référence
N/A
Étapes
Les chiffrements de flux symétriques, tels que RC4, ne doivent pas être utilisés. Au lieu de chiffrements de flux symétriques, les produits doivent utiliser un chiffrement de bloc, en particulier AES avec une longueur de clé d’au moins 128 bits.
Utiliser les algorithmes de hachage MAC/HMAC/indexé approuvés
Titre
Détails
Composant
Application web
Phase SDL
Construire
Technologies applicables
Générique
Attributs
N/A
Informations de référence
N/A
Étapes
Les produits doivent utiliser uniquement des algorithmes d’authentification de message approuvés (MAC) ou de code d’authentification de message basé sur le hachage (HMAC).
Un code d’authentification de message (MAC) est une information jointe à 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 un MAC basé sur le chiffrement de bloc est autorisée tant que tous les algorithmes de hachage ou de chiffrement symétrique sous-jacents sont également approuvés pour une utilisation ; actuellement, cela inclut les fonctions HMAC-SHA2 (HMAC-SHA256, HMAC-SHA384 et HMAC-SHA512) et les contrôleurs de chiffrement de bloc CMAC/OMAC1 et OMAC2 (basés sur AES).
L’utilisation de HMAC-SHA1 peut être autorisée pour la compatibilité de la plateforme, mais vous devrez déposer une exception à cette procédure et subir l’examen de chiffrement de votre organisation. La troncation des HMACs à moins de 128 bits n’est pas autorisée. L’utilisation de méthodes client pour hacher une clé et les données n’est pas approuvée et doit subir l’examen du conseil de chiffrement de votre organisation avant d’utiliser.
Utiliser uniquement les fonctions de hachage de chiffrement approuvées
Titre
Détails
Composant
Application web
Phase SDL
Construire
Technologies applicables
Générique
Attributs
N/A
Informations de référence
N/A
Étapes
Les produits doivent utiliser la famille SHA-2 d’algorithmes de hachage (SHA256, SHA384 et SHA512). Si un hachage plus court est nécessaire, par exemple une longueur de sortie 128 bits afin d’adapter une structure de données conçue avec le hachage MD5 plus court à l’esprit, les équipes de produits peuvent tronquer l’un des hachages SHA2 (généralement SHA256). Notez que SHA384 est une version tronquée de SHA512. La troncation des hachages de chiffrement à des fins de sécurité à moins de 128 bits n’est pas autorisée. Le nouveau code ne doit pas utiliser les algorithmes de hachage MD2, MD4, MD5, SHA-0, SHA-1 ou RIPEMD. Les conflits de hachage sont possibles en termes de calculs pour ces algorithmes, qui les brisent efficacement.
Algorithmes de hachage .NET autorisés pour l’agilité du chiffrement managé (par ordre de préférence) :
SHA512Cng (conforme FIPS)
SHA384Cng (conforme FIPS)
SHA256Cng (conforme FIPS)
SHA512Managed (non conforme à FIPS) (utilisez SHA512 comme nom d’algorithme dans les appels à HashAlgorithm.Create ou CryptoConfig.CreateFromName)
SHA384Managed (non conforme FIPS) (utilisez SHA384 comme nom d’algorithme dans les appels à HashAlgorithm.Create ou CryptoConfig.CreateFromName)
SHA256Managed (non conforme FIPS) (utilisez SHA256 comme nom d’algorithme dans les appels à HashAlgorithm.Create ou CryptoConfig.CreateFromName)
SHA512CryptoServiceProvider (conforme FIPS)
SHA256CryptoServiceProvider (conforme FIPS)
SHA384CryptoServiceProvider (conforme FIPS)
Utiliser des algorithmes de chiffrement forts pour chiffrer les données dans la base de données
Les algorithmes de chiffrement définissent des transformations de données qui ne peuvent pas être facilement inversées par des utilisateurs non autorisés. SQL Server permet aux administrateurs et aux développeurs de choisir parmi plusieurs algorithmes, notamment DES, Triple-DES, TRIPLE_DES_3KEY, RC2, RC4, RC4 128 bits, DESX, AES 128 bits, AES 192 bits et AES 256 bits
Les packages SSIS doivent être chiffrés et signés numériquement
La source d'un package correspond à l'individu ou à l'organisation qui a créé le package. L'exécution d'un package à partir d'une source inconnue ou non approuvée peut être risquée. Pour empêcher toute falsification non autorisée des packages SSIS, les signatures numériques doivent être utilisées. En outre, pour garantir la confidentialité des packages pendant le stockage/transit, les packages SSIS doivent être chiffrés
Ajouter une signature numérique à des éléments sécurisables de base de données critiques
Dans les cas où l’intégrité d’une base de données critique sécurisable doit être vérifiée, les signatures numériques doivent être utilisées. Les éléments sécurisables de base de données tels qu’une procédure stockée, une fonction, un assembly ou un déclencheur peuvent être signés numériquement. Voici un exemple de cas où cela peut être utile : supposons qu’un éditeur de logiciels indépendants (éditeur de logiciels indépendants) a fourni un support à un logiciel fourni à l’un de ses clients. Avant de fournir un support, le fournisseur de logiciels indépendants souhaite s'assurer qu'une base de données sécurisée dans le logiciel n'a pas été falsifiée par erreur ou par une tentative malveillante. Si l’élément sécurisable est signé numériquement, l’ISV peut vérifier sa signature numérique et valider son intégrité.
Utiliser EKM SQL Server pour protéger les clés de chiffrement
La gestion extensible des clés SQL Server permet de stocker les clés de chiffrement qui protègent les fichiers de base de données dans un appareil désactivé, tel qu’une carte à puce, un périphérique USB ou un module EKM/HSM. Cela permet également la protection des données des administrateurs de base de données (à l’exception des membres du groupe sysadmin). Les données peuvent être chiffrées à l’aide de clés de chiffrement auxquelles seul l’utilisateur de base de données a accès sur le module EKM/HSM externe.
Utiliser la fonctionnalité AlwaysEncrypted si les clés de chiffrement ne doivent pas être révélées au moteur de base de données
Always Encrypted est une fonctionnalité conçue pour protéger les données sensibles, telles que les numéros de carte de crédit ou les numéros d’identification nationaux/régionaux (par exemple, les numéros de sécurité sociale des États-Unis), stockées dans des bases de données Azure SQL Database ou SQL Server. Always Encrypted permet aux clients de chiffrer des données sensibles à l’intérieur des applications clientes et de ne jamais révéler les clés de chiffrement au moteur de base de données (SQL Database ou SQL Server). Par conséquent, Always Encrypted fournit une séparation entre ceux qui possèdent les données (et peuvent l’afficher) et ceux qui gèrent les données (mais qui ne doivent pas avoir accès)
Stocker des clés de chiffrement en toute sécurité sur un appareil IoT
Titre
Détails
Composant
Appareil IoT
Phase SDL
Construire
Technologies applicables
Générique
Attributs
Système d’exploitation d’appareil - Windows IoT Core, Connectivité des appareils - Kits de développement logiciel (SDK) d’appareil Azure IoT
Clés privées de certificat ou symétriques dans un stockage matériel protégé tel qu’un module de plateforme sécurisée ou des cartes à puce. Windows 10 IoT Core prend en charge l’utilisateur d’un module TPM et il existe plusieurs TPM compatibles qui peuvent être utilisées : TPM discret (dTPM). Il est recommandé d’utiliser un microprogramme ou un module TPM discret. Un module TPM logiciel ne doit être utilisé qu’à des fins de développement et de test. Une fois qu'un TPM (module de plateforme sécurisée) est disponible et que les clés y sont approvisionnées, le code qui génère le jeton doit être écrit sans coder en dur d'informations sensibles.
Exemple :
TpmDevice myDevice = new TpmDevice(0);
// Use logical device 0 on the TPM
string hubUri = myDevice.GetHostName();
string deviceId = myDevice.GetDeviceId();
string sasToken = myDevice.GetSASToken();
var deviceClient = DeviceClient.Create( hubUri, AuthenticationMethodFactory. CreateAuthenticationWithToken(deviceId, sasToken), TransportType.Amqp);
Comme vous pouvez le voir, la clé primaire de l’appareil n’est pas présente dans le code. Au lieu de cela, il est stocké dans le module TPM à l’emplacement 0. L’appareil TPM génère un jeton SAP de courte durée qui est ensuite utilisé pour se connecter au hub IoT.
Générer une clé symétrique aléatoire de longueur suffisante pour l’authentification auprès d’IoT Hub
Titre
Détails
Composant
Passerelle cloud IoT
Phase SDL
Construire
Technologies applicables
Générique
Attributs
Choix de passerelle - Azure IoT Hub
Informations de référence
N/A
Étapes
IoT Hub contient un registre d’identités d’appareil et lors de l’approvisionnement d’un appareil, génère automatiquement une clé symétrique aléatoire. Il est recommandé d’utiliser cette fonctionnalité d’Azure IoT Hub Identity Registry pour générer la clé utilisée pour l’authentification. IoT Hub permet également de spécifier une clé lors de la création de l’appareil. Si une clé est générée en dehors d’IoT Hub pendant l’approvisionnement d’appareils, il est recommandé de créer une clé symétrique aléatoire ou au moins 256 bits.
Vérifiez qu’une stratégie de gestion des appareils est en place qui nécessite un code confidentiel d’utilisation et autorise l’effacement à distance
Titre
Détails
Composant
Dynamics CRM Mobile Client
Phase SDL
Déploiement
Technologies applicables
Générique
Attributs
N/A
Informations de référence
N/A
Étapes
Vérifiez qu’une stratégie de gestion des appareils est en place qui nécessite un code confidentiel d’utilisation et autorise l’effacement à distance
Vérifiez qu’une stratégie de gestion des appareils est en place qui nécessite un verrou pin/mot de passe/verrouillage automatique et chiffre toutes les données (par exemple, BitLocker)
Titre
Détails
Composant
Dynamics CRM Outlook Client
Phase SDL
Construire
Technologies applicables
Générique
Attributs
N/A
Informations de référence
N/A
Étapes
Vérifiez qu’une stratégie de gestion des appareils est en place qui nécessite un verrou pin/mot de passe/verrouillage automatique et chiffre toutes les données (par exemple, BitLocker)
Assurez-vous que les clés de signature sont renouvelées lors de l’utilisation de l'Identity Server.
Titre
Détails
Composant
Serveur d’identité
Phase SDL
Déploiement
Technologies applicables
Générique
Attributs
N/A
Informations de référence
N/A
Étapes
Vérifiez que les clés de signature sont renouvelées lors de l'utilisation d'Identity Server. Le lien de la section références explique comment cela doit être planifié sans provoquer de pannes aux applications qui s’appuient sur Identity Server.
Assurez-vous que l'ID client et la clé secrète client, tous deux dotés d'une cryptographie robuste, sont utilisés dans Identity Server.
Titre
Détails
Composant
Serveur d’identité
Phase SDL
Construire
Technologies applicables
Générique
Attributs
N/A
Informations de référence
N/A
Étapes
Assurez-vous que des ID clients et des clés secrètes clients cryptographiques fortes sont utilisées dans le serveur d'identité. Les instructions suivantes doivent être utilisées lors de la génération d’un ID client et d’un secret :
Générer un GUID aléatoire en tant qu’ID client
Générer une clé 256 bits aléatoire par chiffrement en tant que secret
Commentaires
Cette page a-t-elle été utile ?
No
Vous avez besoin d’aide pour cette rubrique ?
Vous souhaitez essayer d’utiliser Ask Learn pour clarifier ou vous guider dans cette rubrique ?