Инфраструктура открытых ключей. цифровые сертификаты

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

Но возникает другая проблема – как убедиться в том, что имеющийся у Вас открытый ключ другого абонента на самом деле принадлежит ему. Иными словами, возникает проблема аутентификации ключа. Без этого, на криптографический протокол может быть осуществлена атака типа «человек посередине» (англ. «man in the middle»).

Избежать подобной атаки можно, подтвердив подлинность используемого ключа. Но Алиса и Боб лично никогда не встречались, и передать, например, дискету с ключом из рук в руки не могут. Поэтому, решение задачи подтверждения подлинности берет на себя третья доверенная сторона – некий арбитр, которому доверяют оба абонента. Заверяется ключ с помощью цифрового сертификата.

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

Но вернемся к цифровым сертификатам. Для подтверждения подлинности открытых ключей создается инфраструктура открытых ключей (англ. «Public Key Infrastructure», сокр. PKI).

В приведенном примере, CA_1 заверяет электронной подписью сертификаты подчиненных центров сертификации CA_2 и CA_3, а те, в свою очередь, подписывают сертификаты пользователей и центров более низкого уровня.

Перейдем к рассмотрению самих сертификатов. Наибольшее распространение получили цифровые сертификаты, формат которых определен стандартом X.509. На данный момент, принята третья версия стандарта. Формат сертификата изображен на рисунке 2.12 [11]

Номер версии содержит числовое значение,соответствующееномеру версии (для сертификата версии 1 равен 0 и т. д.). В первой версии X.509 не было уникальных номеров («ID Изготовителя», «ID Субъекта») и полей расширения. Во второй версии добавились указанные идентификаторы, в третьей – расширения.

Серийный номер –уникальный номер,присваиваемый каждомусертификату.

Алгоритм подписи –идентификатор алгоритма,используемогопри подписании сертификата. Должен совпадать с полем Алгоритм ЭЦП.

Изготовитель -имя центра сертификации, выдавшего сертификат. Записывается в формате Relative Distinguished Name - RDN(варианты перевода названия – «относительное отдельное имя», «от-носительное характерное имя»).. CN (англ. «Common Name») – общее имя; OU (англ. «Organization Unit») – организационная единица; DC (англ. «Domain Component») –

N = Microsoft Root Authority,

OU = Microsoft Corporation,

OU = Copyright (c) 1997 Microsoft Corp.

Рисунок 2.12 - Сертификат формата X.509 v.3

Субъект –имя владельца сертификата,представленное в том жеформате RDN. Для указанного в предыдущем примере сертификата значения данного поля:

CN = Microsoft Windows Hardware Compatibility, OU = Microsoft Corporation,

OU = Microsoft Windows Hardware Compatibility Intermediate CA, OU = Copyright (c) 1997 Microsoft Corp.

Период действия –описывает временной интервал,в течениекоторого центр сертификации гарантирует отслеживание статуса сертификата (сообщит абонентам сети о факте досрочного отзыва сертификата и т. д.). Период задается датами начала и окончания действия.

Открытый ключ –составное поле,содержащее идентификаторалгоритма, для которого предназначается данный открытый ключ, и собственно сам открытый ключ в виде набора битов.

ID Изготовителя и ID Субъекта содержат уникальные идентификаторы центра сертификации и пользователя (на случай совпадения имен различных CA или пользователей).

Расширения –дополнительный атрибут,связанный с субъектом,изготовителем или открытым ключом, и предназначенный для управления процессами сертификации. Более подробно он описан ниже.

Алгоритм электронной цифровой подписи (ЭЦП) –идентификатор алгоритма, используемый для подписи сертификата. Должен совпадать со значением поля Алгоритм подписи.

ЭЦП –само значение электронно-цифровой подписи для данного сертификата.

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

- идентификатор пары открытый/секретный ключ центра сертификации (изготовителя), если центр имеет несколько различных ключей для подписи сертификатов;

- идентификатор конкретного ключа пользователя (субъекта), если пользователь имеет несколько сертификатов;

назначение ключа, например, ключ для шифрования данных, проверки ЭЦП данных, для проверки ЭЦП сертификатов и т. д.;

уточнение периода использования – можно сократить время действия сертификата, указанное в поле Период действия (период, в течение которого статус сертификата отслеживается, станет больше, чем разрешенное время использования сертификата);

политики использования сертификата;

выбор соответствия политик использования сертификата для центра сертификации и пользователя, если имеются различные варианты;

альтернативное имя пользователя и центра сертификации;

указания, является ли пользователь сам центром сертификации

насколько глубоко разрешается разворачивать сертификационный путь.

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

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) если же D B, то из справочника запрашивается сертификат C_D открытого ключа подписи абонента D,проверяется на достоверность сертификат C_D;

5) в случае отрицательного ответа принимается решение о не-достоверности сертификата C_B, иначе из C_D извлекается открытый

ключ K_D;

6) с помощью K_D проверяется подпись под сертификатом C_B, по результатам проверки этой подписи судят о достоверности C_B.

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

Номер версии определяет номер версии форматаCRL.Текущаяиспользуемая версия – вторая.

Алгоритм подписи –идентификатор алгоритма,с помощью которого подписан CRL. Должен совпадать по значению с полем Алгоритм ЭЦП.

Изготовитель –имя центра сертификации в форматеRDN. Выпущен –дата выпускаCRL.

Следующий –дата,до которой будет выпущен следующийCRL. Расширения –описывают центр сертификации,точку для поиска

CRL данного центра, номер данного списка и т. д.

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

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

Алгоритм ЭЦП –идентификатор алгоритма ЭЦП,используемого для подписи списка.

ЭЦП –сама электронная цифровая подпись.

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

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

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

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

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

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