19836A8B03030CF83737E3837837FC3s87092827262643FFA82710382828282A
принадлежит
Роберту Джону Смиту
12345, Юниверсити-авеню
Беркли, Калифорния 94702
Дата рождения: 4 июля 1958 г.
Emaiclass="underline" bob@superdupernet.com
Хеш SHA-2 данного сертификата подписан закрытым ключом CA
Илл. 8.26. Пример сертификата и подписанного хеша
Основная задача сертификата — связать открытый ключ с именем принципала (физического или юридического лица). Сами сертификаты никак не защищаются и не хранятся в тайне. Боб может выложить его на свой сайт и поставить ссылку: «Здесь находится сертификат моего открытого ключа». Перейдя по ссылке, пользователь увидит и сертификат, и блок с подписью (подписанный хеш SHA-2 сертификата).
Теперь снова рассмотрим сценарий, показанный на илл. 8.25. Что может сделать Труди, перехватив запрос страницы Боба, отправленный Алисой? Она может выложить свой сертификат и блок с подписью на подложной странице, однако Алиса сразу догадается, что разговаривает не с Бобом: его имени в этом сертификате просто нет. Труди может изменить домашнюю страницу Боба на лету, заменив его открытый ключ своим собственным. Но Алиса может проверить сертификат алгоритмом SHA-2. Тогда она получит значение хеш-функции, которое не согласуется со значением, вычисленным по открытому ключу CA и блоку подписи. Труди не имеет доступа к закрытому ключу CA и никак не может сгенерировать блок подписи, содержащий хеш модифицированной страницы с открытым ключом Труди. Таким образом, Алиса может не беспокоиться о подлинности ключа Боба. Как мы и обещали, при такой схеме не требуется, чтобы CA постоянно работал онлайн. Тем самым ликвидируется потенциально узкое место системы.
Сертификат используется для связывания открытого ключа не только с принципалом, но и с атрибутом. Например, он может содержать такую информацию: «Данный открытый ключ принадлежит лицу старше 18 лет». Этим можно подтвердить статус принципала или убедиться в том, что ему разрешен доступ к некоторым специфическим данным, на которые накладываются возрастные ограничения. При этом имя владельца может и не раскрываться. Обычно владелец отсылает сертификат на веб-сайт, принципалу или процессу, запрашивающему информацию о возрасте клиента. В ответ генерируется случайное число, шифруемое с помощью открытого ключа (считываемого с сертификата). Если клиент (то есть владелец) сможет расшифровать его и отослать обратно, это будет служить подтверждением тому, что он действительно обладает указанными в сертификате характеристиками. Кроме того, это случайное число может быть использовано в качестве сеансового ключа для будущего соединения.
Сертификат может содержать атрибут еще в одном случае: если речь идет об объектно-ориентированной распределенной системе. Каждый объект обычно имеет несколько методов. Владелец объекта может предоставить каждому клиенту сертификат с битовой картой, где перечислены доступные ему методы. Эта битовая карта привязывается к открытому ключу с помощью подписанного сертификата. Если владелец сертификата докажет, что у него есть соответствующий закрытый ключ, он сможет воспользоваться методами, указанными в битовой карте. Особенность этого подхода состоит в том, что необязательно указывать имя владельца. Это полезно в ситуациях, в которых важна конфиденциальность.
8.8.2. X.509
Если бы все желающие подписать что-либо обращались в CA за сертификатами различных видов, обслуживание разнообразных форматов вскоре стало бы проблемой. Во избежание этого МСЭ разработал и утвердил специальный стандарт сертификатов. Он называется X.509 и широко применяется в интернете. Начиная с 1988 года вышло уже три версии X.509; мы рассмотрим новейшую из них — третью.
На стандарт X.509 сильное влияние оказала система OSI, из которой он позаимствовал худшие ее свойства, в частности принцип кодирования и именования. Удивительно, что IETF согласился с данной концепцией, учитывая, что практически во всех областях, начиная с машинных адресов и заканчивая транспортными протоколами и форматами электронных писем, IETF всегда игнорировал OSI и пытался сделать что-нибудь более толковое. IETF-версия X.509 описана в RFC 5280.
По сути, X.509 — это способ описания сертификатов. Основные поля сертификата перечислены на илл. 8.27. Из описаний, приведенных в правой колонке, должно быть понятно, для чего служит соответствующее поле. За дополнительной информацией обращайтесь к RFC 2459.
Поле
Значение
Version
Версия X.509
Serial number
Это число вместе с именем CA однозначно идентифицирует сертификат
Signature algorithm
Алгоритм генерации подписи сертификата
Issuer
X.500-имя CA
Validity period
Начало и конец периода годности
Subject name
Сущность, ключ которой сертифицируется
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 заключается в том, что если Алиса пытается обратиться к Бобу по адресу bob@moneybank.com и имеет данные сертификата с именем в этом формате, для нее вовсе не очевидно, что этот сертификат относится именно к тому Бобу, который ей нужен. К счастью, начиная с третьей версии, появилась возможность использовать имена 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 и признающие легальность их деятельности.