Шрифт:
Закладка:
Public key
Открытый ключ сущности и идентификатор использующего его алгоритма
Issuer ID
Необязательный идентификатор, единственным образом определяющий эмитента (создателя) сертификата
Subject ID
Необязательный идентификатор, единственным образом определяющий владельца сертификата
Extensions
Возможны многочисленные расширения
Signature
Подпись сертификата (генерируется с помощью закрытого ключа CA)
Илл. 8.27. Основные поля сертификата в стандарте X.509
Например, если Боб работает в отделе ссуд банка Money Bank, его X.500-адрес будет выглядеть так:
/C=US/O=MoneyBank/OU=Loan/CN=Bob/
где C — страна, O — организация, OU — отдел организации, CN — имя. CA и другие сущности именуются похожим образом. Серьезная проблема с системой именования X.500 заключается в том, что если Алиса пытается обратиться к Бобу по адресу [email protected] и имеет данные сертификата с именем в этом формате, для нее вовсе не очевидно, что этот сертификат относится именно к тому Бобу, который ей нужен. К счастью, начиная с третьей версии, появилась возможность использовать имена DNS вместо имен X.500, что позволяет наконец забыть об этой проблеме.
Сертификаты кодируются с помощью языка ASN.1 (Abstract Syntax Notation 1 — абстрактная синтаксическая нотация версии 1), используемого в модели OSI. Более подробную информацию о X.509 можно найти в книге Форда и Баума (Ford and Baum, 2000).
8.8.3. Инфраструктуры систем с открытыми ключами
Понятно, что одного CA на весь мир недостаточно. Он бы быстро перестал функционировать из-за огромной нагрузки, да еще и стал бы эпицентром всех проблем, связанных с безопасностью сетей. Возможно, нужно создать целый набор таких CA под руководством одной организации, использующих один и тот же закрытый ключ для подписания сертификатов. Однако хотя это и решит проблему распределения нагрузки, возникнет вопрос утечки ключа. Если по всему миру будут разбросаны десятки серверов, хранящих закрытый ключ CA, велик шанс, что рано или поздно он будет украден или как-то иначе разглашен. Если ключ будет рассекречен, с мировой инфраструктурой электронной безопасности можно будет попрощаться. Вместе с тем наличие всего одного главного CA — это тоже риск.
Следующий вопрос — какая организация будет заведовать CA? Довольно трудно представить себе какую-то структуру, признанную законной и заслуживающей доверия в мировом масштабе. В некоторых странах предпочтительно, чтобы это было государственное учреждение, а где-то — наоборот, чтобы эта структура была какой угодно, но не правительственной.
По этим причинам был разработан альтернативный способ сертификации открытых ключей. Он известен под общим названием инфраструктуры открытых ключей (Public Key Infrastructure, PKI). В этом разделе мы рассмотрим только общие принципы действия PKI, поскольку было внесено множество предложений по ее модификации и некоторые детали могут со временем измениться.
PKI состоит из множества компонентов — пользователей, CA, самих сертификатов, а также каталогов. Она предоставляет возможность структурировать эти компоненты и определяет стандарты, касающиеся различных документов и протоколов. Одним из простейших видов PKI является иерархия CA (илл. 8.28). На рисунке представлены три уровня, но их может быть как больше, так и меньше. CA верхнего уровня (корневой центр сертификации) сертифицирует CA второго уровня — назовем их региональными (промежуточными) центрами сертификации (Regional Authorities, RA), так как они могут обслуживать некоторый географический регион (например, страну или континент). Этот термин не стандартизован. Названия для уровней иерархии вообще не оговариваются стандартом. RA занимаются легализацией реальных CA, эмитирующих сертификаты стандарта X.509 для физических и юридических лиц. Когда корневой центр авторизует RA, он генерирует подтверждающий полномочия RA сертификат X.509, включает в него открытый ключ нового RA, подписывает его и передает RA. Аналогичным образом RA взаимодействуют с CA: выдают и подписывают сертификаты, содержащие открытые ключи CA и признающие легальность их деятельности.
Илл. 8.28. (а) Иерархия PKI. (б) Цепочка сертификатов
Итак, наша PKI работает следующим образом. Допустим, Алисе, чтобы пообщаться с Бобом, нужен его открытый ключ. Она находит сертификат, в котором содержится нужный ключ. Этот сертификат подписан CA 5. Однако Алиса никогда ничего не слышала о CA 5. Этим «CA» вполне может оказаться десятилетняя дочка Боба. Алиса обращается к CA 5 за подтверждением его легитимности. Он предъявляет сертификат, полученный от RA 2 и содержащий открытый ключ CA 5. Теперь, вооружившись открытым ключом CA 5, Алиса может удостовериться в том, что сертификат Боба действительно подписан CA 5, а значит, является легальным.
Если только RA 2 не является двенадцатилетним сыном Боба. Что ж, следующим шагом Алисы будет запрос подтверждения легитимности RA 2. Ответом будет служить сертификат с подписью корневого центра сертификации, содержащий открытый ключ RA 2. Вот теперь Алиса может не сомневаться, что она получила открытый ключ Боба, а не кого-то еще.
А если Алиса хочет узнать открытый ключ корневого CA? Как это сделать? Загадка. Предполагается, что его знают все. Например, он может быть «вшит» в ее браузер.
Но наш Боб — добряк, он не хочет доставлять Алисе лишних хлопот. Он понимает, что она захочет проверить легитимность CA 5 и RA 2, поэтому сам собирает нужные сертификаты и отправляет их вместе со своим. Теперь, зная открытый ключ корневой организации, Алиса может проверить по цепочке все интересующие ее компоненты. Ей не придется никого беспокоить для подтверждения. Поскольку все сертификаты подписаны, она может запросто уличить любые попытки подлога. Цепочка сертификатов, восходящая к корню, иногда называется доверительной цепочкой (chain of trust) или путем сертификации (certification path). Описанный метод широко применяется на практике.
Конечно, остается проблема определения владельца корневой организации. Лучше всего иметь несколько таких структур, причем связать с каждой из них свою иерархию RA и CA. На самом деле в современные браузеры действительно «зашиваются» открытые ключи более 100 корневых CA, иногда называемые доверительными якорями (trust anchors). Как видите, можно избежать проблемы одного всемирного учреждения, занимающегося сертификацией.
Однако встает вопрос, какие доверительные якоря производители браузеров могут считать надежными, а какие — нет. На самом деле все сводится к тому, насколько конечный пользователь доверяет разработчику браузера и уверен в том, что решения генерируются грамотно, а доверительные якоря не принимаются от всех желающих за умеренную плату. Большинство браузеров позволяют пользователям проверять корневые ключи (обычно в виде сертификатов, подписанных корневым CA) и удалять те, которые кажутся сомнительными. Более подробную информацию о PKI можно найти в книге Стэплтона и Эпштейна (Stapleton and Epstein, 2016).
Каталоги
PKI должна решать еще один вопрос. Он касается места хранения сертификатов (и цепочек, ведущих к какому-нибудь доверительному якорю). Можно заставить всех пользователей хранить свои сертификаты у себя. Это безопасно (так как невозможно подделать подписанные сертификаты незаметно), но
