Scénario de nom fort
Mise à jour : novembre 2007
Le scénario suivant met en avant le processus de signature d'un assembly avec un nom fort, puis son référencement par ce nom.
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 2005.
En créant une paire de clés de chiffrement avec l'outil Strong Name Tool (Sn.exe) et en l'assignant à l'assembly à l'aide d'un compilateur de ligne de commande ou d'Assembly Linker (Al.exe). Le Kit de développement logiciel (SDK) Windows fournit Sn.exe et Al.exe.
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.
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é publique elle-même pour économiser de l'espace.
Le Common Language Runtime vérifie la signature de nom fort lorsque 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 contrôles de sécurité .NET Framework et la liaison réussissent, l'assembly B est assuré 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.
.gif "Remarque") Remarque : |
|---|
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. Notez que les noms forts ne requièrent pas que le code soit signé de cette manière. En fait, il n'est pas nécessaire que les clés utilisées pour générer la signature de nom fort soient les mêmes que celles utilisées pour générer une signature Authenticode. |
Ignorer la vérification de signature des assemblys approuvés
À partir du .NET Framework version 3.5 Service Pack 1, les signatures de nom fort ne sont pas validées lorsqu'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 ce AppDomain.
Sans signature différée.
Cette fonctionnalité peut être désactivée pour des applications individuelles ou pour un ordinateur. Consultez Comment : désactiver la fonctionnalité consistant à ignorer les noms forts.
Voir aussi
Référence
Outil Strong Name Tool (Sn.exe)