Я хотів би додати до попередніх відповідей (особливо до тієї, що містить цитату з Вікіпедії), що сильне присвоєння імен за допомогою відкритого / приватного ключа не захищає вас від отримання зміненої збірки або заважає комусь втручатися у ваші збірки.
Перш за все , сильна назва не гарантує, що складання можна довіряти. У вас просто є відкритий ключ / маркер відкритого ключа, але ви не знаєте особу, яка його підписала (крім випадків, коли вони якимось чином оголосять, що їм належить відкритий ключ асамблей).
Наприклад, хакер може взяти вашу збірку, видалити з неї надійне ім'я (є інструменти, які це роблять) і підписати його своїм власним надійним ім'ям. Для тресту існує інший вид підписання цифрового коду сертифікатом. Він передбачає перевірку третьою стороною вас і вашої компанії і не є безкоштовним. Перевірте технологію Authenticode:
https://msdn.microsoft.com/en-us/library/ms537359(v=vs.85).aspx
По-друге , у наступному обговоренні коротко описано метод атаки грубої сили для отримання пари відкритого / приватного ключів з тим самим маркером відкритого ключа, який створив би той самий хеш для фальсифікованого складання:
https://groups.google.com/forum/?hl=uk#!topic/microsoft.public.dotnet.security/Jo6PqypxJN8
Я повинен зазначити, що це могло бути вирішено за допомогою посиленого сильного іменування
https://docs.microsoft.com/en-us/dotnet/framework/app-domains/enhanced-strong-naming
Також під час обговорення була згадана помилка, яка дозволила пропустити перевірку збірки та завантажити підроблену збірку під час виконання. Детальне дослідження тут, помилка виправлена в пізніших версіях .Net framework (тому помилка присутня для старого .Net 1):
http://www.grimes.nildram.co.uk/workshops/fusionWSCrackThree.htm
По-третє , запуск .Net 3.5 sp1 для збільшення продуктивності навантаження збірок не перевіряється за замовчуванням для повноцінних збірок.
https://docs.microsoft.com/en-us/dotnet/framework/app-domains/how-to-disable-the-strong-name-bypass-feature
Умова збірки:
https://blogs.msdn.microsoft.com/shawnfa/2008/05/14/strong-name-bypass/
Дискусія про це на Stack Overflow:
Чи підписані .net-збірки коли-небудь повністю перевіряються при завантаженні, щоб перевірити, що вони не були змінені?
Як я розумію, це означає, що збірка не хешується під час навантаження, щоб перевірити її
Нарешті , я хотів би відзначити, що ведуться суперечки щодо плюсів і мінусів сильних імен, оскільки для них потрібно вказати версію збірки. Корпорація Майкрософт видаляє сильну назву з деяких їх продуктів:
https://www.pedrolamas.com/2016/03/01/still-strong-naming-your-assemblies-you-do-know-its-2016-right/
На закінчення, Я хотів узагальнити всі згадані пункти. Коли я зіткнувся з сильним іменованням, то MSDN та Вікіпедія мене ошукали, що це могло забезпечити якийсь захист для зборів. Я подумав, що "Круто" і сильне іменування залишилося в моїй пам'яті як механізм захисту. До того моменту, коли мені довелося думати про безпеку мого файлу snk із закритим ключем, а потім мій колега сказав мені, що це не так "Класно". Тож я зробив невелике дослідження. Перше, про що я дізнався, це те, що сильне ім’я не означає довіру, для цього слід використовувати сертифікат. Тим не менш, я думав, що якщо я зберігатиму свій приватний ключ у безпеці, тоді фальсифікована збірка не буде підписана мною, тобто, якщо хтось буде модифікувати мою збірку, то йому доведеться також змінити знак, і змінена збірка не буде завантажена CLR. Зараз я не Я не думаю, що сильне найменування це гарантує. Тож слід покладатися на нього лише для того, щоб гарантувати унікальність збірки.
PS. Вибачте за довгий пост з великою кількістю посилань.