Какова роль токена открытого ключа? Имеет ли он какую-либо роль в расшифровке подписанного хэша. В GAC, почему так много сборок от Microsoft с тем же открытым ключом?
Какова роль открытого ключа?
Ответ 1
Какова роль токена открытого ключа?
токен открытого ключа - это небольшое число, которое является удобным "токеном", представляющим открытый ключ. Открытые ключи довольно длинные; цель токена открытого ключа - позволить вам обращаться к клавишам, не указывая весь ключ. Подобным же образом говорят, что "Властелин колец" - это пять слов, которые представляют собой роман на полмиллиона слов. Было бы неудобно, если бы каждый раз, когда вы хотели поговорить об этом, вы должны были указать эти полмиллиона слов.
Есть ли у него какая-либо часть в расшифровке подписанного хэша?
Нет. В токенах открытого ключа нет "информации". Это просто число, представляющее открытый ключ. Он не является публичным ключом.
почему существует так много сборок от Microsoft с тем же открытым токеном открытого ключа?
Поскольку все они были подписаны с одним и тем же закрытым ключом - закрытым ключом Microsoft - и поэтому все проверяются с помощью одного и того же открытого ключа, и поэтому все они имеют один и тот же токен открытого ключа.
Ответ 2
От Wikipedia
"Маркер открытого ключа используется, чтобы сделать уникальным имя сборки. Таким образом, две сильные именованные сборки могут иметь одно имя PE файла, и все же .NET распознает их как разные сборки. Файловая система Windows (FAT32 и NTFS) только распознает имя файла PE, поэтому две сборки с тем же именем PE файла (но с другой культурой, версией или токеном открытого ключа) не могут существовать в той же папке Windows. Чтобы решить эту проблему,.NET представляет что-то, называемое GAC (глобальный кэш сборок)), который рассматривается как одна папка .NET CLR, но фактически реализуется с использованием вложенных папок NTFS (или FAT32).
Чтобы предотвратить атаки спуфинга, где взломщик попытается передать сборку, появившуюся как что-то еще, сборка будет подписана с помощью закрытого ключа. Разработчик предполагаемой сборки сохраняет секретный ключ в секрете, поэтому взломщик не может иметь к нему доступа или просто угадать его. Таким образом, взломщик не может заставить свою сборку выдавать себя за другое, не имея возможности правильно подписать его после изменения. Подписание сборки подразумевает принятие хэша важных частей сборки, а затем шифрование хэша с помощью закрытого ключа. Подписанный хэш сохраняется в сборке вместе с открытым ключом. Открытый ключ расшифровывает подписанный хэш.. Когда среда CLR загружает узкую именованную сборку, она генерирует хэш из сборки, а затем сравнивает ее с дешифрованным хэшем. Если сравнение выполняется успешно, это означает, что открытый ключ в файле (и, следовательно, токен открытого ключа) связан с закрытым ключом, используемым для подписи сборки. Это будет означать, что открытый ключ в сборке является открытым ключом издателя сборки, и, следовательно, атака спуфинга прерывается. "
Ответ 3
Хэш - это своего рода "отпечаток пальца". Он подписан с использованием закрытого ключа, принадлежащего (и только известного) подписывающим лицом. Если вы знаете открытый ключ подписывающего лица, вы можете проверить, действительно ли хэш действительно от подписывающего лица, и, следовательно, если данные/файл действительно происходят от подписывающего лица (и не изменяется). Такие же открытые ключи для некоторых файлов в GAC означают "все, подписанные одним и тем же подписывающим лицом".
Ответ 4
токен открытого ключа - это читаемый фрагмент реального открытого ключа. Полный открытый ключ хранится внутри подписанной сборки и используется для расшифровки подписи (= зашифрованный хеш). Погрузчик использует это для проверки того, что содержимое не подделано (или повреждено). Оригинальный хэш был зашифрован автором с использованием закрытого ключа, и только кто-то, владеющий этим ключом, может создать действительную подпись.
Каждая компания (или отдел) должна использовать только одну пару ключей, поэтому вы видите группы идентичных PKT в GAC.
Ответ 5
Я хотел бы добавить к предыдущим ответам (особенно к цитированию из Википедии), что сильное именование с помощью открытого/закрытого ключа не защищает вас от получения измененной сборки или не позволяет кому-либо вмешаться в ваши сборки,
Прежде всего, сильное имя не гарантирует, что сборке можно доверять. У вас есть только токен открытого ключа/открытого ключа, но вы не знаете того, кто его подписал (за исключением случаев, когда они каким-то образом объявляют, что у них есть открытый ключ сборки).
Например, хакер может принять вашу сборку, удалить из нее сильное имя (есть инструменты, которые это делают) и подписать ее с собственным сильным именем. Для доверия существует другой вид подписания цифрового кода с сертификатом. Он включает стороннюю проверку вас и вашей компании и не является бесплатным. Проверьте технологию Authenticode:
https://msdn.microsoft.com/en-us/library/ms537359(v=vs.85).aspx
Во-вторых,. В следующем обсуждении кратко описывается метод грубой силы, чтобы получить пару открытого/закрытого ключа с тем же открытым токеном открытого ключа, который создавал бы тот же хеш для подделанной сборки:
https://groups.google.com/forum/?hl=en#!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://blogs.msdn.microsoft.com/shawnfa/2008/05/14/strong-name-bypass/
Обсуждение этого вопроса о переполнении стека: Являются ли подписанные сборки .net когда-либо полностью проверенными при загрузке, чтобы проверить, что они не были изменены?
Как я понимаю, это означает, что сборка не хэшируется во время загрузки, чтобы проверить, не ли она
Наконец,, я хотел бы упомянуть, что есть дискуссия о плюсах и минусах сильного наименования, поскольку они требуют, чтобы вы указали версию сборки. Microsoft удаляет сильное имя из некоторых своих продуктов: https://www.pedrolamas.com/2016/03/01/still-strong-naming-your-assemblies-you-do-know-its-2016-right/
В заключение я хотел обобщить все упомянутые моменты. Когда я столкнулся с сильным наименованием, я ошибался в MSDN и Wikipedia, что он мог бы обеспечить некоторую защиту для сборок. Я подумал: "Круто", и сильное имя осталось в моей памяти как механизм защиты. До этого момента мне приходилось думать о безопасности моего файла snk с помощью закрытого ключа, а затем мой коллега сказал мне, что это не так "круто". Поэтому я сделал небольшое исследование. Первое, что я узнал, это то, что сильное имя не означает доверие, вы должны использовать сертификат для него. Тем не менее, я думал, что если я сохраню свой секретный ключ в безопасности, то подделанная сборка не будет подписана мной, а это означает, что если кто-то изменит мою сборку, тогда он также должен будет изменить знак, и модифицированная сборка не будет загружена CLR. Теперь я не думаю, что сильное именование гарантирует это. Поэтому вы должны полагаться только на то, чтобы гарантировать уникальность сборки.
PS. Извините за длинный пост с большим количеством ссылок.