Partager via


Signature Authenticode pour les développeurs de jeux

L’authentification des données est de plus en plus importante pour les développeurs de jeux. Windows Vista et Windows 7 disposent d’un certain nombre de fonctionnalités, telles que les contrôles parental, qui nécessitent que les jeux soient correctement signés pour s’assurer que personne n’a falsifié les données. Microsoft Authenticode permet aux utilisateurs finaux et au système d’exploitation de vérifier que le code du programme provient du propriétaire approprié et qu’il n’a pas été modifié ou endommagé accidentellement. Cet article explique comment commencer à authentifier votre jeu et comment intégrer l’authentification dans un processus de génération quotidien.

Remarque

À compter du 1er janvier 2016, Windows 7 et versions ultérieures n’approuvent plus aucun certificat de signature de code SHA-1 avec une date d’expiration du 1er janvier 2016 ou version ultérieure. Pour plus d’informations, consultez l’application windows de la signature et de l’horodatage du code Authenticode.

Background

Les certificats numériques sont utilisés pour établir l’identité de l’auteur. Les certificats numériques sont émis par un tiers approuvé appelé autorité de certification (CA) telle que VeriSign ou Thawte. L’autorité de certification est chargée de vérifier que le propriétaire ne prétend pas avoir une fausse identification. Après avoir appliqué une autorité de certification pour un certificat, les développeurs commerciaux peuvent s’attendre à une réponse à leur application en moins de deux semaines.

Une fois que l’autorité de certification décide que vous répondez à ses critères de stratégie, elle génère un certificat de signature de code conforme à X.509, le format de certificat standard créé par l’Union internationale des télécommunications, avec les extensions version 3. Ce certificat vous identifie et contient votre clé publique. Il est stocké par l’autorité de certification pour référence et une copie vous est donnée électroniquement. En même temps, vous créez également une clé privée, que vous devez conserver en sécurité et que vous ne devez pas partager avec n’importe qui, même l’autorité de certification.

Une fois que vous avez une clé publique et privée, vous pouvez commencer à distribuer des logiciels signés. Microsoft fournit des outils pour ce faire dans le Kit de développement logiciel (SDK) Windows. Les outils utilisent un hachage unidirectionnel, produisent une synthèse de longueur fixe et génèrent une signature chiffrée avec une clé privée. Ils combinent ensuite cette signature chiffrée avec votre certificat et vos informations d’identification dans une structure appelée bloc de signature et l’incorporent dans le format de fichier de l’exécutable. Tout type de fichier binaire exécutable peut être signé, y compris les DLL, les fichiers exécutables et les fichiers d’armoire.

La signature peut être vérifiée de plusieurs façons. Les programmes peuvent appeler la fonction CertVerifyCertificateChainPolicy et SignTool (signtool.exe) peuvent être utilisés pour vérifier une signature à partir de l’invite de ligne de commande. L’Explorateur Windows comporte également un onglet Signatures numériques dans Propriétés de fichier qui affiche chaque certificat d’un fichier binaire signé. (L’onglet Signatures numériques s’affiche uniquement dans Propriétés de fichier pour les fichiers signés.) En outre, une application peut être auto-vérifiée à l’aide de CertVerifyCertificateChainPolicy.

La signature Authenticode est non seulement utile pour l’authentification des données par les utilisateurs finaux, mais également pour la mise à jour corrective des comptes d’utilisateur limités et par les contrôles parental dans Windows Vista et Windows 7. De plus, les technologies futures dans les systèmes d’exploitation Windows peuvent également exiger que le code soit signé. Il est donc fortement recommandé que tous les développeurs professionnels et amateurs obtiennent un certificat de signature de code auprès d’une autorité de certification. Vous trouverez plus d’informations sur la façon dont cela est effectué plus loin dans cet article dans l’utilisation d’une autorité de certification approuvée.

Le code de jeu, les correctifs et les programmes d’installation peuvent tirer davantage parti de la signature Authenticode en vérifiant que les fichiers sont authentiques dans le code. Cela peut être utilisé pour la sécurité réseau générale et anti-triche. Vous trouverez un exemple de code pour vérifier si un fichier est signé ici : Exemple de programme C : vérification de la signature d’un fichier PE, et un exemple de code permettant de vérifier la propriété d’un certificat de signature sur un fichier signé se trouve ici : Comment obtenir des informations à partir d’exécutables signés Authenticode.

Mise en route

Pour commencer, Microsoft fournit des outils avec Visual Studio 2005 et Visual Studio 2008, et dans le Kit de développement logiciel (SDK) Windows, pour vous aider à effectuer et à vérifier le processus de signature de code. Après avoir installé Visual Studio ou le Kit de développement logiciel (SDK) Windows, les outils décrits dans cet article technique se trouvent dans un sous-répertoire de l’installation, qui peut inclure un ou plusieurs des éléments suivants :

  • %SystemDrive%\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin
  • %SystemDrive%\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\Bin
  • %SystemDrive%\Program Files\Microsoft Visual Studio 9.0\SmartDevices\SDK\SDKTools\
  • %SystemDrive%\Program Files\Microsoft SDKs\Windows\v6.0A\bin\

Les outils suivants sont les plus utiles pour la signature du code :

Outil de création de certificat (MakeCert.exe)

Génère un certificat X.509 de test, en tant que fichier .cer, qui contient votre clé publique et une clé privée, en tant que fichier .pvk. Ce certificat est uniquement à des fins de test interne et ne peut pas être utilisé publiquement.

pvk2pfx.exe

Crée un fichier d’échange d’informations personnelles (.pfx) à partir d’une paire de fichiers .cer et .pvk. Le fichier .pfx contient à la fois votre clé publique et privée.

SignTool (SignTool.exe)

Signe le fichier à l’aide du fichier .pfx. SignTool prend en charge la signature de fichiers DLL, de fichiers exécutables, de fichiers Windows Installer (.msi) et de fichiers d’armoire (.cab).

Remarque

Lors de la lecture d’une autre documentation, vous pouvez trouver des références à SignCode (SignCode.exe), mais cet outil est déconseillé et n’est plus pris en charge : utilisez SignTool à la place.

 

Utilisation d’une autorité de certification approuvée

Pour obtenir un certificat approuvé, vous devez vous appliquer à une autorité de certification, telle que VeriSign ou Thawte. Microsoft ne recommande aucune autorité de certification sur une autre, mais si vous souhaitez l’intégrer au service Windows Error Reporting (WER), vous devez envisager d’utiliser VeriSign pour émettre le certificat, car l’accès à la base de données WER nécessite un compte WinQual qui nécessite un ID VeriSign. Pour obtenir la liste complète des autorités de certification tierces approuvées, consultez Les membres du programme de certificat racine Microsoft. Pour plus d’informations sur l’inscription auprès de WER, consultez « Présentation du rapport d’erreurs Windows » dans la zone ISV.

Après avoir reçu votre certificat de l’autorité de certification, vous pouvez signer votre programme à l’aide de SignTool et libérer votre programme au public. Toutefois, vous devez être prudent pour protéger votre clé privée, qui est contenue dans vos fichiers .pfx et .pvk. Veillez à conserver ces fichiers dans un emplacement sécurisé.

Exemple d’utilisation d’un certificat de test

Les étapes suivantes illustrent la création d’un certificat de signature de code à des fins de test, suivie de la signature d’un exemple de programme Direct3D (appelé BasicHLSL.exe) avec ce certificat de test. Cette procédure crée des fichiers .cer et .pvk ( vos clés publiques et privées, respectivement) qui ne peuvent pas être utilisées pour la certification publique.

Dans cet exemple, un horodatage est également ajouté à la signature. Un horodatage empêche la signature de devenir non valide lorsque le certificat expire. Le code signé mais sans horodatage ne sera pas validé après l’expiration du certificat. Par conséquent, tout le code publié publiquement doit avoir un horodatage.

Pour créer un certificat et signer un programme

  1. Créez un certificat de test et une clé privée à l’aide de l’outil de création de certificat (MakeCert.exe).

    L’exemple de ligne de commande suivant spécifie MyPrivateKey comme nom de fichier pour le fichier de clé privée (.pvk), MyPublicKey comme nom de fichier pour le fichier de certificat (.cer) et MySoftwareCompany comme nom du certificat. Il rend également le certificat auto-signé, afin qu’il ne dispose pas d’une autorité racine non approuvée.

    MakeCert /n CN=MySoftwareCompany /r /h 0 /eku "1.3.6.1.5.5.7.3.3,1.3.6.1.4.1.311.10.3.13" /e 12-31-2020 /sv MyPrivateKey.pvk MyPublicKey.cer
    
  2. Créez un fichier d’échange d’informations personnelles (.pfx) à partir de votre fichier de clé privée (.pvk) et d’un fichier de certificat (.cer) à l’aide de pvk2pfx.exe.

    Le fichier .pfx combine vos clés publiques et privées dans un seul fichier. L’exemple de ligne de commande suivant utilise les fichiers .pvk et .cer de l’étape précédente pour créer le fichier .pfx nommé MyPFX avec le mot de passe your_password :

    pvk2pfx.exe -pvk MyPrivateKey.pvk -spc MyPublicKey.cer -pfx MyPFX.pfx -po your_password
    
  3. Signez votre programme avec votre fichier Personal Information Exchange (.pfx) à l’aide de SignTool.

    Vous pouvez spécifier plusieurs options sur la ligne de commande. L’exemple de ligne de commande suivant utilise le fichier .pfx de l’étape précédente, donne your_password en tant que mot de passe, spécifie BasicHLSL comme fichier à signer et récupère un horodatage à partir d’un serveur spécifié :

    signtool.exe sign /fd SHA256 /f MyPFX.pfx /p your_password /v /t URL_to_time_stamp_service BasicHLSL.exe
    

    Remarque

    L’URL du service d’horodatage est fournie par l’autorité de certification et est facultative pour les tests. Il est important que la signature de production inclue une autorité d’horodatage valide, ou que la signature ne soit pas validée à l’expiration du certificat.

     

  4. Vérifiez que le programme est signé à l’aide de SignTool.

    L’exemple de ligne de commande suivant spécifie que SignTool doit tenter de vérifier la signature sur BasicHLSL.exe à l’aide de toutes les méthodes disponibles tout en fournissant une sortie détaillée :

    signtool.exe verify /a /v BasicHLSL.exe
    

    Dans cet exemple, SignTool doit indiquer que le certificat est attaché, tout en indiquant qu’il n’est pas approuvé, car il n’est pas émis par une autorité de certification.

  5. Approuvez le certificat de test.

    Pour les certificats de test, vous devez approuver le certificat. Cette étape doit être ignorée pour les certificats fournis par une autorité de certification, car celles-ci seront approuvées par défaut.

    Sur les ordinateurs sur lesquels vous souhaitez approuver le certificat de test, exécutez les opérations suivantes :

    certmgr.msc
    

    Cliquez ensuite avec le bouton droit sur Autorités de certification racines approuvées et choisissez Toutes les tâches | Importation. Accédez ensuite au fichier .pfx que vous avez créé et suivez les étapes de l’Assistant, en plaçant le certificat dans les autorités de certification racines approuvées.

    Une fois l’Assistant terminé, vous pouvez commencer à tester avec le certificat approuvé sur cet ordinateur.

Intégration du code de connexion au système de build quotidien

Pour intégrer le code qui se connecte à un projet, vous pouvez créer un fichier de commandes ou un script pour exécuter les outils en ligne de commande. Une fois le projet généré, exécutez SignTool avec les paramètres appropriés (comme indiqué à l’étape 3 de notre exemple).

Soyez particulièrement prudent dans votre processus de génération pour vous assurer que l’accès aux fichiers .pfx et .pvk est limité à autant d’ordinateurs et d’utilisateurs que possible. En guise de bonne pratique, les développeurs ne doivent signer du code qu’à l’aide du certificat de test jusqu’à ce qu’ils soient prêts à être expédiés. Là encore, la clé privée (.pvk) doit être conservée dans un emplacement sécurisé, comme une pièce sécurisée ou verrouillée, et idéalement sur un appareil de chiffrement, comme une carte à puce.

Une autre couche de protection est fournie à l’aide de Microsoft Authenticode pour signer le package WINDOWS Installer (MSI) lui-même. Cela permet de protéger le package MSI contre la falsification et la corruption accidentelle. Reportez-vous à la documentation de votre outil de création MSI pour plus d’informations sur la façon de signer des packages avec Authenticode.

Révocation

Si la sécurité de la clé privée est compromise ou qu’un événement lié à la sécurité restitue un certificat de signature de code non valide, le développeur doit révoquer le certificat. Ce n’est pas le cas pour affaiblir l’intégrité du développeur et l’efficacité du code de signature. Une autorité de certification peut également émettre une révocation avec une heure spécifique ; le code signé avec un horodatage avant l’heure de révocation est toujours considéré comme valide, mais le code avec un horodatage ultérieur n’est pas valide. La révocation de certificats affecte le code dans toutes les applications signées avec le certificat révoqué.

Pilotes de signature de code

Les pilotes peuvent et doivent être signés Authenticode. Les pilotes en mode noyau ont des exigences supplémentaires : les éditions 64 bits de Windows Vista et Windows 7 empêchent l’installation de tous les pilotes en mode noyau non signé, et toutes les versions de Windows présentent une invite d’avertissement lorsqu’un utilisateur tente d’installer un pilote non signé. En outre, les administrateurs peuvent définir la stratégie de groupe pour empêcher l’installation des pilotes non signés sur Microsoft Windows Server 2003, Windows XP Professional x64 Edition et les éditions 32 bits de Windows Vista et Windows 7.

De nombreux types de pilotes peuvent être signés avec une signature approuvée par Microsoft, dans le cadre du Programme de certification Windows de Windows Hardware Quality Labs (WHQL) ou du programme de signature non classifiée (anciennement signature de fiabilité du pilote) qui permet au système de faire entièrement confiance à ces pilotes, et de les installer même sans informations d’identification administratives.

Au minimum, les pilotes doivent être signés Authenticode, car les pilotes non signés ou auto-signés (c’est-à-dire signés avec un certificat de test) ne peuvent pas être installés sur de nombreuses plateformes Windows. Pour plus d’informations sur la signature des pilotes et du code et de la fonctionnalité associée, consultez La configuration requise pour la signature de pilotes pour Windows sur Windows hardware Developer Central.

Résumé

L’utilisation de Microsoft Authenticode est un processus simple. Une fois que vous avez obtenu un cer et créé une clé privée, il s’agit simplement d’utiliser les outils fournis par Microsoft. Vous pouvez ensuite activer des fonctionnalités importantes dans Windows Vista et Windows 7, telles que les contrôles parental, et informer les clients que votre produit provient directement de son propriétaire approprié.

Plus d’informations

Pour plus d’informations sur les outils et les processus liés à la signature de code, consultez les liens suivants :