Идентификация и аутентификация. Протокол Kerberos

Расширения могут определять следующие дополнительные параметры:

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

Предположим, что ключевые пары сгенерированы, открытые ключи заверены сертификатами и размещены в каталоге, реализованном с помощью web-сервера, ftp-сервера, службы каталога или другой технологии. Теперь, если абонент A желает проверить подпись абонента B под полученным сообщением (или зашифровать для B сообщение с помощью его открытого ключа и т.д.), он выполняет следующие действия [21]:

1. запрашивает в сетевом справочнике сертификат C_B открытого ключа подписи (шифрования,...) абонента B ;
2. проверяет достоверность сертификата C_B (см. ниже);
3. в случае успеха проверяет подпись под сообщением (зашифровывает сообщение,...) с помощью открытого ключа, извлеченного из C_B.

Процедура проверки достоверности сертификата C_B состоит в следующем:

1. проверяется срок действия сертификата C_B, если он закончился, сертификат считается недостоверным;
2. из C_B извлекается имя ЦС, подписавшего этот сертификат, обозначим его D ;
3. если D=B, то сертификат самоподписанный, он считается достоверным только, если D=ROOT (хотя, возможно, в некоторых сетях право выдавать самоподписанные сертификаты имеет не один ROOT, это - политика сети);
4. если же , то из справочника запрашивается сертификат C_D открытого ключа подписи абонента D, проверяется на достоверность сертификат C_D ;
5. в случае отрицательного ответа принимается решение о недостоверности сертификата C_B, иначе из C_D извлекается открытый ключ K_D ;
6. с помощью K_D проверяется подпись под сертификатом C_B, по результатам проверки этой подписи судят о достоверности C_B.

Если ключи шифрования досрочно вышли из обращения (причины могут быть различны - пользователь увольняется из компании, секретный ключ скомпрометирован и т.д.), центр сертификации извещает об этом остальных пользователей сети путем выпуска списка отозванных сертификатов (англ. Certificate Revocation List, сокр. CRL). Структура CRL представлена на рис. 5.7.

Рис. 5.7. Структура списка отозванных сертификатов

Поля списка содержат следующую информацию:

• Номер версии определяет номер версии формата CRL. Текущая используемая версия - вторая.
• Алгоритм подписи - идентификатор алгоритма, с помощью которого подписан CRL. Должен совпадать по значению с полем Алгоритм ЭЦП.
• Изготовитель - имя центра сертификации в формате RDN.
• Выпущен - дата выпуска CRL.
• Следующий - дата, до которой будет выпущен следующий CRL.
• Расширения - описывают центр сертификации, точку для поиска CRL данного центра, номер данного списка и т.д.
• Отозванный сертификат - таких полей будет столько, сколько сертификатов отзывается - содержит номер отзываемого сертификата, дату, с которой сертификат отозван, описание причины отзыва.
• Алгоритм ЭЦП - идентификатор алгоритма ЭЦП, используемого для подписи списка.
• ЭЦП - сама электронная цифровая подпись.

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

Другая проблема PKI - самоподписанные сертификаты. Сертификат ROOT должен раздаваться всем абонентам сети в начале работы и сохраняться в защищенном от подделки хранилище. Иначе нарушитель может попробовать навязать свой сертификат в качестве сертификата корневого центра.

Мы рассмотрели случай реализации иерархической модели PKI, при которой центры сертификации организованы в древовидную структуру с корневым центром сертификации на верху иерархии. На практике также встречаются другие варианты организации:

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

Надо отметить, что сфера применения цифровых сертификатов сейчас достаточно широка. В частности, они используются для распределения открытых ключей в протоколах защиты электронной почты S/MIME или PGP, с помощью цифровых сертификатов проверяется подлинность участников соединения по протоколу SSL и т.д.

Начиная с Windows 2000 Server в состав серверных ОС Microsoft входит программное обеспечение для создания центров сертификации. Создание корпоративного ЦС может понадобиться, если принято решение использовать защиту электронной почты с помощью S/MIME, шифрование данных при хранении средствами EFS (EFS - Encrypted File System - реализует шифрование данных на дисках с файловой системой NTFS), шифрование сетевого трафика с помощью протокола IPSec.

Различные практические аспекты использования цифровых сертификатов рассматриваются в лабораторных работах № 6 и 7. Первая из них посвящена работе с сертификатами с точки зрения конечного пользователя (в том числе, получение сертификата для защиты электронной почты с помощью S/MIME), а вторая - созданию и администрированию центра сертификации. Вопросы использования EFS рассматриваются в работе № 8.

Протокол защиты электронной почты S/MIME

Протокол Secure Multipurpose Internet Mail Extensions (S/MIME) предназначен для защиты данных, передаваемых в формате MIME, в основном - электронной почты. Он был предложен в 1995 году компанией RSA Data Security Inc. Дальнейшие работы над протоколом велись рабочей группой организации Internet Engineering Task Force (IETF), разрабатывающей стандарты сети Интернет. На данный момент, последней является версия 3.1 этого протокола, описываемая в документах RFC 3850, 3851, 3852. S/MIME предоставляет следующие криптографические услуги безопасности (криптографические сервисы):

• проверка целостности сообщения;
• установление подлинности отправителя (аутентификация);
• обеспечение секретности передаваемых данных (шифрование).

Нужно отметить, что сам по себе MIME описывает порядок форматирования писем, содержащих различные типы данных (обычный текст, текст в формате html, видео и графические файлы различный типов и т.д.). S/MIME добавляет свои типы (например, application/pkcs7-mime и application/pkcs7-signature), что позволяет указать на то, что данные в этом разделе являются зашифрованными, подписанными и т.д. Протокол позволяет обычным почтовым клиентам защищать исходящую почту и интерпретировать криптографические сервисы, добавленные во входящую почту (расшифровывать сообщения, проверять их целостность и т.д.).

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

S/MIME позволяет использовать различные криптоалгоритмы, причем их список может расширяться. Изначально, из симметричных шифров могли использоваться RC2, DES или TripleDES. Для формирования дайджестов - алгоритмы MD5 и SHA1, причем версия 3 стандарта рекомендует использовать именно последний алгоритм (из-за того, что он формирует более длинный дайджест и считается более надежным). Защита симметричного ключа шифрования и ЭЦП в версии 2 осуществляется с помощью алгоритма RSA с ключом от 512 до 1024 бит. Версия 3 добавляет возможность использовать другие алгоритмы, например алгоритм Диффи-Хеллмана с ключом длиной до 2048 бит. Распределение и аутентификация открытых ключей производится с помощью цифровых сертификатов формата X.509. Таким образом, чтобы защищать переписку с помощью этого протокола оба абонента должны сгенерировать ключевые пары и удостоверить открытые ключи с помощью сертификатов. На рис. 5.8 приведен фрагмент письма, содержащий открытый текст "This is a clear-signed message." и подпись к нему.

S/MIME поддерживается многими почтовыми клиентами: Microsoft Outlook (получение сертификата и настройка рассматривается в лабораторной работе 6), Mozilla, The Bat! и т.д. Более широкое применение протокола сдерживается необходимостью наличия сертификатов у абонентов и плохой совместимостью с системами Web-почты.

Рис. 5.8. Фрагмент электронного письма с подписью