Криптография Режимы шифрования Криптоанализ Сертификаты Брандмауэры Безопасность в беспроводных сетях Конфиденциальность электронной перепискиСтеганография


Информационная безопасность

Сертификаты

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

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

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

Сертификат может связывать открытый ключ не только с принципалом, но и с атрибутом. Сертификаты шифруются с использованием системы записи абстрактного синтаксиса 1 (ASN — Abstract Syntax Notation) OSI. PKI состоит из множества компонентов, среди которых Управления сертификации, сами сертификаты, а также каталоги. Инфраструктура систем с открытыми ключами предоставляет возможность структурной организации этих компонентов и определяет стандарты, касающиеся различных документов и протоколов. Инфраструктура систем с открытыми ключами должна решать еще один вопрос. Он касается места хранения сертификатов (и цепочек, ведущих к какому-нибудь доверительному якорю). Можно заставить всех пользователей хранить свои сертификаты у себя Где хранить списки аннулированных сертификатов? Было бы здорово хранить их там же, где и сами сертификаты. Одна из стратегий подразумевает, что УС периодически выпускает «черные» списки и заставляет вносить обновления в каталоги (удаляя отозванные сертификаты).

Результатом всех этих дискуссий было создание стандарта IPsec (IP security — IP-безопасность), описанного в RFC 2401, 2402, 2406 и др. Не всем пользователям требуется шифрация соединений (выполнение соответствующих процедур может занимать существенную часть вычислительных ресурсов). IPsec может работать в двух режимах. В транспортном режиме заголовок IPsec вставляется сразу за заголовком IP. Поле Protocol заголовка IP изменяется таким образом, чтобы было понятно, что далее следует заголовок IPsec (перед заголовком ТСР). Рассмотрим заголовок АН. Поле Следующий заголовок хранит предыдущее значение, которое в поле Протокол заголовка IP ранее было заменено на 51, чтобы показать, что далее следует заголовок АН. Альтернативой заголовку IPsec служит заголовок ESP (Encapsulating Security Payload — инкапсулированная защищенная полезная нагрузка).

Основная задача сертификата состоит в связывании открытого ключа с именем принципала (физического или юридического лица). Сертификаты сами по себе никак не защищаются и не хранятся в тайне. Например, Боб может выло-

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

Рис. 8.21. Пример сертификата и подписанного хэша

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


Безопасность в компьютерных сетях