Компьютерные сети. 6-е изд.
Шрифт:
Конечно, остается проблема определения владельца корневой организации. Лучше всего иметь несколько таких структур, причем связать с каждой из них свою иерархию RA и CA. На самом деле в современные браузеры действительно «зашиваются» открытые ключи более 100 корневых CA, иногда называемые доверительными якорями (trust anchors). Как видите, можно избежать проблемы одного всемирного учреждения, занимающегося сертификацией.
Однако встает вопрос, какие доверительные якоря производители браузеров могут считать надежными, а какие — нет. На самом деле все сводится к тому, насколько конечный пользователь доверяет разработчику браузера и уверен в том, что решения генерируются грамотно,
Каталоги
PKI должна решать еще один вопрос. Он касается места хранения сертификатов (и цепочек, ведущих к какому-нибудь доверительному якорю). Можно заставить всех пользователей хранить свои сертификаты у себя. Это безопасно (так как невозможно подделать подписанные сертификаты незаметно), но не слишком удобно. В качестве каталога для сертификатов было предложено использовать DNS. Скорее всего, прежде чем соединиться с Бобом, Алисе все равно придется узнать его IP-адрес с помощью DNS. Так почему бы DNS не возвращать вместе с IP-адресом всю цепочку сертификатов?
Кому-то это кажется выходом из положения, но некоторые считают, что лучше иметь специализированные серверы с каталогами для хранения сертификатов X.509. Такие каталоги могли бы обеспечить возможность поиска с помощью имен X.500. Например, теоретически можно представить себе службу сервера каталогов, позволяющую получать ответы на запросы типа «Дайте мне полный список всех сотрудников с именем Алиса, работающих в отделах продаж по всей стране».
Отзыв сертификата
Реальный мир полон разнообразных сертификатов — паспорта, водительские удостоверения и т.д. Иногда их необходимо аннулировать (например, водительское удостоверение объявляется недействительным за езду в нетрезвом виде). Та же проблема возникает и в мире цифровых технологий: лицо, предоставившее сертификат, может отозвать его за нарушение противоположной стороной каких-либо условий. Это необходимо делать и в том случае, если закрытый ключ сущности (а еще хуже, ключ CA) был рассекречен. Таким образом, PKI должна обеспечивать процедуру отзыва сертификата, хотя это все усложняет.
Прежде всего, CA должны периодически выпускать список отозванных сертификатов (Certificate Revocation List, CRL). В нем перечисляются их порядковые номера. Поскольку в сертификатах содержится дата окончания срока годности, в CRL следует включать номера только тех из них, срок годности которых еще не истек. По истечении срока годности сертификаты перестают быть действительными автоматически, это не то же самое, что отозванные сертификаты. В обоих случаях использовать их больше нельзя.
К сожалению, наличие CRL означает, что перед использованием сертификата нужно убедиться в том, что его нет в списке. В противном случае от него следует отказаться. При этом сертификат может быть отозван сразу после выпуска самого свежего варианта списка. Получается, что единственный надежный способ узнать о состоянии сертификата — обратиться непосредственно к CA. Эти запросы придется отсылать при каждом использовании сертификата, так как нет никакой гарантии, что его не отозвали несколько секунд назад.
Еще больше усложняет ситуацию то, что иногда требуется восстановление отозванного сертификата. Например, если причиной отзыва была
Где же хранить списки недействительных сертификатов? Было бы удобно хранить их там же, где и сами сертификаты. Одна из стратегий подразумевает, что CA периодически выпускает CRL и каталоги обновляются (отозванные сертификаты просто удаляются из них). Если для хранения сертификатов каталоги не используются, можно кэшировать их в разных местах в сети. Поскольку CRL сам по себе является подписанным документом, любые попытки подлога тотчас будут замечены.
Если у сертификатов большие сроки годности, CRL также будут довольно длинными. Аналогично, число заблокированных кредитных карточек будет гораздо выше, если их срок годности равен 5 годам, а не 3 месяцам. Стандартный способ борьбы с длинными списками — редко выпускать сами CRL, но часто их обновлять. Помимо прочего, это снижает необходимую для распространения CRL пропускную способность.
8.9. Протоколы аутентификации
Аутентификация — это метод, с помощью которого процесс проверяет, является ли его собеседник тем, за кого он себя выдает. Проверка подлинности удаленного процесса при активных умышленных попытках проникновения представляет собой на удивление сложную задачу и требует применения сложных протоколов, основанных на криптографии. В данном разделе мы познакомимся с несколькими протоколами аутентификации, которые используются в незащищенных компьютерных сетях.
Следует отметить, что иногда аутентификацию путают с авторизацией. Аутентификация связана с вопросом подлинности процесса, с которым происходит взаимодействие. Авторизация касается того, что этому процессу разрешено делать. Например, клиентский процесс обращается к файловому серверу и говорит: «Я процесс Скотта, и я хочу удалить файл cookbook.old». Файл-сервер должен ответить на два вопроса:
1. Действительно ли это процесс Скотта (аутентификация)?
2. Есть ли у Скотта право на удаление файла cookbook.old (авторизация)?
Только получив однозначный утвердительный ответ на оба вопроса, можно выполнить запрошенное действие. Ключевым является первый вопрос. После того как сервер узнает, с кем он разговаривает, для проверки прав доступа нужно лишь просмотреть содержимое локальных таблиц или баз данных. По этой причине в данном разделе мы сосредоточимся на аутентификации.
Общая схема, используемая практически всеми протоколами аутентификации, состоит в следующем. Алиса желает установить защищенное соединение с Бобом или считающимся надежным KDC. Затем в разных направлениях передается еще несколько сообщений. При этом Труди может их перехватить, изменить и повторно воспроизвести, чтобы обмануть Алису и Боба или просто сорвать сделку.
Тем не менее, когда протокол завершает свою работу, Алиса уверена, что разговаривает с Бобом, а он — что разговаривает с Алисой. Кроме того, в большинстве протоколов собеседники могут установить секретный ключ сеанса (session key), чтобы использовать его в предстоящем обмене информацией. На практике, по соображениям производительности, поток данных кодируется с помощью алгоритма с симметричным ключом (обычно это AES), а шифрование с открытым ключом широко применяется для самих алгоритмов аутентификации и для установления ключа сеанса.