Как программно проверить, что сборка подписана определенным сертификатом?

Question

Мой сценарий - у нас есть одна программа (exe), которая запускает другие программы, если они найдены в определенной папке. Я хочу убедиться, что он запускает только те программы, которые подписаны нашим корпоративным сертификатом (одобрен Verisign и т. Д.). По сути, он будет запускать программы только с тем же сертификатом, что и сам. Я не хочу отправлять сертификат сам.

Я искал в Интернете и в пространстве имен системы и не нашел четкого примера, который считывает данные сертификата из файла, а также проверяет их и может проверять по другому файлу. Самым близким, что я нашел, является Signtool, и наличие этой проверки в отдельном exe-файле вроде бы чуть меньше. Я знаю, что Strong Naming не поможет, потому что файл с цифровой подписью отличается, как поясняется здесь (http://blog.codingoutloud.com/2010/03/13/three-ways-to-tell-whether-an-assembly-dl-is-strong-named/) Также некоторые другие примеры в SO показывают шифрование и проверку необработанных данных, но не сборку, в которой они каким-то образом упакованы вместе.

Есть идеи или предложения?

Answer 1

Вот сообщение в блоге с примерами кода о том, как проверить подписи сборки:
http://blogs.msdn.com/b/shawnfa/archive/2004/06/07/150378.aspx

Пример кода в конце показывает, как проверить, подписана ли сборка Microsoft или нет - вы можете сделать то же самое, получив токен сертификата для сертификатов вашей компании.

Обновление: пользователь @Saber отредактировал это со следующим обновлением, но это обновление было отклонено другими. Тем не менее, это очень верный совет, поэтому я публикую его / ее редактирование, так как SO не позволит мне одобрить его:

Редактировать (спасибо, OP): Если вы хотите сделать это более безопасно (то есть сделать вашу программу более защищенной от несанкционированного доступа), укажите ссылку на сборку в вашей программе, строго названную соответствующим ключом, затем используйте токен ссылочной сборки для сравнения с токеном вызывающей сборки. Если вы используете байтовые массивы (по ссылке), их можно просто отредактировать и изменить в шестнадцатеричном формате.

Answer 2

Здесь вы можете попробовать три варианта.

1) Первый использует сборочную загрузку, как здесь:

Assembly myDll =
    Assembly.Load("myDll, Version=1.0.0.1, Culture=neutral, PublicKeyToken=9b35aa32c18d4fb1");

Вы можете напечатать шестнадцатеричный формат открытого ключа и открытого ключа.токен для конкретной сборки с помощью следующей команды Strong Name (Sn.exe):

sn -Tp <assembly>

Если у вас есть файл с открытым ключом, вы можете использовать следующую команду вместо этого (обратите внимание на разницу в регистре наопция командной строки):

sn -tp <assembly>

2) Второй упоминается здесь .И используйте p / Invoke для такой проблемы.

3) Также существует третий, более гибкий и более сложный способ сделать это.Это обязательная политика 1017 *.Вы можете принять это во внимание в том случае, если вам необходимо предоставить обновления для уже развернутого приложения.Когда выйдет новая версия общего компонента, которая может принести пользу вашему приложению, файл политики приложения позволит вам предоставить эти преимущества без перекомпиляции или замены существующих установок.

Подробнее об этой функции можно узнать здесь:

http://msdn.microsoft.com/en-us/library/aa309359%28v=vs.71%29.aspx

http://ondotnet.com/pub/a/dotnet/2003/03/17/bindingpolicy.html

Answer 3

Существуют две технологии подписи для сборок .NET: strongnaming и Authenticode (authenticode используется для подписи PE и некоторых других файлов, а не только сборок .NET).Они используются для разных целей.Сертификаты используются в Authenticode только для аутентификации автора.Strongnaming вообще не аутентифицирует автора.

Помимо проверки подписи, сертификат должен быть проверен, чтобы гарантировать, что он был выдан для данного автора.Правильная проверка - это сложная процедура, включающая проверку CRL (список отзыва сертификатов) и OCSP (статус онлайн-сертификата).

Для проверки подписи Authenticode необходим компонент проверки Authenticode.Один из вариантов - использовать пакет PKIBlackbox нашего продукта SecureBlackbox.Пакет включает в себя проверку подлинности кода, а также полные механизмы проверки сертификата.

Обратите внимание: если вы не собираетесь проверять сертификат, проверять подпись вообще не имеет смысла, поскольку можно создать самозаверяющий сертификат с тем же предметом, серийным номером и т. Д. И использовать его.подписать поддельное собрание.

Answer 4

Я считаю, что есть способ использовать строгое имя для цели «Доверие».Я понимаю, что Microsoft рекомендует использовать строгое имя, чтобы гарантировать, что содержимое сборки не было изменено, и предлагает использовать «Authenticode» для доверия.

Но если приложение-загрузчик (приложение, которое загружает эти сборки / программы) поддерживает Зашифрованный список «Сборок», которые он может загрузить;Разве это не решит проблему «доверия»?

Например, загрузчик пакетов может поддерживать имя сборки с открытыми ключами и загружать сборку / программу через полное имя сборки?