Discussion :

[AdamReith]

Bonjour à tous,

Je viens de lire avec intérêt l'article "Signature d'assembly avec .net" (http://webman.developpez.com/article...semblysigning/) car j'étudie en ce moment les moyens de protections disponibles avec .NET.

J'ai toutefois une question sur le principe même de la signature :
- j'ai crée une application bateau
- j'ai signé l'assembly de l'application (génération de clef avec sn.exe puis j'ai réglé les settings du projet dans VS2005)
- je décompile ensuite l'assembly avec ILDASM
- là je peux supprimer la portion de la clef publique (dans le fichier .IL) et même modifier le code IL
- je recompile l'application avec ILASM
- mon application fonctionne!

Du coup, je ne comprends pas bien l'intérêt de la signature, car avec ILDASM/ILASM il semble facile de contourner la signature? Quel est donc son intérêt?

J'ai surement raté quelque chose d'important (peut-être que si on retire la clef public d'une assembly, elle ne pourra plus être chargée par assemblies qui la référence? Surtout si la référence est basée sur le string name?)

Bref, je suis preneur de tout avis visant à me faire réaliser l'intérêt que représente la signature des assemblies...
Merci!

[smyley]

Celà permet aussi d'enregistrer une assembly dans le GAC, mais bon ce n'est pas vraiment dans un but de "sécurité" l'enregistrement dans le GAC ...

string name

strong name

[Sphax]

Du coup, je ne comprends pas bien l'intérêt de la signature, car avec ILDASM/ILASM il semble facile de contourner la signature? Quel est donc son intérêt?

L'intérêt, du point de vue de la sécurité, est de s'assurer que ton appli tournera bien en chargeant les assemblies avec lesquelles tu l'as développé et testé. Que personne ne pourra modifier une de ces assemblies, te la donner, et que ton appli n'y voit que du feu. C'est important car tu pourrais par exemple donner certains privilèges à du code venant, par exemple de Microsoft. A partir de là tu veux être sûr que ce code qui prétend venir de Microsoft l'est bien, que personne n'ap pu modifier une assembly et te faire croire que c'est du MS...

J'ai surement raté quelque chose d'important (peut-être que si on retire la clef public d'une assembly, elle ne pourra plus être chargée par assemblies qui la référence? Surtout si la référence est basée sur le string name?)

Exactement. Une appli, c'est à dire un exe, n'a que faire d'avoir elle-même un nom fort. Par contre si cette appli référence des dll signées alors .net, lors du chargement de ces dll va vérifier, grâce à la clée publique, que la dll qu'il trouve est bien celle que l'appli référence, à l'octet prêt ! Si ça ne colle pas, rien n'est chargé et l'appli ne démarre pas.

[AdamReith]

Merci, j'ai progressé grâce aux réponses, mais maintenant nouvelle question existentielle :

- j'ai fait une application toute bête qui utilise une assembly signée (référence par nom fort)
- si je m'amuse à bidouiller l'assembly avec ILDASM/ILASM j'ai bien une erreur dès l'utilisation de la DLL par le JITer (OK là je suis très content ça marche bien)
- mais si j'exécute la commande sn -Vr sur mon assembly je désactive le contrôle de clef pour cette assembly et là, mon appli accepte d'utiliser l'assembly trafiquée! Notez que la désactivation court toujours, même après un reboot du système.

D'où ma question, à quoi bon proposer un moyen de protection basé sur une clef privée (jalousement conservée chez le développeur du produit) si on peut facilement désactiver le contrôle de clef avec la commande sn sur un poste final?

Quelqu'un utilise-t-il ce système de "signature" dans un cadre professionnel de façon satisfaisante?

Merci pour tout conseil, idée, etc...
Cordialement,

[Sphax]

Ce sn -Vr sert pour le "delay signing" , un processus permettant de repousser la signature d'une assembly pendant la phase de dev (en général pour que la clé privée ne se retrouve pas sur tous les postes de développement) et qu'une assembly non signée puisse donc qd même être utilisée.

Effectivement c'est une faille de sécurité, mais pour que qqun puisse l'utiliser il faut que ce qqun ait déjà accès à la machine. Enfin c'est qd même un problème oui, des explications plus détaillées ici.