Qu'est-ce qu'un jeton de clé publique et comment est-il calculé dans les noms forts d'assembly?

Question

Qu'est-ce qu'un 'jeton de clé publique' et comment est-il calculé dans les noms forts d'assembly?

Answer 1

En ce qui concerne votre question, "Comment ça se calcule", c'est un hachage SHA1.

De dot net blog:

Microsoft résout le problème « clé publique ballonnement » en utilisant un hachage de la clé publique de l'Assemblée fortement nommé. Ces hachages sont appelés clés publiques , et sont les 8 octets faibles de le hachage SHA1 de la clé publique de l'assembly fortement nommé. SHA1 hashes sont 160 bits (20 byte) hachages, et le haut 12 octets du hachage sont simplement mis au rebut dans cet algorithme.

Answer 2

Ce sont les octets de hachage de la clé utilisée pour signer l'assemblage.

Donc, plutôt que d'énumérer des centaines de chiffres hexadécimaux pour la clé, vous avez quelque chose de plus simple, mais avec toujours peu de risques de collisions.

Answer 3

Un jeton de clé publique est utilisé pour identifier l'organisation dans un assembly fortement nommé. Cette information est ajoutée à la métabase d'assembly. Je suppose que Richard a raison sur la façon dont il est stocké.

Si vous souhaitez afficher la métabase d'un assembly, utilisez ILDASM. Vous pouvez explorer ce qui est stocké dans la métabase en plus de voir l'IL.

Answer 4

De ECMA-335:

Cette déclaration est utilisée pour stocker les basses 8 octets du hachage SHA-1 de clé publique de l'expéditeur dans la référence de montage, plutôt que la pleine clé publique .
Une référence d'assembly peut stocker une clé publique complète ou un jeton de clé publique de 8 octets. permet de valider que la même clé privée utilisée pour signer l'assembly lors de la compilation a également signé l'assembly utilisé à runtime. Aucun des deux ne doit être présent, et bien que les deux puissent être stockés, cela n'est pas utile.

[Justification: La clé publique ou jeton de clé publique stockée dans une référence d'assemblage est utilisé pour faire en sorte que l'ensemble référencé et l'assemblage effectivement utilisé lors de l'exécution ont été produits par une entité en possession de la même clé privée, et peut donc être supposé avoir été conçu dans le même but. Alors que la clé publique complète est cryptographiquement plus sûre, elle nécessite plus de stockage dans la référence. L'utilisation de la clé publique réduit l'espace requis pour stocker la référence tout en affaiblissant légèrement le processus de validation. raison de la fin]

En ce qui concerne la façon dont le hachage est calculé (je suppose que cela peut être ce que vous demandez depuis le jeton de clé publique est pas « calculée »), de la même spécification:

Les métadonnées CLI permettent au producteur d'un assemblage de calculer un hachage cryptographique de cet assemblage (en utilisant la fonction de hachage SHA-1), puis de le crypter en utilisant l'algorithme RSA (voir Partition I) et une paire de clés publique/privée du choix du producteur. Les résultats de ceci (une "signature numérique SHA-1/RSA") peuvent ensuite être stockés dans les métadonnées (§25.3.3) avec la partie publique de la paire de clés requise par l'algorithme RSA. La directive .publickey est utilisée pour spécifier la clé publique qui a été utilisée pour calculer la signature. Pour calculer le hachage, la signature est remise à zéro, le hachage calculé, puis le résultat est stocké dans la signature. Le processus de signature Strong Name (SN) utilise des algorithmes de hachage et de chiffrement standard pour la signature de noms forts. Un hachage SHA-1 sur la majeure partie du fichier PE est généré. Cette valeur de hachage est signée RSA avec la clé privée SN. Pour les besoins de la vérification, la clé publique est stockée dans le fichier PE ainsi que la valeur de hachage signée. À l'exception de ce qui suit, toutes les parties du fichier PE sont hachées: • L'entrée Signature Authenticode: les fichiers PE peuvent être authentifiés. La signature authenticode est contenue dans l'entrée de 8 octets au décalage 128 du répertoire de données d'en-tête PE ("Table de certificats" au §25.2.3.3) et le contenu du fichier PE dans la plage spécifiée par cette entrée de répertoire . [Note: Dans un fichier PE conforme, cette entrée doit être zéro. note de fin] • Blob de nom fort: l'entrée de 8 octets au décalage 32 de l'en-tête CLI ("StrongNameSignature" au §25.3.3) et le contenu des données de hachage contenues dans cette RVA dans le fichier PE. Si l'entrée à 8 octets est 0, il n'y a pas de signature de nom fort associée. • La somme de contrôle d'en-tête PE: l'entrée de 4 octets à l'offset 64 de l'en-tête PE Windows Champs spécifiques ("Fichier Checksum" au § 25.2.3.2). [Note: Dans un fichier PE conforme, cette entrée doit être zéro. fin ndlr]

Vous pouvez télécharger la spécification ici gratuitement: http://www.ecma-international.org/publications/standards/Ecma-335.htm

Answer 5

Si vous avez besoin de générer un jeton de clé publique basée sur une clé publique complète, cette petite méthode statique fonctionne:

private static byte[] GetKeyTokenFromFullKey(byte[] fullKey) 
    { 
     SHA1CryptoServiceProvider csp = new SHA1CryptoServiceProvider(); 
     byte[] hash = csp.ComputeHash(fullKey); 
     byte[] token = new byte[8]; 
     for (int i = 0; i < 8; i++) 
      token[i] = hash[hash.Length - (i+1)]; 

     return token; 
    } 

Answer 6

Vous pouvez obtenir le PublicKeyToken de la ligne VS commande en tapant:

sn –T DLLName.dll