Я должен опубликовать открытый ключ из .snk файла?

1. Вы можете обратиться к какому-либо поставщику сертификатов сторонней организации (например, VeriSign) и приобрести у них сертификат ( Подпись кода в Verisign ).
2. Вы используете данный сертификат, который на нем есть название вашей компании, URL и т. д., чтобы подписать ваш код.
3. Я загружаю ваше приложение и смотрю список сертификатов, с которыми было подписано ваше приложение.
4. Я использую ваш сертификат, возвращаюсь к VeriSign и убедитесь, что сертификат действительно был выдан MyCompany, LLC.
5. Я просматриваю сертификаты, использованные для выдачи вашего сертификата, и проверяю, является ли VeriSign одним из них (Windows поставляется с несколькими установленными доверенными сертификатами).

Краткое описание:
Вы не только проверяете, что код не был возделан, но и подписаны сертификатом, выданным стороной, которой вы доверяете.

Я всегда понимал цель подписания сборки как проверки во время выполнения, чтобы гарантировать, что обновления кода происходят из надежного источника. По сути, они пытаются избежать такого сценария:

Я покупаю библиотеку шифрования у компании A, вскоре после этого компания B получает мои данные электронной почты и высылает мне бесплатное обновление до сборки, претендующей на то, чтобы быть серьезным исправлением ошибки безопасности. от компании A, когда он действительно внедряет скрытый метод в мой код, который отправляет все данные, которые я пытался зашифровать, на серверы компании B. Предполагая, что я Это означает, что знание открытого ключа недостаточно для того, чтобы перестроить сборку таким образом, чтобы она прошла те же самые проверки хеш-функции.

Таким образом, пользователь Z, использующий библиотеку шифрования из компании A, которая находится в своей папке bin приложений. Для этого он ссылается на DLL следующим образом:

Encryption, Version=1.0.0.0, Culture=neutral, PublicKeyToken=bcd6707151635d07"

Цель открытого ключа - предоставить нам три преимущества , с которыми я буду обращаться по одному за раз.

Во-первых, он предоставляет уникальное имя для сборки - это не дает нам дополнительной безопасности, но останавливает dll Hell в стиле C, где две разные компании могут выпустить две разные библиотеки с именем Encyption версии 1.0.0.0, и вы не сможете хранить их в одном каталоге, так как нет способа их дифференцировать.

Во-вторых, это предотвращает сценарий, который я обрисовал в своем первоначальном посте. Компания B не может создать другую версию библиотеки Encryption, которая также является версией 1.0.0.0 и имеет тот же открытый ключ (чтобы полное имя совпадало, и вы вызывали бы их код вместо компании A). Они не могут этого сделать, потому что если их открытый ключ совпадает, то закрытый ключ также должен совпадать (поскольку каждая пара уникальна). Единственный способ получить закрытый ключ для сопоставления - это поставить под угрозу безопасность компании А.

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

Итак, чтобы охватить конкретный сценарий, который я описал выше, представьте, что я Компания B, пытающаяся предоставить Пользователю Z вредоносную версию шифрования dll. , Моя первая попытка состоит в том, чтобы просто создать свою собственную dll с именем Encryption и Version 1.0.0.0 и подписать ее с моей собственной парой ключей. К сожалению, я не могу изменить ссылочный код в приложении пользователя Z, поэтому он не проходит проверку полного имени и не загружается. «Хорошо, - говорит я, закручивая усы, - я просто изменю открытый ключ моей сборки, чтобы он соответствовал ключу компании А». Как только я это сделаю, проверка имени пройдет, но проверка хеша не удастся, потому что приложение пользователя Z победило. не сможет расшифровать хеш, хранящийся в сборке (который был зашифрован с помощью закрытого ключа компании B) с помощью открытого ключа (компании A), который был предоставлен. Следовательно, единственный способ для компании B создать библиотеку, которая претендует на звание компании A, - это узнать закрытый ключ компании A. Ни одна из этих проверок безопасности не зависит от компании А, публикующей открытый ключ где-либо еще, кроме первоначального выпуска сборки.

Также обратите внимание, что все эти функции не гарантируют (и не утверждают, что гарантируют), что исходная сборка была получена от компании A, которая обрабатывается другими системами, такими как Verisign или службой Microsoft Authenticode , они гарантируют, что только после ссылки на сборку только компания A может внести изменения в этот код.

s закрытый ключ) с открытым ключом (Компанией А), который был предоставлен. Следовательно, единственный способ для компании B создать библиотеку, которая претендует на звание компании A, - это узнать закрытый ключ компании A. Ни одна из этих проверок безопасности не зависит от компании А, публикующей открытый ключ где-либо еще, кроме первоначального выпуска сборки.

Также обратите внимание, что все эти функции не гарантируют (и не утверждают, что гарантируют), что исходная сборка была получена от компании A, которая обрабатывается другими системами, такими как Verisign или службой Microsoft Authenticode , они гарантируют, что только после ссылки на сборку только компания A может внести изменения в этот код.

s закрытый ключ) с открытым ключом (Компанией А), который был предоставлен. Следовательно, единственный способ для компании B создать библиотеку, которая претендует на звание компании A, - это узнать закрытый ключ компании A. Ни одна из этих проверок безопасности не зависит от компании А, публикующей открытый ключ где-либо еще, кроме первоначального выпуска сборки.

Также обратите внимание, что все эти функции не гарантируют (и не утверждают, что гарантируют), что исходная сборка была получена от компании A, которая обрабатывается другими системами, такими как Verisign или службой Microsoft Authenticode , они гарантируют, что только после ссылки на сборку только компания A может внести изменения в этот код.

Следовательно, единственный способ для компании B создать библиотеку, которая претендует на звание компании A, - это узнать закрытый ключ компании A. Ни одна из этих проверок безопасности не зависит от компании А, публикующей открытый ключ где-либо еще, кроме первоначального выпуска сборки.

Также обратите внимание, что все эти функции не гарантируют (и не утверждают, что гарантируют), что исходная сборка была получена от компании A, которая обрабатывается другими системами, такими как Verisign или службой Microsoft Authenticode , они гарантируют, что только после ссылки на сборку только компания A может внести изменения в этот код.

Следовательно, единственный способ для компании B создать библиотеку, которая претендует на звание компании A, - это узнать закрытый ключ компании A. Ни одна из этих проверок безопасности не зависит от компании А, публикующей открытый ключ где-либо еще, кроме первоначального выпуска сборки.

Также обратите внимание, что все эти функции не гарантируют (и не утверждают, что гарантируют), что исходная сборка была получена от компании A, которая обрабатывается другими системами, такими как Verisign или службой Microsoft Authenticode , они гарантируют, что только после ссылки на сборку только компания A может внести изменения в этот код.

Также обратите внимание, что все эти функции не гарантируют (и не утверждают, что гарантируют), что исходная сборка была получена от компании A, которая обрабатывается другими системами, такими как Verisign или Microsoft Служба Authenticode , они гарантируют, что только после того, как вы ссылаетесь на сборку, только Компания А может вносить изменения в этот код.

Также обратите внимание, что все эти функции не гарантируют (и не утверждают, что гарантируют), что исходная сборка была получена от компании A, которая обрабатывается другими системами, такими как Verisign или Microsoft Служба Authenticode , они гарантируют, что только после того, как вы ссылаетесь на сборку, только Компания А может вносить изменения в этот код.