Чтобы подписать сборку A, вы должны убедиться, что все сборки B, C, D, которые используются A, подписаны, а затем все сборки, которые используются B, C, D и так далее. Я не понимаю, в чем преимущество этого для безопасности. Я думаю, что это должно предотвратить подделку, но сборке A разрешено открывать любой файл, и они могут быть подделаны. То же самое и с внешним веб-сервером.
Кроме того, слишком легко подписать сборку с помощью файла .snk, который вы публикуете, в обход требования.
Дело в том, что иначе вы могли бы заменить сборку B / C / D на другую (взломанную), и A никогда бы не заметил; он загрузит их и выполнит код. С сильным именованием вы не можете сделать это без повторной подписи взломанного B / C / D тем же ключом или взлома A.
Еще одна причина строгого именования - это управление версиями. Если вы ссылаетесь на сборку со строгим именем, вы получаете эту конкретную версию - и она загружает свои зависимости в конкретных версиях, на которые она полагается.
ИЗМЕНИТЬ
Пример сценария: если вы помещаете сборку в GAC, она должна иметь строгое имя, чтобы обеспечить параллельное управление версиями. Однако вы не могли бы поместить его в GAC, если бы его зависимости не были там (иначе они не загрузились бы во время выполнения). Чтобы эти сборки загружались надежно, они также должны иметь строгие имена и в GAC.
Это потому, что сборка со строгим именем подразумевает, что ей можно доверять, а уровни предоставленной безопасности основаны на идее, что код взят из законного источника. Это означает, что все другие элементы, с которыми он взаимодействует, также должны быть доверенными, поскольку он выполняется в том же контексте безопасности.
Если бы объекты со строгими именами не работали таким образом, метод атаки заключался бы в замене элементов, которые не подписаны, мошенническим кодом, который злоумышленник хочет выполнить. Мошеннический код будет выполняться в надежном контексте безопасности подписанного элемента.
