Quel est le rôle du jeton de clé publique?

Quel est le rôle du jeton de clé publique? A-t-il un rôle à jouer dans le déchiffrement du hachage signé? Dans GAC, pourquoi y a-t-il autant d’assemblages de Microsoft avec le même jeton de clé publique?

Quel est le rôle du jeton de clé publique?

Le jeton de clé publique est un petit nombre qui est un “jeton” pratique représentant une clé publique. Les clés publiques sont assez longues le but de la clé publique est de vous permettre de vous référer aux clés sans indiquer la clé entière. De la même manière, dire “Le Seigneur des Anneaux” est cinq mots qui représentent un roman d’un demi-million de mots. Ce serait un peu gênant si chaque fois que vous vouliez en parler, vous deviez énoncer ces demi-million de mots.

A-t-il un rôle à jouer dans le décryptage du hachage signé?

Non. Le jeton de clé publique ne contient aucune “information”. C’est juste un nombre qui représente une clé publique. Ce n’est pas en soi une clé publique.

Pourquoi y a-t-il autant d’assemblages de Microsoft avec le même jeton de clé publique?

Parce qu’ils ont tous été signés avec la même clé privée – la clé privée de Microsoft – et sont donc tous vérifiés avec la même clé publique, et ont donc tous le même jeton de clé publique.

De Wikipedia

“Le jeton de clé publique est utilisé pour rendre le nom de l’assembly unique. Ainsi, deux assemblys nommés forts peuvent avoir le même nom de fichier PE et pourtant .NET les reconnaîtra comme des assemblys différents. Le système de fichiers Windows (FAT32 et NTFS) ne reconnaît que Le nom de fichier PE, donc deux assemblys avec le même nom de fichier PE (mais une culture, une version ou un jeton de clé publique différents) ne peuvent pas exister dans le même dossier Windows. Pour résoudre ce problème, .NET introduit quelque chose appelé GAC (Global Assembly Cache) traité comme un seul dossier par le CLR .NET, mais est réellement implémenté en utilisant des dossiers NTFS (ou FAT32) nesteds.

Pour éviter les attaques par usurpation d’identité, où un pirate tenterait de faire passer un assemblage apparaissant comme quelque chose d’autre, l’assembly est signé avec une clé privée. Le développeur de l’assemblage prévu conserve le secret de la clé privée, de sorte qu’un pirate ne peut y accéder ni simplement le deviner. Ainsi, le pirate ne peut pas faire passer son assemblée pour autre chose, sans la possibilité de la signer correctement après le changement. Signer l’assemblage implique de prendre un hachage de parties importantes de l’assemblage, puis de chiffrer le hachage avec la clé privée. Le hachage signé est stocké dans l’assembly avec la clé publique. La clé publique décryptera le hachage signé. Lorsque le CLR charge un assembly fortement nommé, il génère un hachage à partir de l’assembly, puis le compare au hachage déchiffré. Si la comparaison réussit, cela signifie que la clé publique du fichier (et donc le jeton de clé publique) est associée à la clé privée utilisée pour signer l’assembly. Cela signifie que la clé publique de l’assembly est la clé publique de l’éditeur d’assembly et qu’une attaque par usurpation d’identité est donc entravée. ”

Le hash est une sorte d’empreinte digitale. Il est signé en utilisant une clé privée (et uniquement connue) par le signataire. Si vous connaissez la clé publique du signataire, vous pouvez vérifier si le hachage provient réellement du signataire et donc si les données / fichiers proviennent réellement du signataire (et sont inchangés). Les mêmes clés publiques pour certains fichiers du GAC signifient “toutes signées par le même signataire”.

Le jeton de clé publique est un extrait assez lisible de la clé publique réelle. La clé publique complète est stockée dans un assembly signé et est utilisée pour décrypter la signature (= cryptage crypté). Le chargeur l’utilise pour vérifier que le contenu n’est pas falsifié (ou endommagé). Le hachage d’origine a été chiffré par l’auteur à l’aide d’une clé privée et seule une personne en possession de cette clé peut produire une signature valide.

Chaque entreprise (ou service) ne doit utiliser qu’une seule paire de clés, c’est pourquoi vous voyez des groupes de PKT identiques dans le GAC.

Je voudrais append aux réponses précédentes (en particulier à celle avec la citation de Wikipedia) que la dénomination forte via une clé publique / privée ne vous protège pas contre un assemblage modifié ou empêche quelqu’un de manipuler vos assemblys.

Tout d’abord , le nom fort ne garantit pas la fiabilité de l’assemblage. Vous avez juste un jeton clé publique / clé publique, mais vous ne connaissez pas la personne qui l’a signé (sauf s’il annonce en quelque sorte qu’il possède la clé publique des assemblys).

Par exemple, le pirate informatique peut prendre votre assemblage, en retirer un nom fort (il existe des outils pour le faire) et le signer avec son propre nom. Pour la confiance, il existe un autre type de signature de code numérique avec le certificate. Cela implique que des tiers vérifient vous et votre entreprise et qu’ils ne soient pas gratuits. Découvrez la technologie Authenticode:

https://msdn.microsoft.com/en-us/library/ms537359(v=vs.85).aspx

Deuxièmement , dans la discussion qui suit, nous décrivons brièvement une méthode d’attaque par force brute pour obtenir une paire de clés publique / privée avec le même jeton de clé publique qui produirait le même hachage pour un assemblage falsifié:

https://groups.google.com/forum/?hl=fr#!topic/microsoft.public.dotnet.security/Jo6PqypxJN8

Je dois noter que cela pourrait avoir été résolu par le nom fort renforcé https://docs.microsoft.com/en-us/dotnet/framework/app-domains/enhanced-strong-naming

Il y avait également un bogue mentionné dans la discussion qui permettait d’ignorer la validation de l’assemblage et de charger un assemblage falsifié au moment de l’exécution. La recherche détaillée est ici, le bogue a été corrigé dans les versions ultérieures de .Net Framework (donc le bogue présent pour l’ancien .Net 1):

http://www.grimes.nildram.co.uk/workshops/fusionWSCrackThree.htm

Troisièmement , le démarrage de .Net 3.5 sp1 pour augmenter les performances de la charge des assemblys n’est pas validé par défaut pour les assemblys de confiance totale.

https://docs.microsoft.com/en-us/dotnet/framework/app-domains/how-to-disable-the-strong-name-bypass-feature

La condition pour les assemblages: https://blogs.msdn.microsoft.com/shawnfa/2008/05/14/strong-name-bypass/

La discussion à ce sujet sur le débordement de la stack: les assemblys

Si je comprends bien, cela signifie que l’assemblage n’est pas haché pendant le chargement pour vérifier si

Enfin , je voudrais mentionner qu’il existe un débat sur les avantages et les inconvénients des noms forts, car ils exigent que vous spécifiiez une version d’assemblage. Microsoft supprime le nom fort de certains de ses produits: https://www.pedrolamas.com/2016/03/01/still-strong-naming-your-assemblies-you-do-know-its-2016-right/

En conclusion , je voulais résumer tous les points mentionnés. Lorsque j’ai rencontré de nombreuses personnes, le MSDN et Wikipedia m’ont laissé croire que cela pourrait constituer une sorte de défense pour les assemblées. Je pensais que “Cool” et le nom fort est resté dans ma mémoire en tant que mécanisme de protection. Jusqu’au moment où je devais réfléchir à la sécurité de mon fichier snk avec une clé privée et mon collègue m’a dit que ce n’était pas si “cool”. J’ai donc fait un peu de recherche. La première chose que j’ai apprise, c’est qu’un nom fort ne signifie pas confiance, vous devez utiliser le certificate pour cela. Pourtant, je pensais que si je gardais ma clé privée en sécurité, l’assemblage falsifié ne serait pas signé par moi, ce qui signifie que si quelqu’un modifiait mon assemblage, il devait également modifier le signe et l’assemblage modifié ne serait pas chargé par le CLR. Maintenant, je ne pense pas que ce nom solide le garantisse. Vous ne devez donc compter que sur lui pour garantir l’unicité de l’assemblage.

PS Désolé pour le long post avec beaucoup de références.