Fonctionnalités CNG

  • Article

CNG a les fonctionnalités suivantes.

Agilité de chiffrement

L’une des propositions de valeur clé de CNG est l’agilité de chiffrement, parfois appelée agnosticisme de chiffrement. La conversion de l’implémentation de protocoles tels que SSL ( Secure Sockets Layer Protocol) ou TLS ( Transport Layer Security ), CMS (S/MIME), IPsec, Kerberos, etc., en CNG, était toutefois nécessaire pour rendre cette capacité précieuse. Au niveau CNG, il était nécessaire de fournir une substitution et une détectabilité pour tous les types d’algorithmes (fonctions symétriques, asymétriques, de hachage), la génération de nombres aléatoires et d’autres fonctions utilitaires. Les modifications au niveau du protocole sont plus significatives, car dans de nombreux cas, les API de protocole étaient nécessaires pour ajouter la sélection d’algorithme et d’autres options de flexibilité qui n’existaient pas auparavant.

CNG est d’abord disponible dans Windows Vista et est positionné pour remplacer les utilisations existantes de CryptoAPI dans toute la pile logicielle Microsoft. Les développeurs tiers trouveront un grand nombre de nouvelles fonctionnalités dans CNG, notamment :

  • Un nouveau système de configuration de chiffrement, prenant en charge une meilleure agilité de chiffrement.
  • Abstraction plus fine pour le stockage de clés (et séparation du stockage des opérations d’algorithme).
  • Isolation des processus pour les opérations avec des clés à long terme.
  • Générateurs de nombres aléatoires remplaçables.
  • Soulagement des restrictions de signature d’exportation.
  • Sécurité des threads dans toute la pile.
  • API de chiffrement en mode noyau.

En outre, CNG prend en charge tous les algorithmes suite B requis, y compris le chiffrement de courbe elliptique (ECC). Les applications CryptoAPI existantes continueront de fonctionner à mesure que CNG devient disponible.

Certification et conformité

Le GNC est validé selon les normes FIPS (Federal Information Processing Standards) 140-2 et fait partie de la cible d’évaluation pour la certification Critères communs Windows. CNG a été conçu pour être utilisable en tant que composant dans un système validé fiPS niveau 2.

CNG est conforme aux exigences des critères communs en stockant et en utilisant des clés de longue durée dans un processus sécurisé.

Prise en charge de Suite B

Une fonctionnalité importante de CNG est sa prise en charge des algorithmes suite B. En février 2005, la National Security Agency (NSA) de l’États-Unis a annoncé un ensemble coordonné de chiffrement symétrique, d’accord de secret asymétrique (également appelé échange de clés), de signature numérique et de fonctions de hachage pour une utilisation future du gouvernement américain appelé Suite B. La NSA a annoncé que les implémentations de la Suite B certifiées peuvent et seront utilisées pour la protection des informations désignées comme des informations top secrètes, secrètes et privées qui, dans le passé, étaient décrites comme sensibles mais non classifiées. Pour cette raison, la prise en charge de la Suite B est très importante pour les éditeurs de logiciels d’application et les intégrateurs de systèmes, ainsi que pour Microsoft.

Tous les algorithmes de suite B sont connus publiquement. Ils ont été développés en dehors du cadre du secret gouvernemental historiquement associé au développement d’algorithmes de chiffrement. Dans ce même laps de temps, certains pays et régions européens ont également proposé les mêmes exigences de suite B pour la protection de leurs informations.

La suite B de chiffrement recommande l’utilisation de l'Diffie-Hellman de courbe elliptique (ECDH) dans de nombreux protocoles existants tels que l’Internet Key Exchange (IKE, principalement utilisé dans IPsec), TLS ( Transport Layer Security ) et LE MIME sécurisé (S/MIME).

CNG prend en charge la suite B qui s’étend à tous les algorithmes requis : AES (toutes les tailles de clé), la famille SHA-2 (SHA-256, SHA-384 et SHA-512) des algorithmes de hachage, ECDH et DSA de courbe elliptique (ECDSA) sur les courbes primaires standard NIST P-256, P-384 et P-521. Les courbes binaires, les courbes Koblitz, les courbes premiers personnalisées et les courbes elliptiques Menezes-Qu-Vanstone (ECMQV) ne sont pas prises en charge par les fournisseurs d’algorithmes Microsoft inclus dans Windows Vista.

Support hérité

CNG prend en charge l’ensemble actuel d’algorithmes dans CryptoAPI 1.0. Tous les algorithmes actuellement pris en charge dans CryptoAPI 1.0 continueront d’être pris en charge dans CNG.

Prise en charge du mode noyau

CNG prend en charge le chiffrement en mode noyau. Les mêmes API sont utilisées en mode noyau et en mode utilisateur pour prendre entièrement en charge les fonctionnalités de chiffrement. SSL/TLS et IPsec fonctionnent en mode noyau en plus des processus de démarrage qui utilisent CNG. Toutes les fonctions CNG ne peuvent pas être appelées à partir du mode noyau. La rubrique de référence pour les fonctions qui ne peuvent pas être appelées à partir du mode noyau indique explicitement que la fonction ne peut pas être appelée à partir du mode noyau. Sinon, toutes les fonctions CNG peuvent être appelées à partir du mode noyau si l’appelant s’exécute à PASSIVE_LEVELIRQL. En outre, certaines fonctions CNG en mode noyau peuvent être appelées à DISPATCH_LEVEL IRQL, en fonction des fonctionnalités du fournisseur.

L’interface du fournisseur de support de sécurité du noyau Microsoft (Ksecdd.sys) est un module de chiffrement logiciel à usage général résidant au niveau du mode noyau de Windows. Ksecdd.sys s’exécute en tant que pilote d’exportation en mode noyau et fournit des services de chiffrement via leurs interfaces documentées aux composants du noyau. Le seul algorithme de fournisseur Microsoft intégré qui n’est pas pris en charge par Ksecdd.sys est DSA.

Windows Server 2008 et Windows Vista : CNG ne prend pas en charge les algorithmes et fournisseurs enfichables en mode noyau. Les seuls algorithmes de chiffrement pris en charge disponibles en mode noyau sont les implémentations fournies par Microsoft via les API CNG en mode noyau.

Audit

Pour se conformer à certaines exigences des critères communs en plus d’offrir une sécurité complète, de nombreuses actions qui se produisent dans la couche CNG sont auditées dans le fournisseur de stockage de clés logicielles (KSP) Microsoft. Le KSP Microsoft respecte les instructions suivantes pour créer des enregistrements d’audit dans le journal de sécurité :

  • Les échecs de génération de clé et de paire de clés, y compris les échecs d’auto-test, doivent être audités.
  • L’importation et l’exportation des clés doivent être auditées.
  • Les échecs de destruction de clé doivent être audités.
  • Les clés persistantes doivent être auditées lorsqu’elles sont écrites et lues dans des fichiers.
  • La cohérence par paire case activée les échecs doivent être audités.
  • Les échecs de validation de clé secrète, le cas échéant, doivent être audités, par exemple, les contrôles de parité sur les clés 3DES.
  • Les échecs de chiffrement, de déchiffrement, de hachage, de signature, de vérification, d’échange de clés et de génération de nombres aléatoires doivent être audités.
  • Les autotests de chiffrement doivent être audités.

En général, si une clé n’a pas de nom, il s’agit d’une clé éphémère. Une clé éphémère ne persiste pas et le KSP Microsoft ne génère pas d’enregistrements d’audit pour les clés éphémères. Le KSP Microsoft génère des enregistrements d’audit en mode utilisateur dans le processus LSA uniquement. Aucun enregistrement d’audit n’est généré par le CNG en mode noyau. Les administrateurs doivent configurer la stratégie d’audit pour obtenir tous les journaux d’audit KSP à partir du journal de sécurité. Un administrateur doit exécuter la ligne de commande suivante pour configurer des audits supplémentaires générés par les fournisseurs de services clés :

auditpol /set /subcategory:"other system events » /success:enable /failure:enable

Générateurs de nombres aléatoires remplaçables

Une autre amélioration apportée par CNG est la possibilité de remplacer le générateur de nombres aléatoires (RNG) par défaut. Dans CryptoAPI, il est possible de fournir un autre RNG dans le cadre d’un fournisseur de services de chiffrement (CSP), mais il n’est pas possible de rediriger les fournisseurs de services cloud de base Microsoft pour utiliser un autre RNG. CNG permet de spécifier explicitement un RNG particulier à utiliser dans des appels particuliers.

Cohérence de thread

Toutes les fonctions qui modifient la même zone de mémoire en même temps (sections critiques) lors de l’appel à partir de threads distincts ne sont pas thread-safe.

Mode d’opération

CNG prend en charge cinq modes d’opérations qui peuvent être utilisés avec des chiffrements de blocs symétriques via les API de chiffrement. Ces modes et leur prise en charge sont répertoriés dans le tableau suivant. Le mode de fonctionnement peut être modifié en définissant la propriété BCRYPT_CHAINING_MODE pour le fournisseur d’algorithme à l’aide de la fonction BCryptSetProperty .

Mode de fonctionnement BCRYPT_CHAINING_MODE valeur Algorithmes Standard
BCE (Codebook électronique) BCRYPT_CHAIN_MODE_ECB Chiffrements par blocs symétriques SP800-38A
CBC (Cipher Block Chaining) BCRYPT_CHAIN_MODE_CBC Chiffrements par blocs symétriques SP800-38A
BFC (Commentaires sur le chiffrement) BCRYPT_CHAIN_MODE_CFB Chiffrements par blocs symétriques SP800-38A
CCM (Counter with CBC) BCRYPT_CHAIN_MODE_CCM AES SP800-38C
GCM (Galois/Counter Mode) BCRYPT_CHAIN_MODE_GCM AES SP800-38D

 

Notes

Seuls les modes de fonctionnement ECB, CBC et CFB sont définis dans Windows Vista. GCM et CCM nécessitent Windows Vista avec Service Pack 1 (SP1) ou Windows Server 2008.