|
Код написан и подписан - значит, будет жить... В последнем выпуске нашего журнала за 1999 мы затронули тему цифровых сертификатов и их роли в мире информационных технологий. В продолжение темы, данная статья посвящена наиболее актуальной для разработчиков группе цифровых сертификатов, предназначенных для подписи кода, инсталлируемого или исполняемого в среде Internet. Три законченные части статьи помогут разобраться в общих вопросах подписи кода, выяснить различие в моделях безопасности популярных броузеров Internet Explorer и Netscape Navigator, а также освоить утилиты, необходимые для работы с цифровыми сертификатами. 1. Вместо предисловия... Прежде чем начать изложение хочу отметить, что данная статья является прежде всего результатом синтеза материалов, найденных на сайтах таких известных компаний, как VeriSign, Microsoft и Netscape. Предтечей поиска стала необходимость заставить клиентский Java апплет печатать изображение на принтер и сохранять его в файл на локальном диске пользователя. Оценив и успешно испробовав то, что доступно всеобщему обозрению, я решился на написание этой статьи. Подобный путь может проделать каждый, имеющий доступ к Internet, но надеюсь, статья все же будет полезной, поскольку и искать будет значительно легче (все необходимые адреса приведены в статье), да и разбираться придется, теперь, только лишь в деталях. Дабы слова не расходились с делом, сразу же хочу представить вашему вниманию несколько ссылок, которые послужили мне источником общей информации в вопросах получения цифрового сертификата и использования его для подписи кода: 1. http://www.microsoft.com/ - без комментариев 2. http://developer.netscape.com/ - сайт, содержащий массу полезной информации для разработчиков, пользующихся продуктами компании Netscape 3. http://www.thawte.com/ - южноафриканская компания, занимающаяся выдачей сертификатов, на мой взгляд, с гораздо более практичным подходом к делу и ценам чем всем известный Verisign. 4. http://www.verisign.com/ - а вот, собственно, и ссылка на сам Verisign - пожалуй самый известный и наиболее авторитетный Источник Сертификатов; ресурс весьма полезный - содержит много нужной информации о процессе и технологиях сертифицирования. И последнее. Любая техническая область знаний предполагает наличие специфической терминологии. Не смотря на то, что тема, затрагиваемая в статье, имеет единое теоретическое обоснование (о котором мы поговорим в первой части), и тем не менее , основными объектами, обсуждаемыми в статье, будут разные коммерческие продукты разных производителей. Все мы хорошо знаем, что в сфере сбыта роль выверенной терминологии не всегда столь значительна как в науке, и потому, зачастую, одни и те же понятия в интерпретации разных фирм обозначаются разными названиями. Это утверждение совершенно справедливо для таких продуктов как Internet Explorer и Netscape Navigator (на чем, от части, делает деньги VeriSign). В связи с этим, в статье выбрана нейтральная терминология, предлагаемая автором исходя из смыслового содержания описываемого понятия. 2. Часть 1. Теория подписи кода 2.1 Зачем нужно подписывать код Если программное обеспечение покупается непосредственно у производителя, то вопрос о степени доверия полномочиям данного продукта отпадает, как бы, сам собой. Если это заказное программное обеспечение, то сомнений тут и быть не может, так как ответственность сторон оговаривается договором, а необходимая функциональность должна соответствовать техническому заданию, утвержденному в общем порядке. Если же это программное обеспечение общего характера, приобретенное у авторизированного дилера или дистрибьютера, то, как правило, технические свойства такого продукта широко известны и неприятных неожиданностей тоже быть не может. Совсем другое дело Internet приложения. Internet среда глобальная, построенная на принципах виртуально безграничной свободы, регулируемой лишь уровнем технической грамотности и интеллекта ее создателей и участников. Любому человеку, работавшему с Internet, наверняка, хорошо знакомо предупреждающее сообщение о потенциальной опасности любой выкачки информации с любого сервера (даже если выкачка осуществляется броузером Internet Explorer с сайта Microsoft). И причина этого сообщения одна - в виртуальном мире все не потенциально настоящее, а потому потенциально опасное. В таких условиях трудно говорить о доверии программному обеспечению выкачиваемому из Internet. Хорошим решением в данном случае являются уже хорошо знакомые нам цифровые сертификаты. Они выпускаются третьей совершенно реальной и авторитетной стороной (Certificate Authority), что обеспечивает им статус общего доверия. Цифровые сертификаты можно использовать для: Шифрования каналов безопасной коммуникации между клиентскими компьютерами и серверами Internet; Удостоверения личности клиентов и серверов для каналов безопасной коммуникации; Шифрования сообщений для безопасной передачи сообщений электронной почты; Подписи исполняемого кода, загружаемого из Internet. В последнем, наиболее интересно для нас сейчас, случае цифровые сертификаты предоставляют гарантию следующих двух аспектов: авторство - в том смысле, что производителем (или ответственным представителем производителя) данного кода действительно является организация, использовавшая для подписи данный сертификат (certificate publisher). целостность подписанного кода - то есть, код, подписанный сертификатом, предстает пользователю в таком виде, в каком его хочет представить выпустившая сторона. Изменения из вне (заражение вирусом, взлом) невозможны. Такого рода гарантии весьма существенны как для производителей программного обеспечения, так и для конечных пользователей и покупателей. Пользователи получают точную информацию о производителе программного обеспечения и о исходных свойствах программного продукта. И кроме того, они точно могут быть уверены в том, что используемое приложение будет работать только так, как было заложено производителем (и ни кем иным). Со своей стороны, производители, использующие сертификаты для подписи своей продукции, обеспечивают определенный рейтинг своей торговой марке. Поскольку при использовании сертификатов для подписи кода, даже в условиях неконтролируемого использования и распространения результатов их деятельности (ActiveXT компонентов, JavaT апплетов и т.д.) каждый пользователь обязательно будет знать о реальном производителе и будет оценивать продукт в аспекте конкретного авторства. 2.2 Что такое цифровой сертификат В прошлом номере, в статье "Обзор цифровых сертификатов" в общих чертах уже обсуждался этот вопрос. В этот раз мы поговорим о технической стороне вопроса. Итак, цифровой сертификат (цифровой идентификатор) представляет собой электронное удостоверение личности, имеющее хождение в среде Internet. Аналогия совершенно однозначная, хотя бы даже потому, что также как и водительские права или, скажем, паспорт, цифровые сертификаты выдаются их владельцам в централизированном порядке специальными организациями, отвечающими за проверку достоверности идентификационной информации (для получения цифрового сертификата в компанию Источник Сертификатов необходимо предоставить оформленные в надлежащем виде официальные документы, которые могут однозначно засвидетельствовать подлинность физического или юридического лица). Эти независимые организации, именуемые Источниками Сертификатов или Сертификационными Авторитетами (Certification Authority), являются публичными организациями (не обязательно коммерческими - в Украине эту роль вполне может выполнять такая организация как СБУ, например) с устоявшимся уровнем доверия к ним со стороны Internet сообщества. Технология цифровых идентификаторов базируется на теории кодирования с открытым ключом. В криптографических системах, использующих кодирование с открытым ключом, процесс кодирования и раскодирования организуется при помощи взаимосвязанной пары ключей, один из которых (как правило, меньший по длине) объявляется открытым, а другой, соответственно, закрытым. Открытые ключи передаются пользователям системы в явном виде (на то они и открытые), тогда как закрытые ключи остаются в распоряжении лишь их владельца, который всеми силами стремится сохранить их в тайне. Принцип кодирования с открытым ключом заключается в том, что информация закодированная закрытым ключом может быть раскодирована исключительно при помощи соответствующего открытого ключа (ключи генерируются парами по определенному алгоритму). С точки зрения проблемы аутентификации данную особенность систем шифрования с открытым ключом можно интерпретировать следующим образом: любой код, который был успешно верифицирован при помощи открытого ключа (полученного вместе с цифровой сигнатурой), изначально мог быть подписан только соответствующим закрытым ключом, который находится в распоряжении владельца кода. Кроме того, как мы увидим позднее, процедура верификации построена таким образом, что успешной она может быть только в случае, если подписанный код представлен в исходном виде. Более подробную информацию о системах кодирования с открытым и закрытым ключами можно посмотреть здесь: http://www.verisign.com/repository/crptintr.html. Роль цифрового сертификата в такой схеме вырисовывается достаточно ясно. Он является подтвержденным идентификатором владельца пары открытого и закрытого ключей. Буквально, это выражается в том, что цифровой сертификат содержит общую информацию о его владельце, проверенную Источником Сертификата, информация о котором также присутствует в кодированном теле сертификата. Одним из наиболее известных и авторитетных Источников Сертификатов является компания VeriSign (http://www.verisign.com/). Однако это не единственный авторизированный источник сертификатов в Internet. В качестве альтернативы VeriSign, я мог бы по рекомендовать компанию Thawt: (http://www.thawte.com/), которая кроме ценовых преимуществ (цены ровно в 2 раза ниже, чем на VeriSign) предоставляет сертификат, который может быть использован как для подписи кода для Microsoft Internet Explorer, так и для Netscape Communicator. В числе авторитетных источников сертификатов, из числа указанных в списке Trusted Root Certification Authorities Internet Explorer есть компания Baltimore http://www.baltimore.com/cert/index.html. Сертификаты указанных компаний поддерживаются по умолчанию как Internet Explorer, так и Netscape Communicator. Выбор компании Источником Сертификатов - дело весьма ответственное. При этом должны учитываться все факторы: ценовая и сервисная политика компании, ее известность, надежность и т.д. В любом случае, получение сертификата - процедура моторошная и совсем не дешевая. Однажды подписав свой код, вы вынуждены будете поддерживать сертификацию для подписанного продукта на протяжении всего цикла его существования, а сертификаты, как известно, имеют ограниченный срок действия (как правило, 1 год). Этот фактор заставляет обращать особое внимание на цены услуг компаний Источников Сертификатов. С другой стороны, уровень и известность Источника Сертификатов должны соответствовать уровню компании, использующей сертификаты. И компромиса по данным факторам достичь порой бывает очень трудно. 2.3 Цифровые сертификаты на клиентской стороне Технология подписи кода основана на общепринятых промышленных стандартах криптографической техники таких как: X.509 v3 - для формирования тела сертификата PKCS #7 и #10 - сигнатурные стандарты Все вышеперечисленные стандарты поддерживаются как Microsoft Internet Explorer, так и Netscape Communicator. Как уже отмечалось, технология подписи кода основывается на процедуре формирования и верификации сигнатуры (Рисунок 1). При помощи закрытого ключа сигнатура формируется - а верификация производится, соответственно, с использованием открытого ключа. С целью ускорения процедуры верификации, в протоколе подписи кода используется криптографический дайджест (cryptographic digest), который представляет собой специальным образом сформированный хеш-код документа (one-way hash) . В общем виде процесс формирования и использования подписанного кода можно представить следующим образом: 1. Заинтересованная сторона (разработчик) получает цифровой сертификат от Источника Сертификатов (этот этап занимает около 3 месяцев при первом запросе). 2. Разрабатывается код 3. При помощи специальных утилит (для каждого броузера своя утилита), о которых мы поговорим позднее, выполняются следующие действия:
4. Броузер конечного пользователя при загрузке подписанного приложения определяет наличие пакета с информацией о подписи кода. Следует отметить, что поддержка системы безопасности реализуется далеко не всеми броузерами. Более того не все версии даже известных броузеров поддерживают работу с сертификатами. Так, для полноценной работы с сертификатами вам понадобится Internet Explorer начиная с версии 4.0, или Netscape Communicator тоже не ранее 4.0. 5. Первым делом броузер извлекает информацию, находящуюся в цифровом сертификате распространителя кода. Для этого используется открытый ключ соответствующего корневого Источника сертификатов (CA root Public Key). Это возможно только в том случае, если открытый ключ данного Источника Сертификатов уже инсталлирован в базу броузера (открытые ключи наиболее известных Источников Сертификатов входят в пакет инсталляции наиболее популярных броузеров, таких как IE и Netscape; сертификаты из любых других источников могут быть проинсталлированы в ручную в любое время). 6. Используя открытый ключ распространителя кода, который хранится в пакете вместе его цифровым сертификатом, броузер декодирует контрольную сумму подписанного кода. 7. Затем, броузер по тому же алгоритму, что и распространитель кода, вычисляет хеш-код для кода извлеченного из архива и сравнивает полученную сумму с оригинальной. 8. Если оба значения хеш-кода совпадают, пользователь информируется о том, что загружаемый программный код подписан (моменты выдачи этой информации у IE и Netscape разные). Пользователю предоставляется информация о распространителе кода, о Источнике Сертификатов, подтверждающем достоверность информации о распространителе кода и срок действия сертификата. 9. В противном случае, код считается не подписанным и в силу вступают настройки безопасности броузера, ограничивающие свободу действий приложений, к которым установлен низкий уровень доверия. 
Как видно из представленного выше описания, процесс верификации кода базируется исключительно на открытых ключах. Открытые ключи Источников Сертификатов хранятся в специальной базе данных броузера. Организация хранилища информации о сертификатах и ключах зависит от конкретного броузера. Так, Netscape хранит все ключи в специальных файлах, расположенных на локальном диске пользователя:
Хранилище информации о сертификатах и ключах в Internet Explorer имеет сложную иерархическую структуру, где каждый раздел хранилища имеет свое уникальное имя. Однако, детального описания физической реализации этой структуры Microsoft не публикует. 3. Часть 2. Модели безопасности броузеров 3.1 Web ресурсы Дабы не возвращаться к этому вопросу по ходу изложения, хотелось бы сразу выделить следующие адреса в Internet, по которым вы можете найти дополнительную информацию по теме данного раздела: 1. http://www.verisign.com/developer/index.html - руководства по подписи кода (с описанием особенностей броузеров) 2. http://support.microsoft.com/support/kb/articles/q179/6/52.asp - отличия между Microsoft и Netscape моделями безопасности. 3. http://developer.netscape.com/docs/manuals/signedobj/capabilities/index.html - подробное описание Netscape Capabilities API. 3.2 Различия между моделями безопасности Microsoft и Netscape Не смотря на то, что оба броузера - от Microsoft и от Netscape, предоставляют приблизительно одинаковые возможности для доступа в Internet, в их моделях безопасности Java имеется целых пять существенных отличий. Причем, все они, так или иначе, отражаются на процессе подготовки и подписи кода приложения. Итак, приступим к детальному рассмотрению каждого из отличий. 3.2.1 Архивные пакеты Непременным условием предоставления исключительных прав подписанному Java коду является наличие специального архивированного пакета, из которого, собственно, и загружается этот код. Internet Explorer и Netscape Communicator поддерживают разные форматы этих самых пакетов - для Internet Explorer необходим CAB пакет, а для Netscape Communicator - JAR. Справедливости ради, отметим, что Internet Explorer вполне воспринимает и JAR формат, однако он воспринимает JAR пакет исключительно как архив, предназначенный для уменьшения сетевого трафика при выкачке кода (информация о подписи кода, содержащаяся в JAR пакете не распознается Internet Explorer-ом). В свою очередь, Netscape Communicator совершенно не воспринимает CAB пакеты. Таким образом, если необходимо обеспечить работоспособность приложения как под Internet Explorer, так и под Netscape Communicator, то необходимо при помощи двух разных утилит создать и подписать два разных пакета. Селекция нужного пакета будет производится на этапе обработку броузером тега <APPLET>. Формат этого тега как раз и является предметом следующего отличия в моделях безопасности обсуждаемых броузеров. 3.2.2 HTML теги Для того, чтобы Internet Explorer начал работать с CAB файлом, в объявлении тега <APPLET> обязательно должен присутствовать параметр апплета Cabbase. Следующий формат тега <APPLET> поддерживается Internet Explorer, начиная с версии 3.0: <APPLET code=MyClass.class width=100 height=100> <PARAM NAME=cabbase VALUE=MyApplet.cab, MyLib.cab> <PARAM NAME=... VALUE=...> </APPLET> Начиная с версии 4.0, Internet Explorer поддерживает, так называемый, Менеджер Пакетов (Package Manager). Рассмотрение этого элемента Internet Explorer выходит за рамки данной статьи. Отметим лишь то обстоятельство, что при использовании менеджера пакетов CAB пакеты загружаются при помощи параметра Useslibrary: <APPLET code=com.mycorp.AppletMain width=100 height=100> <PARAM NAME=useslibrary VALUE="MyApplet"> <PARAM NAME=useslibrarycodebase VALUE="MyApplet.cab"> <PARAM NAME=useslibraryversion VALUE="1,1,2,3"> <PARAM NAME=... VALUE=...> </APPLET> В случае Netscape Communicator, JAR пакет подключается через атрибут archive тега <APPLET>, а не через параметр апплета, как в случае Internet Explorer: <APPLET code="MyApplet" width=200 height=200 archive=MyApplet.jar, MyLib.jar> <PARAM NAME="ApplicationClass" VALUE="mycompany.MyApplet"> <PARAM NAME=... VALUE=...> </APPLET> Такой формат тега <APPLET> поддерживается Netscape Communicator, начиная с версии 4.0. Таким образом, задача одновременной увязки в одном теге пакетов с подписанным кодом как для Internet Explorer, так и для Netscape Communicator становится вполне разрешимой. Для этого достаточно в одном теге <APPLET> указать атрибут archive и задать параметр апплета <PARAM NAME=cabbase VALUE=... > : Netscape в принципе не понимает .CAB формат (и уж тем более не занимается анализом параметров апплета на предмет выявления Cabbase или Useslibrary). Internet Explorer 4.x первым делом пытается определить значение параметра апплета Useslibrary. Если такой параметр не задан, Internet Explorer проверяет параметр Cabbase. И уж только после этого он смотрит значение атрибута archive. Необходимо отметить, что при помощи параметра Useslibrary CAB пакеты физически инсталлируются на машину пользователя и остаются на ней до тех пор, пока сам пользователь явным образом не удалит их (т.е., в общем случае, выкачка такого пакета производится всего один раз). В случае использования параметра Cabbase, пакет будет выкачиваться всякий раз при активизации, соответствующего тега. Особенности управления пакетами при помощи Менеджера Пакетов и составляют предмет следующего отличия в моделях безопасности броузеров Internet Explorer и Netscape Communicator. 3.2.3 Инсталляция Java апплетов и приложений Как уже отмечалось, Java апплеты и приложения могут физически инсталлироваться на машину пользователя при помощи Менеджера Пакетов, реализованного в рамках Internet Explorer 4.0x и более поздних версиях. Netscape Communicator пока что не предоставляет ничего подобного. Менеджер Пакетов предоставляет возможность гибкого управления версиями используемых пакетов, он позволяет организовывать и контролировать выделенное пространство имен приложений. Менеджер Пакетов позволяет расширить диапазон настроек безопасности, а также предоставляет возможность деинсталляции установленных пакетов. Более подробную информацию о Менеджере Пакетов можно подчерпнуть по адресу http://www.microsoft.com/java/sdk/. Следует отметить, что для Менеджера Пакетов CAB пакет необходимо создавать специальной утилитой - dubuild. Эту утилиту мы не будем рассматривать в данной статье. Заинтересованные в более подробной информации об этой утилите смогут найти ее в помощи по Microsoft Java SDK в разделе Tools. 3.2.4 Технология подписи кода Как ни странно, компания Microsoft (видимо с подачи Verisign) утверждает мнение о том, что Internet Explorer и Netscape Communicator поддерживают принципиально разные технологии подписи кода. В обиход были введены даже разные термины для обозначения этого процесса - в Internet Explorer работа с подписанным кодом именуется Authenticode technology, тогда как Netscape Communicator использует термин Object Signing. Странным это выглядит потому, что для подписи кода в обоих случаях используются одни и те же стандарты: X. 509 v3 для сертификатов и PKCS #7 для сигнатур. Более того, процесс подписи и последующей верификации кода, также строится по единой схеме (несмотря на то, что для этого используются разные форматы пакетов и разные утилиты). Безусловно имеется какая-то разница в деталях реализации, однако, на мой взгляд, различие в деталях реализации не могут послужить поводом для селекции технологических ветвей. Подтверждением тому, что данное отличие является надуманным, является тот факт, что компания Thawt предоставляет всего один сертификат, который может быть использован как для подписи кода под Internet Explorer, так и под Netscape Communicator (инструкции по этому поводу в открытом виде хранятся на сервере компании: http://www.thawte.com/certs/developer/diffapps.html). 3.2.5 Реализация модели безопасности Вот в чем действительно имеется различие в моделях безопасности Internet Explorer и Netscape Communicator, так это в реализации модели. Microsoft заложила в основу Internet Explorer статическую модель безопасности, которая предполагает определение доверия приложению один раз при его загрузке и сразу же всем его функциям. В то время как Netscape реализовала динамическую модель безопасности, в рамках которой приложение запрашивает у пользователя привилегии по мере необходимости в них и в индивидуальном порядке (т.е. категория доверия определяется по каждой экстремальной функции отдельно). При этом, правда, пользователь получает большее сообщений с просьбой о подтверждении прав приложения и в больших приложениях с комплексным интерфейсом и это может стать достаточно раздражающей процедурой (хотя для Java апплетов это вряд ли актуально). Гибкость статической модели Microsoft проявляется в возможности параметрической настройки запрашиваемых привилегий. Так, скажем, привилегии приложения можно настроить таким образом, чтобы оно запрашивало не просто разрешение доступа к файлам на локальном диске клиента, а конкретно к файлам с определенным именем и расширением в определенном каталоге, находящемся на определенном разделе диска. К сожалению, в Netscape такой уровень настроек модели безопасности недоступен. Различия в реализациях моделей безопасности в Internet Explorer и в Netscape Communicator не ограничиваются рассмотренным выше чисто внутренним аспектом. Так, Netscape обязывает разработчиков пользоваться специальным Сapabilities API, без которого получить доступ к расширенному набору функций, осуществимых в контексте подписанного приложения (таких как печать или работа с файлами на локальном диске клиента), просто невозможно. То есть, отличия буду не только в поведении приложений, но также и в их исходном коде, который, как выясняется, должен учитывать особенности внутренней архитектуры исполняющего броузера (по меньшей мере, это касается Netscape Communicator, поскольку система безопасности Internet Explorer вполне корректно укладывается в рамки классов стандартного JDK). Конечно, это не причина, чтобы разделать приложение на две версии, каждая из которых адаптирована под конкретный броузер. Однако дополнительные хлопоты, связанные с организацией ветвления логики работы программы в зависимости от среды исполнения (причем, обязательно в блоке try/catch, отслеживающем исключение ClassNotFound), ничего, кроме усталости и раздражения, программисту не дадут. Подробную информацию о Netscape Сapabilities API можно найти по адресу http://developer.netscape.com/docs/manuals/signedobj/capabilities/index.html. Причина отсутствия специального API для запроса и подтверждения привилегий в Internet Explorer кроется в структуре CAB файла, который включает в себя сигнатуру специального вида с закодированными в ней запросами привилегий. Однако, порой привилегиями нужно управлять и в процессе выполнения приложения (это, собственно, и предоставляется Netscape Сapabilities API), что явно не вписывается в концепцию Microsoft. В связи с этим, Microsoft также разработала отдельное API, которое может быть использовано исключительно в рамках Internet Explorer. Подробное описание это API можно найти в документации по Microsoft SDK для Java 2.0 и выше или по адресу http://www.microsoft.com/java/sdk. 3.3 Пользовательский интерфейс системы безопасности Netscape Communicator Когда Netscape Communicator регистрирует запрос от исполняемого
приложения на получение разрешения выполнения некоторой критичной функции
на стороне клиента (через Сapabilities API), он прежде всего проверяет
наличие в пакете, из которого было запущено приложение, цифровой
сигнатуры. Если таковая не обнаружена, приложение рассматривается как
неподписанное (с минимальным уровнем доверия) и выполнение критической
операции безапелляционно блокируется. Если же сигнатура выявлена и успешно
верифицирована, а в локальной базе сертификатов Netscape имеется
информация об Источнике Сертификатов, выдавшем сертификат для подписи
этого кода, то пользователь получит информационное окно запроса
привилегий, подобное представленному на Рисунке 2. Это окно содержит следующие поля: Communicator сам определяет степень риска запрашиваемой операции (высокая, средняя или низкая) и сообщает ее пользователю. Суть запрашиваемой операции и структуру риска пользователь может оценить сам, щелкнув на кнопке "Details". Решение, принятое пользователем относительно данной операции для
данного сеанса работы с приложением, запоминается броузером на все
оставшееся время до момента выгрузки приложения. Это значит, что если в
пределах этого сеанса работы приложению потребуется аналогичная функция, к
ней будет применено однажды принятое решение пользователя. Будьте
осторожны с флажком "Remember this decision". Установив его, вы
зафиксируете свои решения для всех сеансов работы с данным приложением
(сигнатура приложения будет запомнена в базе броузера и вместе с ней будут
хранится все принятые решения по функциям, требующим контроля со стороны
системы безопасности). Однако это совсем не означает, что однажды принятое
решение нельзя изменить. Вы можете сделать это в любой момент времени,
щелкнув на кнопке Security в панели инструментов Netscape Communicator и
выбрав пункт меню "Java/JavaScripts" в появившемся окне настроек (Рисунок
3). Выбрав в списке приложение, вы всегда можете отредактировать привилегии, установленные для него, вне зависимости от того, распространяются ли они на один сеанс работы или на все сразу, не говоря уже о том, что вы можете аннулировать принятые решения путем простого удаления "профиля" из списка. 3.4 Пользовательский интерфейс системы безопасности Internet Explorer Поведение Internet Explorer при загрузке и локальном запуске приложений существенно отличается от поведения Netscape Communicator. Как известно, настройки безопасности Internet Explorer производятся для четырех уровней защищенности: High, Medium, Low и Custom, активность которых определяется состоянием текущего соединения (Internet, Intranet...). В зависимости от того, какой уровень защиты установлен для текущего соединения, при загрузке по сети неподписанного кода могут возникать следующие ситуации:
А вот если загружаемое приложение подписано (и в базе броузера имеется
зарегистрирован соответствующий Источник Сертификатов), то при его
загрузке пользователь получит информационное окно с запросом привилегий,
пример которого представлен на Рисунке 5. 
Как и в случае Netscape, данное информационное окно содержит: Кроме того, в этом окне пользователю предоставляется ссылка на описание параметров загружаемого приложения. А в Internet Explorer 5.0 еще перечисляются запрашиваемые приложением привилегии. Для просмотра полной информации о сертификате, использованном для
подписи приложения, нужно нажать кнопку "More Info". При этом пользователь
получит окно, пример кторого представлен на Рисунке 6. 4. Часть 3. Обзор инструментальных средств В данной части мы рассмотрим примеры использования конкретных утилит, необходимых при подписи кода для Netscape Communicator и Internet Explorer. Причем, изложение будет построено не на описании свойств самих процедур, которые вы и без того сможете найти в документации (все необходимые адреса будут представлены), на описании процесса подписи - начиная от выгрузки и инсталляции необходимых утилит и заканчивая, собственно, процедурой подписи. Итак... 4.1 Пять этапов процесса подписи кода для Netscape Communicator В общем процесс подписи кода для Netscape Communicator можно уложить в
следующие четыре шага: 4.1.1 Генерация тестового сертификата и инсталляция его в базу данных Netscape Получение сертификата у авторитетного источника сертификатов - процедура весьма длительная и дорогостоящая. Подстраивать процесс разработки и отладки программного обеспечения под эту процедуру вряд ли имеет смысл. В связи с этим, любой, боле не менее серьезный, пакет для подписи кода представляет возможность генерации и использования в отладочных целях тестового сертификата. Так утилита signtool имеет опцию -G, которая принуждает утилиту генерировать пару ключей (открытый и закрытый) и тестовый сертификат к ним. При этом в качестве аргумента, утилите передается идентификатор сертификата, который понадобится в последствии при подписи кода. Сгенерированные ключи и сертификат автоматически инсталлируются в базу данных Netscape (файлы cert7.db key3.db обычно расположенные в директории :\Program Files\Netscape\Users\user_name\ ), путь к которой устанавливается опцией -d. При работе в среде Unix опцию -d указывать не обязательно. Сгенерированный сертификат также сохраняется в файле с именем
x509.cacert (если не задано другое имя), который имеет MIME тип
application/x-x509-ca-cert. Данный файл позволяет использовать тестовый
сертификат не только на локальной машине, на которой производилась подпись
кода тестовым сертификатом, но и на других машинах. Для инсталляции его на
другие броузеры, необходимо разместить x509.cacert на Web сервере. Создать
для него отдельную виртуальную директорию. И настроить для нее MIME тип
(т.е. связать расширение .cacert с типом application/x-x509-ca-cert).
Затем, открывая в любом броузере этот адрес (с указанием файла
x509.cacert), вы будете активировать мастер инсталляции сертификата,
который все сделает за вас (главное установить флажок В процессе генерации сертификата, утилита задаст вам ряд вопросов с
целью выяснения общей информации, которая должна быть включена в
сертификат. Процесс генерации тестового сертификата в среде Unix выглядит
на экране следующим образом: Как видно из этого примера, в процессе генерации утилита попросит вас
ввести пароль для доступа к базе данных сертификатов Netscape. Этот пароль
обязательно должен быть определен до начала генерации сертификата. Для
того, чтобы задать этот пароль, необходимо щелкнуть на пиктограмме
Security в панели инструментов Netscape, выбрать раздел Passwords, и
нажать на кнопку Set Password. Последнее важное замечание относительно генерации тестового
сертификата. Утилита signtool модифицирует файлы баз данных сертификатов и
ключей Netscape. Очень важно, что бы при этом не была запущена ни одна
копия броузера. Иначе вся информация из этих баз может быть безвозвратно
утеряна. Более подробную информацию о генерации тестового сертификата при помощи
утилиты signtool вы можете найти по адресу http://developer.netscape.com/docs/manuals/cms/41/adm_gide/app_sign.htm#1013184. 4.1.2. Подпись кода и ее верификация Эта процедура не имеет такого множества нюансов как предыдущая. Она
достаточно проста, и представляет собой следующую последовательность
действий: 1. Создаем новую пустую директорию 2. Записываем в нее файлы подписываемого приложения 3. Задаем идентификатор сертификата (если вы забыли идентификатор
тестового сертификата или используете подлинный сертификат от Источника
Сертификатов, то посмотреть имя сертификатов подходящих для подписи кода в
любой момент можно при помощи опции -l: signtool.exe -d "C:\Program
Files\Netscape\Users\alex" -l), используемого для подписи кода, имя
будущего пакета и имя каталога с подписываемыми файлами: 4. Теперь нужно ввести пароль для доступа к базе сертификатов и ключей.
Если пароль введен правильно, вы получите следующее сообщение: Проверка действительности подписи и сертификата: Более детальную информацию о Netscape Signing Tool последней версии
можно получить по адресу http://developer.netscape.com/docs/manuals/signedobj/signtool/index.htm. 4.2 Шесть этапов процесса подписи кода для Internet Explorer В отличии от Netscape, процесс подписи кода для Internet Explorer
включает в себя на один этап больше: 1. Выкачивание из Internet всех необходимых инструментальных средств
для подписи кода. А именно: Данный комплект программного обеспечения вы можете совершенно бесплатно
выкачать со следующего адреса http://www.microsoft.com/java/download/dl_sdk40.htm. Этот дополнительный этап связан с формированием CAB пакета при помощи
отдельной утилиты из набора Internet Client SDK. Но обо всем по
порядку. 4.2.1 Генерация тестового сертификата и инсталляция его в базу Internet
Explorer В комплект утилит Internet Client SDK входит утилита MakeCert (каталог
BIN). Описание этой утилиты можно найти как в MSDN, так и в документации,
входящей в комплект поставки SDK (раздел Tool reference\Sofware
distribution tools). Это достаточно сложная утилита, построенная на основе
комплексной архитектуры хранилищ сертификатов в Internet Explorer, с
множеством различных опций и настроек (следует отметить, что сложность
конфигурации и многовариантность использования отличает все утилиты,
используемы для подписи кода под Internet Explorer). Мы не будем сейчас
сильно углубляться в изучение этой утилиты (желающие смогут сделать это
самостоятельно по достаточно подробной документации). Тем более, что в
этом не особой необходимости. Базовая процедура подписи кода,
рассмотренная ниже, одинакова для всех случаев. При помощи настроек,
рассмотрение которых здесь опущено, можно лишь добиться каких либо сверх
тонких эффектов, связанных с хранилищем сертификатов и ключей Internet
Explorer. Итак, что для генерации тестового сертификата достаточно выполнить
следующий вызов: makecert -ss Root -sv Test.pvk NewCer.cer где: -ss Root - означает, что сертификат будет сгенерирован тестовым
источником сертификатов, считающимся корневым для Internet Explorer, и что
информация о нем будет помещена в хранилище сертификатов Root (Trusted
Root Certification Authorities, как я думаю). -sv NewTest.pvk - задает имя файла, в котором будет сохранен
сгенерированный закрытый ключ. NewCer.cer - имя файла, в который будет записан сгенерированный
сертификат В дальнейшем, для подписи CAB пакет нам понадобится этот сертификат
представленный в специальном формате SPC. Для конвертации из стандартного
формата CER в SPC имеется специальная утилита cert2spc. На входе у нее
задаются имена файлов: исходного в формате CER и результирующего в формате
SPC: где cert1...certN - имена файлов, содержащих сертификаты в формате X.509,
которые должны быть включены в результирующий SPC файл. оutput - имя результирующего объекта в формате PKCS #7 Как и в случае с Netscape, база данных закрытых ключей в Internet
Explorer защищена паролем, который изначально не определен. Поэтому при
самом первом запуске утилиты makecert вы получите приглашение ввести и
подтвердить пароль. При всех последующих запусках этой утилиты вы будете
получать приглашение ввести пароль, пример которого представлен на рисунке
7. 4.2.2. Подготовка кода к подписи Как уже отмечалось, подготовка кода к подписи заключается в
формировании CAB пакета. Для этого используется утилита cabarc, которая
также входит в комплект Internet Client SDK: Подробное описание значений полей этой утилиты вы найдете в
документации по Internet Client SDK. Здесь я лишь приведу пример
выполнения этой утилиты: Обратите внимание на формат поля [список архивируемых файлов]. Это поле
представляет собой перечисление путей и масок файлов, которые должны быть
включены в архив. Все пути объединяются знаком <+>. В данном случае
перечисленные директории находились в одном подкаталоге с исполняющим bat
файлом (при этом, удобно использовать bat файл, чтобы не набирать каждый
раз такие длинные команды). Опция /p заставляет сохранять в CAB архиве информацию о директориях, в
которых расположены архивируемые файлы (для Java проектов это
существенно). Опция /r определяет рекурсивное выполнение операции
архивирования (т.е. если в указанных директориях имеются подкаталоги, то
они также будут, в этом случае, включены в архив). Команда N определяет создание нового архива в указанном директории (в
данном случае, в текущем каталоге). 4.2.3. Подпись CAB пакета Для подписи кода под Internet Explorer используется утилита
signcode: signcode [опции] <имя_подписываемого_архива> У этой утилиты имеется большое количество опций, которые подробно
расписывать мы сейчас не будем. Я использовал следующий формат этой
утилиты: Опция -j подключает библиотеку, которая обеспечивает корректное
формирование атрибутов сигнатуры. В нашем случае используется
JavaSign.dll. Именно эта библиотека должна использоваться для подписи Java
кода. Опция -jp задает уровень привилегий, необходимых приложению. Это может
быть один из стандартных уровней: LowX MediumX HighX. Либо, как
вышеприведенном примере, это может быть текстовый файл предопределенного
формата с детальным описанием требуемых привилегий. Мы уже упоминали о
том, что реализация модели безопасности в Internet Explorer предоставляет
возможность гибкого выбора уровня привилегий. Вот именно при помощи этого
файла и осуществляется этот выбор. В моем случае файл был таким
permissions.ini: Это полный формат файла настроек привилегий. Подробное описание его
можно найти в MSDN и в документации по (sample permissions ini file). Как
видите, привилегии, которые мне были не нужны, остались просто
неопределенными. Но это не значит, что их нужно удалять из файла. Я
пробовал это делать, и могу сказать, что это негативно сказывается на
результате (при этом, как правило, теряются некоторые установки, которые
как раз должны были попасть в CAB пакет). Хочу обратить внимание на следующую строку настроек привилегий: Эта настройка регулирует возможность записи в файлы на локальном диске
клиента. Значения, перечисленные в этой строке, определяют результат
вызова такого метода стандартного java.lang.SecurityManager в Java
апплете: public void checkWrite(String file) Под Internet Explorer этот метод сгенерирует SecurityException
исключение, если параметр file будет содержать ссылку на файл с любым
расширением, кроме *.jpg;*.jpeg. Это касается и всех остальных проверок
SecurityException. Под Netscape, к сожалению, методы стандартного
java.lang.SecurityManager мало полезны. Опции -spc и -v, соответственно, задают имя SPC файла с сертификатом
для подписи и имя файла с закрытым ключом. Последний элемент в командной строке утилиты signcode - это имя CAB
файла, содержащего подписываемый код. В процессе работы этой утилиты, вы получите два диагностических окна.
Первое с запросом пароля доступа к базе закрытых ключей (рисунок 7). А
второе с просьбой подтвердить желание добавить сертификат в корневое
хранилище - рисунок 8. Этот запрос актуален только в случае использования тестового
сертификата (поскольку настоящий сертификат, полученный от авторитетного
Источника Сертификатов, к моменту подписи кода, уже должен находиться в
хранилище Internet Explorer). Дело в том, что тестовый сертификат для
Internet Explorer - это, на самом деле, не настоящий сертификат. Internet
Explorer никогда полностью не доверяет этому сертификату, и постоянно
будет напоминать вам, что он тестовый. Это будет проявляться в том, что,
когда вы будете загружать приложение, подписанное тестовым сертификатом,
Internet Explorer будет выдавать окно, представленное на рисунке
9. В отличие от диалога, представленного на рисунке 5, в этом окне
фигурирует фраза о том, что тестовый сертификат не может быть распознан
как Trusted Root (хотя мы и генерировали его как Trusted Root). На самом
деле это никак не скажется на работе приложения, и если вы выберете Yes,
вся функциональность, требующая подписанного контекста, будет доступна.
Если вас сильно смущает эта фраза (например, демо-версию нужно показать
заказчику, и она должна быть <как живая>), то ее можно избежать. Для
этого в Internet Client SDK имеется утилита setreg. С ее помощью можно
заставить Internet Explorer доверять тестовому сертификату. Выполните
следующую команду: И никаких смущающих глаз предупреждений вы больше не получите. 5. И напоследок... Использование различного рода сертификатов в среде Internet будет
неустанно расти. В этом сомнений нет (ведь <популярность> паспортов
или водительских прав, вряд ли кто-то станет оспаривать). И это совсем не
дань моде, а, скорее, выстраданная необходимость. В связи с этим, к
грядущей волне работы (которую, скорее всего, придется выполнять именно
нам - разработчикам программного обеспечения) нужно быть готовыми. И я,
как автор, искренне надеюсь, что данная статья была не бесполезной для
читателей. |
