Я довольно смущен тем, как работает сильная подпись для сборки .NET. Я подписал с сильным именем мою сборку .NET, вставив пароль и создав файл .pfx...
как это должно защищать мою dll? Может кто-нибудь объяснить это мне простыми словами? Я новичок с цифровой подписью, и вам нужно будет сделать БОЛЬШОЙ шаг назад, чтобы я понял это.
Я новичок с цифровой подписью, и вам нужно будет сделать БОЛЬШОЙ шаг назад, чтобы я понял это.
Хорошо, сделайте большой шаг назад и задайте еще несколько основных вопросов. Я получу живое слово для каждого слова, имеющего точный смысл.
Какова цель системы безопасности?
Чтобы защитить ресурс (куча золотых дублонов) против угрозы успешной атаки (кражи) со стороны враждебной (a вор), который стремится использовать уязвимость (разблокированное окно). (*)
Как вообще работает защита кода .NET Code Access?
Это эскиз системы безопасности .NET 1.0; он довольно сложный и более или менее заменен несколько более простой системой, но основные функции одинаковы.
Каждая сборка представляет доказательства для среды выполнения. Администратор домена, администратор компьютера, пользователь и создатель приложения могут создать политику безопасности. Политика - это утверждение о том, какие разрешения предоставляются, когда присутствует определенная часть доказательств. Когда сборка пытается выполнить потенциально опасную операцию, то есть операцию, которая может представлять угрозу для ресурса - среда выполнения требует, чтобы разрешение было предоставлено. Если доказательств недостаточно для предоставления этого разрешения, операция прекращается с исключением.
Итак, предположим, что на сборке представлены доказательства "Я только что был загружен из Интернета", и в политике говорится, что "загруженный из Интернета код получает разрешение на запуск и доступ к принтеру", и этот код затем пытается записать C:\Windows\System32. Разрешение не было предоставлено из-за недостаточных доказательств, и поэтому операция не удалась. Ресурс - содержимое системного каталога - защищен от несанкционированного доступа.
Какова цель подписания сборки с цифровым сертификатом, который я получил от VeriSign?
Агрегат, подписанный с цифровым сертификатом, представляет доказательства времени выполнения, описывающего сертификат, который использовался для подписи сборки. Администратор, пользователь или приложение могут изменить политику безопасности, чтобы заявить, что это свидетельство может предоставить конкретное разрешение.
Доказательства, представленные собранием, подписанным с цифровым сертификатом, заключаются в следующем: эта сборка была подписана кем-то, у кого был секретный ключ, связанный с этим сертификатом, и, кроме того, удостоверение владельца сертификата было проверено VeriSign.
Цифровые сертификаты позволяют пользователю вашего программного обеспечения принимать решение о доверии на основе вашей личности, проверенной доверенной третьей стороной.
Итак, как это защитит мою DLL?
Это не так. Ваша DLL - это лом, который будет использоваться, чтобы задушить окно, а не кучу золотых монет! Ваша DLL не является ресурсом, который должен быть защищен в первую очередь. Пользовательские данные - это ресурс, который необходимо защитить. Цифровые подписи существуют для облегчения существующих отношений доверия. Ваш клиент доверяет вам написать код, который делает то, что он говорит на этикетке. Подпись позволяет им знать, что код, который они запускают, действительно исходил от вас, потому что идентификатор автора кода был проверен доверенной третьей стороной.
Не сильное ли именовать то же самое?
Нет.
Сильное именование аналогично, поскольку сильная именная DLL представляет криптографически убедительные доказательства для среды выполнения, что сборка была подписана определенным частным ключом, связанным с определенным открытым ключом. Но цель сильного именования различна. Как следует из этого термина, сильное именование заключается в создании имени для сборки, которое может быть связано только с реальной сборкой. Любой может создать DLL с именем foo.dll, и если вы загрузите foo.dll в память по его слабому имени, вы получите любую DLL на машине этого имени, независимо от того, кто ее создал. Но только владелец закрытого ключа, соответствующий открытому ключу, может создать dll с сильным именем foo, Version=1.2.3.4, Culture=en, PublicKeyToken=03689116d3a4ae33.
Итак, цель сильного именования заключается не в том, чтобы упростить доверительные отношения между поставщиком программного обеспечения и пользователем. Цель сильного именования - убедиться, что разработчик, который использует вашу библиотеку, действительно использует определенную версию той библиотеки, которую вы фактически выпустили.
Я заметил, что VeriSign не был фактором сильного именования. Нет ли доверенной третьей стороны?
Это право; с сильным именем нет доверенной третьей стороны, которая проверяет, что открытый ключ, связанный с данным сильным именем, фактически связан с конкретной организацией или физическим лицом.
Этот механизм в цифровых сертификатах облегчает доверительные отношения, потому что доверенная сторонняя сторона может поручиться, что открытый ключ действительно связан с доверенной организацией. Не имея такого механизма, потребитель почему-то должен знать, что такое открытый ключ вашей организации. Как вы общаетесь с ними безопасно, зависит от вас.
Есть ли другие последствия для того, что нет надежной третьей стороны при сильном именовании?
Да. Предположим, например, что кто-то ворвался в ваш офис и крал компьютер с закрытым ключом цифрового сертификата. Этот злоумышленник теперь может производить программное обеспечение, подписанное с этим ключом. Но сертификационные органы, такие как VeriSign, публикуют "списки отзыва" известных сертификатов. Если ваши клиенты находятся в актуальном состоянии при загрузке списков аннулирования из своих сертификационных органов, то после отзыва вашего сертификата они могут обнаружить, что ваше программное обеспечение может быть от враждебной третьей стороны. У вас возникла сложная задача - получить новый сертификат, повторно подписать весь ваш код и распространить его на клиентов, но, по крайней мере, существует определенный механизм для решения этой проблемы.
Не так с сильными именами. Нет никакого централизованного центра сертификации, чтобы обратиться к списку скомпрометированных сильных имен. Если ваш сильный секретный ключ имени украден, вам не повезло. Механизм отмены не существует.
Я взглянул на мою политику безопасности по умолчанию, и он говорит, что (1) любой код на локальном компьютере полностью доверен, и (2) полностью доверен любой код на локальном компьютере, который имеет сильное имя от Microsoft. Разве это не избыточно?
Да. Таким образом, если первая политика становится более ограничительной, тогда применяется вторая политика. Представляется разумным, что администратор может захотеть снизить уровень доверия установленного программного обеспечения, не снижая уровень доверия сборок, которые должны быть полностью доверены, поскольку они поддерживают работу самой системы безопасности.
Но подождите немного, это все еще кажется излишним. Почему бы не установить политику по умолчанию: "(1) любой код на локальном компьютере доверен (2) любой код с сильным именем Microsoft полностью доверен"?
Предположим, что произошел стихийный бедствие, а закрытый ключ Microsoft взломан. Он хранится глубоко в хранилище под зданием 11, защищенном акулами лазерными лучами, но все же предположим, что это произошло. Это было бы катастрофой эпических масштабов, потому что, как я только что сказал, нет системы аннулирования. Если это произошло И политика безопасности была такой, как вы описали, то злоумышленник, у которого есть ключ, может помещать в Интернет враждебное программное обеспечение, которому тогда полностью доверяют политика безопасности по умолчанию! В соответствии с политикой безопасности, как она заявлена, требующей как сильного имени, так и локального расположения компьютера, злоумышленник, у которого есть закрытый ключ, теперь может обмануть пользователя при загрузке и установке.
Это пример "защиты в глубину". Всегда предполагайте, что всякая другая система безопасности потерпела неудачу и все еще делает все возможное, чтобы остановить атакующего.
Как наилучшая практика, вы всегда должны устанавливать сильное имя или политику цифровой подписи для включения местоположения.
Итак, сильное именование - это не защита моей DLL.
Right. Цель системы безопасности никогда не защищать вас, поставщика программного обеспечения или любого артефакта, который вы производите. Это защита ваших клиентов от злоумышленников, которые стремятся воспользоваться доверительными отношениями между вашими клиентами и вами. Сильное имя гарантирует, что код, который использует ваши библиотеки, действительно использует ваши библиотеки. Он делает это, создавая чрезвычайно удобный механизм для идентификации конкретной версии конкретной DLL.
Где я могу узнать больше?
Я написал всю короткую книгу в системе безопасности .NET 1.0, но теперь она выходит из печати и в любом случае заменяется новой упрощенной системой.
Вот еще несколько статей, которые я написал на эту тему:
http://ericlippert.com/2009/06/04/alas-smith-and-jones/
(*) Системы безопасности имеют другие цели, кроме предотвращения успешной атаки; хорошая система безопасности также предоставит неопровержимые доказательства успешной атаки, чтобы злоумышленник мог быть отслежен и подвергнут судебному преследованию после нападения. Эти функции выходят за рамки этого обсуждения.
Вкратце, одной из основных целей является защита от загрузки сборки с помощью CLR после ее изменения. Например, вы отправляете программное обеспечение с помощью DLL, кто-то может его отразить, изменить код и построить его снова, и пусть ваша программа загрузит его, думая, что это ваша dll. Чтобы защитить от этого, хеш вычисляется, когда вы создаете свою DLL и сохраняете ее. Во время выполнения, когда CLR загружает DLL, он снова вычисляет хэш и сравнивает с тем, что хранится в DLL, если DLL все еще нетронута, тогда он должен соответствовать, и CLR будет загружать его, иначе он не будет загружаться.
Это должно дать вам очень хорошее объяснение с более подробной информацией:
http://resources.infosecinstitute.com/dot-net-assemblies-and-strong-name-signature/