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

6.2.2 Компоненты инфраструктуры открытых ключей (PKI)

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

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

• протокол безопасных соединений SSL (Secure Socket Layer);
• безопасный протокол передачи электронной почты S/MIME (Secure Multimedia Internet Mail Extension);
• протокол IPSec (IP Security);
• протокол защищенных электронных транзакций SET (Secure Electronic Transactions);
• программа шифрования PGP (Pretty Good Privacy).

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

Основные компоненты инфраструктуры открытых ключей (PKI), как показано на рис. 6.17, включают:

• конечные объекты [ End Entity (EE) ];
• центр сертификации [ Certificate Authority (CA) ];
• репозиторий сертификатов [ Certificate Repository (CR) ];
• центр регистрации [ Registration Authority (RA) ];
• цифровые сертификаты [ Digital Certificates (X.509 V3) ];

Далее следуют подробные определения этих компонентов.

Рис. 6.17. Компоненты PKI

Конечный объект [End-Entity (EE)]

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

Центр сертификации [Certificate Authority (CA)]

Центр сертификации [ Certificate Authority (CA) ] по существу, является подписчиком сертификатов. Центр сертификации, зачастую совместно с центром регистрации (описанным далее), имеет своей обязанностью обеспечивать надлежащую идентификацию сертификата конечного объекта ( ЕЕ ). Логический домен, в котором СА выпускает сертификаты и управляет ими, называется доменом безопасности (security domain), который может быть реализован для защиты множества различных групп разных размеров, начиная от одного контрольного пользователя вплоть до департамента и далее до уровня всей организации. Основные проводимые СА операции включают: выпуск сертификатов, обновление сертификатов и аннулирование сертификатов.

Выпуск сертификатов

СА создает цифровой сертификат путем подписывания его цифровой подписью. По существу пара открытого и секретного ключей генерируется запрашивающим клиентом ( ЕЕ ). После этого клиент передает СА на рассмотрение запрос на выпуск сертификата.

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

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

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

К примеру, при установке безопасного HTTP-соединения посредством SSL основные Web-браузеры имеют список сертификатов нескольких, заслуживающих доверия СА (обычно упоминаемых как Trusted Roots или Trusted CAs), уже зарегистрированных при добавлении и таких, как (но необязательно только их) VeriSign, Entrust, Thawte, Baltimore, IBM World Registry и т. д. Если Web-сервер использует сертификат, который подписан подобным доверенным CA, браузеры будут полностью доверять серверу, за исключением тех случаев, когда пользователь умышленно удаляет сертификат CA-подписчика из списка доверенных СА.

СА способен выпускать определенное количество различных типов сертификатов, таких, как:

• Сертификаты пользователей. Они могут выпускаться для обыкновенного пользователя или для объекта другого типа, такого, как сервер или приложение. После получения сертификата пользователя эти конечные объекты станут доверенными для СА. Если частью инфраструктуры является центр регистрации RA, то он также должен иметь этот сертификат. Сертификат пользователя может быть ограничен до специфических случаев применения и целей (таких, как безопасная электронная почта, безопасный доступ к серверам и т. д.).
• Сертификаты центров сертификации ( СА ). Когда СА выпускает сертификат для самого себя, такой сертификат называется самоподписанным сертификатом или корневым сертификатом для этого СА. Если СА выпускает сертификат для подчиненного СА, то этот сертификат также называется сертификатом СА.
• Перекрестные сертификаты. Они используются для перекрестной сертификации, которая представляет собой процесс аутентификации между доменами безопасности.

Обновление сертификатов

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

Аннулирование сертификатов

Максимальный срок службы сертификата ограничен датой истечения его срока действия. Однако в некоторых случаях возникает необходимость аннулировать сертификаты до наступления этой даты. Когда это случается, CA включает сертификат в список аннулированных сертификатов [Certificate Revocation List ( CRL )]. На самом деле, если быть более точным, CA включает в этот список серийный номер сертификата вместе с некоторой другой информацией. Клиенты, которым необходимо знать о достоверности сертификата, могут осуществлять в CRL поиск по любому уведомлению об аннулировании.

Репозиторий сертификатов (CR)

Репозиторий сертификатов [Certificate Repository ( CR )] является хранилищем выпущенных сертификатов и аннулированных сертификатов в CRL. Несмотря на то что CR необязательный компонент инфраструктуры открытых ключей, он значительно способствует доступности и управляемости PKI.

Так как формат сертификатов X.509 нормально приспособлен к каталогу X.500, то соответственно наилучшим образом будет реализовать CR как каталог (Directory), который затем может быть доступен посредством наиболее общего протокола доступа – облегченного протокола доступа к каталогам LDAP (Lightweight Directory Access Protocol), последней версией которого является LDAP v3.

LDAP является наиболее эффективным и наиболее распространенным методом, с помощью которого конечные объекты или СА извлекают или модифицируют хранящиеся в CR сертификаты и информацию CRL. LDAP предлагает команды или процедуры, которые делают это эффективно и равномерно, такие, как bind, search или modify и unbind. Также для поддержки со стороны сервера LDAP, действующего как сервер CR, определены классы объектов и атрибутов [называемые схемами (Schemas)].

Для получения сертификатов или информации CRL, если в каталоге не реализован CR, существуют альтернативные методы. Однако их применять не рекомендуется, и после рассмотрения требований, которым должен соответствовать CR, все сводится к тому, что каталог на самом деле является лучшим местом для хранения информации CR. Эти требования включают: простую доступность, доступ на основе стандартов, сохранение новейшей информации, встроенную безопасность (если требуется), вопросы управления данными и возможность объединения подобных данных. В случае инфраструктуры открытых ключей в Интернете на основе Domino репозиторием сертификатов является каталог Domino (Domino Directory).

Центр регистрации (RA)

Центр регистрации [Registration Authority ( RA )] является необязательным компонентом инфраструктуры открытых ключей. В некоторых случаях роль RA выполняет CA. Там, где используется отдельный RA, он является доверенным конечным объектом, который сертифицирован CA и действует как подчиненный сервер CA. CA может делегировать некоторые из своих функций управления RA. К примеру, RA может выполнять персональные задачи аутентификации, сообщать об аннулированных сертификатах, генерировать ключи или архивировать пары ключей. Однако RA не производит выпуск сертификатов или CRL.

6.2.3 Сертификаты X.509

Ключевой частью инфраструктуры открытых ключей (и достойной собственного раздела для описания) является сертификат X.509.

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

Сертификаты X.509 обычно используются в защищенных интернет-протоколах, таких, как те, которые мы рассматриваем в настоящей лекции, а именно:

• SSL (Secure Sockets Layer);
• S/MIME (Secure Multipurpose Internet Message Extension).

Что такое стандарт X.509?

Первоначально основной целью стандарта X.509 было определить средства для проведения аутентификации на основе сертификатов по отношению к каталогу X.500. Аутентификация каталогов в X.509 может проводиться с использованием либо техники секретных ключей, либо техники открытых ключей. Последняя основана на сертификатах открытых ключей.

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

Краткая история сертификатов X.509

RFC, касающиеся электронной почты повышенной защиты [Privacy Enhanced Mail (PEM)] в Интернете, которые были опубликованы в 1993 г., включают спецификации для инфраструктуры открытых ключей на основе сертификатов X.509 v1 (за подробностями обратитесь к RFC 1422). Опыт, приобретенный при осуществлении попыток использовать RFC 1422, ясно выявил, что форматы сертификатов v1 и v2 были не совсем полными в некоторых отношениях. Наиболее существенной была необходимость в большем количестве полей для размещения требуемой и нужной информации. Для удовлетворения этих новых требований организации ISO/IEC/ITU и ANSI X9 разработали формат сертификата X.509 версии 3 (v3). Формат v3 расширил формат v2 за счет обеспечения дополнительными полями расширения.

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

Содержимое сертификата X.509

Сертификат X.509 состоит из следующих полей:

• Версия сертификата;
• Серийный номер сертификата;
• Идентификатор алгоритма цифровой подписи (для цифровой подписи выпускающего сертификат);
• Имя выпускающего сертификат (это имя СА);
• Период достоверности;
• Имя субъекта (пользователя или сервера);
• Информация об открытом ключе субъекта: идентификатор алгоритма и значение открытого ключа;
• Уникальный идентификатор выпускающего сертификат – только для версий 2 и 3 (добавлено в версии 2);
• Уникальный идентификатор субъекта – только для версий 2 и 3 (добавлено в версии 2);
• Расширения – только для версии 3 (добавлено в версии 3);
• Цифровая подпись выпускающего сертификат для полей выше.

Стандартные расширения включают среди прочих атрибуты субъекта и выпускающего сертификат, информацию о политике сертификации, ограничения в использовании ключей. Структура сертификата X.509 V3 проиллюстрирована на рис. 6.18.

увеличить изображение
Рис. 6.18. Структура сертификата X.509

Данные сертификата записываются согласно правилу синтаксиса системы обозначений для описания абстрактного синтаксиса 1 (ASN. 1), как это можно увидеть на рис. 6.19.

Рис. 6.19. Представление сертификата X.509 согласно системе обозначений для описания абстрактного синтаксиса 1 (ASN. 1)

После этого они конвертируются в двоичные данные в соответствии с характерными правилами кодирования ASN.1, который является языком описания данных и определен организацией ITU-T как стандарты X.208 и X.209. Эта операция позволяет сделать данные сертификата независимыми от правил кодирования каждой конкретной платформы.

В некоторых полях сертификата для представления специальной последовательности значений параметров используется идентификатор объекта [object identifier ( OID )]. К примеру, на рис. 6.19 можно увидеть AlgorithmIdentifier для signatureAlgorithm, который фактически состоит из идентификатора объекта ( OID ) и необязательных параметров. Этот OID представляет конкретный алгоритм, используемый для цифровых подписей выпускающего сертификат ( СА ). Приложение, которое проверяет подпись сертификата, должно понимать OID, который представляет алгоритм шифрования и алгоритм сборника сообщений наряду с другой информацией.