tanenbaum_seti_all.pages (525408), страница 233
Текст из файла (страница 233)
Оно бы быстро перестало функционировать из-за огромной нагрузки, да ешс и стало бы эпицентром всех проблем, связанных с безопасностью сетей. Возможно, следует создать целый набор таких Управлений, использугошпх один и тот же закрытый ключ для подписания сертификатов, под покровительством одной и той же организации.
Однако, хотя это и решит проблему распределения нагрузки, возникнет новый вопрос, связанный с углечкий ключа. Если по всему миру будут разбросаны дссятки серверов, хранящих закрытый ключ Управления сертификации, велик шанс, что рано или поздно этот ключ будет украден или пропадет каким-то иным образом. Если ключ будет рассекречен, всю мировую инфраструктуру электронной безопасности можно будет похоронить.
Вмсстс с тем, наличие всего одного центрального Управления сертификации — это тоже риск. Далее, какая организация будет заведовать Управлсниеы7 Довольно трудно представить себе какую-либо законнуго структуру с большим кредитом доверия мирового масштаба. В некоторых странах предпочтительно, чтобы это было какое-нибудь правительственное учрсждснис, а гле-то — наоборот, чтобы это было чем угодно, но нс правительством.
По этим причинам был разработан альтернативный способ сертификации открытых ключей. Он известен под общим названием РК! (РцЪБс Кеу тп)газ(гцсгпге — инфраструктура систем с открытыми ключами). В атом разделе мы 868 Глава 8. Безопасность в сетях рассмотрим только общие принципы действия РК1, поскольку было внесено множество предложений по се модификации и некоторые детали могут со временем измениться. РК1 состоит из множества компонентов, среди которых Управления сертификации, сами сертификаты, а также каталоги.
Инфраструктура систем с открытыми ключами предоставляет возможность структурной организации этих компонентов и определяет стандарты, касающиеся различных документов и протоколов. Одним из простейших видов РК1 является иерархия Управлений, представленная на рис. 8.22. На рисунке представлены три уровня, однако реально их может быть как больше, так и меньше. Управление сертификапии верхнего уровня (гост) мы будем называть Центральным управлением (ЦУ).
Центральное управление сертифицирует управл~ния второго уровня — назовем их Региональными отделами (РО), — так как они могут обслуживать некоторый географический регион, например, страну или континент. Этот термин не стандартизован. Названия для уровней иерархии вообше нс оговариваются стандартом. Региональные отделы, в сво1о очередь, занимаются легализацией реальных Управлений сертификации (УС), эмитируюших сертификаты стандарта Х.509 для физических и юридических лиц.
При легализации Центральным управлением нового Регионального отдела последнему выдается сертификат, подтверждающий его признание. Он содержит открытый ключ нового РО и подпись ЦУ. Аналогичным образом РО взаимодействуют с Управлениями сертификации: выдают и подписывают сертификаты, содержащие открытые ключи УС и признающие легальность деятельности. Рис.
8.22. Иерархия РК! (а); цепочка сертификатов Гб) Итак, наш РК1 работает следующим образом. Допустим, Алисе нужен откры. тый ключ Боба, чтобы опа могла с ним пообщаться. Она ишет и находит содержащий его сертификат, нолписанный уС 5. Однако Алиса никогда ничего не слышала про УС 5. Этим «Управлением» может оказаться, на самом деле, лесятилегняя дочка Боба. Алиса может отправиться в УС 5 н попросить подтвердить легитимность. Управление в ответ может показать сертификат, полученный от Управление открытыми ключами 869 РО 2 и содержащий открытый ключ УС 5. Теперь, вооружившись открытым ключом УС 5, Алиса может удостовериться в том, что сертификат Боба действительно подписан УС 5, а значит, является легальным.
Если только РО 2 не является двенадцатилетним сыном Боба. Если Алисе вдруг придет в голову такая мысль, она может запросить подтверждение легитимности РО 2. Ответом будет служить сертификат, подписанный Центральным управлением и содержащий открытый ключ РО 2. Вот теперь Алиса может не сомневаться, что она получила открытый ключ Боба, а не кого-то другого.
А сели Алиса хочет узнать открьпый ключ ЦУ? Как это сделать? Загадка. Предполагается, что открытый ключ ЦУ знают все. Например, он может быть «зашит» внутрь ее браузера. Но наш Боб — добряк, он не хочет доставлять Алисе лишние хлопоты. Он понимает, что она захочет проверить легитимность УС 5 н РО 2, поэтому он сам собирает соответствующис сертификаты и отправляет их ей вместс со своим. Теперь, зная открытый ключ ЦУ, Алиса может проверить по цепочке все интересующис сс организации. Ей нс придется никого беспокоить для подтверждения.
Поскольку все сертификаты подписаны, она может запросто уличить любые попытки подлога. Цепочка сертификатов, восходяпшя к ЦУ, иногда называется доверительной цепочкой или путем сертификата. Описанный метод широко применяется на практике. Конечно, остается проблема определения владельца ЦУ. Следует иметь не одно Центральное управление, а несколько, причем связать с каждым из них свою иерархию репюнальных отделов и управлений сертификации.
На самом деле, в современные браузеры действительно «зашиваются» открытые ключи более 100 центральных управлений, иногда называемые доверительными якорями. Как видите, можно избежать проблемы одного всемирного учреждения, занимающегося сертификацией. Олнако встает вопрос, какие доверительные якоря производители браузеров могут считать надежными, а какие — нет. Все, на самом деле, сводится к тому, насколько конечный пользователь доверяет разработчику браузера, насколько он уверен в том, что решения генерируются грамотно и довсритсльные якоря не принимаются от всех желающих за умеренную плату.
Большинство браузеров обеспечивают возможность проверки ключей ЦУ (обычно это делается с помощью сертификатов, подписанных им) и удаления подозрительных ключей. Каталоги Инфраструктура систем с открытыми ключами должна решать еще один вопрос. Он касается места хранения сертификатов (и цепочек, ведусяих к какому-нибудь доверительному якорю). Можно заставить всех пользователей хранить свои сертификаты у себя.
Это безопасно (так как невозможно поллелать подписанные сертификаты незаметно), но не слишком удобно. В качестве каталога для сертификатов было предложено использовать |ЭИ5. Прежде чем соединиться с Бобом, Алисе, видимо, все равно придется узнать с помощью службы имен доменов (ПХ5) его 1Р-адрес. Так почему бы не заставить 1ЭМ5 возвращать вместе с 1Р-адресом всю цепочку сертификатов? В70 Глава 8, Безопасность в сетях Кому-то это кажется выходом из положсиия, однако некоторые считают, что лучше иметь специализированные серверы с каталогами для хранения сертификатов Х.509.
Такис каталоги могли бы с помощью имен Х.500 обеспечивать возможность поиска. Например, теоретически можно представить себе услугу сервера каталогов, позволяющую получать ответы иа запросы типа «Дайте мие полиый список всех людей по имени Алиса, работающих в отделе продаж в любом месте США или Канады». Хранить такую информацию можно, например, при помощи 1?)АР. Аннулирование Реальный мир полон разного рода сертификатов, среди которых, например, паспорта, водительские удостоверения.
Иногда зти сертификаты необходимо аннулировать (иапример, водительское удостоверение надо аннулировать за езду в нетрезвом состоянии). Та же проблема возникает и в мире цифровых технологий: лицо, предоставившее сертификат, может отозвать его за нарушение противоположной стороной каких-либо условий. Это необходимо делать и тогда, когда закрытый ключ, в сущности, перестал быть защищеииым или, что еще хуже, ключ УС потерял кредит доверия. Таким образом, инфраструктура систем с открытыми ключами должна как-то обеспечивать процедуру аннулирования. Первым шагом в этом направлении является принуждение всех УС к периодическому выпуску списка аннулированных сертификатов (СК1 — Сегбйсате Кечосааоп ~Ьг). В ием перечисляются порядковые номера всех аннулированных сертификатов.
Поскольку в сертификатах содержится дата окончания срока годности, в СК1 следует включать номера только тех из иих, срок годности которых еще не истек. По истечеции срока годности сертификаты перестают быть дсйствительиыми автоматически, поэтому нужно различать случаи аннулирования «по старости» и по другим причинам. В любом случае их использование необходимо запрещать. К сожалению, возникновение списков аннулированных сертификатов озиачает, что лицо, собирающееся использовать сертификат, должно вначале убедиться в том, что его иет в этом списке. В противном случае от использования надо отказаться.