Сильные имена и совместное использование сборок. Построение ключей. Сертификация сборки.
Сильные имена, как и GUID, должны быть уникальными в пространстве и времени. В отличие от GUID, которые теоретически могут быть похищены, сильные имена защищены от несанкционированного использования при помощи механизма шифрования с открытым ключом [При условии надежного хранения закрытого ключа.]. Конкретные схемы шифрования бывают очень сложными, однако в целом шифрование с открытым ключом построено на довольно простой идее – в некоторых ситуациях вернуться от конечного результата к исходным данным бывает очень, очень сложно. Например, вы можете легко перемножить два целых числа и получить результат, но узнать исходные множители по произведению невозможно – для этого нужно знать хотя бы один из них [Этот принцип заложен в основу RSA, распространенного алгоритма шифрования с открытым ключом.].
Примечание
Внутренняя реализация выглядит следующим образом: на основании всей информа-ции, содержащейся в сборке, .NET вычисляет хэш-код и применяет к нему закрытый ключ. Результатом является зашифрованный хэш-код. Поскольку схема шифрования должна обеспечивать возможность восстановления зашифрованных данных, зашифрованный хэш-код расшифровывается при помощи открытого ключа, при этом получается исходный хэш-код. На последнем шаге хэш-код заново вычисляется на основании данных, содержащихся в манифесте, и два числа сравниваются. Если хэш-коды не совпадают, значит, сборка была модифицирована, и .NET отказывается загружать ее.
Во всех схемах с открытым ключом используется пара ключей: открытый и закрытый. Открытый ключ (public key) может свободно распространяться, поскольку без знания закрытого ключа зашифрованное сообщение невозможно восстановить за сколько-нибудь приемлемый промежуток времени. Применение закрытого ключа к данным манифеста позволяет сертифицировать их. Другие пользователи при помощи открытого ключа убеждаются в том, что сборка поступила именно от вас, а не из постороннего источника. А в некоторых случаях (например, при использовании Verisign) они даже могут убедиться в том, что открытый ключ принадлежит именно вам, а не кому-то другому (шифрование с открытым ключом защищает целостность данных, но для проверки открытого ключа необходимы услуги третьей стороны).
Построение ключей
При программировании в .NET ключи (открытый и закрытый) обычно создаются утилитой sn.exe, входящей в .NET SDK (сокращение "sn" означает "strong name", то есть "сильное имя").
Ключи хранятся в двоичных файлах. Команда построения ключей имеет следующий синтаксис:
sn – k <имя_файла>
Файлам должно быть присвоено расширение.snk. В нашем примере пара ключей была создана командой:
sn – k c:\keys\pair.snk
Примечание
Файл .snk можно сгенерировать и в VS.NET IDE (команда Strong Name в диалоговом окне Project Properties), но большинство программистов предпочитает создавать ключи в отдельном процессе с максимальным уровнем защиты. Файл.snk должен быть защищен от несанкционированного доступа; если закрытый ключ станет известен посторонним, проку от него будет немного.
Сертификация сборки
При наличии пары ключей в виде файла .snk можно сертифицировать сборку закрытым ключом. При этом .NET включает открытый ключ в манифест сборки [Точнее говоря, в манифест включается хэшированная версия ключа, которая в .NET называется образцом (token) открытого ключа. Вероятно, хэширование применяется для экономии места, хотя нам кажется, что в манифесте следовало бы просто опубликовать открытый ключ.] и вычисляет хэш-код всех данных сборки по закрытому ключу. Результат тоже включается в манифест. По этим данным другие сборки, использующие ваш код, смогут убедиться в том, что сборка не подверглась постороннему вмешательству. Для этого открытый ключ применяется к зашифрованному хэш-коду, а результат сравнивается с приведенным в манифесте.
Чтобы сертифицировать сборку, включите в программу атрибут AssemblyKeyFile-Attribute с именем файла .snk после всех команд импортирования или же воспользуйтесь вкладкой Sharing диалогового окна Project Settings. Пример:
Imports System.Reflection
<Assembly:AssemblyKeyFi1eAttribute("c:\keys\pai r .snk")> \
Примечание
Многие компании не предоставляют своим работникам доступа к закрытому ключу, поэтому в .NET была предусмотрена возможность отложить сертификацию сборки (за дополнительной информацией обращайтесь к документации).