2.23. Управление открытыми ключами

Криптография с использованием открытых ключей позволяет передавать секретные данные, не обладая общим ключом, а также создавать электронные подписи сообщений без необходимости привлечения третьей, доверительной стороны. Наконец, подписанные профили сообщений позволяют легко проверять целостность и аутентичность полученных данных.

Однако мы как-то слишком ловко обошли один вопрос: если Алиса и Боб друг друга не знают, как они смогут обменяться открытыми ключами перед началом общения? Вот, казалось бы, очевидное решение: выложить открытый ключ на веб-сайте. Однако так делать нельзя, и вот почему: представим себе, что Алиса хочет найти открытый ключ Боба на его веб-сайте. Каким образом она это делает? Набирает URL сайта. Браузер ищет DNS-адрес домашней страницы Боба и посылает запрос GET. К сожалению, Труди в этот момент перехватывает запрос и посылает Алисе фальшивую страницу. В качестве таковой может выступать, к примеру, копия страницы Боба, на которой вместо его открытого ключа выложен открытый ключ Труди. После того как Алиса зашифрует свое первое сообщение с помощью £_т, Труди расшифрует его, прочтет, зашифрует с помощью открытого ключа Боба и перешлет сообщение Бобу, который даже не подозревает обо всех этих перипетиях. Но гораздо хуже то, что Труди может изменять сообщения перед повторной шифрацией и отправкой Бобу. Очевидно, нужен некий механизм секретного обмена открытыми ключами.

2.24. Сертификаты

Первая попытка организации защищенного обмена ключами может состоять в создании круглосуточного интернет-центра распространения ключей по требованию. Один из множества недостатков такого решения заключается в том, что данную систему не удастся масштабировать, и сам этот центр очень скоро станет узким местом. А если он не выдержит нагрузки, вся интернет-безопасность в один момент сойдет на нет.

По этой причине было придумано новое решение, не требующее, чтобы центр распространения ключей был доступен постоянно. В общем-то, даже не требуется, чтобы он вообще работал в подключенном (онлайновом) режиме. Вместо этого на него возлагается обязанность сертификации открытых ключей, принадлежащих как физическим, так и юридическим лицам. Организация, занимающаяся сертификацией открытых ключей, в настоящее время называется Управлением сертификации (СА — Certification Authority).

В качестве примера рассмотрим такую ситуацию: Боб хочет разрешить Алисе и другим лицам устанавливать с ним защищенные соединения. Он приходит в Управление сертификации со своим открытым ключом, а также паспортом или другим удостоверением личности и просит зарегистрировать ключ. Управление выдает ему сертификат и подписывает хэш SHA-1 своим закрытым ключом. Затем Боб оплачивает услуги Управления и получает дискету с сертификатом и подписанным хэшем.

Основная задача сертификата состоит в связывании открытого ключа с именем принципала (физического или юридического лица). Сертификаты сами по себе никак не защищаются и не хранятся в тайне. Например, Боб может выложить его на свой сайт и поставить ссылку: «Здесь можно посмотреть на сертификат моего открытого ключа». Перейдя по этой ссылке, пользователь увидит и сертификат, и блок с подписью (подписанный хэш SHA-1 сертификата).

Давайте теперь снова рассмотрим сценарий, описанный в прошлом пункте. Что может сделать Труди, перехватив запрос страницы Боба, посланный Алисой? Она может выложить на странице свой собственный сертификат и блок с подписью на подложной странице, однако Алиса, читая этот сертификат, сразу догадается, что она разговаривает не с Бобом: в нем его имени просто нет. Труди может изменить домашнюю страницу Боба «на лету», заменив его открытый ключ своим собственным. И все же, проверив сертификат алгоритмом SHA-1, она получит значение хэш-функции, не согласующееся с тем, которое будет вычислено по открытому ключу Управления сертификации и блоку подписи. Так как Труди не имеет доступа к закрытому ключу Управления сертификации, она никак не может сгенерировать блок подписи, содержащий хэш модифицированной страницы с выложенным на ней открытым ключом Труди. Таким образом, Алиса может не беспокоиться о подлинности ключа Боба. И вот, как мы и обещали, при такой схеме не требуется, чтобы Управление сертификации постоянно работало в подключенном режиме. Тем самым ликвидируется потенциально узкое место системы.

Сертификат может связывать открытый ключ не только с принципалом, но и с атрибутом. Например, сертификат может содержать такую информацию:

«Данный открытый ключ принадлежит лицу старше 18 лет». Этим можно подтвердить статус принципала или убедить окружающих в том, что ему разрешен доступ к некоторым специфическим данным, на которые накладываются возрастные ограничения. При этом имя принципала может и не раскрываться. Обычно владелец сертификата отсылает его на веб-сайт, принципалу или тому процессу, который обеспокоен возрастом клиента. В ответ генерируется случайное число, шифруемое с помощью открытого ключа (считываемого с сертификата). Если клиент сможет расшифровать его и отослать обратно, это будет служить подтверждением того, что он действительно обладает указанными в сертификате характеристиками. Еще это случайное число может быть использовано в качестве сеансового ключа для будущего соединения.

Сертификат может содержать атрибут еще в одном случае: если речь идет об объектно-ориентированной распределенной системе. Каждый объект обычно обладает некоторым набором методов. Владелец объекта может предоставлять каждому клиенту сертификат с указанием тех методов, которыми он может пользоваться. Этот список в виде поразрядной карты отображения информации (битовой карты) можно связать с открытым ключом, используя подписанный сертификат. Опять же, если владелец сертификата сможет подтвердить факт обладания соответствующим закрытым ключом, он сможет воспользоваться методами, указанными в списке. Особенностью такого использования сертификатов является отсутствие необходимости указывать имя владельца. Это бывает полезно в ситуациях, когда важна конфиденциальность.

2.25. X.509

Если бы все желающие подписать что-нибудь обращались в Управление идентификации, обслуживание клиентов с разного рода документами, требующими подписи, вскоре стало бы проблемой. Во избежание этого был разработан и утвержден организацией ITU специальный стандарт сертификатов. Он называется Х.509 и широко применяется в Интернете. В свет, начиная с 1988 года, вышло уже три версии стандарта, и мы будем рассматривать новейшую из них — третью.

По сути, Х.509 — это способ описания сертификатов. Основные поля сертификата перечислены в табл. 8.3. Из описаний, приведенных в правой колонке, должно быть понятно, что для чего служит поле. За дополнительной информацией обращайтесь к RFC 2459.

Например, если Боб работает в отделе ссуд банка Money Bank, его Х.500-адрес будет выглядеть так:

/C=US/0=MoneyBank/OU=Loan/CN=Bob/

где С — страна, 0 — организация, 0U — отдел организации, CN — имя. Управление сертификации и другие сущности именуются похожим образом. Существенная проблема с системой именования Х.500 заключается в том, что если Алиса пытается соединиться с bob@moneybank.com и имеет данные сертификата с именем в этом формате, для нее вовсе не очевидно, что этот сертификат имеет отношение именно к тому Бобу, который ей нужен. К счастью, начиная с третьей версии, разрешено использование имен DNS вместо Х.500, поэтому данная проблема может счастливо разрешиться.

Сертификаты шифруются с использованием системы записи абстрактного синтаксиса 1 (ASN — Abstract Syntax Notation) OSI. Ее можно рассматривать как нечто подобное структуре в языке С, за тем исключением, что эта запись очень странная и многословная.

Таблица 3

Основные поля сертификата X.509.

Поле	Значение
Version	Версия Х.509
Serial number	Это число вместе с названием Управления сертификации однозначно идентифицирует сертификат
Signature algorithm	Алгоритм генерации подписи сертификата
Issuer	Х.500-имя Управления
Validity period	Начало и конец периода годности
Subject name	Сущность, ключ которой сертифицируется
Public key	Открытый ключ сущности и идентификатор использующего его алгоритма
Issuer ID	Необязательный идентификатор, единственным образом определяющий эмитента (создателя) сертификата
Subject ID	Необязательный идентификатор, единственным образом определяющий владельца сертификата
Extensions	Различные возможные расширения
Signature	Подпись сертификата (генерируется с помощью закрытого ключа Управления сертификации)