Partager via

Fonctionnalités CNG

  • Article

CNG dispose des fonctionnalités suivantes :

Agilité de chiffrement

L’une des principales propositions de valeur de CNG est l’agilité du chiffrement, parfois appelée agnosticisme de chiffrement. La conversion de l'implémentation de protocoles tels que SSL (Secure Sockets Layer), TLS (Transport Layer Security), CMS (S/MIME), IPsec, Kerberos et ainsi de suite, a toutefois été nécessaire pour que CNG soit avantageux. Au niveau de CNG, il était nécessaire de fournir une substitution et une découvrabilité pour tous les types d’algorithmes (fonctions symétriques, asymétriques et de hachage), la génération de nombres aléatoires et d’autres fonctions utilitaires. Les modifications au niveau du protocole sont plus importantes, car dans de nombreux cas, les API de protocole ont dû ajouter une sélection d’algorithmes et d’autres options de flexibilité qui n’existaient pas précédemment.

CNG est disponible pour la première fois dans Windows Vista et est prêt à remplacer les utilisations existantes de CryptoAPI dans l'ensemble de 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, offrant une meilleure agilité de chiffrement.
  • Une abstraction plus fine pour le stockage de clés (et une séparation entre le stockage et les opérations d’algorithme).
  • Une isolation des processus pour les opérations avec des clés à long terme.
  • Des générateurs de nombres aléatoires remplaçables.
  • Un allègement des restrictions de signature pour l’exportation.
  • Une sécurité des threads dans toute la pile.
  • Une API de chiffrement en mode noyau.

En outre, CNG inclut la prise en charge de l'ensemble des algorithmes Suite B requis, notamment le chiffrement à courbe elliptique (ECC). Les applications CryptoAPI existantes continueront de fonctionner au fur et à mesure que CNG devient disponible.

Certification et conformité

CNG est conforme aux normes FIPS (Federal Information Processing Standards) 140-2 et fait partie de la cible d’évaluation pour la certification des critères communs Windows. CNG a été conçu pour être utilisable en tant que composant dans un système conforme au niveau 2 des normes FIPS.

CNG est conforme aux exigences des critères communs en stockant et en utilisant des clés à long terme dans le cadre d’un processus sécurisé.

Prise en charge de Suite B

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

Tous les algorithmes Suite B sont connus publiquement. Le secret gouvernemental historiquement associé au développement d’algorithmes de chiffrement ne concerne pas le développement de ces algorithmes. Dans un même temps, certains pays et certaines régions d'Europe ont également proposé les mêmes exigences de chiffrement Suite B pour la protection de leurs informations.

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

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

Prise en charge héritée

CNG prend en charge l’ensemble actuel d’algorithmes dans CryptoAPI 1.0. Chaque algorithme actuellement pris en charge dans CryptoAPI 1.0 continuera 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 afin de prendre entièrement en charge les fonctionnalités de chiffrement. Les protocoles SSL/TLS et IPsec fonctionnent en mode noyau en plus des processus de démarrage qui utiliseront CNG. Les fonctions CNG ne peuvent pas toutes être appelées à partir du mode noyau. La rubrique de référence concernant les fonctions qui ne peuvent pas être appelées à partir du mode noyau indique explicitement les fonctions qui ne peuvent pas être appelées à partir du mode noyau. Sinon, toutes les fonctions CNG peuvent être appelées à partir du mode noyau si l’appelant s’exécute à PASSIVE_LEVEL IRQL. 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 la prise en charge de la 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 aux composants du noyau via leurs interfaces documentées. Le seul algorithme intégré du fournisseur Microsoft 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 en mode noyau sont ces implémentations fournies par Microsoft via les API CNG en mode noyau.

Audit

Pour se conformer à certaines des exigences des critères communs tout en fournissant 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 suit les consignes 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’autotest, doivent être audités.
  • L’importation et l’exportation de clés doivent être auditées.
  • Les échecs de destruction de clés doivent être audités.
  • Les clés persistantes doivent être auditées lorsqu’elles sont écrites et lues dans des fichiers.
  • Les échecs de vérification de cohérence par paire doivent être audités.
  • Les échecs de validation de clé secrète, le cas échéant, doivent être audités (par exemple, les vérifications 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 n’est pas persistante 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 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 des KSP :

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

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

Une autre amélioration que fournit CNG est la possibilité de remplacer le générateur de nombres aléatoires par défaut (RNG). 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 CSP cloud de Microsoft Base pour utiliser un autre RNG. CNG permet de spécifier explicitement le RNG à utiliser dans des appels particuliers.

Cohérence de thread

Toutes les fonctions qui modifient la même zone de mémoire simultanément (sections critiques) quand elles sont appelées à partir de threads distincts ne sont pas thread-safe.

Mode de fonctionnement

CNG prend en charge cinq modes de fonctionnement qui peuvent être utilisés avec des chiffrements par 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’algorithmes à l’aide de la fonction BCryptSetProperty.

Mode de fonctionnement Valeur BCRYPT_CHAINING_MODE Algorithmes Standard
ECB (Electronic Codebook) 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
CFB (Cipher Feedback) 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

 

Remarque

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