Э. Таненбаум - Компьютерные сети. (4-е издание) (DJVU) (1130092), страница 233
Текст из файла (страница 233)
Во избежание этого был разработан и утвержден организацией 1Т11 специальный стандарт сертификатов. Он называется Х.509 и широко применяется в Интернете. В свет, начиная с 1988 года, вышло уже три версии стандарта, и мы будем рассматривать новейшую из них — третью. На стандарт Х.509 сильное влияние оказал мир 081, в связи с чем в нем появились некоторые неприятные вещи, как, например, определенный принцип кодирования и именования. Удивительно, что проблемная группа по развитию Интернета, 1ЕТГ, согласилась с данной концепцией, особенно учитывая то, что практически во всех областях, начиная с машинных адресов и заканчивая транспортными протоколами и форматами электронных писем, 1ЕТЕ всегда игнорировала 051 и пыталась сделать что-нибудь более толковое.
1ЕТР-версия Х.509 описана в КГС 3280. По сути, Х.509 — зто способ описания сертификатов. Основные поля сертификата перечислены в табл 8.3. Из описаний, приведенных в правой колонке, должно быть понятно, что для чего служит поле. За дополнительной информацией обращайтесь к ВЕС 2459. Например, если Боб работает в отделе ссуд банка Мопеу Вапй, его Х.500-адрес будет выглядеть так: /С-85!О-НопеуВаФ/ВО=Спал!Сй=ВоЫ где С вЂ” страна, 0 — организация, 00 — отдел организации, СИ вЂ” имя.
Управление сертификации и другие сущности именуются похожим образом. Существенная проблема с системой именования Х.500 заключается в том, что если Алиса пытается соединиться с ЬоЬРтоиеуЬагь1 сот и имеет данные сертификата с именем в этом формате, для нее вовсе не очевидно, что этот сертификат имеет отношение именно к тому Бобу, который ей нужен. К счастью, начиная с третьей версии, разрешено использование имен 1)Х5 вместо Х.500, поэтому данная проблема может счастливо разрешиться, Сертификаты шифруются с использованием системы записи абстрактного синтаксиса 1 САЯХ вЂ” АЬзггасс 5увгах 1чогаг1оп) О51. Ее можно рассматривать Управление открытыми ключами 367 как нечто подобное структуре в языке С, за тем исключением, что эта запись очень странная и многословная.
Более подробную информацию можно найти в (Гоги и Вацтп, 2000). 1вбпмца 8.3. Основные поля сертификата в стандарте Х.509 Поле Значение Нетвюп Зет)а) питЬет Версия Х.509 Это число вместе с названием Управления сертификации однозначно идентифицирует сертификат Алгоритм генерации подписи сертификата Х.500-имя Управления Начало и конец периода годности Сущнооть, ключ которой сертифицируется Открытый ключ сущности и идентификатор использующего его алгоритма Необязательный идентификатор, единственным образом определяющий эмитента (создателя) сертификата Необязательный идентификатор, единственным образом определяющий владельца сертификата Различные возможные расширения Подпись сертификата (генерируется с помощью закрытого ключа Управления сертификации) З)влетите а)допвлт )звиег На))б))у репоб ЗиЬ)ест пате РиЬВс Кеу )зэиег)О Зиь)ес) )О Ектепзюпз З)платите Инфраструктуры систем с открытыми ключами Понятно, что одного Управления сертификации на весь мир недостаточно.
Оно бы быстро перестало функционировать из-за огромной нагрузки, да еще и стало бы эпицентром всех проблем, связанных с безопасностью сетей. Возможно, следует создать целый набор таких Управлений, использующих один и тот же закрытый ключ для подписания сертификатов, под покровительством одной и той же организации. Однако, хотя это и решит проблему распределения нагрузки, возникнет новый вопрос, связанный с утечкой ключа.
Если по всему миру будут разбросаны десятки серверов, хранящих закрытый ключ Управления сертификации, велик шанс, что рано или поздно этот ключ будет украден или пропадет каким-то иным образом. Если ключ будет рассекречен, всю мировую инфраструктуру электронной безопасности можно будет похоронить. Вместе с тем, наличие всего одного центрального Управления сертификации — это тоже риск. Далее, какая организация будет заведовать Управлением? Довольно трудно представить себе какую-либо законную структуру с большим кредитом доверия мирового масштаба. В некоторых странах предпочтительно, чтобы это было какое-нибудь правительственное учреждение, а где-то — наоборот, чтобы это было чем угодно, но не правительством.
По этим причинам был разработан альтернативный способ сертификации открытых ключей. Он известен под общим названием РК1 (РцЫ1с Кеу 1п1газсгпсспге — инфраструктура систем с открытыми ключами). В атом разделе мы 888 Глава 8.
Безопасность в сетях рассмотрим только общие принципы действия РК1, поскольку баяло внесено множество предложений по ее модификации и некоторые детали могут со временем измениться. РК1 состоит из множества компонентов, среди которых Управления сертификации, сами сертификаты, а также каталоги. Инфраструктура систем с открытыми ключами предоставляет возможность структурной организапии этих компонентов и определяет стандарты, касающиеся различных документов и протоколов. Одним из простейших видов РК1 является иерархия Управлений, представленная на рис.
8.22. На рисунке представлены три уровня, однако реально их может быть как больше, так и меньше. Управление сертификации верхнего уровня (грос) мы будем называть Центральным управлением (ЦУ). Центральное управление сертифицирует управления второго уровня — назовем их Региональными отделами (РО), — так как они могут обслуживать некоторый географический регион, например, страну или континент.
Этот термин не стандартизован. Названия для уровней иерархии вообще нс оговариваются стандартом. Рсгиональныс отделы, в свою очередь, занима|отея легализацией реальных Управлений сертификации (УС), змитирующих сертификаты стандарта Х.509 для физических и юридических лиц. При легализации Центральным управлением нового Регионального отдела последнему выдается сертификат, подтверждающий его признание. Он содержит открытый ключ нового РО и подпись ЦУ. Аналогичным образом РО взаимодействуют с Управлениями сертификации: выдают и подписывают сертификаты, содержащие открытые ключи УС и признающие легальность деятельности. Рис.
6.22. Иерархия РК! (а); цепочка сертификатов )б) Итак, наш РК1 работает следующим образом. Допустим, Алисе нужен открытый ключ Боба, чтобы она могла с ним пообщаться. Она ищет и находит содержаший его сертификат, подписанный УС 5.
Однако Алиса никогда ничего не слышала про УС 5. Этим «Управлением» может оказаться, на самом деле, десятилетняя дочка Боба. Алиса может отправиться в УС 5 и попросить подтвердить легитимность. Управление в ответ может показать сертификат, полученный от Управление открытыми ключами 869 РО 2 н содержащий открытый ключ УС 5. Теперь, вооружившись открытым ключом УС 5, Алиса может удостовериться в том, что сертификат Боба действительно подписан УС 5, а значит, является легальным.
Если только РО 2 не является двенадцатилетним сыном Боба. Если Алисе вдруг придет в голову такая мысль, она может запросить подтверждение легитимности РО 2. Ответом будет служить сертификат, подписанный Центральным управлением и содержащий открытый ключ РО 2. Вот теперь Алиса может не сомневаться, что она получила открытый ключ Боба, а не кого-то другого.
А если Алиса хочет узнать открытый ключ ЦУ? Как это сделать? Загадка. Предполагается, что открытый ключ ЦУ знают все. Например, он может быть кзашить внутрь ее браузера. Но наш Боб — добряк, он не хочет доставлять Алисе лишние хлопоты. Он понимает, что она захочет проверить легитимность УС 5 н РО 2, поэтому он сам собирает соответствующие сертификаты и отправляет их ей вместе со своим. Теперь, зная открьггый ключ ЦУ, Алиса может проверить по цепочке все интересующие ее организации.
Ей не придется никого беспокоить для подтверждения. Поскольку все сертификаты подписаны, она может запросто уличить любые попытки подлога. Цепочка сертификатов, восходя|цая к ЦУ, иногда называется доверительной цепочкой или путем сертификата. Описанный метод широко применяется на практике, Конечно, остается проблема определения владельца ЦУ. Следует иметь не одно Центральное управление, а несколько, причем связать с каждым из них свою иерархию региональных отделов и управлений сертификации.
На самом деле, в современные браузеры действительно «зашиваются» открытые ключи более 100 центральных управлений, иногда называемые доверительными якорями. Как видите, можно избежать проблемы одного всемирного учреждения, занимающегося сертификацией. Однако встает вопрос, какие доверительные якоря производители браузеров могут считать надежными, а какие — нет. Все, на самом деле, сводится к тому, насколько конечный пользователь доверяет разработчику браузера, насколько он уверен в том, что решения генерируются грамотно и доверительные якоря не принимаются от всех желающих за умеренную плату.
Большинство браузеров обеспечивают возможность проверки ключей ЦУ (обычно это делается с помощью сертификатов, подписанных им) и удаления подозрительных ключей. Каталоги Инфраструктура систем с открытыми ключами должна решать еще один вопрос. Он касается места хранения сертификатов (и цепочек, ведущих к какому-нибуль доверительному якорю).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
