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

StackOverflow https://stackoverflow.com/questions/573079

  •  05-09-2019
  •  | 
  •  

Question

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

Était-ce utile?

La solution

En ce qui concerne votre question, "Comment est-il calculé", il est un hachage SHA1.

De dot blog net :

  

Microsoft résout la « clé publique   problème ballonnement » en utilisant un hachage du   clé publique de l'assemblée fortement nommé.   Ces hash sont appelés publics   jetons clés, et les faibles 8 octets   le hachage SHA1 du nom fortement   clé publique de l'assemblée. hash SHA1 sont   160 bits (20 octets) hachages, et la partie supérieure   12 octets du hachage sont tout simplement   mis au rebut dans cet algorithme.

Autres conseils

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

sn –T DLLName.dll

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;
    }

De ECMA-335:

  

Cette déclaration est utilisée pour stocker les basses 8 octets du hachage SHA-1 de l'auteur de   clé publique dans la référence de montage, plutôt que la pleine clé publique.
  Une référence d'assemblage peut stocker soit une clé publique complète ou 8 octets « jeton de clé publique. » Ou peut être utilisé pour   valider que la même clé privée utilisée pour signer l'assemblée au moment de la compilation a également signé l'ensemble utilisé à   exécution. Ni est tenu d'être présent, et alors que les deux peuvent être stockés, ce 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 veiller à ce que le   ensemble étant 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é prévu dans le même but. Tandis que le   clé publique complète est plus sûre cryptographiquement, il faut plus de stockage dans la référence. L'utilisation de la clé publique   jeton réduit l'espace nécessaire pour stocker la référence alors que seulement affaiblir le processus de validation légèrement.   justification d'extrémité]

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 de CLI permet au producteur d'un ensemble de calculer un hachage cryptographique de cet ensemble (à l'aide   la fonction de hachage SHA-1), puis de le chiffrer en utilisant l'algorithme RSA (voir la partition I) et un partenariat public / privé   paire de clés du choix du producteur. Les résultats de cette (une « signature SHA-1 / RSA numérique ») peuvent alors être stockés   dans les métadonnées (§25.3.3) avec la partie publique de la paire de clés requis par l'algorithme RSA. le   directive .publickey permet de spécifier la clé publique qui a été utilisée pour calculer la signature. Calculer   le hachage, la signature est remis à zéro, la valeur de hachage calculée, puis le résultat est stocké dans la signature.

     

Le processus de signature Strong Name (SN) utilise hachage standard et des algorithmes de chiffrement pour la signature de nom fort. Un   hachage SHA-1 sur la majeure partie du fichier PE est généré. Cette valeur de hachage est RSA-signé avec la clé privée SN. Pour   des fins de vérification de 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és:   • L'entrée de signature Authenticode: les fichiers PE peuvent être authenticode signé. le authenticode   la signature est contenue dans le décalage à l'entrée de 8 octets 128 du PE en-tête Répertoire des données   ( « Certificat de table » dans §25.2.3.3) et le contenu du fichier PE dans la plage spécifiée par cette   entrée d'annuaire. [Note: Dans un fichier PE conforme, cette entrée est égale à zéro. Note de fin]   • Le nom fort Blob: L'entrée de 8 octets de décalage à 32 de l'en-tête CLI ( « StrongNameSignature »   dans §25.3.3) et le contenu des données de hachage contenues dans ce RVA dans le fichier PE. Si le 8 octets   l'entrée est 0, il n'y a pas de signature de nom fort associé.   • Le PE-tête Checksum: L'entrée de 4 octets à l'offset 64 de l'en-tête PE Windows NT spécifique   Les champs ( « Fichier checksum » dans §25.2.3.2). [Note: Dans un fichier PE conforme, cette entrée est égale à zéro.   end note]

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

Un jeton de clé publique est utilisée pour identifier l'organisation dans un ensemble fortement nommé. Ces informations sont ajoutées à la métabase de montage. Je suppose que Richard est correct sur la façon technique, il est stocké.

Si vous voulez voir la métabase d'un ensemble, utilisez ILDASM. Vous pouvez naviguer dans ce qui est stocké dans la métabase en plus de voir l'IL.

Il est les octets de hachage de la clé utilisée pour signer l'assemblage.

Ainsi, plutôt que la liste des centaines de chiffres hexadécimaux pour la clé, vous avez quelque chose de simple, mais avec peu de risques de collisions.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top