Компьютерные сети. 6-е изд. - Эндрю Таненбаум
Шрифт:
Интервал:
Закладка:
Кому-то это кажется выходом из положения, но некоторые считают, что лучше иметь специализированные серверы с каталогами для хранения сертификатов X.509. Такие каталоги могли бы обеспечить возможность поиска с помощью имен X.500. Например, теоретически можно представить себе службу сервера каталогов, позволяющую получать ответы на запросы типа «Дайте мне полный список всех сотрудников с именем Алиса, работающих в отделах продаж по всей стране».
Отзыв сертификата
Реальный мир полон разнообразных сертификатов — паспорта, водительские удостоверения и т.д. Иногда их необходимо аннулировать (например, водительское удостоверение объявляется недействительным за езду в нетрезвом виде). Та же проблема возникает и в мире цифровых технологий: лицо, предоставившее сертификат, может отозвать его за нарушение противоположной стороной каких-либо условий. Это необходимо делать и в том случае, если закрытый ключ сущности (а еще хуже, ключ CA) был рассекречен. Таким образом, PKI должна обеспечивать процедуру отзыва сертификата, хотя это все усложняет.
Прежде всего, CA должны периодически выпускать список отозванных сертификатов (Certificate Revocation List, CRL). В нем перечисляются их порядковые номера. Поскольку в сертификатах содержится дата окончания срока годности, в CRL следует включать номера только тех из них, срок годности которых еще не истек. По истечении срока годности сертификаты перестают быть действительными автоматически, это не то же самое, что отозванные сертификаты. В обоих случаях использовать их больше нельзя.
К сожалению, наличие CRL означает, что перед использованием сертификата нужно убедиться в том, что его нет в списке. В противном случае от него следует отказаться. При этом сертификат может быть отозван сразу после выпуска самого свежего варианта списка. Получается, что единственный надежный способ узнать о состоянии сертификата — обратиться непосредственно к CA. Эти запросы придется отсылать при каждом использовании сертификата, так как нет никакой гарантии, что его не отозвали несколько секунд назад.
Еще больше усложняет ситуацию то, что иногда требуется восстановление отозванного сертификата. Например, если причиной отзыва была неуплата каких-либо взносов, после внесения необходимой суммы не остается никаких причин для отказа в восстановлении сертификата. Необходимость заниматься отзывом (и возможным восстановлением) сводит на нет такое ценное свойство сертификатов, как возможность их использования без обращения к CA.
Где же хранить списки недействительных сертификатов? Было бы удобно хранить их там же, где и сами сертификаты. Одна из стратегий подразумевает, что CA периодически выпускает CRL и каталоги обновляются (отозванные сертификаты просто удаляются из них). Если для хранения сертификатов каталоги не используются, можно кэшировать их в разных местах в сети. Поскольку CRL сам по себе является подписанным документом, любые попытки подлога тотчас будут замечены.
Если у сертификатов большие сроки годности, CRL также будут довольно длинными. Аналогично, число заблокированных кредитных карточек будет гораздо выше, если их срок годности равен 5 годам, а не 3 месяцам. Стандартный способ борьбы с длинными списками — редко выпускать сами CRL, но часто их обновлять. Помимо прочего, это снижает необходимую для распространения CRL пропускную способность.
8.9. Протоколы аутентификации
Аутентификация — это метод, с помощью которого процесс проверяет, является ли его собеседник тем, за кого он себя выдает. Проверка подлинности удаленного процесса при активных умышленных попытках проникновения представляет собой на удивление сложную задачу и требует применения сложных протоколов, основанных на криптографии. В данном разделе мы познакомимся с несколькими протоколами аутентификации, которые используются в незащищенных компьютерных сетях.
Следует отметить, что иногда аутентификацию путают с авторизацией. Аутентификация связана с вопросом подлинности процесса, с которым происходит взаимодействие. Авторизация касается того, что этому процессу разрешено делать. Например, клиентский процесс обращается к файловому серверу и говорит: «Я процесс Скотта, и я хочу удалить файл cookbook.old». Файл-сервер должен ответить на два вопроса:
1. Действительно ли это процесс Скотта (аутентификация)?
2. Есть ли у Скотта право на удаление файла cookbook.old (авторизация)?
Только получив однозначный утвердительный ответ на оба вопроса, можно выполнить запрошенное действие. Ключевым является первый вопрос. После того как сервер узнает, с кем он разговаривает, для проверки прав доступа нужно лишь просмотреть содержимое локальных таблиц или баз данных. По этой причине в данном разделе мы сосредоточимся на аутентификации.
Общая схема, используемая практически всеми протоколами аутентификации, состоит в следующем. Алиса желает установить защищенное соединение с Бобом или считающимся надежным KDC. Затем в разных направлениях передается еще несколько сообщений. При этом Труди может их перехватить, изменить и повторно воспроизвести, чтобы обмануть Алису и Боба или просто сорвать сделку.
Тем не менее, когда протокол завершает свою работу, Алиса уверена, что разговаривает с Бобом, а он — что разговаривает с Алисой. Кроме того, в большинстве протоколов собеседники могут установить секретный ключ сеанса (session key), чтобы использовать его в предстоящем обмене информацией. На практике, по соображениям производительности, поток данных кодируется с помощью алгоритма с симметричным ключом (обычно это AES), а шифрование с открытым ключом широко применяется для самих алгоритмов аутентификации и для установления ключа сеанса.
Существует несколько причин, по которым для каждого нового соединения используется новый, случайно выбранный ключ сеанса. Это снижение количества трафика, передаваемого с использованием закрытых и открытых ключей пользователя, уменьшение объема зашифрованного текста, который может получить злоумышленник, а также минимизация вреда, причиняемого в случае, если процесс даст сбой и дамп ядра (содержимое памяти) попадет не в те руки. Желательно, чтобы при этом в процессе хранился только ключ сеанса. Все постоянные ключи должны быть удалены после установления соединения.
8.9.1. Аутентификация на основе общего секретного ключа
Для нашего первого протокола аутентификации предположим, что у Алисы и Боба есть общий секретный ключ KAB. О нем можно договориться лично или по телефону, но только не по незащищенной сети.
В основе данного протокола лежит принцип, актуальный для многих протоколов аутентификации: одна сторона отправляет другой случайное число, а та особым образом преобразует его и возвращает результат. Такие протоколы называют запросно-ответными (challenge-response). При рассмотрении протоколов аутентификации будут использоваться следующие условные обозначения:
A и B — Алиса и Боб;
Ri — запросы, где i — индекс отправителя;
Ki — ключи, где i — индекс владельца ключа;
KS — ключ сеанса.
Последовательность сообщений данного протокола аутентификации с общим ключом показана на илл. 8.29. В первом сообщении Алиса отсылает свое удостоверение личности A Бобу (тем способом, который ему понятен).
