Еще больше усложняет ситуацию то, что иногда требуется восстановление отозванного сертификата. Например, если причиной отзыва была неуплата каких-либо взносов, после внесения необходимой суммы не остается никаких причин для отказа в восстановлении сертификата. Необходимость заниматься отзывом (и возможным восстановлением) сводит на нет такое ценное свойство сертификатов, как возможность их использования без обращения к 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 Бобу (тем способом, который ему понятен). Боб, конечно, не знает, от кого пришло это сообщение — от Алисы или от Труди, поэтому он выбирает большое случайное число RB и отправляет его в качестве запроса «Алисе» открытым текстом (сообщение 2). Затем Алиса шифрует это сообщение секретным ключом, общим для нее и Боба, и возвращает зашифрованный текст KAB(RB) в сообщении 3. Когда Боб видит это сообщение, он сразу понимает, что оно пришло именно от Алисы, поскольку Труди не располагает ключом KAB и потому не может сформировать такое сообщение. Более того, поскольку запрос RB выбирался случайным образом из большого пространства чисел (скажем, 128-битных), вероятность того, что Труди уже видела этот запрос и соответствующий ответ в одном из предыдущих сеансов, крайне низка. И вряд ли ей удастся подобрать правильный ответ на запрос наугад.
Илл. 8.29. Двусторонняя аутентификация с использованием запросно-ответного протокола
К этому моменту Боб уверен, что говорит с Алисой, однако она еще пока ни в чем не уверена. Алиса понимает, что Труди могла перехватить сообщение 1 и отправить обратно запрос RB. Возможно, Боба уже нет в живых. Чтобы узнать, с кем она говорит, Алиса выбирает случайное число RA и отправляет его Бобу в виде открытого текста (сообщение 4). Когда Боб возвращает ответ KAB(RA), это убеждает Алису в том, что она говорит именно с ним. После этого они могут установить временный ключ сеанса KS, который можно переслать друг другу, закодировав его все тем же общим ключом KAB.
Число сообщений в этом протоколе можно сократить, объединив в каждом из них ответ на предыдущее сообщение с новым запросом (илл. 8.30). Здесь Алиса сама в первом же сообщении отправляет запрос Бобу. Отвечая на него, Боб помещает в это же сообщение свой запрос. Таким образом, вместо пяти сообщений понадобилось всего три.
Илл. 8.30. Укороченный двусторонний протокол аутентификации
Можно ли утверждать, что этот протокол лучше изначального? С одной стороны, да, ведь он короче. Но, к сожалению, применять его не рекомендуется. При некоторых обстоятельствах Труди может атаковать этот протокол, используя зеркальную атаку (reflection attack). В частности, она может взломать его, если с Бобом можно открыть сразу несколько сеансов связи. Это вполне возможно, если Боб, скажем, является банком, который готов установить множество соединений с банкоматами одновременно.
Схема зеркальной атаки показана на илл. 8.31. Она начинается с того, что Труди, объявляя себя Алисой, отсылает запрос RT. Боб, как обычно, отвечает своим собственным запросом RB. Теперь, казалось бы, Труди в тупике. Что ей делать? Она ведь не знает KAB(RB).
Илл. 8.31. Зеркальная атака
Однако Труди может открыть второй сеанс сообщением 3 и подать в качестве запроса Бобу его собственный запрос, взятый из сообщения 2. Боб спокойно шифрует его и отсылает обратно KAB(RB) в сообщении 4. Сообщения второго сеанса выделены в нашей схеме серым цветом. Труди получила нужную информацию, поэтому она завершает первый сеанс и прерывает второй. Теперь Боб уверен, что Труди — это Алиса, поэтому предоставляет ей доступ к банковским счетам Алисы и позволяет перевести деньги с ее текущего счета на секретный счет в швейцарском банке без малейших колебаний.
Мораль истории такова:
Разработать корректный протокол аутентификации гораздо сложнее, чем это может показаться.
Следующие четыре общих правила помогают разработчикам избежать распространенных ошибок.
1. Инициатор сеанса должен подтверждать свою личность прежде, чем это сделает отвечающая сторона. Это помешает злоумышленнику получить ценную для него информацию, прежде чем он подтвердит свою личность.
2. Следует использовать два раздельных общих секретных ключа: один для инициатора сеанса, а другой для отвечающего: KAB и KʹAB.
3. Инициатор и отвечающий должны выбирать запросы из разных наборов. Например, инициатор может использовать четные числа, а отвечающий — нечетные.
4. Протокол должен уметь противостоять атакам, при которых запускается второй параллельный сеанс, информация для которого извлекается из первого сеанса (или наоборот).
Если нарушается хотя бы одно из этих правил, протокол становится уязвимым. В приведенном примере игнорировались все четыре правила, что привело к разрушительным последствиям.
Вернемся к ситуации, показанной на илл. 8.29. Подвержен ли этот протокол зеркальным атакам? Точно сказать нельзя. Труди удалось справиться с нашим протоколом с помощью зеркальной атаки, поскольку он позволял запустить параллельный сеанс с Бобом и ввести его в заблуждение его собственным запросом. А что произойдет, если Алиса — обычный компьютер общего назначения, принимающий параллельные сеансы связи, а н