Книга: Инфраструктуры открытых ключей

Стандарты Internet X.509 PKI (PKIX)

Стандарты PKIX для описания инфраструктур используют сходные понятия " инфраструктура открытых ключей PKI " и " инфраструктура управления привилегиями PMI " (Privilege Management Infrastructure). Главное отличие между ними заключается в том, что PKI управляет сертификатами открытых ключей, а PMI - атрибутными сертификатами. Сертификат открытого ключа можно сравнить с паспортом субъекта, а атрибутный сертификат - с визой, первый обеспечивает идентификацию личности, а второй дает определенное разрешение. Основные термины и аббревиатуры, используемые в стандартах PKIX, а также их аналоги на русском языке приведены в табл. 15.5.

Системы, использующие сертификаты, и PKI

Результатом усилий технических специалистов по повышению безопасности Интернета стала разработка группы протоколов безопасности, таких как S/MIME, TLS и IPsec. Все эти протоколы используют криптографию с открытыми ключами для обеспечения сервисов конфиденциальности, целостности данных, аутентификации источника данных и неотказуемости.

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

|Термин на английском языке | Аббревиатура | Термин на русском языке |

|Attribute Authority | AA | Атрибутный центр |

|Attribute Certificate | AC | Атрибутный сертификат |

|Certificate | | Сертификат |

|Certification Authority | CA | Удостоверяющий центр (УЦ) |

|Certificate Policy | CP | Политика применения сертификатов (ППС) |

|Certification Practice Statement | CPS | Регламент УЦ |

|End-Entity | EE | Конечный субъект |

|Public Key Certificate | PKC | Сертификат открытого ключа |

|Public Key Infrastructure | PKI | Инфраструктура открытых ключей |

|Privilege Management Infrastructure | PMI | Инфраструктура управления привилегиями |

|Registration Authority | RA | Регистрационный центр (РЦ) |

|Relying Party | | Доверяющая сторона |

|Root CA | | Корневой УЦ |

|Subordinate CA | | Подчиненный УЦ |

|Subject | | Субъект |

|Top CA | | УЦ верхнего уровня |

Таблица 15.5.Термины PKIX

Согласно стандартам PKIX, PKI представляет собой комплекс программного и аппаратного обеспечения, персонала, а также политик и процедур, необходимых для создания, управления, хранения, распространения и аннулирования сертификатов открытых ключей. Компоненты PKI представлены в табл. 15.6. Сертификат открытого ключа имеет ограниченный период действия, который зафиксирован в содержании сертификата. Поскольку клиент должен иметь возможность самостоятельно проверить подпись сертификата открытого ключа и его срок действия, сертификаты должны открыто публиковаться и распространяться посредством даже ненадежных коммуникаций и систем серверов.

|Компонент | Описание |

|Удостоверяющие центры (УЦ) | Выпускают и аннулируют сертификаты |

|Регистрационные центры (РЦ) | Подтверждают связывание открытых ключей и личностей владельцев сертификатов и других атрибутов |

|Владельцы сертификатов | Подписывают и шифруют электронные документы |

|Клиенты | Проверяют подлинность цифровых подписей и соответствующих цепочек сертификатов при помощи открытого ключа доверенного УЦ |

|Репозитории | Хранят и предоставляют информацию о сертификатах и списках САС |

Таблица 15.6.Компоненты PKI

Сертификаты открытых ключей используются в процессе валидации (подтверждения) заверенных цифровой подписью данных, когда получатель проверяет, чтобы:

1 информация, идентифицирующая отправителя, соответствовала данным, содержащимся в сертификате;

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

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

4 данные не были изменены с момента создания ЭЦП.

После валидации получатель может принять данные, подписанные отправителем.

Общая схема функционирования PKI представлена на рис. 15.2. Конечный субъект отправляет запрос на сертификат в РЦ (транзакция управления). Если запрос фактически одобрен, то направляется непосредственно в УЦ для заверения цифровой подписью. УЦ проверяет запрос на сертификат, и если тот проходит верификацию, то подписывается и выпускается сертификат. Сертификат публикуется в репозитории; в зависимости от конкретной конфигурации PKI, эта функция может быть возложена на регистрационный или удостоверяющий центр.

На рис. 15.2 показаны все возможные коммуникации между конечным субъектом и УЦ. Процесс аннулирования сертификата аналогичен процессу его генерации. Конечный субъект запрашивает УЦ об аннулировании своего сертификата, РЦ принимает решение и направляет запрос об аннулировании в УЦ. УЦ вносит изменения в список аннулированных сертификатов и публикует его в репозитории. Конечные субъекты могут проверить статус конкретного сертификата через операционный протокол.

Рис. 15.2.  Схема функционирования PKI

Операционные протоколы - это протоколы для доставки сертификатов (или информации об их статусе) и списков аннулированных сертификатов к клиентским системам, использующим сертификаты. Существуют разнообразные механизмы распространения сертификатов и САС с использованием протоколов LDAP, HTTP и FTP. Например, поиск САС для проверки статуса сертификата осуществляет операционный протокол.

Протоколы управления необходимы для поддержки взаимодействий в онлайновом режиме между пользователем PKI и субъектами управления.

Протоколы управления поддерживают:

1 регистрацию субъекта для получения сертификата;

2 инициализацию (например, генерации пары ключей);

3 выпуск сертификата;

4 восстановление пары ключей;

5 обновление пары ключей по истечении срока действия сертификата;

6 обращение с запросом об аннулировании сертификата;

7 кросс-сертификацию, когда два удостоверяющих центра обмениваются информацией для генерации кросс-сертификата.

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

Системы, использующие сертификаты, и PMI

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

Для некоторых систем этого бывает достаточно, тем не менее часто появляется потребность управлять доступом на основе определенных принципов, ролей или должностей. Тогда для принятия решений по управлению доступом требуется дополнительная информация, которая обычно не включается в сертификат, так как период жизни подобной информации бывает намного меньше срока действия пары ключей. Атрибутный сертификат (АС) используется для связывания такой информации с сертификатом.

Формат атрибутного сертификата позволяет связать любую дополнительную информацию о владельце с сертификатом открытого ключа, включая в структуру данных, заверенных цифровой подписью, ссылку на один или несколько сертификатов открытых ключей одного и того же субъекта. Атрибутный сертификат может иметь несколько назначений (например, предназначаться для доступа к web-серверу и хосту электронной почты).

Согласно стандартам PKIX, PMI представляет собой комплекс программного и аппаратного обеспечения, кадров, а также политик и процедур, необходимых для создания, управления, хранения и аннулирования атрибутных сертификатов. Компоненты PMI представлены в табл. 15.7.

|Компонент | Описание |

|Атрибутные центры (АЦ) | Издатели атрибутных сертификатов. Выпускают и аннулируют атрибутные сертификаты |

|Пользователи атрибутных сертификатов | Анализируют или обрабатывают атрибутные сертификаты (АС) |

|Верификаторы атрибутных сертификатов | Подписывают и шифруют электронные документы |

|Клиенты | Запрашивают действие, для которого должна быть сделана проверка авторизации |

|Репозиторий | Хранит и предоставляет информацию о сертификатах и САС |

Таблица 15.7.Компоненты PKI

Направления стандартизации

Группа PKIX IETF разрабатывает документы для следующих направлений стандартизации:

1 профили сертификатов и списков аннулированных сертификатов;

2 протоколы управления ;

3 операционные протоколы ;

4 политики применения сертификатов и регламенты;

5 сервисы проставления меток времени и сертификации/валидации данных.

К первому направлению относятся стандарты RFC 3280 >[167], RFC 3281 >[168], RFC 3039 >[164] и RFC 3279 >[166]. Стандарт RFC 3280 (бывший RFC 2459) Certificate & CRL Profile предлагает форматы сертификатов версии X.509 v3 и списка аннулированных сертификатов версии X.509 v2 для использования в Интернете, детализирует информацию, относящуюся к формам имен и стандартным дополнениям. Документ описывает алгоритм проверки цепочек сертификатов и форматы открытых ключей и электронной цифровой подписи для алгоритмов шифрования ключей RSA, DSA и Диффи-Хэллмана.

Стандарт RFC 3281An Internet Attribute Certificate Profile for Authorization определяет профильатрибутного сертификата для использования в Интернет-протоколах. Атрибутный сертификат подобен сертификату открытого ключа, но в отличие от него содержит не открытый ключ, а атрибуты, характеризующие его владельца: принадлежность к какой-либо группе, роль, полномочия, уровень прозрачности информации о владельце и т.п. Стандарт обеспечивает поддержку атрибутных сертификатов для электронной почты в Интернете, протокола IPsec, приложений безопасности World Wide Web.

Стандарт RFC 3039 Qualified Certificates Profile описывает формат сертификата ограниченного использования. Владельцем этого сертификата может быть только физическое лицо. Термин "ограниченное использование" трактуется в общепринятом для государственного права смысле. Пока стандарт определяет основной синтаксис сертификата ограниченного использования без учета особенностей законодательства разных стран.

Стандарт RFC 3279 Algorithms and Identifiers for the Internet X.509 Public Key In-frastructure Certificate and Certificate Revocation List (CRL) Profile определяет идентификаторы алгоритмов и форматы шифрования используемых в PKIX открытых ключей и цифровых подписей, односторонние хэш-функции для генерации ЭЦП сертификатов и САС. Стандарт описывает шифрование цифровых подписей, сгенерированных при помощи криптографических алгоритмов RSA, DSA и алгоритма эллиптических кривых (ECDSA), задает форматы шифрования открытых ключей, используемых в криптографических алгоритмах RSA, DSA, Диффи-Хеллмана и алгоритма шифрования ключей (KEA).

Второе направление представлено документами RFC 2510 >[150], RFC 2511 >[151], RFC 2560 >[155] и RFC 2797 >[160]. Стандарты RFC 2510 Certificate Management Protocols (CMP) и RFC2511 Certificate Request Protocol определяют соответственно сообщения протоколов для процессов создания и управления сертификатами и синтаксис запроса на выпуск сертификата формата X.509.

Стандарт RFC 2560 Online Certificate Status Protocol (OCSP) предлагает онлайновый протокол для определения статуса сертификата без использования САС. По замыслу разработчиков, этот протокол должен удовлетворять операционным требованиям более своевременного поступления информации об аннулировании, чем это возможно при помощи САС. Протокол управляет обменом данными между OCSP-клиентами, проверяющими статус сертификата, и OCSP-исполнителем, информирующим об этом статусе.

Стандарт RFC 2797 Certificate Management Messages over CMS определяет протокол управления сертификатами на основе сообщений управления сертификатами. Документ разрабатывался для решения двух важных проблем сообщества PKI в Интернете:

1 реализации интерфейса с продуктами и сервисами PKI, базирующимися на сообщениях управления сертификатами и стандарте синтаксиса запроса на сертификат - PKCS#10;

2 использования стандарта SMIME v3 в протоколе регистрации сертификатов открытых ключей (Диффи-Хеллмана), подписанных при помощи алгоритма DSA.

К третьему направлению можно отнести документы RFC 2559 >[154], RFC 2587 >[157] и RFC 2585 >[156].

Стандарт RFC 2559 LDAP V2 Operational Protocols закрепляет использование протокола LDAP v2 для обеспечения доступа к репозиторию с целью поиска сертификатов и другой релевантной PKI информации и управления ими.

Стандарт RFC 2587 LDAP V2 Schema описывает минимально необходимую схему поддержки PKIX в среде LDAP v2 (как этого требует документ RFC 2559) и определяет только специфические PKIX-компоненты. В соответствии с этим документом серверы LDAP, действующие как хранилища (репозитории) PKIX, должны поддерживать вспомогательные классы объектов, определенные данным стандартом, и интегрировать эту схему с общими и специфическими для приложений схемами в зависимости от сервисов, предоставляемых сервером.

Документ RFC 2585 HTTP/FTP Operations описывает применение протоколов HTTP/FTP для получения сертификатов и списков аннулированных сертификатов из репозитория УЦ.

Четвертое направление представлено одним базовым стандартом RFC 2527 Certificate Policy and Certification Practices Framework >[152], определяющим политику применения сертификатов и структуру регламента УЦ и подробно описанным в лекции 14.

К пятому направлению стандартизации относятся документы RFC 3029 >[163], RFC 2875 >[162], RFC 3161 >[165]. Стандарт RFC 3029 Data Validation and Certification Server Protocols вводит понятие сервера сертификации и проверки достоверности данных для обеспечения надежности сервисов неотказуемости и предлагает протоколы для взаимодействия с этим сервером. На сервер возлагаются функции доверенной третьей стороны, проверяющей подлинность сертификатов открытых ключей и документов с цифровой подписью.

Стандарт RFC 2875 Diffie-Hellman Proof-of-Possession (POP) Algorithms описывает два метода получения значения проверки целостности на основе пары ключей Диффи-Хэллмана. В документе предлагаются два алгоритма доказывания владения, использующие процесс согласования ключей Диффи-Хеллмана для получения разделенного секрета на основе значения проверки целостности. В первом алгоритме значение формируется для конкретного получателя/верификатора при помощи открытого ключа этого верификатора. Во втором алгоритме значение формируется для произвольного верификатора. Документ RFC 3161 Time-Stamp Protocol (TSP) описывает протокол проставления метки времени.

Оглавление книги