В.3.3.3. Стандарт сертификатов х.509
Международный союз ITU-T разработал рекомендацию X.509 [51], включающую стандартизацию сертификата открытого ключа и процедуры аутентификации.
Начиная с 1988 года, вышло 3 версии стандарта. По сути, X.509 – это способ описания сертификатов. Основные поля сертификатов приведены в таблице В.1. Проблема заключается в том, что если Алиса пытается соединиться с bob@mail.com и имеет данные сертификата с именем в формате, для неё вовсе не очевидно, что этот сертификат имеет отношение именно к тому Бобу, который ей нужен.
Таблица В.1. Основные поля сертификатов в стандарте X.509
Поле |
Значение |
V |
Версия X.509 |
SN |
Это число вместе с названием Центра Сертификации однозначно идентифицирует сертификат |
AI |
Алгоритм подписи сертификата |
CA |
Имя Центра Сертификации (Удостоверяющего центра) |
Ta |
Начало и конец периода годности сертификата |
A |
Идентификатор владельца, ключ которого сертифицируется |
Ap |
Открытый ключ владельца и идентификатор алгоритма, с которым должен использоваться этот ключ |
- |
Расширения |
- |
Подпись сертификата |
Стандарт X.509 не требует использовать конкретный алгоритм, хотя и рекомендует RSA.
Стандарт X.509 использует следующую запись:
CA << A >> = CA {V, SN, AI, CA, Ta, A, Ap}-это сертификат пользователя А в центре сертификации CA.
Y << Х >> – это сертификат пользователя Х, выданный Центром Сертификации Y;
Y{I} – подпись для I, создаваемая объектом Y. Она состоит из I и добавленного зашифрованного профиля I.
Центр сертификации подписывает сертификат своим закрытым ключом. Пользователь, зная открытый ключ ЦС, может удостовериться, что подписанный ЦС сертификат подлинный. Сертификат пользователя, создаваемый Центром Сертификации, имеет следующие характеристики:
любой пользователь, имеющий открытый ключ Центра Сертификации, может восстановить сертифицированный открытый ключ пользователя;
никто, кроме Центра Сертификации, не может изменить сертификат без того, чтобы это было обнаружено.
Поскольку сертификаты фальсифицировать невозможно, их можно разместить в каталоге без применения специальных средств защиты. Если все пользователи используют один ЦС, это означает общее доверие данному Центру Сертификации. Тогда сертификаты пользователей могут размещаться в одном каталоге, доступном всем. Кроме того, любой пользователь может передать свой сертификат другому пользователю непосредственно. В любом случае, если В имеет сертификат А, то В может быть уверен в том, что сообщения, которые он шифрует открытым ключом А, будут защищены от прочтения, а сообщения, подписанные закрытым ключом А, - от фальсификации.
В большом сообществе пользователей обращения всех пользователей к одному и тому же Центру Сертификации практически невозможно. Поскольку сертификаты подписываются Центром Сертификации, каждый пользователь должен иметь собственный экземпляр открытого ключа Центра Сертификации, чтобы проверять подписи. Этот открытый ключ должен быть доставлен каждому пользователю абсолютно защищённым способом (обеспечивающим целостность и аутентичность), чтобы пользователь имел полную уверенность в поступающих сертификатах. Таким образом, при большом числе пользователей может оказаться более удобным иметь ряд ЦС, каждый из которых должен будет защищённым способом доставить открытый ключ некоторой части пользователей.
Предположим, что А получает сертификат от Центра Сертификации Х1, а В – от Х2. Если пользователю А не был представлен открытый ключ Х2 (ЕХ2), то сертификат В (ЕВ…DX2(EB)), выданный Центром Сертификации Х2, окажется для А бесполезным. Пользователь А сможет прочитать сертификат В, но не сможет проверить подпись. Однако, если два Центра Сертификации по какой-то защищённой схеме обменялись своими открытыми ключами, то следующая процедура открывает для А возможность получить открытый ключ В.
На рис. В.8 приведена такая цепочка из двух Центров Сертификации.
Рис. В.8. Цепочка из двух центров сертификации
Покажем, каким образом пользователь А использует цепочку сертификатов, чтобы получить открытый ключ пользователя В. В обозначениях X.509 эта цепочка записывается в виде X1<<X2>>X2<<B>>.
Этап 1. Пользователь А получает из каталога сертификат Х2, подписанный Х1 (X1 <<X2>>, т.е. ЕХ2…DX1(h(ЕХ2)). Поскольку А с уверенностью знает открытый ключ Х1, из полученного сертификата пользователь А сможет извлечь открытый ключ Х2 (ЕХ2) и проверить его с помощью подписи, которая была создана Х1 для этого сертификата.
Этап 2. Затем А снова обращается к каталогу и получает сертификат В, подписанный Х2 (X2<< B >>). Поскольку теперь пользователь А имеет экземпляр открытого ключа Х2 (EX2), пользователь А может проверить подпись и получить открытый ключ В.
Точно также В может получить открытый ключ А, но по обратной цепочке:
X2<<X1>>X1<<A>>.
В цепочке может участвовать любое число центров сертификации. Цепочка из N элементов будет иметь следующий вид:
X1<<X2>>X2<<X3>>…XN<<B>>
В этом случае пара центров сертификации в каждом звене (Xi, Xi+1) должна иметь уже готовые сертификаты друг для друга. Все сертификаты Центров Сертификации должны размещаться в каталоге, а пользователю необходимо знать, как они связаны, чтобы проследовать по подходящему маршруту к нужному сертификату открытого ключа другого пользователя.
На рис. В.9 показан гипотетический пример такой иерархии.
Рис. В.9. Гипотетический пример иерархии Центров Сертификации
Соединённые окружности обозначают иерархически связанные Центры Сертификации, а в указанных рядом прямоугольных блоках приводятся сертификаты, имеющиеся в каталоге соответствующего Центра Сертификации. Каталог Центра Сертификации включает 2 типа сертификатов:
прямые сертификаты. Сертификаты Х, выданные другими Центрами Сертификации;
возвратные сертификаты. Сертификаты, выданные для сертификации других Центров Сертификации.
В данном примере пользователь А может запросить следующие сертификаты из каталога, чтобы построить сертификационный маршрут к В:
X<<W>>W<<V>>V<<Y>>Y<<Z>>Z<<B>>
Получив эти сертификаты, пользователь А сможет развернуть сертификаты по маршруту один за другим и восстановить надёжный экземпляр открытого ключа В. Используя этот открытый ключ, А сможет посылать В шифрованные сообщения. Если же А понадобится получать шифрованные сообщения от В, то В потребуется открытый ключ А, который может быть получен по следующей цепочке сертификатов:
Z<<Y>>Y<<V>>V<<W>>W<<X>>X<<A>>
Пользователь В может получить этот набор сертификатов другим способом, если пользователь А включил этот набор в своё исходное сообщение (например, в Х включить сертификат Х<<Z>>, а в Z включить сертификат Z<<X>>.
Приведённые Центры Сертификации (или удостоверяющие центры), сами сертификаты и каталоги хранения сертификатов объединены в так называемую инфраструктуру систем с открытыми ключами PKI (Public Key Infrastructure).
В.3.3.3.1. Пример проверки подлинности открытого ключа с помощью цепочки сертификатов
Рассмотрим проверку абонентом A открытого ключа абонента B и на примере инфраструктуры PKI, состоящей из цепочки трёх Центров Сертификации ЦС1, ЦС2 и ЦС3 (рис. В.10). Для этого абонент A получает:
сертификат 1 абонента B, выданный ЦС3
Рис. В.10. Пример проверки с помощью сертификатов абонентом A открытого ключа абонента B
ЦС1<<В>>=EBOBDЦС3 (h(EB,OB)), где
EB – открытый ключ абонента B;
OB – часть сертификата абонента B, кроме открытого ключа EB и цифровой подписи;
DЦС3(h(EB,OB)) – цифровая подпись сертификата B.
Абонент A не может быть уверен в подлинности открытого ключа EB, так как не имеет подлинного открытого ключа ЦС3 (т.е. EЦС3), который позволяет проверить подлинность цифровой подписи в полученном сертификате. Для того, чтобы проверить эту подпись, абонент A получает ещё 2 сертификата:
сертификат 3 ЦС2, выданный ему ЦС1.
ЦС1<<ЦС2>> =EЦС2OЦС2DЦС1 (h(EЦС2,OЦС2)), где
EЦС2 – открытый ключ ЦС2;
OЦС2 – часть сертификата ЦС2, кроме EЦС2 и цифровой подписи;
DЦС1(h(EЦС2,OЦС2)) – цифровая подпись сертификата ЦС2.
сертификат 4 ЦС3, выданный ему ЦС2.
ЦС2<<ЦС3>> =EЦС3OЦС3DЦС2 (h(EЦС3,OЦС3)), где
EЦС3 – открытый ключ ЦС3;
OЦС3 – часть сертификата ЦС3, кроме EЦС3 и цифровой подписи;
DЦС2(h(EЦС3,OЦС3)) – цифровая подпись сертификата ЦС3.
Сертификат абонента A получен в ЦС1, поэтому ему известен открытый ключ ЦС1, т.е. EЦС1. С помощью этого ключа, проверив подпись в сертификате 3 ЦС2, он убеждается в подлинности открытого ключа EЦС2. С помощью ключа EЦС2, проверив подпись сертификата 4 ЦС3, абонент A убеждается в подлинности открытого ключа EЦС3. С помощью ключа EЦС3, проверив подпись сертификата 1, абонент A убеждается в подлинности открытого ключа абонента B. В соответствии с принятым обозначением в рекомендации Х.509) соответствующая цепочка сертификатов имеет следующий вид
ЦС1<<ЦС2>>ЦС2<<ЦС3>> ЦС3<<В>>
Аналогичным образом может быть с помощью соответствующих сертификатов проведена проверка абонентом B открытого ключа абонента A. В этом случае цепочка сертификатов имеет следующий вид
ЦС3<<ЦС2>>ЦС2<<ЦС1>> ЦС1<<А>>
В.3.3.3.2. Процедуры стандарта Х.509 аутентификации сообщений и рассылка общих ключей симметричного шифрования
В настоящем разделе приводятся три альтернативные процедуры аутентификации, изложенные в стандарте ITU-T Х.509. Шифрование с открытым ключом, кроме создания ЭЦП (что обеспечивает аутентификацию, целостность данных и неотказуемость) используется также для рассылки общих ключей симметричного шифрования.
Схемы всех трех процедур аутентификации Х.509 показаны на рис. В.11. Процедуры аутентификации Х.509 включают аутентификацию источника сообщения и целостность самого сообщения. Значение внутри фигурных скобок включает набор указанных значений и зашифрованная закрытым ключом отправителя хеш-функция этого набора, т.е. цифровая подпись. Предполагается, что каждая из двух сторон (А и В) проверила подлинность открытого ключа с помощью сертификатов.
Рис. В.11. Процедура аутентификации Х.509