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

Стандарты 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

К числу наиболее известных национальных инициатив по обеспечению функциональной совместимости можно отнести инициативы США: Automotive Network eXchange, Bridge CA Demonstration, проект федеральной PKI, инициативу разработки спецификации минимальной функциональной совместимости MISPC, а также проект национальной ассоциации автоматизированных клиринговых палат США [44].

Automotive Network eXchange

В рамках инициативы Automotive Network eXchange (ANX) на основе технологии виртуальных частных сетей была спроектирована общая сеть компаний-производителей автомобилей для обеспечения защищенных коммуникаций между ними. В ходе реализации проекта был разработаны профили сертификатов и списков САС, которые включены как приложение в документ, названный политикой применения сертификатов ANX [94].

Bridge CA Demonstration

По инициативе правительства США в 1999-2001 гг. был реализован проект демонстрации мостового УЦ - Bridge CA Demonstration с целью показать возможности функциональной совместимости двух (или более) доменов PKI, основанных на разных моделях доверия. В ходе выполнения проекта была сделана попытка доказать, что один УЦ способен действовать как мост между несколькими доменами PKI. Деятельность по разработке профилей включала создание минимального профиля сертификата и САС, схемы каталога и профиля функциональной совместимости, были также утверждены процессы построения и валидации путей сертификации [210].

Федеральная PKI

В октябре 1994 г. федеральное правительство США создало техническую рабочую группу по PKI (PKI-TWG) для решения проблем реализации федеральной инфраструктуры открытых ключей (FPKI). Рабочая группа действовала под руководством национального института по стандартам и технологии США - National Institute of Standards and Technology (NIST) и состояла из представителей федеральных агентств. Она разработала профиль дополнений сертификата и САС федеральной инфраструктуры, названный Federal Public Key Infrastructure Certificate and CRL Extensions Profile [206].

Спецификация минимальной функциональной совместимости

В 1996 г. институт NIST совместно с рядом поставщиков продуктов, лидирующих на рынке PKI - AT&T, IREBBN, Motorola Certicom, Nortel (Entrust), Cylink, Spyrus, DynCorp и VeriSign, - выступил с инициативой разработки спецификации минимальной функциональной совместимости. Первая версия спецификации "Minimum Interoperability Specification for PKI components, Version 1" была опубликована в июне 1997 г. [51] и содержала ссылку на реализацию, пригодную для тестирования соответствия компонентов PKI профилю минимальной функциональной совместимости. Этот документ позволил сообществу поставщиков демонстрировать соответствие их PKI-продуктов требованиям профиля.

Работа над спецификацией продолжалась, и в августе 2001 г. была опубликована вторая версия документа, названная "Minimum Interoperability Specification for PKI components, Version 2 - Second Draft" [92]. Она объединяет некоторые работы группы IETF PKIX, опубликованные в 1998-2001 гг. (в частности, RFC 2459, RFC 2510 и RFC 2511), и дополняет первую версию положениями о поддержке сервисов конфиденциальности.

Проект национальной ассоциации автоматизированных клиринговых палат

Национальная ассоциация автоматизированных клиринговых палат США (National Automated Clearing House Association - NACHA) финансировала успешный проект функциональной совместимости удостоверяющих центров CA Interoperability Pilot, завершенный в октябре 1998 г. Участниками проекта были такие известные компании, как CertCo, Digital Signature Trust (DST), Entrust, GTE CyberTrust, IBM и VeriSign. В качестве базовой модели PKI в пилотном проекте была выбрана четырехсторонняя модель (см. лекцию 5), имитирующая приобретение товаров и услуг через Интернет. Посредниками сделок между покупателем и продавцом выступали банки каждой из сторон, которые действовали как самостоятельные удостоверяющие центры. Все решения относительно финансовых транзакций должны были инициироваться банками.

С технологической точки зрения, главной целью проекта была демонстрация пригодности PKI-продуктов многих поставщиков для реализации предложенной модели, поэтому банки-участники проекта использовали разные программные продукты для поддержки УЦ, предоставленные поставщиками технологии. В дальнейшем поставщики - участники проекта совместно работали над созданием профилей сертификата и САС, и тестирование функциональной совместимости выполнялось для этих профилей. Результаты этой работы были опубликованы в документе "Функциональная совместимость удостоверяющих центров: от концепции к реальности" [90].

Апробация концепции SIRCA

Апробация концепции головного УЦ отрасли средств безопасности Securities Industry Root CA (SIRCA) [110] выполнялась Ассоциацией отрасли средств безопасности США Securities Industry Association вместе с компаниями Digital Signature Trust (DST) и ABAecom. УЦ отрасли действовал как головной центр в двухуровневой иерархии и служил источником доверия для доверяющих сторон - фирм, занимающихся бизнесом в сфере средств безопасности. Каждая из двадцати фирм - участников проекта организовала свой УЦ, связанный с головным УЦ отрасли, а затем выпускала и подписывала цифровые сертификаты для своих служащих, для того чтобы они могли защищенно обмениваться сообщениями электронной почты с партнерами по бизнесу из других фирм.

Концепция SIRCA, аналогичная концепции мостового УЦ, по-своему реализовала установление отношений доверия между многими доменами PKI, которое, в противном случае, потребовало бы заключения двусторонних соглашений о кросс-сертификации каждого домена с каждым. В ходе апробации использовался относительно простой профиль сертификатов: приложение защищенной электронной почты S/MIME v2 профилировалось в том смысле, что выполнялось требование, чтобы в каждое заверенное цифровой подписью сообщение включался полный список сертификатов, необходимых для проверки пути сертификации.

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

PKI X.509

Как уже отмечалось выше, ведущим центром по выпуску согласованных стандартов в области PKI является рабочая группа PKIX организации IETF. Профиль сертификата и САС, который был описан в документе RFC 2459, известном как первая часть PKIX, стал предложенным стандартом в январе 1999 года, а затем дополнен и заменен в апреле 2002 года документом RFC 3280. RFC 3280 ввел в формат сертификата и САС дополнения, которые содержат информацию, позволяющую клиентскому программному обеспечению определять местонахождение УЦ и репозитория. Многие специалисты в области PKI признают разработку стандарта RFC 2459 поворотным моментом в развитии инфраструктур открытых ключей, способствовавшим созданию функционально совместимых PKI-продуктов (более подробная информация о документах группы PKIX приведена в разделе "Стандарты Internet X.509 PKI").

Проект EEMA PKI Challenge

Европейский Форум по электронному бизнесу (European Forum for Electronic Business - EEMA) с начала января 2001 года выполнял двухлетний проект PKI Challenge (pkiC), который финансировали Европейский Союз и правительство Швеции [211]. К участию в проекте помимо 13 организаций, входящих в состав Форума, были привлечены поставщики PKI-продуктов, пользователи, консультанты, академические институты, поставщики услуг по выпуску и поддержке цифровых сертификатов для выработки решений по обеспечению функциональной совместимости PKI-продуктов. Рекомендации, выработанные в результате реализации проекта, приведены в табл. 15.8.

|Компонент PKI | Рекомендация |

|УЦ | УЦ должен публиковать списки аннулированных сертификатов (САС) в соответствии со стандартом X.509 v2.

В сертификатах должно присутствовать дополнение CRL Distribution Points, где перечислены пункты распространения САС.

Все действия, выполняемые УЦ, должны регистрироваться в контрольных журналах.

Для автоматической регистрации конечных пользователей должен поддерживаться, по крайней мере, протокол Simple CMP

|

|Репозиторий | Предпочтительно использование репозитория типа X.500, доступ к которому осуществляется по протоколу LDAP.

Поставщикам следует ориентироваться на поддержку LDAP v3.

Необходимо поддерживать следующий минимальный набор компонентов отличительного имени Distinguished Name (DN):

* C (страна);

* L (местонахождение);

* O (организация);

* OU (подразделение организации);

* CN (общее имя);

* DC (компонент домена).

Поставщикам следует реализовать и протестировать дополнения, введенные стандартом RFC 3280, которые содержат информацию о местонахождении удостоверяющих центров Authority Information Access и репозиториев Subject Information Access

|

|OCSP-респондер | Ответ OCSP-респондера может быть подписан одним из следующих ключей:

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

2 ключом, выпущенным для OCSP-респондера вместе с соответствующим сертификатом открытого ключа, который имеет в поле дополнения Extended Key Usage параметр OCSP-Signing. Этот сертификат должен быть выпущен тем же УЦ, который издал сертификат, подлежащий валидации;

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

Те поставщики, которые пока не реализовали поддержку OCSP-ответа, должны ориентироваться на второй вариант

|

|Клиентское ПО | Клиентское ПО конечного субъекта должно иметь возможность:

* генерировать пару ключей для регистрации;

* управлять содержимым локального репозитория, предназначенного для хранения копий сертификатов корневого УЦ, списков САС и сертификатов корреспондентов;

* локально управлять идентификационными данными субъекта, а также предлагать средства дистанционного управления ими через УЦ

|

|PKI-совместимые приложения | Приложения, использующие PKI, должны:

* работать с файловыми форматами PKCS#10, PKCS#7 и PKCS#11, а также поддерживать либо протокол PKIX-CMP, либо CMC;

* иметь возможность выполнять поиск в каталоге LDAP или любом LDAP-совместимом каталоге;

* понимать дополнения сертификатов, связывающих сертификат с той PKI, которая его поддерживает (т.е. crl Distribution Point, authority Information Access, Subject Information Access)

|

Таблица 15.8.Рекомендации проекта pkiC Европейского Форума по электронному бизнесу

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

|Стандарты PKIX |

RFC 2459/RFC 3280: Internet X.509 Public Key

Infrastructure Certificate and Certificate Revocation

List (CRL) Profile

RFC 2510: Internet X.509 Public Key Infrastructure

Certificate Management Protocols

RFC 2511: Internet X.509 Certificate Request Message

Format

RFC 2511 bis Internet X.509 Certificate Request

Message Format

RFC 2797: Certificate Management Messages over

CMS

RFC 2559: Internet X.509 Public Key Infrastructure

Operational Protocols - LDAP v2

RFC 2587: Internet X.509 Public Key Infrastructure

LDAP v2 Schema

RFC 3279: Algorithms and Identifiers for the Internet

X.509 Public Key Infrastructure Certificate and

Certificate Revocation List (CRL) Profile

|

|Стандарты PKCS |

PKCS#1: RSA Cryptography Standard

PKCS#7: Cryptographic Message Syntax Standard

PKCS#10: Certification Request Syntax Standard

PKCS#11: Cryptographic Token Interface Standard

PKCS#12: Personal Information Exchange Syntax

Standard

PKCS#15: Cryptographic Token Information Format

Standard

|

|Дополнительные стандарты |

RFC 1777: Lightweight Directory Access Protocol

RFC 1823: The LDAP Application Program Interface

RFC 2251: Lightweight Directory Access Protocol (v3)

RFC 2252: Lightweight Directory Access Protocol

(v3): Attribute definition

RFC 2253: Lightweight Directory Access Protocol (v3):

UTF-8 String Representation of Distinguished Names

RFC 2254: Lightweight Directory Access Protocol (v3)

The String Representation of LDAP Search Filters

RFC 2255: Lightweight Directory Access Protocol (v3)

The LDAP URL Format

RFC 3369: S/MIME Cryptographic Message Syntax

|

|Проекты стандартов |

Draft RFC2510 bis: Internet X.509 Public Key

Infrastructure Certificate Management Protocols

Draft: Internet X.509 Public Key Infrastructure LDAP

v2 Schema for X.509 CRLs

Draft: Internet X.509 Public Key Infrastructure LDAP

v2 Schema for X.509 Attribute Certificates

Draft: LDAP v3 DN strings for use with PKIs

|

Таблица 15.9.Рекомендуемый список поддерживаемых стандартов

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