Partager via

Horodatage des signatures Authenticode

  • Article

Les signatures Microsoft Authenticode fournissent des garanties d’intégrité et de création pour les données binaires. L’horodatage Authenticode est basé sur des contre-signatures PKCS #7 standard. Les outils de signature de Microsoft permettent aux développeurs d’apposer des horodatages en même temps que des signatures Authenticode. L’horodatage permet de vérifier les signatures Authenticode même après l’expiration des certificats utilisés pour la signature.

Brève présentation d’Authenticode

Authenticode applique une technologie de signature numérique pour garantir la création et l’intégrité des données binaires telles que les logiciels installables. Un navigateur web client, ou d’autres composants système, peuvent utiliser les signatures Authenticode pour vérifier l’intégrité des données lorsque le logiciel est téléchargé ou installé. Les signatures Authenticode peuvent être utilisées avec de nombreux formats logiciels, notamment .cab, .exe, .ocx et .dll.

Microsoft gère une liste des autorités de certification (CA) publiques. Les émetteurs de certificats Authenticode incluent actuellement SSL.com, Digicert, Sectigo(Comodo) et GlobalSign.

À propos de l’horodatage de chiffrement

Diverses méthodes d’horodatage de chiffrement ont été proposées dans le passé. Reportez-vous, par exemple, à « How to Time-Stamp a Digital Document » de Haber et Stornetta dans Journal of Cryptology (1991) et à « One-Way Accumulators: A Decentralized Alternative to Digital Signatures » de Benaloh et De Mare dans Springer-Verlag Lecture Notes in Computer Science vol. 765 (EUROCRYPT ’93). Un résumé complet de cet article est disponible dans Microsoft Research. (Ces ressources peuvent ne pas être disponibles dans certaines langues et dans et certains pays ou régions.) Le temps étant une donnée physique plutôt que mathématique, ces méthodes concernent généralement la manière de lire des objets afin de déterminer leur ordre de création ou de regrouper efficacement des objets dont la création peut être qualifiée de simultanée.

Les systèmes qui prétendent authentifier le temps en tant que quantité nécessitent toujours une certaine forme de confiance. Dans un environnement fortement conflictuel, des protocoles complexes peuvent être utilisés pour garantir un certain degré de synchronisation. Toutefois, ces protocoles nécessitent une interaction importante entre les parties concernées. Dans la pratique, si l’on n’a besoin que d’une certification temporelle émanant d’une source fiable, celle-ci peut simplement faire office de notaire en fournissant une déclaration signée (certification) attestant que l’objet a été présenté pour signature à l’heure indiquée.

La méthode de contre-signature de l’horodatage implémentée ci-dessous permet de vérifier les signatures même après l’expiration ou la révocation du certificat de signature. L’horodatage permet au vérificateur de connaître de manière fiable l’heure à laquelle la signature a été apposée et, par conséquent, de faire confiance à la signature si elle était valide à ce moment-là. L’horodateur doit disposer d’une source de temps fiable et protégée.

Documents signés PKCS #7 et contre-signatures

PKCS #7 est un format standard pour les données de chiffrement, notamment les données signées, les certificats et les listes de révocation de certificats (CRL). Le type de PKCS #7 qui nous intéresse dans le contexte de l’horodatage est celui des données signées, correspondant au type de contenu SignedData défini par PKCS #7.

Le package PKCS #7 se compose de SignedData qui identifie le contenu réel et certaines informations le concernant, ainsi que de blocs de signature SignerInfo. Un SignerInfo peut lui-même contenir une contre-signature, qui est récursivement un autre SignerInfo. En principe, une séquence de ces contre-signatures peut être présente. La contre-signature est un attribut non authentifié par rapport à la signature figurant dans SignerInfo, c’est-à-dire qu’elle peut être apposée après la signature d’origine. Dans les grandes lignes :

SignedData (PKCS #7)

  • Version (de PKCS #7, généralement la version 1)
  • DigestAlgorithms (collection de tous les algorithmes utilisés par les blocs de signature SignerInfo, pour un traitement optimisé)
  • ContentInfo (contentType est égal à SignedData, plus le contenu ou la référence au contenu)
  • Certificats FACULTATIFS (collection de tous les certificats utilisés)
  • CRL FACULTATIVES (collection de toutes les CRL)
  • Blocs de signature SignerInfo (signature réelle, composée d’un ou de plusieurs blocs de signature SignerInfo)

SignerInfo (bloc de signature)

  • Version (de PKCS #7, généralement la version 1)
  • Certificat (émetteur et numéro de série pour identifier de manière unique le certificat du signataire dans SignedData)
  • DigestAlgorithm, plus le DigestEncryptionAlgorithm, plus le Digest (hachage), ainsi que l’EncryptedDigest (signature réelle)
  • AuthenticatedAttributes FACULTATIFS (par exemple, signés par ce signataire)
  • UnauthenticatedAttributes FACULTATIFS (par exemple, non signés par ce signataire)

Un exemple d’attribut authentifié est l’heure de signature (OID 1.2.840.113549.1.9.5), car elle fait partie des éléments signés par le service d’horodatage. Un exemple d’attribut non authentifié est la contre-signature (OID 1.2.840.113549.1.9.6), car elle peut être apposée après la signature. Dans ce cas, le SignerInfo contient lui-même un SignerInfo (contre-signature).

Remarque

L’objet signé dans la contre-signature est la signature d’origine (autrement dit, l’EncryptedDigest du SignerInfo d’origine).

 

SignTool et le processus Authenticode

SignTool est disponible pour la signature Authenticode et l’horodatage des données binaires. L’outil est installé dans le dossier \Bin du chemin d’installation du kit de développement logiciel (SDK) Microsoft Windows.

La signature et l’horodatage des données binaires sont des opérations relativement simples avec SignTool. L’éditeur doit obtenir un certificat de signature de code à partir d’une autorité de certification (CA) de signature de code commercial. Pour des raisons pratiques, Microsoft publie et met à jour une liste de CA publiques, y compris celles qui émettent des certificats Authenticode. Lorsqu’ils sont prêts à être publiés, les fichiers objet sont signés et horodatés à l’aide des paramètres de ligne de commande appropriés de l’outil SignTool. Le résultat d’une opération SignTool est toujours un SignedData au format PKCS #7.

SignTool accepte en entrée soit des données binaires brutes à signer et horodater, soit des données binaires déjà signées à horodater. Les données qui ont déjà été signées peuvent être horodatées à l’aide de la commande signtool timestamp.

Argument Description
/t HTTPAddress Indique que le fichier doit être horodaté. Une URL spécifiant l’adresse d’un serveur d’horodatage doit être fournie. /t peut être utilisé avec les commandes signature signtool et signtool timestamp.

 

Pour obtenir plus d’informations sur les outils qui peuvent être utiles dans ce contexte, consultez Outils de chiffrement et SignTool.

Détails de l’implémentation et format de transmission

SignTool s’appuie sur l’implémentation de Windows Authenticode pour créer et horodater des signatures. Authenticode fonctionne avec des fichiers binaires, par exemple .cab, .exe, .dll ou .ocx. Authenticode crée d’abord la signature, produisant un SignedData PKCS #7. Ce SignedData doit être contre-signé, comme décrit dans PKCS #9.

Le processus de contre-signature se déroule en quatre étapes :

  1. Copiez la signature (autrement dit, l’encryptedDigest) à partir du SignerInfo du SignedData PKCS #7.
  2. Créez une demande d’horodatage dont le contenu est la signature d’origine. Envoyez-la au serveur d’horodatage Abstract Syntax Notation One (ASN.1) encodé en tant que TimeStampRequest.
  3. Recevez un horodatage, mis en forme en tant que deuxième SignedData PKCS #7, renvoyé par le serveur d’horodatage.
  4. Copiez le SignerInfo à partir de l’horodatage directement dans le SignedData PKCS #7 d’origine, sous la forme d’une contre-signature PKCS #9 (autrement dit, un attribut non authentifié dans le SignerInfo de la signature originale).

Demande d’horodatage

La demande d’horodatage est envoyée dans un message POST HTTP 1.1. Dans l’en-tête HTTP, la directive CacheControl est définie sur no-cache et la directive Content-Type est définie sur application/octet-stream. Le corps du message HTTP est un encodage en base64 de l’encodage Distinguished Encoding Rules (DER) de la demande d’horodatage.

Bien qu’elle ne le soit pas actuellement, la directive Content-Length doit également être utilisée pour créer le message HTTP, car elle aide le serveur d’horodatage à localiser l’emplacement de la requête dans HTTP POST.

D’autres en-têtes HTTP peuvent également être présents et doivent être ignorés s’ils ne sont pas compris par le demandeur ou le serveur d’horodatage.

La demande d’horodatage est un message encodé ASN.1. Le format de la demande se présente comme suit.

TimeStampRequest ::= SEQUENCE {
   countersignatureType OBJECT IDENTIFIER,
   attributes Attributes OPTIONAL, 
   content  ContentInfo
}

Le countersignatureType est l’identificateur d’objet (OID) qui l’identifie comme contre-signature d’horodatage et doit être précisément l’OID 1.3.6.1.4.1.311.3.2.1.

Aucun attribut n’est actuellement inclus dans la demande d’horodatage.

Le contenu est un ContentInfo tel que défini par PKCS #7. Le contenu correspond aux données à signer. Pour l’horodatage de signature, le ContentType doit être Data et le contenu doit correspondre à l’encryptedDigest (signature) du SignerInfo du contenu PKCS #7 à horodater.

Réponse d’horodatage

La réponse d’horodatage est également envoyée dans un message HTTP 1.1. Dans l’en-tête HTTP, la directive Content-Type est également définie sur application/octet-stream. Le corps du message HTTP est un encodage en base64 de l’encodage DER de la réponse d’horodatage.

La réponse d’horodatage est un message signé PKCS #7 signé par l’horodateur. Le ContentInfo du message PKCS #7 est identique au ContentInfo reçu dans l’horodatage. Le contenu PKCS #7 contient l’attribut authentifié au moment de la signature (défini dans PKCS #99, OID 1.2.840.113549.9.5).

Une fois qu’Authenticode reçoit l’horodatage du serveur, Authenticode incorpore l’horodatage dans le SignedData PKCS #7 en tant que contre-signature. Pour ce faire, le ContentInfo du SignedData PKCS #7 renvoyé est ignoré et le SignerInfo de l’horodatage renvoyé est copié en tant que contre-signature dans le SignerInfo du SignedData PKCS #7 d’origine. La chaîne de certificats de l’horodatage est également copiée dans les certificats dans le SignedData PKCS #7 d’origine en tant qu’attribut non authentifié du signataire d’origine.