Ольга Полянская - Инфраструктуры открытых ключей

Приложения электронной почты и обмена сообщениями используют пары ключей для шифрования сообщений и файлов и заверения их цифровыми подписями. Системы электронного обмена данными поддерживают транзакции, требующие аутентификации сторон, обеспечения конфиденциальности и целостности данных. Браузеры и web-серверы используют шифрование для аутентификации, обеспечения конфиденциальности, а также в приложениях электронной коммерции и онлайнового предоставления банковских услуг. Шифрование и аутентификация применяются также для создания виртуальных частных сетей (Virtual Private Networks - VPN) на основе сетей общего пользования, для защиты коммуникаций между сайтами или удаленного доступа (клиент-сервер). Заверение цифровой подписью программных кодов и файлов дает возможность пользователям подтвердить источник получаемых по Интернету программ и файлов и целостность их содержания, это важно и для контроля вирусного заражения.

Как известно, технология "клиент-сервер" предполагает обслуживание клиента только по его запросу, тот же самый принцип справедлив и для PKI. Клиентское программное обеспечение (ПО) пользователя должно запрашивать сервисы сертификации и обрабатывать информацию об аннулированных сертификатах, понимать истории ключей и отслеживать своевременное обновление или восстановление ключей, анализировать необходимость проставления меток времени. Клиентскому ПО необходимо распознавать идентификаторы политики применения сертификатов, вовремя определять статус сертификата и правильно выполнять обработку пути сертификации (см. лекцию 11).

Клиентское ПО - существенный компонент полнофункциональной PKI. Важно отметить, что клиентское ПО не является ни программным обеспечением приложения, ни PKI-совместимым кодом, который размещается внутри приложения, подобного браузеру или приложению электронной почты. Такая архитектура фундаментально нарушала бы концепцию PKI как инфраструктуры, согласованно обеспечивающей безопасность всем использующим ее приложениям и платформам. Наоборот, клиентское ПО - это код, который существует вне любых приложений и реализует необходимую клиентскую сторону PKI. Приложения связываются с клиентским ПО через стандартные точки входа, им не приходится самостоятельно взаимодействовать с разными серверами PKI. Таким образом, приложения используют инфраструктуру, а не являются частью инфраструктуры [44].

Компонент клиентской стороны PKI может быть:

* относительно большим ("толстый" клиент), выполняющим большую часть операционной работы PKI, в том числе обработку путей сертификации и валидацию;

* относительно небольшим ("тонкий" клиент), просто вызывающим внешние серверы для выполнения PKI-функций;

* Java-апплетом или аналогичным мобильным кодом, при необходимости загружаемым в режиме реального времени, а затем удаляемым после завершения работы вызывающего приложения (подобного web-браузеру);

* динамически подключаемой библиотекой (Dynamically Linked Library - DLL) или аналогичной, которая размещается резидентно на клиентской платформе.

Существует много возможностей реализации и вызова клиентского ПО, но главным требованием является независимость этого компонента от приложений, использующих PKI.

Каждый компонент, чтобы быть частью PKI, должен удовлетворять критерию безопасности. Этот критерий характеризует необходимый для целей бизнеса уровень защищенности в пределах допустимого уровня риска [10]. Механизмы безопасности, обеспечивающие заданный уровень защищенности, обычно подразделяют на механизмы защиты аппаратных средств, компьютерной платформы, сети и приложений. PKI-совместимые приложения не позволяют обеспечить полную безопасность корпоративной сети и должны быть дополнены другими средствами защиты, например, межсетевыми экранами, сервисами аутентифицируемых имен (службами имен) и строгим контролем администратора сети.

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

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

Этот сервис заключается в генерации хэш-кода сообщения и подписи его цифровым образом.

Посредством этого сервиса устанавливается подлинность сообщения и соответствующей ему цифровой подписи.

Сертификаты выпускаются УЦ для пользователей (физических и юридических лиц), для подчиненных ему удостоверяющих центров, а также для удостоверяющих центров сторонних PKI в случае кросс-сертификации.

Концепция единой глобальной PKI, объединяющей всех пользователей в мире, вряд ли воплотится в жизнь в ближайшее время. Скорее всего, сохранится сегодняшняя модель, когда существуют многие независимо реализованные и функционирующие PKI, которые обслуживают разные среды и сообщества пользователей. Однако с течением времени неизбежно возникает необходимость в объединении, по крайней мере, некоторых инфраструктур из этого множества независимо реализованных PKI. Изменение деловых связей или другие причины вызывают потребность в защищенных коммуникациях между сообществами пользователей разных PKI, даже если раньше защищенная связь между ними не была нужна.

Концепция кросс-сертификации возникла в связи с необходимостью формировать отношения доверия между ранее не связанными реализациями PKI. В отсутствии глобальной PKI кросс-сертификация служит общепринятым механизмом, позволяющим пользователям одного PKI-сообщества полагаться на сертификаты другого PKI-сообщества. В деловой среде в результате слияния, приобретения новых компаний, сотрудничества с новыми партнерами появляется потребность в установлении связей между различными PKI. Без механизма однородного и контролируемого связывания разных инфраструктур в среде могут возникнуть проблемы с разрушительными последствиями, такие как, например, аннулирование всех сертификатов приобретаемой компании или выпуск новых сертификатов для приобретающей компании. Кросс-сертификация отвечает важным требованиям бизнеса к безопасности взаимного связывания разнородных PKI.

Если секретный ключ пользователя потерян, похищен или скомпрометирован, либо существует вероятность наступления таких событий, действие сертификата должно быть прекращено. После получения подтверждения запроса пользователя об аннулировании сертификата УЦ уведомляет об аннулировании все заинтересованные стороны, используя список аннулированных сертификатов (САС).

УЦ заверяет цифровой подписью сертификат, связывающий открытый ключ с идентичностью пользователя. Однако события реального мира часто разрушают эту связь: идентификационные данные субъекта могут измениться, например, при заключении брака (девичья фамилия заменяется фамилией супруга) или при хищении его секретного ключа злоумышленником. Появляется необходимость в предупреждении остального сообщества пользователей о недопустимости использования данного ключа для данной идентичности. Этот механизм предупреждения в терминах PKI называется аннулированием сертификатов.

Пример 3.1. В качестве примера можно привести следующую аналогию аннулирования сертификатов. Водительские права - это один из видов сертификатов, который связывает идентичность (имя и фотографию) с номером водительских прав (то есть разрешением на вождение) и выдается доверенным центром (автоинспекцией). Когда инспектор останавливает машину, то он не просто проверяет, на какой срок выданы права, но также может связаться с доверенным центром, чтобы выяснить, не были ли права аннулированы. Проверка на предмет аннулирования необходима, потому что иногда связь "идентичность-разрешение" в непросроченных правах не является надежной [10].