Главная | Обратная связь

Аннулирование ключей

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

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

В системе шифрования с открытым ключом дела обстоят несколько иначе. Если пара ключей несанкционированно раскрывается и аннулируется, не существует определенного способа информирования всех потенциальных пользователей открытого ключа о том, что ключ недействителен. В некоторых случаях открытые ключи публикуются на серверах ключей. Лицо, желающее связаться с владельцем ключа, может зайти на сервер для получения сертифицированного открытого ключа. Если ключ раскрыт и аннулирован, каким образом об этом узнает стороннее лицо? Решением этой проблемы является периодическое посещение сервера ключей для выяснения того, был ли он отменен; владелец ключа должен размещать информацию об аннулировании ключа на всех потенциальных серверах ключей. Серверы ключей должны содержать данную информацию об отмене ключей до тех пор, пока не истечет срок действия оригинального сертификата.

Доверие в информационной системе

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

Возможно, самой серьезной проблемой, связанной с доверием, является его установление и поддержание. Для обеспечения доверия в среде с открытым ключом используются две основные схемы - иерархия и сеть. У обеих схем есть как преимущества, так и недостатки.

Иерархия

Иерархическая модель доверия наиболее проста для восприятия. Говоря простым языком, в данном случае вы доверяете человеку, который находится выше в иерархической цепи, так как от него было получено соответствующее указание о необходимости доверия. На рисунке 12.12 изображена схема этой модели. Как видно из рисунка, пользователи User1 и User2 располагаются под CA1. Следовательно, если CA1 говорит, что сертификат открытого ключа принадлежит пользователю User1, пользователь User2 будет верить этому. На практике User2 передает пользователю User1 свой сертификат открытого ключа, подписанный CA1. Пользователь User1 проверяет подпись CA1 с использованием открытого ключа CA1. Так как CA1 находится в иерархии выше, чем User1, то User1 доверяет CA1 и, следовательно, доверяет сертификату пользователя User2.

Мы рассмотрели довольно простой случай. Если пользователю User1 нужно проверить информацию от пользователя User3, все несколько усложняется. CA1 не знает о пользователе User3, в отличие от CA2. Тем не менее, пользователь User1 не доверяет CA2, так как это бюро сертификатов напрямую не принадлежит цепочке пользователя User1. Следующий уровень вверх по цепочке - CA4. Пользователь User1 может верифицировать информацию от пользователя User3 посредством проверки с помощью CA4 следующим образом.

1. Пользователь User1 смотрит на сертификат пользователя User3. Он подписан в CA2.
2. Пользователь User1 получает сертификат пользователя CA2. Он подписан в CA4.
3. Так как пользователь User1 доверяет CA4, открытый ключ CA4 может использоваться для верификации сертификата CA2.
4. Как только сертификат CA2 верифицирован, пользователь User1 может верифицировать сертификат пользователя User3.
5. Как только будет верифицирован сертификат пользователя User3, пользователь User1 может использовать открытый ключ пользователя User3 для верификации данных.

Как видите, все довольно быстро усложняется. Представьте себе, какой объем операций по верификации необходимо было бы производить, если бы пользователю User1 нужно было верифицировать данные, поступившие от пользователя User4. Две цепочки не пересекаются вплоть до CA9! Так реализована сертификация в X.509. Иерархия устанавливается таким образом, чтобы между любыми двумя нижними объектами могла быть создана цепочка сертификатов.

С теоретической точки зрения все выглядит неплохо. Однако на практике все иначе. Одной из причин, по которой данная технология не функционировала, заключается в том, что не существовало реальных CA корневого уровня. CA корневого уровня - это наивысшая точка в иерархии. В одно время было принято считать, что в каждой стране должно быть свое бюро сертификатов корневого уровня. Также предполагалось, что компании, выпускающие кредитные карты, должны стать корневыми CA, или что каждая организация должна иметь свое собственное CA. На практике почти ничего не было реализовано. Возникал еще один вопрос, который представлял собой потенциальную проблему: сколько CA должны сертифицировать каждого конечного пользователя? Если конечный пользователь живет в стране А, обладает кредитной картой компании B и работает в организации C, должны ли все три объекта подписывать один и тот же сертификат?

Установка CA

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

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

Вопрос к эксперту

Вопрос. Существуют ли CA общего пользования?

Ответ. Да, существуют "общие" бюро сертификатов, предназначенные для обслуживания основной массы населения, а не определенных организаций. VeriSign (http://www.verisign.com) и Thawte (http://www.thawte.com/) являются наиболее яркими примерами таких CA. Организация может создать пару открытого ключа, например для веб-сервера, и отправить открытый ключ в CA. CA создает сертификат и предоставляет его организации. CA получает прибыль от предоставления этой услуги. Использование таких сертификатов можно наблюдать при посещении многих защищенных сайтов в интернете. Так как открытые ключи CA известны большей части веб-браузеров, сертификат веб-сайта верифицируется с помощью открытого ключа CA.

Примечание

Системы, используемые в CA, и сертификаты CA (в особенности секретные ключи CA) должны быть хорошо защищены, так как CA является "сердцем" системы. Меры, предпринимаемые для защиты секретного ключа CA, как правило, требуют, чтобы разблокировку секретного ключа производили два человека.

Как видно из списка, приведенного выше, при разработке CA возникает целый ряд вопросов. Если организация достаточно крупная или имеет большое число объектов нижних уровней (т. е. пользователей), администрирование сертификатов пользователей будет отнюдь не простой задачей. Перед подписыванием сертификата нужно будет проверить личность каждого пользователя. Срок действия сертификатов будет периодически истекать, и, следовательно, будет возникать потребность в издании новых сертификатов. Некоторые сертификаты придется аннулировать.