Partager via

Créer et utiliser des assemblys avec nom fort

  • Article

Un nom fort est constitué de l'identité de l'assembly (son simple nom textuel, son numéro de version et des informations de culture, le cas échéant) ainsi que d'une clé publique et d'une signature numérique. Il est généré à partir d'un fichier d'assembly à l'aide de la clé privée correspondante. (Le fichier d'assembly contient le manifeste d'assembly, qui contient les noms et les hachages de tous les fichiers composant l'assembly.)

Avertissement

Ne comptez pas sur les noms forts pour la sécurité. Ils fournissent seulement une identité unique.

Un assembly avec nom fort peut uniquement utiliser les types d'autres assemblys avec nom fort. Si ce n'était pas le cas, l’intégrité de l’assembly avec nom fort serait compromise.

Notes

Bien que .NET Core prenne en charge les assemblys à nom fort et que tous les assemblys de la bibliothèque .NET Core soient signés, la majorité des assemblys tiers n’ont pas besoin de noms forts. Pour plus d’informations, consultez Signature de nom fort sur GitHub.

Scénario de nom fort

Le scénario suivant met en avant le processus de signature d'un assembly avec nom fort, puis son référencement par ce nom.

  1. L'assembly A est créé avec un nom fort à l'aide de l'une des méthodes suivantes :

    • En utilisant un environnement de développement qui prend en charge la création de noms forts, tel que Visual Studio.

    • En créant une paire de clés de chiffrement avec l’outil Strong Name (Sn.exe) et en l’assignant à l’assembly à l’aide d’un compilateur de ligne de commande ou de Assembly Linker (Al.exe). Le SDK Windows fournit Sn.exe et Al.exe.

  2. L'environnement de développement ou l'outil signe le hachage du fichier contenant le manifeste de l'assembly avec la clé privée du développeur. Cette signature numérique est stockée dans le fichier exécutable portable (PE) qui contient le manifeste de l'assembly A.

  3. L’assembly B est un consommateur de l’Assembly A. La section de référence du manifeste de l’assembly B inclut un jeton qui représente la clé publique de l’assembly A. Un jeton est une partie de la clé publique complète. Il est utilisé à la place de la clé pour économiser de l'espace.

  4. Le Common Language Runtime vérifie la signature de nom fort quand l'assembly est placé dans le Global Assembly Cache. Lors de la liaison par nom fort au moment de l’exécution, le common language runtime compare la clé stockée dans le manifeste de l’Assembly B avec la clé utilisée pour générer le nom fort de l’Assembly A. Si les vérifications de la sécurité .NET et la liaison réussissent, l’Assembly B a une garantie que les bits de l’Assembly A n’ont pas été falsifiés et qu’ils proviennent réellement des développeurs de l’Assembly A.

Notes

Ce scénario ne traite pas des problèmes de confiance. Outre un nom fort, les assemblys peuvent posséder des signatures Microsoft Authenticode complètes. Les signatures Authenticode incluent un certificat établissant la confiance. Il est important de noter que les noms forts ne nécessitent pas que le code soit signé de cette manière. Les noms forts fournissent seulement une identité unique.

Ignorer la vérification de signature des assemblys approuvés

À partir du .NET Framework 3.5 Service Pack 1, les signatures de nom fort ne sont pas validées quand un assembly est chargé dans un domaine d'application de confiance totale tel que le domaine de l'application par défaut pour la zone MyComputer. Cette fonctionnalité permet d’ignorer les noms forts. Dans un environnement de confiance totale, les demandes de StrongNameIdentityPermission aboutissent toujours pour les assemblys de confiance totale signés, quelle que soit leur signature. La fonctionnalité consistant à ignorer les noms forts évite les traitements inutiles liés à la vérification de signature de nom fort des assemblys de confiance totale dans cette situation, ce qui permet un chargement plus rapide des assemblys.

Cette fonctionnalité s’applique à tout assembly signé avec un nom fort qui présente les caractéristiques suivantes :

  • Confiance totale sans preuve StrongName (par exemple, dispose de la preuve de zone MyComputer).

  • Chargé dans un AppDomain de confiance totale.

  • Chargé à partir d'un emplacement sous la propriété ApplicationBase de cet AppDomain.

  • Sans signature différée.

Cette fonctionnalité peut être désactivée pour des applications individuelles ou pour un ordinateur. Consultez Guide pratique pour désactiver la fonctionnalité consistant à ignorer les noms forts.

Intitulé Description
Guide pratique pour créer une paire de clés publique/privée Décrit comment créer une paire de clés de chiffrement pour signer un assembly.
Guide pratique pour signer un assembly avec un nom fort Décrit comment créer un assembly avec nom fort.
Amélioration de l’utilisation de noms forts Décrit les améliorations apportées aux noms forts dans .NET Framework 4.5.
Guide pratique pour référencer un assembly avec un nom fort Décrit comment référencer des types ou des ressources dans un assembly avec nom fort au moment de la compilation ou de l'exécution.
Procédure : Désactiver la fonctionnalité de contournement des noms forts Décrit comment désactiver la fonctionnalité qui ignore la validation des signatures avec nom fort. Cette fonctionnalité peut être désactivée pour toutes les applications ou pour des applications spécifiques.
Créer des assemblys Fournit une vue d'ensemble des assemblys multifichiers et à fichier unique.
Guide pratique pour repousser la signature d’un assembly dans Visual Studio Explique comment signer un assembly avec un nom fort après la création de l'assembly.
sn.exe (outil Strong Name) Décrit l'outil inclus dans le .NET Framework qui facilite la création d'assemblys avec des noms forts. Cet outil fournit des options de gestion des clés, de génération des signatures et de vérification des signatures.
al.exe (Assembly Linker) Décrit l'outil inclus dans le .NET Framework qui génère un fichier possédant un manifeste d'assembly à partir de modules ou de fichiers de ressources.