Signatures numériques pour les modules de noyau sur les systèmes exécutant Windows Vista

  • Article

 

Microsoft Corporation

Mise à jour en juin 2007

S’applique à :
   Windows Vista
   Windows Server 2008

Résumé: Pour Microsoft Windows Vista et les versions ultérieures de la famille de systèmes d’exploitation Windows, les logiciels en mode noyau doivent avoir une signature numérique pour se charger sur les systèmes informatiques x64. Découvrez comment gérer le processus de signature pour les logiciels en mode noyau pour Windows Vista. (22 pages imprimées.)

La version actuelle de ce document est conservée sur le Web à l’adresse : https://www.microsoft.com/whdc/system/platform/64bit/kmsigning.mspx.

Contenu

Introduction
   Les signatures numériques en tant que meilleure pratique
   Options de signature de code en mode noyau
Processus de signature du code en mode noyau
   Comment obtenir un certificat de publication de logiciels (SPC)
   Création d’un fichier .cat signé
   Ajout d’une signature incorporée à un fichier image de pilote
Comment désactiver l’application des signatures pendant le développement
Comment utiliser la signature de test
   Activation de la résolution des problèmes de signature de test
   Détection des erreurs de chargement des pilotes
   Activation des événements du journal système de diagnostic d’intégrité du code
   Options de débogage de vérification du pilote
Ressources

Introduction

Pour les consommateurs et les utilisateurs d’entreprise de Windows dans le monde entier, la protection des données personnelles et d’entreprise reste une préoccupation majeure. Microsoft s’engage à implémenter de nouvelles méthodes pour aider à limiter la propagation de logiciels malveillants. Les signatures numériques pour les logiciels en mode noyau constituent un moyen important de garantir la sécurité sur les systèmes informatiques.

Les signatures numériques permettent à l’administrateur ou à l’utilisateur final qui installe un logiciel Windows de savoir si un éditeur légitime a fourni le package logiciel. Lorsque les utilisateurs choisissent d’envoyer des données Rapport d'erreurs Windows à Microsoft après une erreur ou une autre erreur, Microsoft peut analyser les données pour savoir quel logiciel des éditeurs s’exécutait sur le système au moment de l’erreur. Les éditeurs de logiciels peuvent ensuite utiliser les informations fournies par Microsoft pour rechercher et résoudre les problèmes dans leurs logiciels.

Windows Vista s’appuie sur des signatures numériques sur le code en mode noyau pour améliorer la sécurité et la stabilité de la plateforme Microsoft Windows et permettre de nouvelles expériences client avec du contenu Premium de nouvelle génération :

  • Les pilotes doivent être signés pour les appareils qui diffusent du contenu protégé. Cela inclut les pilotes audio qui utilisent l’audio en mode utilisateur protégé (PUMA) et le chemin d’accès audio protégé (PAP), ainsi que les pilotes de périphériques vidéo qui gèrent les commandes de gestion de la protection de sortie de chemin d’accès vidéo protégé (PVP-OPM).
  • Les logiciels en mode noyau non signés ne se chargent pas et ne s’exécutent pas sur les systèmes x64.

Note: Même les utilisateurs disposant de privilèges d’administrateur ne peuvent pas charger du code en mode noyau non signé sur des systèmes x64. Cela s’applique à tous les modules logiciels qui se chargent en mode noyau, y compris les pilotes de périphérique, les pilotes de filtre et les services du noyau.

L’étendue de la nouvelle stratégie de signature de code en mode noyau est très étendue. Pour les développeurs qui publient des logiciels en mode noyau, cette stratégie a les effets suivants :

  • Pour tout composant en mode noyau qui n’est pas encore signé, les éditeurs doivent obtenir un certificat de publication de logiciels (SPC) et utiliser le SPC pour signer tous les logiciels 64 bits en mode noyau qui s’exécuteront sur des systèmes d’ordinateurs x64 exécutant Windows Vista. Cela inclut les logiciels de services en mode noyau.

  • Les éditeurs qui fournissent un pilote de périphérique 64 bits ou d’autres logiciels en mode noyau déjà signés via le programme de logo Windows verront leurs catalogues de pilotes signés avec une signature WHQL (Hardware Quality Labs) Windows. Pour tester entièrement le package de pilotes avant de le soumettre à WHQL, signez le catalogue de pilotes à l’aide d’un SPC.

  • Dans le cas particulier des pilotes de démarrage, il est également nécessaire d’utiliser un SPC pour signer incorporé le fichier image binaire du pilote pour des performances de démarrage optimales.

    Note Un pilote est dit démarrage s’il est chargé par le chargeur du système d’exploitation Windows Vista. Les pilotes de démarrage peuvent être identifiés comme suit : le pilote INF spécifie le type de démarrage « Start=0 », ou un service noyau est configuré avec un ServiceType comme pilote de noyau ou pilote de système de fichiers et StartMode pour être « démarrage ».

La stratégie de signature de code en mode noyau obligatoire s’applique à tous les logiciels en mode noyau sur les systèmes x64 exécutant Windows Vista. Toutefois, Microsoft encourage les éditeurs à signer numériquement tous les logiciels, y compris les pilotes de périphérique pour les plateformes 32 bits et 64 bits. Windows Vista effectue la vérification de signature en mode noyau sur les systèmes x86 pour prendre en charge le contenu multimédia protégé. Toutefois, les signatures de pilotes en mode noyau ne sont pas obligatoires pour les systèmes 32 bits.

Cet article explique comment gérer le processus de signature du code en mode noyau pour Windows Vista, notamment comment obtenir un certificat de publication de logiciels (SPC), des instructions pour la protection des clés et comment signer un package de pilotes à l’aide des outils fournis dans le Kit de pilotes Windows (WDK).

Les signatures numériques en tant que meilleure pratique

Depuis la publication de Windows 98, Microsoft a promu la signature de pilotes pour les classes d’appareils désignées en tant que mécanisme permettant d’améliorer la fiabilité des pilotes, de fournir une meilleure expérience utilisateur, de réduire les coûts de support pour les fournisseurs de logiciels et de matériel et de réduire le coût total de possession pour les clients.

Pour les pilotes de périphérique et d’autres logiciels en mode noyau, les pilotes signés dans le cadre du programme de logo Windows augmentent la confiance de l’utilisateur final dans la qualité du logiciel et améliorent l’expérience utilisateur, car un logo Windows appartenant à un pilote indique que le pilote a été testé et que la signature numérique qui accompagne le logo Windows confirme n’a pas été modifiée depuis le test.

Pour la plupart des packages de pilotes en mode noyau, une signature numérique est fournie dans un fichier de catalogue signé (.cat). Le Laboratoire de qualité matérielle Windows (WHQL) fournit un fichier .cat signé par Microsoft à distribuer avec un package de pilotes qui répond aux exigences du programme de logo Windows.

Le processus de création d’un logiciel en mode noyau signé se compose de deux activités distinctes mais connexes. Celles-ci peuvent être effectuées en parallèle, car le logiciel n’a généralement pas besoin d’être signé jusqu’à relativement tard dans le processus de développement.

  • Gestion du processus de signature. Cela est généralement géré par la gestion des programmes et les services de publication de logiciels des éditeurs et comprend :

    • Sélection de l’option de signature appropriée.
    • Obtention des certificats nécessaires.
    • Gestion de la signature numérique ou des clés de signature de code.

    Note Pour signer numériquement des fichiers binaires d’images ou des catalogues, un éditeur de logiciel doit disposer d’une clé de signature de code certifiée, ce qui signifie qu’une autorité de certification a suffisamment établi l’identité de l’éditeur.

  • Implémentation du pilote à signer. Cette opération est généralement gérée par l’équipe de développement de l’éditeur et comprend les éléments suivants :

    • Implémentation du pilote lui-même.
    • Création d’un package de pilote signé pour les tests internes ou la mise en production.

Ces processus sont documentés pour les versions antérieures de Windows dans WDK et le Kit de développement logiciel (SDK) de plateforme. Cet article décrit les options supplémentaires liées à la signature de code en mode noyau pour Windows Vista.

Options de signature de code en mode noyau

Plusieurs options sont disponibles pour utiliser la configuration requise pour la signature de code en mode noyau (KMCS) dans Windows Vista. La signature des fichiers de pilote n’est pas requise pour que Windows Vista charge les pilotes lors du développement du code en mode noyau. Au lieu de cela, les développeurs peuvent utiliser l’un des mécanismes pour désactiver temporairement les vérifications au moment du chargement par le noyau sur les systèmes de développement et de test non automatisés. Toutefois, la signature de test des packages de pilotes est nécessaire pour automatiser l’installation d’un package de pilotes sur les systèmes de test sans avoir de fenêtres contextuelles d’installation de pilotes. L’infrastructure de gestion des pilotes (DMI) vérifie la signature du package de pilotes lors de l’installation et avertit les utilisateurs des pilotes non signés.

Le tableau suivant compare les options pour les modules de noyau de signature numérique pris en charge par Windows Vista.

Options de signature de modules de noyau

Options de signature Fonctionnalité vérifiée pour répondre aux exigences de logo Identité vérifiée Utilisation prévue
Programme de logo Windows Oui Oui Libérer
Signature de code en mode noyau à l’aide d’un SPC Non Oui Libérer
Programme de signature de test WHQL Non Oui Test
Signature de test KMCS Non Non Test

Le programme Logo Windows vérifie les fonctionnalités correctes du pilote et garantit une qualité et une fiabilité élevées. Les packages de pilotes soumis au programme de logo Windows sont signés numériquement par Microsoft. Le programme Logo Windows accepte les packages d’appareils installés via un fichier INF pour le matériel qui répond aux exigences du logo Windows. L’éditeur de pilotes envoie le package de pilotes après avoir terminé les tests de vérification du pilote pour le programme de logo Windows. Les pilotes éligibles pour le logo reçoivent un fichier .cat signé par Microsoft. Pour plus d’informations sur le programme de logo Windows, consultez la section Ressources à la fin de ce document.

Les développeurs peuvent signer le fichier image de pilote ou le catalogue de pilotes avec un SPC à des fins de test avant de l’envoyer à WHQL afin de vérifier que le pilote se charge et fonctionne correctement.

La signature de code en mode noyau à l’aide d’un SPC permet d’identifier l’éditeur d’un module de noyau chargé dans Windows Vista. Il ne fournit aucun niveau de certification de la fonctionnalité ou de la fiabilité du module noyau. Pour les pilotes qui ne sont pas éligibles pour le logo Windows ou qui ne font pas partie des exigences du produit, l’éditeur peut créer un fichier .cat pour le package de pilotes et le signer avec le SPC de l’éditeur.

Important La signature de code en mode noyau ne remplace pas le programme WHQL. Microsoft encourage les éditeurs à utiliser le programme de logo Windows pour garantir la qualité des pilotes. La signature de code en mode noyau ne nécessite pas que l’éditeur de logiciels réponde aux exigences de test du programme de logo Windows associées à WHQL.

Un fichier .cat signé est tout ce qui est nécessaire pour que la plupart des packages de pilotes s’installent et se chargent correctement sur les systèmes x64, à l’exception des packages qui contiennent un pilote chargé par le chargeur de démarrage Windows Vista. Un package de pilotes qui contient un pilote de périphérique chargé par le chargeur de démarrage Windows Vista doit être signé de deux façons :

  • Le fichier binaire du pilote en mode noyau chargé au moment du démarrage doit avoir une signature incorporée dans le fichier binaire signé avec un SPC. Par souci de simplicité, il peut être plus facile d’intégrer la signature de tous les fichiers image de pilote dans le package.
  • Le package de pilotes installé à l’aide d’un fichier INF doit également avoir un fichier catalogue signé, tout comme les packages de pilotes qui ne contiennent pas de pilote de démarrage, pour la vérification de signature pendant l’installation.

Les fabricants doivent s’assurer que les fournisseurs de matériel acquièrent un SPC et signent tous les pilotes de démarrage qui seront installés sur les systèmes installés par le fabricant.

À des fins de test pendant le cycle de développement, la signature de code à l’aide d’un certificat « test » est recommandée au lieu de signer avec un certificat de mise en production. Un fichier binaire signé de test est reconnu par les systèmes Windows Vista uniquement lorsqu’une option de configuration de démarrage qui autorise l’utilisation de certificats de signature de test est activée. La signature de test n’est pas activée par défaut et les signatures de test ne seront pas approuvées par la majorité des systèmes Windows Vista.

Le programme signature de test WHQL est également pris en charge pour la signature de test. Les participants au programme peuvent envoyer des packages de pilotes pour la signature de test WHQL. La signature sur les catalogues signés de test est générée par un certificat émis sous l’autorité racine de test Microsoft. L’autorité racine de test Microsoft est acceptée lorsque le paramètre de configuration de démarrage de Windows Vista active la signature de test. Pour plus d’informations sur le programme de signature de test WHQL, consultez la section Ressources à la fin de ce document.

Pour la signature « test » et « release », l’équipe de développement doit suivre les meilleures pratiques pour la gestion des clés, comme décrit dans Guide pour la protection des clés de signature de code plus loin dans ce document.

La signature de test est abordée plus en détail dans la section Comment utiliser la signature de test plus loin dans ce document.

Processus de signature du code en mode noyau

La signature numérique d’un fichier image en mode noyau ou d’un catalogue établit l’intégrité du ou des fichiers signés. Les modules logiciels ne doivent jamais être modifiés une fois l’opération de signature de code effectuée. La modification du fichier image après la signature du code entraîne des échecs de vérification de la signature au moment de l’installation et au moment du chargement.

Un package de pilotes contenant plusieurs fichiers peut être signé à l’aide d’un catalogue. Le package de pilotes doit avoir un fichier de catalogue signé (.cat) qui permet d’identifier le serveur de publication lors de l’installation du package de pilotes et de vérifier l’image du pilote lorsqu’il est chargé dans le noyau. Le fichier catalogue contient un certificat numérique qui identifie l’éditeur, ainsi que des hachages du contenu du package qui permettent au système de vérifier que les fichiers du package n’ont pas été modifiés.

Comme mentionné précédemment, les pilotes de démarrage doivent avoir des signatures incorporées dans le fichier image du pilote. Les signatures incorporées dans les fichiers image du pilote de démarrage optimisent les performances de démarrage du système d’exploitation en éliminant la nécessité de localiser le fichier appropriate.cat lorsque le chargeur du système d’exploitation vérifie la signature du pilote.

La signature de pilote n’est pas requise pour chaque build pendant le processus de développement du pilote. Les développeurs peuvent désactiver l’application de la signature des pilotes, comme décrit dans Comment désactiver l’application de signature pendant le développement plus loin dans ce document.

Les sections suivantes expliquent comment obtenir et gérer des certificats. Les mécanismes de signature des packages de pilotes sont abordés plus loin dans ce document.

Comment obtenir un certificat de publication de logiciels (SPC)

Obtenez un SPC pour la signature de votre logiciel en mode noyau qui répond à la stratégie obligatoire de signature de code en mode noyau en procédant comme suit :

  1. Obtenez un SPC auprès d’une autorité de certification commerciale qui émet des certificats numériques pour la signature du code en mode noyau. La liste des autorités de certification qui fournissent des certificats de publication de logiciels (ou des certificats de signature de code) qui peuvent être utilisés pour la signature de code en mode noyau est disponible sur la page web Signature de code en mode noyau Microsoft Inter-certificats pour Windows Vista .
  2. Téléchargez un certificat croisé correspondant à partir de la page web Signature de code Microsoft Cross-certificates pour Windows Vista En mode noyau pour l’autorité de certification racine qui a émis le SPC. Le certificat croisé est utilisé dans la signature numérique pour le code en mode noyau afin que la signature puisse être vérifiée jusqu’à une autorité racine approuvée connue du noyau Windows Vista.

Lorsque vous demandez un certificat de publication de logiciels à une autorité de certification commerciale, suivez les instructions sur le site web de l’autorité de certification pour savoir comment acquérir et installer le certificat de signature de code sur l’ordinateur sur lequel vous utiliserez la clé privée pour signer le code.

Conseils pour la protection des clés de signature de code

Les clés de chiffrement qui sont au cœur du processus de signature de code doivent être bien protégées et traitées avec le même soin que les ressources les plus précieuses pour toute entreprise. Ces clés représentent une identité d’entreprise. Tout code signé avec ces clés apparaît à Windows comme s’il contient une signature numérique valide qui peut être tracée jusqu’à l’entreprise. Si les clés sont volées, elles peuvent être utilisées pour signer frauduleusement du code malveillant et entraîner la remise de code contenant un cheval de Troie ou un virus qui semble provenir d’un éditeur légitime.

Pour obtenir des informations détaillées sur la protection sécurisée des clés privées, reportez-vous aux meilleures pratiques en matière de signature de code.

Utilisation de certificats croisés avec signature de code en mode noyau

La signature de code en mode noyau utilise des certificats croisés dans le cadre du processus de signature de code. Un certificat croisé est un certificat X.509 émis par une autorité de certification qui signe la clé publique pour le certificat racine d’une autre autorité de certification. Le chargeur du système d’exploitation Windows Vista et le noyau reconnaissent les certificats croisés lors de la vérification des signatures du pilote. Les certificats croisés permettent au noyau d’avoir une seule autorité racine Microsoft approuvée, mais offrent également la possibilité d’étendre la chaîne d’approbation à plusieurs autorités de certification commerciales qui émettent des certificats d’éditeur de logiciels.

Les certificats croisés permettent aux développeurs et aux éditeurs d’utiliser des certificats d’éditeur de logiciels pour signer des logiciels en mode noyau. Les développeurs qui utilisent la signature de code en mode noyau téléchargent le fichier de certificat croisé (.cer) correct sur le système où l’opération de signature numérique est effectuée. Les éditeurs n’ont pas besoin de distribuer le fichier inter-certificats avec leur package logiciel ou pilote. Le certificat croisé est inclus avec la signature numérique dans le fichier image du pilote ou le catalogue de package de pilotes. Les utilisateurs qui installent le package de pilotes n’auront pas besoin d’effectuer des étapes de configuration pour Que Windows Vista vérifie la signature numérique qui inclut un certificat croisé.

Important SignTool dans windows Vista Beta2 WDK est la seule version de SignTool qui prend actuellement en charge l’ajout de certificats croisés à une signature numérique. Les versions précédentes de SignTool dans le Kit de développement logiciel (SDK) de plateforme Windows Server 2003 ou le DDK ne prennent pas en charge l’ajout de certificats croisés.

Les certificats croisés pour plusieurs autorités de certification à utiliser pour la signature de code en mode noyau peuvent être téléchargés à partir du site web Microsoft WHDC. Pour plus d’informations, consultez Microsoft Cross-certificates for Windows Vista Kernel Mode Kernel Mode Signing dans les ressources à la fin de ce document.

Pour plus d’informations sur l’ajout du certificat croisé à la signature numérique, consultez les sections Comment signer un fichier .cat et Ajouter une signature incorporée à un fichier image de pilote.

Génération de certificats de test

Les certificats de test sont utilisés à la place des SPC pour les modules logiciels en mode noyau de signature de test qui ne sont pas destinés à être distribués ou mis en production en dehors de votre organization. La signature de test applique une signature numérique aux fichiers binaires en mode noyau ou aux catalogues de packages de pilotes utilisés à des fins de test interne. La signature de test est abordée plus en détail dans la section Comment utiliser la signature de test plus loin dans ce document. Lors de l’utilisation d’un certificat de test pour la signature de code en mode noyau, un certificat croisé n’est pas obligatoire.

Les certificats de test peuvent être générés à l’aide d’une autorité de certification d’entreprise ou de l’utilitaire Makecert. Pour plus d’informations sur l’utilisation d’une autorité de certification d’entreprise pour émettre des certificats de signature de test au sein de votre organization, consultez Meilleures pratiques de signature de code.

Dans l’exemple suivant, Makecert génère un certificat de test émis par la racine de test par défaut, stocke la clé privée dans un conteneur de clés et génère le certificat dans un magasin de certificats et un fichier de certificat :

Makecert –r –pe –ss SubjectCertStoreName –n "CN= CertName" OutputFile.cer

Les arguments de Makecert dans l’exemple effectuent les opérations suivantes :

  • -r
    Crée un certificat auto-signé, c’est-à-dire qu’il s’agit d’un certificat racine.
  • -Pe
    Rend la clé privée associée au certificat exportable.
  • -ssSubjectCertStoreName
    Spécifie le nom du magasin de certificats qui contient le certificat racine.
  • **-n « CN=**CertName »
    Spécifie un nom pour le certificat. Si aucun nom de certificat n’est fourni, le nom par défaut du certificat est « Joe’s Software Emporium ».
  • OutputFile.cer
    Nom du fichier dans lequel le certificat racine est enregistré.

Un exemple de script de commande utilisant makecert est disponible dans le WDK. Le nom du fichier de script est, selfsign_example.txt, situé sous le répertoire « bin\selfsign ». Avant d’installer votre package de pilote, vous devez ajouter vos certificats de test dans le magasin de certificats sur l’ordinateur de test cible.

L’exemple suivant montre comment ajouter les certificats de test au magasin racine approuvé et au magasin d’éditeur approuvé sur l’ordinateur de test cible.

certmgr.exe -add OutputFile.cer -s -r localMachine root 
certmgr.exe -add OutputFile.cer -s -r localMachine trustedpublisher

Les arguments de Certmgr dans l’exemple effectuent les opérations suivantes :

  • -Ajouter
    Ajoute le certificat dans le fichier de certificat à un magasin de certificats.
  • -s
    Indique que le magasin de certificats est un magasin système.
  • -r
    Indique que l’emplacement du Registre du magasin système est sous HKEY_LOCAL_MACHINE clé
  • Root ou trustedpublisher
    Indique le nom du magasin de certificats système

Pour plus d’informations sur Certmgr et Makecert, consultez les ressources à la fin de cet article.

Création d’un fichier .cat signé

Les outils utilisés pour générer et signer des fichiers de catalogue, MakeCat et SignTool, sont fournis dans le WDK Windows Vista.

Notez Signtool.exe et MakeCat.exe se trouvent dans le répertoire « bin\selfsign » du WDK.

Comment créer un fichier .cat

Un fichier .cat signé numériquement contient les hachages de tous les modules en mode noyau qui sont vérifiés lors du chargement dans le noyau. Le fichier catalogue peut également inclure des hachages pour d’autres fichiers dans le package logiciel, tels que les programmes d’application en mode utilisateur (.exes) et les extensions d’application (.dlls). Microsoft recommande que le fichier .cat contienne les hachages de tous les fichiers d’un package logiciel.

Le fichier .cat contient une liste de hachages de fichiers qui correspondent à un ensemble de fichiers spécifié. Un hachage de fichier est le produit d’un hachage SHA1 sur un fichier cible. Un hachage de fichier plat n’est pas utilisé pour les fichiers, tels que les pilotes, qui utilisent le format de fichier exécutable portable (PE). Au lieu de cela, les sections pertinentes telles que l’en-tête PE, les données exécutables et les attributs authentifiés sont hachées de manière sélective.

Lorsqu’un pilote est chargé en mémoire, le noyau Windows Vista effectue un hachage SHA1 sur les sections appropriées du fichier image binaire du pilote. Windows vérifie que le fichier n’a pas été falsifié en comparant la valeur de hachage obtenue à la liste des hachages binaires dans le fichier .cat associé.

Si vous installez le pilote avec un fichier INF via Plug-and-Play, utilisez l’outil Signability du WDK pour créer un catalogue comme décrit ci-dessous. Sinon, créez manuellement un catalogue comme décrit dans La procédure de création manuelle d’un catalogue plus loin dans ce document.

Comment créer un catalogue à l’aide de signabilité

La signabilité est un outil utilisé pour valider les fichiers INF et créer un fichier catalogue basé sur le fichier INF. Il est inclus dans le WDK et peut être exécuté à partir de l’environnement de génération WDK. La signabilité nécessite un fichier INF valide pour votre package de pilotes. Pour plus d’informations sur la création d’un fichier INF, consultez la documentation WDK. Pour créer un catalogue à l’aide de l’outil de signabilité, procédez comme suit :

Utilisation de la signabilité pour créer un catalogue

  1. Créez un répertoire de package de pilotes qui contient tous les fichiers de votre package de pilotes.
  2. Créez un fichier INF dans le répertoire de votre package de pilotes et modifiez-le pour Windows Vista. Plus précisément, remplacez la date de build par 4/1/2006 ou une version ultérieure et la version par 6. Par exemple : DriverVer=04/01/2006, 6.0.1.0
  3. Exécutez Signability pour créer un fichier .cat valide basé sur le fichier INF :

    • Exécutez Signability.exe et utilisez l’interface graphique graphique pour créer le fichier catalogue.

    • Exécutez Signability à partir de la ligne de commande. Notez package_directory doit être le chemin complet du répertoire du package.

      Signability.exe /auto /cat /driver:package_directory /os:512

Cet exemple crée un fichier .cat dans le répertoire driver_package , à l’aide de plusieurs arguments pris en charge par Signability :

  • /auto
    Configure l’outil Signability pour qu’il s’exécute sans intervention de l’utilisateur.
  • /Chat
    Configure l’outil Signability pour générer le fichier catalogue dont le nom est fourni par le fichier INF du package de pilotes.
  • /driver:DriverPath
    Fournit le chemin d’accès au répertoire qui contient les fichiers de package de pilotes.
  • /os:nnn
    Configure l’outil Signability pour vérifier que le fichier INF du package de pilotes est conforme aux exigences des versions de Windows spécifiées par la valeur d’indicateur nnn. 512 est la valeur de Windows Vista, Édition 64 bits.

Comment créer un catalogue manuellement

Pour créer manuellement un fichier .cat, commencez par utiliser un éditeur de texte pour créer un fichier de définition de catalogue (.cdf). Le fichier .cdf inclut une liste des fichiers qui doivent être catalogués et leurs attributs.

L’exemple suivant montre le contenu d’un fichier .cdf classique nommé Good.cdf. Le package à cataloguer contient deux fichiers, File1 et File2. Le fichier .cat résultant est nommé Good.cat.

[CatalogHeader]
Name=Good.cat
PublicVersion=0x0000001
EncodingType=0x00010001
CATATTR1=0x10010001:OSAttr:2:6.0
[CatalogFiles]
<hash>File1=File1
<hash>File2=File2

Un fichier .cat est créé avec l’outil en ligne de commande MakeCat, qui est inclus dans le Kit de développement logiciel (SDK) de plateforme et wdK. L’outil MakeCat :

  • Vérifie la liste des attributs pour chaque fichier répertorié.
  • Ajoute les attributs répertoriés au fichier .cat.
  • Hachage de chacun des fichiers répertoriés.
  • Stocke les hachages de chaque fichier dans le fichier .cat.

Pour créer un fichier .cat

  1. Utilisez un éditeur de texte pour créer un fichier .cdf qui contient une liste de fichiers à cataloguer, avec leurs attributs.
  2. Exécutez MakeCat sur le fichier .cdf.

Note MakeCat ne modifie pas le fichier .cdf.

L’exemple suivant montre comment créer un fichier .cat à partir de Good.cdf. L’indicateur -v spécifie la version détaillée de MakeCat. Les fichiers hachés et le fichier Good.cat nouvellement généré sont placés dans le même dossier que File1 et File2.

MakeCat -v Good.cdf

Le fichier .cat est maintenant prêt à être signé.

Pour plus d’informations sur MakeCat et le format des fichiers .cdf, consultez la documentation MakeCat répertoriée dans les ressources à la fin de ce document.

Comment signer un fichier .cat

Le fichier .cat généré par MakeCat contient tous les hachages de fichiers requis pour installer des modules en mode noyau sur le système d’un utilisateur. Toutefois, le fichier doit également être signé numériquement.

Un fichier .cat est signé avec l’outil en ligne de commande SignTool. La signature numérique du catalogue, utilisée pour vérifier les fichiers image en mode noyau, doit contenir un certificat croisé. Le certificat croisé est ajouté à l’aide d’une nouvelle option de commande à SignTool.

Important Vous devez utiliser la version de SignTool de Windows Vista Beta2 WDK pour ajouter le certificat croisé à la signature numérique.

L’exemple suivant montre comment utiliser Signtool pour signer un fichier .cat avec un SPC et une clé privée correspondante importé dans le magasin de certificats Windows. Pour plus d’informations sur l’utilisation de Signtool avec un HSM, consultez la documentation SignTool répertoriée dans les ressources à la fin de ce document.

SignTool sign /v /ac CrossCertificateFile /s SPCCertificateStore /n SPCSubjectName /t http://timestamp.verisign.com/scripts/timestamp.dll Good.cat

Cet exemple utilise plusieurs des arguments pris en charge par SignTool :

  • Signe
    Configure l’outil pour signer le fichier .cat nommé CatFileName.cat.
  • /v
    Spécifie l’option détaillée pour une exécution réussie et les messages d’avertissement*.*
  • /Ac
    Ajoute le certificat croisé du fichier CrossCertificateFile à la signature numérique
  • /s
    Spécifie un magasin de certificats nommé SPCCertificateStore.
  • /n
    Spécifie un certificat avec le nom d’objet SPCSubjectName.
  • URL /t
    Spécifie que la signature numérique sera horodatée par l’autorité d’horodatage (TSA) indiquée par l’URL.

Important Le brouillard de signature du catalogue ou du pilote inclut un horodatage pour fournir les informations nécessaires à la révocation de clé en cas de compromission de la clé privée de signature du code du signataire.

Pendant l’installation de l’appareil, si le SPC utilisé pour la signature a expiré et que la signature n’a pas été horodatée, le fichier .cat n’est pas installé et Windows n’autorise pas le chargement du pilote. Toutefois, si la signature est horodatée par une autorité d’horodatage approuvée, le fichier .cat est installé et Windows autorise le chargement du pilote.

Signature du fichier de téléchargement à extraction automatique

Les logiciels publiés pour la distribution sur un site web de support produit sont généralement empaquetés dans un fichier d’archive auto-extracteur. L’exécutable à extraction automatique est téléchargé à l’aide d’un navigateur web et le contenu extrait avant que l’utilisateur ne commence à l’installer sur son ordinateur. Utilisez le SPC qui a signé le fichier .cat du package de pilotes pour signer numériquement le fichier .exe auto-extracteur.

La signature numérique du fichier de .exe auto-extraction identifie l’éditeur du fichier d’archive et garantit l’intégrité du fichier .exe auto-extracteur téléchargé sur Internet. Les utilisateurs qui téléchargent le fichier .exe auto-extracteur reçoivent généralement une boîte de dialogue d’approbation ou un avertissement de sécurité lorsqu’ils choisissent de télécharger et d’exécuter le fichier à extraction automatique.

Dans Windows Vista, si l’utilisateur examine les détails de la boîte de dialogue Avertissement de sécurité et sélectionne « Toujours installer le logiciel à partir du nom> de <l’éditeur », cette option simplifie la confirmation ultérieure lorsqu’un package de pilotes est installé. Lorsque le package de pilotes est installé, l’utilisateur est invité à faire confiance au serveur de publication du package de pilotes signé avant le début de l’installation du pilote. Si l’utilisateur a sélectionné l’option permettant d’installer toujours le logiciel à partir de l’éditeur de pilotes lorsqu’il a téléchargé le fichier .exe auto-extracteur, l’invite de dialogue d’approbation lors de l’installation du pilote ne se produit pas.

Comment installer un fichier .cat signé

Pour les pilotes installés via Plug-and-Play, aucune modification du processus d’installation n’est attendue. L’installation d’un pilote signé incorporé ne nécessite aucun traitement spécial au-delà des mécanismes d’installation et d’INF standard. Notez que seuls les utilisateurs membres du groupe Administrateurs sont autorisés à installer des packages de pilotes.

Les pilotes qui ne sont pas installés via Plug-and-Play doivent installer leurs fichiers .cat dans le dossier racine du catalogue système. L’installation d’un catalogue dans le dossier racine du catalogue peut être gérée à l’aide d’appels d’API de catalogue Win32 existants, en particulier CryptCATAdminAddCatalog.

Ajout d’une signature incorporée à un fichier image de pilote

Pour optimiser les performances de la vérification du pilote au moment du démarrage, les fichiers binaires des pilotes de démarrage doivent avoir une signature incorporée à l’aide du SPC en plus du fichier .cat signé pour le package. La signature incorporée permet de gagner beaucoup de temps pendant le démarrage du système d’exploitation, car il n’est pas nécessaire que le chargeur de système d’exploitation localise le fichier .cat dans le pilote. Un système Windows Vista classique peut avoir plus d’une centaine de fichiers catalogue différents dans le magasin racine du catalogue. La localisation du fichier catalogue correct pour vérifier le hachage de l’image d’un pilote particulier peut impliquer beaucoup de surcharge système lors de la recherche du fichier correct dans plusieurs catalogues.

Les pilotes de démarrage sont identifiés en fonction de la valeur StartType du service de SERVICE_BOOT_START (0).

Les signatures incorporées n’interfèrent pas avec la signature ou la validation du fichier .cat. Notez que les hachages contenus dans les catalogues et les signatures incorporées excluent sélectivement la partie signature du format de fichier PE

Pour utiliser Signtool.exe d’incorporer une signature dans un fichier binaire de pilote de démarrage à l’aide d’un SPC et d’une clé privée correspondante importée dans le magasin de certificats Windows, utilisez la commande suivante :

SignTool sign /v /ac CrossCertificateFile /s SPCCertificateStore /n SPCSubjectName /t http://timestamp.verisign.com/scripts/timestamp.dll winloaddriver.sys

Cet exemple utilise plusieurs des arguments pris en charge par SignTool :

  • Signe
    La commande sign configure l’outil pour signer le pilote nommé winloaddriver.sys.
  • /v
    Spécifie l’option détaillée pour une exécution réussie et les messages d’avertissement*.*
  • /Ac
    Ajoute le certificat croisé du fichier CrossCertificateFile à la signature numérique
  • Options /s
    Spécifie le magasin de certificats nommé SPCCertificateStore
  • /n
    Spécifie le certificat avec le nom d’objet SPCSubjectName.
  • URL /t
    Spécifie que la signature numérique doit être horodatée par le TSA indiqué par l’URL.

Important: Le catalogue ou le pilote doit être horodaté, car cela fournit les informations nécessaires pour la révocation de clé en cas de compromission de la clé des signataires.

Comment vérifier une signature incorporée

La procédure suivante montre comment vérifier une signature incorporée avec Windows Explorer.

Pour vérifier les signatures incorporées

  1. Lorsque vous exécutez Windows Vista, cliquez avec le bouton droit sur le pilote .sys fichier, puis cliquez sur Propriétés dans le menu contextuel.
  2. Cliquez sur l’onglet Signatures numériques , s’il est présent.
    • Si cet onglet n’est pas présent, le fichier n’a pas de signature incorporée.
  3. Sélectionnez le signataire, puis cliquez sur Détails pour ouvrir la boîte de dialogue Détails de la signature.
  4. Cliquez sur Afficher le certificat pour ouvrir les pages de propriétés du certificat.
    • Vérifiez qu’il n’existe aucune boîte de dialogue d’avertissement.
    • Vérifiez que le nom de l’objet des certificats est Publisher est inscrit auprès d’une autorité de certification reconnue.
  5. Cliquez sur l’onglet Chemin de certification .
    • Vérifiez que le nom d’objet du certificat supérieur est Microsoft Code Verification Root.

Pour vérifier les signatures incorporées à l’aide de signtool.exe pour la stratégie de signature de code en mode noyau

  • Signtool.exe pouvez être utilisé pour vérifier la signature sur un fichier .cat à l’aide de la commande suivante :
Signtool verify /kp /c tstamd64.cat toaster.sys

Vérifiez que le hachage de l’image pour le fichier toaster.sys se trouve dans le fichier catalogue. L’outil retourne la chaîne « Success ».

Comment désactiver l’application des signatures pendant le développement

Au cours des premières phases de développement, les développeurs peuvent désactiver l’application dans Windows afin que la signature de pilote ne soit pas nécessaire. Les options suivantes sont disponibles pour permettre aux développeurs de désactiver temporairement l’application de la signature du code en mode noyau afin que Windows Vista charge un pilote non signé.

  • Attachement d’un débogueur de noyau. L’attachement d’un débogueur de noyau actif à l’ordinateur cible désactive l’application des signatures en mode noyau dans Windows Vista et permet au pilote de se charger.

  • Utilisation de l’option F8. Une option de démarrage avancé F8 introduite avec Windows Vista , « Désactiver l’application de signature de pilote », est disponible pour désactiver l’application de signature du noyau uniquement pour la session de démarrage actuelle. Ce paramètre ne persiste pas entre les sessions de démarrage.

  • Définition de la configuration de démarrage. Un paramètre de configuration de démarrage est disponible dans la version bêta2 de Windows Vista qui désactive l’application des signatures en mode noyau pour qu’elles soient conservées entre les sessions de démarrage.

    Windows Vista inclut un outil en ligne de commande, BCDedit, qui peut être utilisé pour définir l’option dans Windows Vista Bêta2 afin de désactiver les vérifications de signature. Pour utiliser BCDedit, l’utilisateur doit être membre du groupe Administrateurs sur le système et exécuter la commande à partir d’une invite de commandes avec élévation de privilèges. Une invite de commandes avec élévation de privilèges peut être lancée en créant un raccourci de bureau vers cmd.exe, puis en cliquant avec le bouton droit et « Exécuter en tant qu’administrateur ».

    Voici un exemple d’exécution de BDCedit à l’invite de commandes :

    // Disable enforcement – no signing checks
Bcdedit.exe –set nointegritychecks ON 

// Enable enforcement – signing checks apply
Bcdedit.exe –set nointegritychecks OFF 

// Disabling integrity check on an alternate OS 
// specified by a GUID for the system ID
Bcdedit.exe –set {4518fd64-05f1-11da-b13e-00306e386aee} nointegritychecks ON

Note L’option Bcdedit pour désactiver les vérifications d’intégrité est uniquement disponible pour le chargement de pilotes non signés sur la version bêta2 de Windows Vista. Pour plus d’informations, consultez le FAQ sur l’éditeur BCD sur le site Web MSDN.

Comment utiliser la signature de test

La signature de test fournit des options supplémentaires aux organisations de développement pour l’incorporation de la signature de code en mode noyau pour les logiciels de préversion qui ne sont pas prêts pour la publication. La signature de test permet d’utiliser des certificats de signature de code « test » pour signer des pilotes qui se chargeront sur Windows Vista lorsque le paramètre de configuration de démarrage de Windows Vista autorise les signatures de test.

La signature de test peut être appropriée à utiliser dans les scénarios suivants :

  • Les équipes de développement doivent tester les versions préliminaires d’un pilote sur des systèmes de test où il n’est pas pratique d’attacher un débogueur de noyau.
  • Les tests automatisés des logiciels en mode noyau rendent peu pratique l’utilisation de l’option de démarrage avancé F8 pour désactiver temporairement l’application de la signature du pilote à chaque cycle de démarrage de l’ordinateur.

La signature de test permet aux développeurs de signer des versions préliminaires des fichiers binaires en mode noyau de manière à ce que Windows Vista puisse vérifier et charger le pilote signé. La signature de test implique les différences suivantes par rapport à la signature de production ou de mise en production normale :

  • Les certificats utilisés pour la signature de test peuvent être générés à l’aide de l’outil de signature de code Makecert.exe ou émis par une autorité de certification d’entreprise, au lieu d’utiliser un SPC émis par une autorité de certification commerciale.
  • L’option de configuration de démarrage Windows Vista pour activer la signature de test doit être activée sur le système Windows Vista qui chargera le pilote signé de test.

Les organisations de développement peuvent configurer une PKI d’entreprise et émettre leurs propres certificats de signature de code de test à utiliser pour la signature de test. Lorsque Windows Vista active la signature de test, la vérification de la signature numérique sur le fichier binaire du pilote accepte les certificats émis par une autorité de certification ou une autorité d’émission. La signature de test vérifie que l’image du pilote est signée, mais la validation du chemin d’accès du certificat effectuée en mode noyau ne nécessite pas que l’émetteur soit configuré en tant qu’autorité racine approuvée. Cela permet aux organisations d’utiliser des signatures individuelles sur des fichiers binaires de test, en fonction des informations d’identification émises pour la signature de code dans le organization. Microsoft recommande cette forme de déploiement pour tester la signature au sein de la signature de code en mode noyau.

L’utilisation de certificats générés par l’outil makecert.exe est également acceptable pour la signature de test. Toutefois, les certificats générés par makecert ne fournissent souvent pas d’informations d’identité utiles et il n’existe aucun moyen de suivre le développeur individuel qui a créé une version de test signée du fichier binaire de préversion.

Note La version bêta2 de Windows Vista accepte uniquement les certificats de test générés par l’outil makecert. Les certificats de signature de code de test émis par une autorité de certification d’entreprise pour la signature de test ne sont pas disponibles dans Windows Vista Bêta2.

Les instructions signtool de ce document fonctionnent de la même façon, que vous utilisiez un SPC ou un certificat généré par l’utilitaire makecert, ou que vous utilisiez un certificat émis par une autorité de certification d’entreprise. La seule différence est généralement le nom de l’émetteur et du sujet dans le certificat.

Le programme signature de test WHQL est également pris en charge pour la signature de test. Les participants au programme peuvent envoyer des packages de pilotes pour les signatures de test WHQL. La signature sur les catalogues signés de test est générée par un certificat émis sous l’autorité racine de test Microsoft. L’autorité racine de test Microsoft est acceptée par défaut sur Windows Vista Beta2 dans le cadre du programme bêta. Dans la version finale de Windows Vista, l’autorité racine de test Microsoft est acceptée lorsque le paramètre de configuration de démarrage de Windows Vista active la signature de test.

Les fichiers binaires en mode noyau signé de test ne se chargent pas sur les systèmes Windows Vista par défaut. Les signatures numériques sur les fichiers binaires signés de test ne sont pas valides sur les systèmes Windows Vista par défaut, car la stratégie de signature de code en mode noyau n’accepte pas et n’approuve pas les certificats de signature de test.

Activation de la signature de test

Utilisez l’outil en ligne de commande Bcdedit pour activer la signature de test. Pour utiliser BCDedit, l’utilisateur doit être membre du groupe Administrateurs sur le système et exécuter la commande à partir d’une invite de commandes avec élévation de privilèges. Une invite de commandes avec élévation de privilèges peut être lancée en créant un raccourci de bureau vers cmd.exe, puis en cliquant avec le bouton droit et « Exécuter en tant qu’administrateur ».

Voici un exemple d’exécution de BDCedit à l’invite de commandes :

// Accept test signed kernel mode signatures
Bcdedit.exe –set TESTSIGNING ON 

// Do not accept test signed kernel mode signatures
Bcdedit.exe –set TESTSIGNING OFF

L’option TESTSIGNING de configuration de démarrage détermine si Windows Vista accepte les fichiers binaires en mode noyau signé de test. L’option n’est pas définie par défaut, ce qui signifie que les signatures numériques sur les pilotes en mode noyau signés de test ne sont pas vérifiées et ne se chargent pas. Lorsque Windows Vista accepte les fichiers binaires du mode noyau signés de test, certains contenus Premium protégés peuvent ne pas être accessibles sur le système.

Dépannage

Vous pouvez suivre des étapes spécifiques pour identifier et résoudre les problèmes potentiels liés à la vérification des signatures de code en mode noyau. Cette section fournit des informations sur la résolution des problèmes liés à l’application de la signature des pilotes. Les outils main pour résoudre les problèmes de signature de pilote sont les suivants :

  • Détection des erreurs de chargement des pilotes
  • Activation des événements de journal système de diagnostic d’intégrité du code.

L’application grille-pain incluse dans le WDK Windows Vista est utilisée comme exemple. L’application grille-pain se trouve dans le WDK sous le répertoire « src\general\grille-pain ».

Détection des erreurs de chargement des pilotes

L’application grille-pain installe un pilote de périphérique (toaster.sys), qui, pour cet exemple, n’est pas signé. Le symptôme d’un problème avec le pilote non signé est que le périphérique de grille-pain ne parvient pas à démarrer. À l’aide de l’Gestionnaire de périphériques, vous pouvez case activée l’status de l’appareil Grille-pain et afficher le status du pilote, comme illustré dans l’image d’écran suivante.

Bb530195.digitalsigskernmodules01(en-us,MSDN.10).gif

Figure 1. Erreur de pilote non signé

L’appareil n’a pas pu démarrer, car le pilote de périphérique n’était pas signé et l’application de la signature en mode noyau a bloqué le chargement du pilote dans le noyau. Afin d’identifier définitivement la source du problème, nous avons configuré le système pour activer l’application des diagnostics de signature, comme décrit ci-dessous.

Activation des événements du journal système de diagnostic d’intégrité du code

L’application de la signature de code en mode noyau est implémentée par un composant Windows Vista appelé Intégrité du code. L’intégrité du code génère des événements de diagnostic et un événement de journal d’audit système lorsque la signature d’un module de noyau ne parvient pas à vérifier correctement.

  • Les événements opérationnels d’intégrité du code sont toujours activés. Les événements opérationnels sont des événements d’avertissement lorsqu’une vérification d’image case activée échoué lors du chargement d’un fichier binaire en mode noyau.
  • Les événements d’audit du système d’intégrité du code sont générés lorsque la stratégie d’audit système est activée. La stratégie d’audit système n’est pas activée par défaut.
  • Les événements détaillés d’intégrité du code sont des événements d’informations analytiques et de débogage qui montrent toutes les vérifications d’image réussies lors du chargement de fichiers binaires en mode noyau. Les événements détaillés ne sont pas activés par défaut.

Les événements d’intégrité du code sont visibles sous le observateur d'événements, qui fait partie du composant logiciel enfichable MMC Gestion de l’ordinateur. (Dans le bouton Démarrer , cliquez avec le bouton droit sur Ordinateur, puis sélectionnez Gérer).

Le flux d’événements d’intégrité du code se trouve sous la hiérarchie suivante :

observateur d'événements -> Journaux des applications et des services -> Microsoft -> Windows -> CodeIntegrity

Bb530195.digitalsigskernmodules02(en-us,MSDN.10).gif

Figure 2 : Événements d’intégrité du code

Le journal opérationnel d’intégrité du code affiche les événements générés par le noyau lorsqu’un pilote en mode noyau échoue à une vérification d’image case activée lors du chargement du pilote. L’échec de la vérification de l’image peut être dû à plusieurs raisons, notamment les suivantes :

  • Le pilote n’a pas été signé, mais installé sur le système par un administrateur et l’intégrité du code n’autorise pas le chargement du pilote.
  • Le pilote a été signé, mais le fichier image du pilote a été modifié ou falsifié et la modification a invalidé la signature du pilote.
  • Le périphérique de disque système peut présenter des erreurs d’appareil lors de la lecture du fichier image de l’appareil à partir de secteurs de disque défectueux.

Une entrée de journal opérationnel pour un échec de vérification d’image de pilote non signé ou modifié ressemble à l’exemple suivant :

Bb530195.digitalsigskernmodules03(en-us,MSDN.10).gif

Figure 3. Entrée du journal opérationnel

L’événement indique que le pilote de grille-pain (toaster.sys) n’a pas pu être chargé, car il n’a pas été signé (ou l’image toaster.sys qui tente de charger n’est pas la même que celle qui a été signée numériquement par l’éditeur).
Tous les messages du journal des événements d’intégrité du code sont répertoriés dans la section Code Integrity Event Logt Messages ci-dessous.

Événements du journal d’audit système

L’intégrité du code génère des événements de journal d’audit système correspondant aux événements d’avertissement opérationnel en cas d’échec de la vérification d’image d’un pilote en mode noyau. Les événements du journal système sont visibles dans le observateur d'événements sous l’affichage Journaux Windows, Journal système.

Les événements d’audit système peuvent ne pas être activés sur tous les systèmes Windows Vista. Utilisez le composant logiciel enfichable MMC Paramètres de sécurité locaux pour vérifier ou activer les « événements système d’audit » sous les paramètres Stratégies locales, Stratégie d’audit.

Événements d’information dans le journal détaillé

Des événements d’information supplémentaires sur l’intégrité du code pour toutes les vérifications d’image en mode noyau sont disponibles à l’aide de l’affichage des événements détaillé. Ces événements montrent une vérification d’image réussie de tous les pilotes chargés sur le système.

Les étapes d’activation de l’affichage d’événements détaillé d’intégrité du code sont les suivantes :

  1. Cliquez avec le bouton gauche sur la vue opérationnelle pour afficher les événements d’intégrité du code actuels (le cas échéant).
  2. Cliquez avec le bouton gauche sur le nœud Intégrité du code pour définir le focus.
  3. Cliquez avec le bouton droit sur le nœud Intégrité du code pour obtenir le menu contextuel.
  4. Sélectionnez Affichage.
  5. Sélectionnez Afficher les journaux analytiques et de débogage.
  6. Cela crée une sous-arborescence avec deux nœuds supplémentaires, le nœud Opérationnel et le nœud détaillé .
  7. Cliquez avec le bouton droit sur le nœud détaillé et sélectionnez Propriétés.
  8. Sélectionnez la feuille Général, puis sélectionnez l’option Activer la journalisation. Cela doit activer le mode de journalisation détaillé.
  9. Redémarrez le système pour recharger tous les fichiers binaires en mode noyau.
  10. Après le redémarrage, ouvrez le composant logiciel enfichable Gestion de l’ordinateur et affichez le journaldes événementsdétaillé de l’intégrité du code.

Vous pouvez case activée si toaster.sys est correctement signé comme suit :

Dans ce cas particulier, toaster.sys est un pilote PnP nommé dans un fichier catalogue (tstamd64.cat dans « \src\general\toaster\toastpkg\toastcd ». Utilisez l’utilitaire SignTool pour vérifier si toaster.sys est correctement signé par le catalogue à l’aide de la commande suivante :

Signtool verify /kp /c tstamd64.cat toaster.sys

Options de débogage de vérification du pilote

Dans certains cas, les développeurs peuvent vouloir appliquer une stratégie de signature de code en mode noyau obligatoire même lorsqu’un débogueur est attaché. Par exemple, lorsqu’une pile de pilotes a un pilote non signé (tel qu’un pilote de filtre) qui ne parvient pas à se charger, ce qui peut invalider l’ensemble de la pile. Étant donné que l’attachement d’un débogueur permet au pilote non signé de se charger, le problème semble disparaître dès que le débogueur est attaché. Le débogage de ce type de problème peut être difficile. Afin de faciliter le débogage dans ce cas, l’intégrité du code prend en charge une clé de Registre qui peut être définie pour appliquer l’application de la signature en mode noyau, même lorsqu’un débogueur est attaché.

Deux indicateurs sont définis dans le Registre qui contrôlent le comportement d’intégrité du code sous le débogueur. Les indicateurs ne sont pas définis par défaut.

Créez une valeur de Registre comme suit :

Key:   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CI
Value:   DebugFlags      REG_DWORD

Valeurs possibles :

  • 00000001
    Entraîne une interruption de débogage dans le débogueur et le pilote non signé est autorisé à charger avec g.
  • 00000010
    CI ignore la présence du débogueur et le chargement des pilotes non signés est bloqué.

Toute autre valeur entraîne le chargement des pilotes non signés. Il s’agit de la stratégie par défaut.

Messages du journal des événements d’intégrité du code

Voici les événements d’avertissement enregistrés dans le journal opérationnel d’intégrité du code :

  • « L’intégrité du code ne peut pas vérifier l’intégrité de l’image du <nom> du fichier, car le hachage du fichier est introuvable sur le système. »
  • « L’intégrité du code a détecté un pilote non signé. »
  • « Cet événement est lié à l’analyse de la qualité des logiciels (SQM). »

Voici les événements d’information enregistrés dans le journal détaillé de l’intégrité du code :

  • « L’intégrité du code a trouvé un ensemble de hachages d’image par page pour le nom> de < fichier dans un < nom >de catalogue. »
  • « L’intégrité du code a trouvé un ensemble de hachages d’image par page pour le nom> de fichier < dans le certificat incorporé à l’image. »
  • « L’intégrité du code a trouvé un hachage de fichier pour le nom> du < fichier dans un < nom >de catalogue. »
  • « L’intégrité du code a trouvé un hachage de fichier pour le nom> du < fichier dans le certificat incorporé à l’image. »
  • « L’intégrité du code a déterminé qu’un nom >de fichier de module< de noyau non signé est chargé dans le système. Consultez l’éditeur pour voir si une version signée du module de noyau est disponible. »
  • « L’intégrité du code ne peut pas vérifier l’intégrité de l’image du <nom> du fichier, car le jeu de hachages d’image par page est introuvable sur le système. »
  • « L’intégrité du code ne peut pas vérifier l’intégrité de l’image du nom> du < fichier, car l’ensemble de hachages d’image par page est introuvable sur le système. L’image est autorisée à se charger, car le débogueur en mode noyau est attaché. »
  • « L’intégrité du code ne peut pas vérifier l’intégrité de l’image du <nom> du fichier, car un hachage de fichier est introuvable sur le système. L’image est autorisée à se charger, car le débogueur en mode noyau est attaché. »
  • « L’intégrité du code n’a pas pu charger le catalogue de noms> de < fichiers. »
  • « L’intégrité du code a correctement chargé le catalogue de noms> de < fichiers. »

Ressources