Рис. 8.20. Способ вторжения в систему с открытыми ключами
8.5.1. Сертификаты
Первая попытка организации защищенного обмена ключами может состоять в создании круглосуточного интернет-центра распространения ключей по требованию. Один из множества недостатков такого решения заключается в том, что данную систему не удастся масштабировать, и сам этот центр очень скоро станет узким местом. А если он не выдержит нагрузки, вся интернет-безопасность в один момент сойдет на нет.
По этой причине было придумано новое решение, не требующее, чтобы центр распространения ключей был доступен постоянно. В общем-то, даже не требуется, чтобы он вообще работал в подключенном (онлайновом) режиме. Вместо этого на него возлагается обязанность сертификации открытых ключей, принадлежащих как физическим, так и юридическим лицам. Организация, занимающаяся сертификацией открытых ключей, в настоящее время называется Управлением сертификации (CA — Certification Authority).
В качестве примера рассмотрим такую ситуацию: Боб хочет разрешить Алисе и другим лицам, с которыми он не знаком, устанавливать с ним защищенные соединения. Он приходит в Управление сертификации со своим открытым ключом, а также паспортом или другим удостоверением личности и просит зарегистрировать ключ. Управление выдает ему сертификат, напоминающий тот, что показан на рис. 8.21, и подписывает хэш SHA-1 своим закрытым ключом. Затем Боб оплачивает услуги Управления и получает дискету с сертификатом и подписанным хэшем.
Рис. 8.21. Пример сертификата и подписанного хэша
Основная задача сертификата состоит в связывании открытого ключа с именем принципала (физического или юридического лица). Сертификаты сами по себе никак не защищаются и не хранятся в тайне. Например, Боб может выложить его на свой сайт и поставить ссылку: «Здесь можно посмотреть на сертификат моего открытого ключа». Перейдя по этой ссылке, пользователь увидит и сертификат, и блок с подписью (подписанный хэш SHA-1 сертификата).
Давайте теперь снова взглянем на сценарий, показанный на рис. 8.20. Что может сделать Труди, перехватив запрос страницы Боба, посланный Алисой? Она может выложить на странице свой собственный сертификат и блок с подписью на подложной странице, однако Алиса, читая этот сертификат, сразу догадается, что она разговаривает не с Бобом: в нем его имени просто нет. Труди может изменить домашнюю страницу Боба «на лету», заменив его открытый ключ своим собственным. И все же,
проверив сертификат алгоритмом SHA-1, она получит значение хэш-функции, не согласующееся с тем, которое будет вычислено по открытому ключу Управления сертификации и блоку подписи. Так как Труди не имеет доступа к закрытому ключу Управления сертификации, она никак не может сгенерировать блок подписи, содержащий хэш модифицированной страницы с выложенным на ней открытым ключом Труди. Таким образом, Алиса может не беспокоиться о подлинности ключа Боба. И вот, как мы и обещали, при такой схеме не требуется, чтобы Управление сертификации постоянно работало в подключенном режиме. Тем самым ликвидируется потенциально узкое место системы.
Сертификат может связывать открытый ключ не только с принципалом, но и с атрибутом. Например, сертификат может содержать такую информацию: «Данный открытый ключ принадлежит лицу старше 18 лет». Этим можно подтвердить статус принципала или убедиться в том, что ему разрешен доступ к некоторым специфическим данным, на которые накладываются возрастные ограничения. При этом имя принципала может и не раскрываться. Обычно владелец сертификата отсылает его на веб-сайт, принципалу или тому процессу, который обеспокоен возрастом клиента. В ответ генерируется случайное число, шифруемое с помощью открытого ключа (считываемого с сертификата). Если клиент сможет расшифровать его и отослать обратно, это будет служить подтверждением тому, что он действительно обладает указанными в сертификате характеристиками. Еще это случайное число может быть использовано в качестве сеансового ключа для будущего соединения.
Сертификат может содержать атрибут еще в одном случае: если речь идет об объектно-ориентированной распределенной системе. Каждый объект обычно обладает некоторым набором методов. Владелец объекта может предоставлять каждому клиенту сертификат с указанием тех методов, которыми он может пользоваться. Этот список в виде поразрядной карты отображения информации (битовой карты) можно связать с открытым ключом, используя подписанный сертификат. Опять же, если владелец сертификата сможет подтвердить факт обладания соответствующим закрытым ключом, он сможет воспользоваться методами, указанными в списке. Особенностью такого использования сертификатов является отсутствие необходимости указывать имя владельца. Это бывает полезно в ситуациях, когда важна конфиденциальность.
8.5.2. X.509
Если бы все желающие подписать что-нибудь обращались в Управление идентификации с различными видами сертификатов, обслуживание всех различных форматов вскоре стало бы проблемой. Во избежание этого был разработан и утвержден организацией ITU специальный стандарт сертификатов. Он называется X.509 и широко применяется в Интернете. В свет, начиная с 1988 года, вышло уже три версии стандарта, и мы будем рассматривать новейшую из них — третью.
На стандарт X.509 сильное влияние оказал мир OSI, в связи с чем в нем появились некоторые неприятные вещи, как, например, определенный принцип кодирования и именования. Удивительно, что проблемная группа по развитию Интернета, IETF, согласилась с данной концепцией, особенно учитывая то, что практически во всех
областях, начиная с машинных адресов и заканчивая транспортными протоколами и форматами электронных писем, IETF всегда игнорировала OSI и пыталась сделать что-нибудь более толковое. IETF-версия X.509 описана в RFC 5280.
По сути, X.509 — это способ описания сертификатов. Основные поля сертификата перечислены в табл. 8.3. Из описаний, приведенных в правой колонке, должно быть понятно, для чего служит поле. За дополнительной информацией обращайтесь к RFC 2459.
Например, если Боб работает в отделе ссуд банка Money Bank, его Х.500-адрес будет выглядеть так:
где C — страна, O — организация, OU — отдел организации, CN — имя. Управление сертификации и другие сущности именуются похожим образом. Существенная проблема с системой именования X.500 заключается в том, что если Алиса пытается соединиться с [email protected] и имеет данные сертификата с именем в этом формате, для нее вовсе не очевидно, что этот сертификат имеет отношение именно к тому Бобу, который ей нужен. К счастью, начиная с третьей версии, разрешено использование имен DNS вместо X.500, поэтому данная проблема может счастливо разрешиться.
Сертификаты кодируются с использованием OSI ASN.1 (Abstract Syntax Notation 1 — системы записи абстрактного синтаксиса 1). Ее можно рассматривать как нечто подобное структуре в языке С, за тем исключением, что эта запись очень странная и многословная. Более подробную информацию о X.509 можно найти в (Ford и Baum, 2000).
Таблица 8.3. Основные поля сертификата в стандарте X.509
8.5.3. Инфраструктуры систем с открытыми ключами
Понятно, что одного Управления сертификации на весь мир недостаточно. Оно бы быстро перестало функционировать из-за огромной нагрузки, да еще и стало бы эпицентром всех проблем, связанных с безопасностью сетей. Возможно, следует создать целый набор таких Управлений, использующих один и тот же закрытый ключ для подписания сертификатов, под покровительством одной и той же организации. Однако, хотя это и решит проблему распределения нагрузки, возникнет новый вопрос, связанный с утечкой ключа. Если по всему миру будут разбросаны десятки серверов, хранящих закрытый ключ Управления сертификации, велик шанс, что рано или поздно этот ключ будет украден или пропадет каким-то иным образом. Если ключ будет рассекречен, всю мировую инфраструктуру электронной безопасности можно будет похоронить. Вместе с тем, наличие всего одного центрального Управления сертификации — это тоже риск.
