Les signatures numériques indiquent la provenance des programmes et vérifient qu'ils n'ont pas été endommagés. Votre logiciel de navigateur personnalisé et tout programme personnalisé doivent comporter une signature numérique pour vous assurer que les utilisateurs ne reçoivent pas d'avertissement lorsqu'ils installent leurs navigateurs personnalisés. Les utilisateurs peuvent recevoir un avertissement pour ne pas installer les contrôles ActiveX et les logiciels Java qui ne portent pas de signature. Vous devez spécifier les informations concernant votre certificat numérique lors de l'utilisation de l'Assistant IEAK.
Au moment de la création de logiciels de navigateur personnalisés pour les plates-formes Windows 95 ou Windows NT 4.0, vous devez signer les fichiers .cab personnalisés créés par IEAK avant de les publier sur les réseaux Internet ou intranet. La signature de vos fichiers .cab et de vos programmes personnalisés nécessite deux étapes : l'obtention d'un certificat numérique et la signature du code. Il n'est pas nécessaire de signer les fichiers que vous avez l'intention d'installer sur la plate-forme Windows 3.x.
Une fois votre logiciel de navigateur créé, vous devez signer les fichiers suivants :
Remarques
Les certificats numériques font partie de la technologie Authenticode, qui identifie la provenance des programmes et vérifie qu'ils n'ont pas été modifiés. Deux sources différentes peuvent fournir les certificats : une instance de certification, telle que VeriSign ou GTE, ou un serveur de certificats privé. Les certificats peuvent être commerciaux or individuels.
Certaines entreprises jouent le rôle de LRA (Local Registration Agencies). Une LRA étudie les demandes d'inscription, vérifie les documents et transmet la demande acceptée pour signature à l'instance de certification. L'instance de certification et la LRA peuvent varier sur les termes de leur arrangement, présentés dans un contrat.
L'exemple suivant décrit la relation entre l'instance de certification et la LRA. VeriSign peut être une instance de certification racine proposant des services d'instance de certification complets. Une université peut vouloir fournir des certificats à tous ses étudiants de maîtrise. Elle peut authentifier l'identité de ses étudiants et prendre en charge les formulaires nécessaires, mais ne pas vouloir s'occuper des problèmes de fiabilité. Ainsi, l'université délègue les questions de fiabilité à l'instance de certification racine et se constitue en LRA.
Après l'obtention d'un certificat, vous devez signer le code. IEAK Resource Kit fournit des outils de signature de code, tels que Code Signing Wizard (Signcode.exe). Ils se trouvent dans le dossier \Program Files\IEAK\Reskit\Tools. D'autres ressources sont disponibles dans le kit de développement de Microsoft Internet Client.
Vous devez également connaître les clés publiques et privées : elles constituent un jeu assorti de clés créées par l'éditeur de logiciels et utilisées pour le cryptage et le décryptage. Ces clés sont créées au moment de la demande de certificat par l'instance de certification. Elles sont générées sur votre ordinateur et votre clé privée n'est jamais envoyée à l'instance de certification ou à un tiers.
Vous pouvez utiliser les programmes suivants pour signer des fichiers numériquement et pour vérifier qu'ils sont signés avec succès :
Ces outils se trouvent dans le dossier \Program Files\IEAK\Reskit\Tools d'IEAK et dans le kit de développement de Microsoft Internet Client. Pour plus d'informations sur l'utilisation de ces outils, consultez Utilisation d'outils pour signer et tester du code.
Authenticode est une technologie basée sur des spécifications appliquées avec succès dans le domaine industriel depuis un certain temps, y compris PKCS #7 (norme cryptographique de syntaxe pour les messages), PKCS #10 (formats de demande de certificats), X.509 (spécification de certificat) et des algorithmes de hachage SHA et MD5.
Les instances de certification publient des stratégies et agissent en tant qu'autorité délivrant des signatures de code (certificats), basées sur des critères établis dans différentes spécifications. Les instances de certification ont également pour charge de gérer les certificats (inscription, renouvellement et révocation), de stocker les clés de base, de vérifier les documents présentés par les candidats, de fournir des outils pour l'inscription et d'approuver la fiabilité associée à la gestion de ces éléments. Les instances de certification constituent un élément essentiel de ce programme, car elles garantissent que tous les éditeurs de logiciels travaillent conformément au même ensemble de règles définies.
L'expiration des certificats apporte une mesure de sécurité supplémentaire. (Par exemple, si une université certifie tous ses étudiants avec des identifications numériques, elle peut demander que chaque identification expire lorsque l'étudiant quitte l'université.) Un code signé avec un certificat expiré n'est pas valide. Lorsque le certificat expire, l'éditeur de logiciels doit signer à nouveau son code et publier ses nouvelles versions. À l'avenir, lorsqu'une heure Internet définie sera disponible, les éditeurs de logiciels pourront signer des codes avec cette dernière pour prouver que le certificat était en vigueur au moment de la signature du code. Dès lors, le code signé sera valide, même après l'expiration du certificat.
Internet Explorer propose plusieurs niveaux de sécurité en divisant Internet en zones. Les zones de sécurité permettent aux utilisateurs d'éviter des documents à risque sur Internet.
Les utilisateurs peuvent savoir dans quelle zone la page Web active se trouve en consultant le côté droit de la barre d'état d'Internet Explorer. Lorsque vous essayez d'ouvrir ou de télécharger un document Web, Internet Explorer vérifie les paramètres de sécurité de cette zone du site Web.
L'affectation du contenu aux différentes zones se fait de plusieurs manières. Si les opérations relatives à chaque niveau de sécurité sont définies, les utilisateurs peuvent en revanche créer des paramètres personnalisés pour chaque niveau.
Si vous êtes administrateur de corporation, vous pouvez préconfigurer les zones de sécurité, prédéfinir les contrôles d'accès et personnaliser les instances de certification. Vous pouvez également contrôler si les utilisateurs peuvent modifier leurs paramètres de sécurité par l'intermédiaire du règlement et des restrictions du système. Pour plus d'informations sur les paramètres spécifiques, consultez Options de sécurité d'Internet Explorer.
Vous pouvez vous assurer que les utilisateurs finals reçoivent des avertissements lorsqu'ils essaient de visualiser un contenu potentiellement à risque. Vous pouvez également empêcher les utilisateurs de télécharger les contrôles ActiveX et les logiciels Java ne comportant pas de signature.
Le processus de signature de code est simple et rapide. Il n'est pas nécessaire de connaître les détails du fonctionnement de ce processus pour pouvoir signer un code.
Après avoir développé et testé un code, l'éditeur de logiciels le signe. Le code est exécuté par l'intermédiaire d'une fonction de hachage unilatérale, générant une « assimilation » de longueur définie. Cette dernière est alors cryptée à l'aide de la clé privée de l'éditeur de logiciels et combinée dans un bloc de signature comportant le nom de l'algorithme de hachage et le certificat (composé du nom de l'éditeur, de la clé publique, du nom du certificat de l'instance de certification, etc.). Ce bloc de signature est ensuite réinséré dans le format de fichier portable-exécutable dans une section réservée et le code est diffusé sur Internet. Si vous signez un fichier .cab, le bloc de signature est également stocké dans ce fichier.
Lorsque l'utilisateur télécharge le code, l'application de téléchargement appelle les API WinVerifyTrust. Le système extrait la signature, détermine l'instance de certification qui a authentifié le certificat et obtient la clé publique de l'éditeur de logiciels distribuée par cette instance de certification. Le système utilise alors la clé publique pour décrypter l'assimilation. Il applique à nouveau l'algorithme de hachage au code, créant ainsi une nouvelle assimilation. Si le code n'a pas été modifié depuis sa signature, la nouvelle assimilation doit correspondre à l'ancienne. Si les deux assimilations ne correspondent pas, cela signifie que le code a été modifié ou que les clés publique et privée ne constituent pas une paire assortie. Dans les deux cas, le code n'est plus fiable et l'utilisateur en est averti.