Артём Санников

Многие протоколы и приложения, которые пользуются услугами Интернет, применяют в целях безопасности технологию общих ключей. Для безопасного управления общими ключами в среде широкораспределенных пользователей или систем им необходим PKI. Стандарт X.509 — представляет собой весьма популярную основу для подобной инфраструктуры. Он определяет форматы данных и процедуры распределения общих ключей с помощью сертификатов с цифровыми подписями, которые проставляются сертификационными органами (CA). RFC 1422 создает основу для PKI на базе X.509, что позволяет удовлетворить потребности электронной почты с повышенным уровнем защищенности, передаваемой через Интернет (PEM). С момента появления RFC 1422 требования приложений к PKI для сети Интернет резко выросли. Столь же резко возросли и возможности X.509. Предстоит большая работа по поддержке цифровых сертификатов в web приложениях, а также в приложениях электронной почты и приложениях IPSec. В действующих стандартах определен сертификат X.509 версия 3 и список отзыва сертификатов (CRL) версия 2.

Для технологии общих ключей необходимо, чтобы пользователь общего ключа был уверен, что этот ключ принадлежит именно тому удаленному субъекту (пользователю или системе), который будет использовать средства шифрования или цифровой подписи. Такую уверенность дают сертификаты общих ключей, то есть структуры данных, которые связывают величины общих ключей с субъектами. Эта связь достигается цифровой подписью доверенного CA под каждым сертификатом. Сертификат имеет ограниченный срок действия, указанный в его подписанном содержании. Поскольку пользователь сертификата может самостоятельно проверить его подпись и срок действия, сертификаты могут распространяться через незащищенные каналы связи и серверные системы, а также храниться в кэш-памяти незащищенных пользовательских систем. Содержание сертификата должно быть одинаковым в пределах всего PKI. В настоящее время в этой области предлагается общий стандарт для Интернет с использованием формата X.509 v3 (см. рисунок 28).

Каждый сертификат состоит из трех основных полей: текста сертификата, алгоритма подписи и самой подписи. В тексте сертификата указывается номер версии, серийный номер, имена эмитента и субъекта, общий ключ для субъекта, срок действия (дата и время начала и окончания действия сертификата). Иногда в этом тексте содержится дополнительная опционная информация, которую помещают в уникальные поля, связывающие пользователей или общие ключи с дополнительными атрибутами. Алгоритм подписи – это алгоритм, который использует CA для подписи сертификата. Подпись создается пропусканием текста сертификата через одностороннюю хэш-функцию. Величина, получаемая на выходе хэш-функции, зашифровывается частным ключом CA. Результат этого шифрования и является цифровой подписью (см. рисунок 29).

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

CRL представляет собой список отозванных сертификатов с указанием времени. Он подписывается CA и свободно распространяется через общедоступный репозиторий. В списке CRL каждый отозванный сертификат опознается по своему серийному номеру. Когда у какой-то системы возникает необходимость в использовании сертификата (например, для проверки цифровой подписи удаленного пользователя), эта система не только проверяет подпись сертификата и срок его действия, но и просматривает последний из доступных списков CRL, проверяя, не отозван ли этот сертификат. Значение термина «последний из доступных» зависит от местной политики в области безопасности, но обычно здесь имеется в виду самый последний список CRL. CA составляет новые списки CRL на регулярной основе с определенной периодичностью (например, каждый час, каждый день или каждую неделю). Отозванные сертификаты немедленно вносятся в список CRL. Записи об отозванных сертификатах удаляются из списка в момент истечения официального срока действия сертификатов. На рисунке 30 показан пример связи между системами и единым CA при помощи цифровых сертификатов.

Оба маршрутизатора и CA имеют свои пары общих/частных ключей. Вначале CA должен передать обоим маршрутизаторам по защищенным каналам сертификат X.509 v3. Кроме того, оба маршрутизатора должны получить по защищенным каналам копию общего ключа CA. После этого, если маршрутизатор в Нью-Йорке имеет трафик для отправки парижскому маршрутизатору и хочет передать этот трафик аутентичным и конфиденциальным способом, он должен предпринять следующие шаги:

1. Маршрутизатор в Нью-Йорке направляет запрос в CA для получения общего ключа парижского маршрутизатора.
2. CA отправляет ему сертификат парижского маршрутизатора, подписанный своим частным ключом.
3. Маршрутизатор в Нью-Йорке проверяет подпись общим ключом CA и убеждается в аутентичности общего ключа парижского маршрутизатора.
4. Парижский маршрутизатор направляет запрос в CA для получения общего ключа нью-йоркского маршрутизатора.
5. CA отправляет ему сертификат нью-йоркского маршрутизатора, подписанный своим частным ключом.
6. Парижский маршрутизатор проверяет подпись общим ключом CA и убеждается в аутентичности общего ключа нью-йоркского маршрутизатора.

Теперь, когда оба маршрутизатора обменялись своими общими ключами, они могут пользоваться средствами шифрования и с помощью общих ключей отправлять друг другу аутентичные конфиденциальные данные. Для получения общего секретного ключа обычно используется метод Диффи-Хеллмана, поскольку общий секретный ключ, как правило, применяется для шифрования больших объемов данных.

Предстоит большая работа по созданию эффективной инфраструктуры обращения общих ключей в среде Интернет и в корпоративной среде. Еще не решены вопросы ввода в действие новых сертификатов (как регистрировать новый сертификат в CA?), распределения сертификатов через какую-то службу директорий (рассматривается возможность использования для этой цели FTP или Lightweight Directory Access Protocol [LDAP] ) и перекрестной сертификации сертификатов (управления иерархией сертификатов).

Источник: Решения компании Cisco Systems по обеспечению безопасности корпоративных сетей

Метки: Cisco, Cisco Security, X.509.