Meilleures pratiques pour signer des assemblys .NET ?

Question

J'ai une solution composée de cinq projets, chacun étant compilé dans des assemblys séparés.En ce moment, je les signe en code, mais je suis presque sûr de me tromper.Quelle est la meilleure pratique ici ?

• Signez chacun avec une clé différente ;assurez-vous que les mots de passe sont différents
• Signez chacun avec une clé différente ;utilise le même mot de passe si tu veux
• Signez chacun avec la même clé
• Tout autre chose

Fondamentalement, je ne suis pas sûr de ce que la « signature » leur fait, ni quelles sont les meilleures pratiques ici, donc une discussion plus générale serait bonne.Tout ce que je sais vraiment c'est que FxCop m'a crié dessus, et c'était facile à résoudre en cochant la case "Signer cet assembly" et en générant un fichier .pfx à l'aide de Visual Studio (2008).

Answer 1

Si votre seul objectif est d'empêcher FxCop de vous crier dessus, alors vous avez trouvé la meilleure pratique.

La meilleure pratique pour signer vos assemblys dépend entièrement de vos objectifs et de vos besoins.Nous aurions besoin de plus d’informations telles que votre déploiement prévu :

• Pour usage personnel
• À utiliser sur les PC du réseau d'entreprise en tant qu'application client
• Exécuté sur un serveur Web
• Exécution dans SQL Server
• Téléchargé sur Internet
• Vendu sur CD sous film rétractable
• Téléchargé directement dans un cerveau cybernétique
• Etc.

Généralement, vous utilisez la signature de code pour vérifier que les assemblys proviennent d’une source fiable spécifique et n’ont pas été modifiés. Donc chacun avec la même clé, c'est bien. Maintenant, la manière dont cette confiance et cette identité sont déterminées est une autre histoire.

MISE À JOUR: Les avantages que cela apporte à vos utilisateurs finaux lorsque vous effectuez un déploiement sur le Web sont les suivants : si vous avez obtenu un certificat de signature de logiciel d'une autorité de certification.Ensuite, lorsqu'ils téléchargent vos assemblys, ils peuvent vérifier qu'ils proviennent Le magasin de logiciels de Domenic, et ils n'ont pas été modifiés ou corrompus en cours de route.Vous souhaiterez également signer le programme d’installation lors de son téléchargement.Cela évite l'avertissement que certains navigateurs affichent indiquant qu'il a été obtenu à partir d'une source inconnue.

Notez que vous paierez pour un certificat de signature de logiciel.Ce que vous obtenez, c'est que l'autorité de certification devient le tiers de confiance qui vérifie que vous êtes bien celui que vous prétendez être.Cela fonctionne grâce à un réseau de confiance qui remonte à un certificat racine installé dans leur système d'exploitation.Vous avez le choix entre plusieurs autorités de certification, mais vous devez vous assurer qu'elles sont prises en charge par les certificats racine du système d'exploitation cible.

Answer 2

La différence la plus évidente entre les assemblys signés et non signés réside dans une application ClickOnce.Si vous ne le signez pas, les utilisateurs recevront une boîte de dialogue d'avertissement effrayante "Éditeur inconnu" la première fois qu'ils exécuteront votre application.Si vous l'avez signé avec un certificat d'une autorité de confiance, puis ils voient un dialogue moins effrayant.Pour autant que je sache, signer avec un certificat que vous générez vous-même n'affecte pas l'avertissement « Éditeur inconnu ». SSL instantané de Comodo a des exemples de dialogues.

Il existe des différences plus subtiles.Vous devez signer un assembly avant de pouvoir l'installer dans le Global Assembly Cache (GAC), où il peut être partagé par plusieurs applications.La signature fait partie intégrante de la sécurité d'accès au code (CAS), mais je n'ai trouvé personne capable de faire fonctionner CAS.Je suis presque sûr que le GAC et le CAS fonctionnent correctement avec les certificats que vous générez vous-même.

Answer 3

Cela aide car l'exécutable attend un assembly fortement nommé.Cela empêche quiconque se substitue de manière malveillante à l’une des vôtres dans une autre assemblée.L'utilisateur peut également accorder à un assembly des autorisations CAS en fonction du nom fort.

Je ne pense pas que vous devriez distribuer le fichier .pfx, vous le gardez en sécurité pour démissionner de l'assemblée.

Answer 4

Il est important de garder votre fichier PFX secret car il contient la clé privée.

Si cette clé est mise à la disposition d'autres personnes, n'importe qui peut signer des assemblys ou des programmes qui se font passer pour vous.

Pour associer votre nom à vos assemblys (aux yeux de Windows), vous devrez obtenir un certificat numérique (la partie du fichier PFX contenant votre nom) signé par une autorité de confiance.

En fait, vous recevrez un nouveau certificat, mais avec les mêmes informations.

Vous devrez payer pour ce certificat (probablement annuellement), mais le autorité de certification se portera effectivement garant de votre existence (après leur avoir faxé des copies de votre passeport ou permis de conduire et une facture nationale).

Answer 5

La signature est utilisée pour identifier de manière unique un assembly.Plus de détails sont dans Comment:Signer un assemblage (Visual Studio).

En termes de bonnes pratiques, il est possible d'utiliser la même clé tant que les assemblys portent des noms différents.