Информационная безопасность. Лекция 16: Протоколы безопасности
Многие протоколы и приложения, которые пользуются услугами Интернет, применяют в целях безопасности технологию общих ключей. Для безопасного управления общими ключами в среде широкораспределенных пользователей или систем им необходим PKI. Стандарт Х.509 определяет форматы данных и процедуры распределения общих ключей с помощью сертификатов с цифровыми подписями, которые проставляются сертификационными органами (СА). RFC 1422 создает основу для PKI на базе Х.509, что позволяет удовлетворить потребности электронной почты с повышенным уровнем защищенности, передаваемой через Интернет (РЕМ). В действующих стандартах определен сертификат Х.509 версии 3 и список отзыва сертификатов (CRL) версии 2.
Для технологии общих ключей необходимо, чтобы пользователь общего ключа был уверен, что этот ключ принадлежит именно тому удаленному субъекту (пользователю или системе), который будет использовать средства шифрования или цифровой подписи. Такую уверенность дают сертификаты общих ключей, то есть структуры данных, которые связывают величины общих ключей с субъектами. Эта связь достигается цифровой подписью доверенного СА под каждым сертификатом. Сертификат имеет ограниченный срок действия, указанный в его подписанном содержании. Поскольку пользователь сертификата может самостоятельно проверить его подпись и срок действия, сертификаты могут распространяться через незащищенные каналы связи и серверные системы, а также храниться в кэш-памяти незащищенных пользовательских систем. Содержание сертификата должно быть одинаковым в пределах всего PKI. В настоящее время в этой области предлагается общий стандарт для Интернет с использованием формата Х.509 v3 (рис.6).
Рис.6. Формат сертификата X.509 v3.
Каждый сертификат состоит из трех основных полей: текста сертификата, алгоритма подписи и самой подписи. В тексте сертификата указывается номер версии, серийный номер, имена эмитента и субъекта, общий ключ для субъекта, срок действия (дата и время начала и окончания действия сертификата). Иногда в этом тексте содержится дополнительная опционная информация, которую помещают в уникальные поля, связывающие пользователей или общие ключи с дополнительными атрибутами. Алгоритм подписи — это алгоритм, который использует СА для подписи сертификата. Подпись создается пропусканием текста сертификата через одностороннюю хэш-функцию. Величина, получаемая на выходе хэш-функции, зашифровывается частным ключом СА. Результат этого шифрования и является цифровой подписью (рис.7).
Рис.7. Создание цифровой подписи для сертификата X.509 v3.
При выдаче сертификата подразумевается, что он будет действовать в течение всего указанного срока. Однако могут возникнуть обстоятельства, требующие досрочного прекращения действия сертификата. Эти обстоятельства могут быть связаны с изменением имени, изменением ассоциации между субъектом и СА (если, например, сотрудник уходит из организации), а также с раскрытием или угрозой раскрытия соответствующего частного ключа. В этих случаях СА должен отозвать сертификат.
CRL представляет собой список отозванных сертификатов с указанием времени. Он подписывается СА и свободно распространяется через общедоступный репозиторий. В списке CRL каждый отозванный сертификат опознается по своему серийному номеру. Когда у какой-то системы возникает необходимость в использовании сертификата (например, для проверки цифровой подписи удаленного пользователя), эта система не только проверяет подпись сертификата и срок действия, но и просматривает последний из доступных списков CRL, проверяя, не отозван ли этот сертификат. Значение термина «последний из доступных» зависит от местной политики в области безопасности, но обычно здесь имеется в виду самый последний список CRL. СА составляет новые списки CRL на регулярной основе с определенной периодичностью (например, каждый час, каждый день или каждую неделю). Отозванные сертификаты немедленно вносятся в список CRL. Записи об отозванных сертификатах удаляются из списка в момент истечения официального срока действия сертификатов.
На рисунке 8 показан пример связи между системами и единым СА при помощи цифровых сертификатов.
 |
Рис.8. Передача цифрового сертификата.
Оба маршрутизатора и СА имеют свои пары общих/частных ключей. Вначале СА должен передать обоим маршрутизаторам по защищенным каналам сертификат Х.509 v3. Кроме того, оба маршрутизатора должны получить по защищенным каналам копию общего ключа СА. После этого, если маршрутизатор 1 имеет трафик для отправки маршрутизатору 2 и хочет передать этот трафик аутентичным и конфиденциальным способом, он должен предпринять следующие шаги:
1. Маршрутизатор 1 направляет запрос в СА для получения общего ключа маршрутизатора 2.
2. СА отправляет ему сертификат маршрутизатора 2, подписанный своим частным ключом.
3. Маршрутизатор 1 проверяет подпись общим ключом СА и убеждается в аутентичности общего ключа маршрутизатора 2.
4. Маршрутизатор 2 направляет запрос в СА для получения общего ключа маршрутизатора 1.
5. СА отправляет ему сертификат маршрутизатора 1, подписанный своим частным ключом.
6. Маршрутизатор 2 проверяет подпись общим ключом СА и убеждается в аутентичности общего ключа маршрутизатора 1.
Теперь, когда оба маршрутизатора обменялись своими общими ключами, они могут пользоваться средствами шифрования и с помощью общих ключей отправлять друг другу аутентичные конфиденциальные данные. Для получения общего секретного ключа обычно используется метод Диффи-Хеллмана, поскольку общий секретный ключ, как правило, применяется для шифрования больших объемов данных.
