Инфраструктура Открытого Ключа (часть 1)

Введение в PKI

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

Сначала определим ключевые термины, используемые в Инфраструктуре Открытого Ключа (Public Key Infrastructure – PKI) и основные исторические моменты разработки PKI. Затем рассмотрим архитектуру PKI, определим основные форматы данных и протоколы взаимодействия участников PKI.

Одним из требований к алгоритмам цифровой подписи является требование, чтобы было вычислительно невозможно, зная открытый ключ KU, определить закрытый ключ KR. Казалось бы, открытый ключ KU можно распространять по небезопасным сетям и хранить в небезопасных репозиториях. Но при этом следует помнить, что при использовании цифровой подписи необходимо быть уверенным, что субъект, с которым осуществляется взаимодействие с использованием алгоритма открытого ключа, является собственником соответствующего закрытого ключа. В противном случае возможна атака, когда оппонент заменяет открытый ключ законного участника своим открытым ключом, оставив при этом идентификатор законного участника без изменения. Это позволит ему создавать подписи от имени законного участника и читать зашифрованные сообщения, посланные законному участнику, используя для этого свой закрытый ключ, соответствующий подмененному открытому ключу. Для предотвращения такой ситуации следует использовать сертификаты, которые являются структурами данных, связывающими значения открытого ключа с субъектом. Для связывания необходимо наличие доверенного удостоверяющего (или сертификационного) центра (Certification Authority – СА), который проверяет идентификацию субъекта и подписывает его открытый ключ и некоторую дополнительную информацию своим закрытым ключом.

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

Основным понятием Инфраструктуры Открытого Ключа является понятие сертификата.

Сертификат участника, созданный СА, имеет следующие характеристики:

1. Любой участник, имеющий открытый ключ СА, может восстановить открытый ключ участника, для которого СА создал сертификат.
2. Никто другой, кроме данного удостоверяющего центра, не может модифицировать сертификат без обнаружения этого проверяющей стороной.

Мы будем рассматривать сертификаты Х.509, хотя существует достаточно много сертификатов других форматов.

CCITT (Consultative Committee for International Telegraphy and Telephony) разработал серию рекомендаций для создания так называемого сервиса Директории. Директория является сервером или распределенным набором серверов, которые поддерживают распределенную базу данных, содержащую информацию о пользователях и других объектах, которая называется Информационной Базой Директории (Directory Information Base – DIB). Данная информация может включать имя пользователя или объекта, а также другие атрибуты. Эти рекомендации носят название стандарта Х.500.

Стандарт Х.509 первоначально являлся частью стандарта Х.500 и описывал основные требования к аутентификации в Х.500 Директории. Но Х.509 используется не только в контексте сервиса Директории Х.500. Сертификаты, определяемые данным стандартом, используются практически всеми программными продуктами, относящимися к обеспечению сетевой безопасности.

Стандарты ITU-T X.509 и ISO/IEC 9594-8, которые впервые были опубликованы в 1988 году как часть рекомендаций Х.500 Директории, определили формат сертификата Х.509. Формат сертификата в стандарте 1988 года называется форматом версии 1 (v1). Стандарт Х.500 был пересмотрен в 1993 году, в результате чего было добавлено несколько новых полей в формат сертификата Х.509, который был назван форматом версии 2 (v2).

Опыт реализации первой и второй версий говорит о том, что форматы сертификата v1 и v2 имеют ряд недостатков. Самое важное, что для хранения различной информации требуется больше полей. В результате ISO/IEC, ITU-T и ANSI X9 разработали формат сертификата Х.509 версии 3 (v3). Формат v3 расширяет формат v2 путем добавления заготовок для дополнительных полей расширения. Конкретные типы полей расширения могут быть определены в стандартах или определены и зарегистрированы любой организацией или сообществом. В июне 1996 года стандартизация базового формата v3 была завершена.

Однако расширения стандарта ISO/IEC, ITU-T и ANSI X9 являются очень общими, чтобы применять их на практике. Для того чтобы разрабатывать интероперабельные реализации систем, взаимно использующие сертификаты Х.509 v3, необходимо четко специфицировать формат сертификата Х.509 v3. Специалисты IETF разработали профиль сертификата X.509 v3 и опубликовали его в RFC 3280.

В табл. 13.2 рассмотрены основные элементы сертификата.

Часто используется следующая нотация для обозначения сертификата:

СА << A >>

– сертификат пользователя А, выданный сертификационным центром СА.

СА подписывает сертификат своим закрытым ключом. Если соответствующий открытый ключ известен пользователю, то пользователь может проверить, что сертификат, подписанный СА, действителен.

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

В любом случае если В имеет сертификат А, В уверен, что сообщение, которое он расшифровывает открытым ключом А, никто не мог просмотреть, и что сообщение, подписанное закрытым ключом А, не изменялось.

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

Теперь предположим, что А получил сертификат от уполномоченного органа Х1, и В получил сертификат от уполномоченного органа Х2. Если А не знает безопасным способом открытый ключ Х2, то сертификат В, полученный от Х2, для него бесполезен. А может прочитать сертификат В, но не в состоянии проверить подпись. Тем не менее, если два САs могут безопасно обмениваться своими открытыми ключами, возможна следующая процедура для получения А открытого ключа В.

1. А получает из директории сертификат Х₂, подписанный Х₁. Так как А знает открытый ключ Х₁ надежным способом, А может получить открытый ключ Х₂ из данного сертификата и проверить его с помощью подписи Х₁ в сертификате.
2. Затем А возвращается обратно в директорию и получает сертификат В, подписанный Х². Так как А теперь имеет открытый ключ Х² надежным способом, А может проверить подпись и безопасно получить открытый ключ В.

Для получения открытого ключа В А использует цепочку сертификатов. В приведенной выше нотации эта цепочка выглядит следующим образом:

Х1 << Х2 >> Х2 << B >>

Аналогично В может получить открытый ключ А с помощью такой же цепочки:

Х2 << Х1 >> Х1 << А >>

Данная схема не обязательно ограничена цепочкой из двух сертификатов. Для получения цепочки может использоваться путь CАs произвольной длины. Цепочка, содержащая N элементов, выглядит следующим образом:

Х1 << Х2 >> Х2 << Х3 >> . . . ХN << B >>

В этом случае каждая пара САs в цепочке (Хⁱ , Хⁱ⁺¹) должна создать сертификаты друг для друга.

Все эти сертификаты CAs необходимо разместить в директории, и пользователи должны иметь информацию о том, как они связаны друг с другом, чтобы получить путь к сертификату открытого ключа другого пользователя. Это определяет Инфраструктуру Открытого Ключа, изучению которой и посвящены следующие лекции.