Компьютерные сети. 6-е изд.

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. Подвержен ли этот протокол зеркальным атакам? Точно сказать нельзя. Труди удалось справиться с нашим протоколом с помощью зеркальной атаки, поскольку он позволял запустить параллельный сеанс с Бобом и ввести его в заблуждение его собственным запросом. А что произойдет, если Алиса — обычный компьютер общего назначения, принимающий параллельные сеансы связи, а не человек? Посмотрим, что Труди сможет сделать.

Чтобы понять, каким образом Труди взламывает протокол, обратимся к илл. 8.32. Алиса объявляет свои идентификационные данные в сообщении 1. Труди это сообщение перехватывает и запускает собственный сеанс, отправляя сообщение 2 и прикидываясь Бобом. Здесь мы, как и раньше, изобразили серыми прямоугольниками сообщения второго сеанса. Алиса отвечает на сообщение 2: «Ты утверждаешь, что ты Боб? Докажи» (сообщение 3). Здесь Труди заходит в тупик: она не может подтвердить, будто она — это Боб.

Что же ей делать? Она возвращается к первому сеансу, где как раз наступает ее очередь отправки запроса. При этом отправляется запрос RA, полученный в сообщении 3. Алиса любезно отвечает на это в сообщении 5, предоставляя тем самым Труди информацию, необходимую ей для создания сообщения 6 в сеансе 2. Теперь Труди может выбирать сеанс, так как она корректно ответила на запрос Алисы во втором сеансе. Сеанс 1 можно закрыть, отправить в сеансе 2 любое старое число и получить аутентифицированный сеанс связи с Алисой.

Но будучи перфекционисткой, Труди очень хочет показать, на что она способна. Вместо того чтобы отправить какое-нибудь старое число для завершения регистрации сеанса 2, она ждет, пока Алиса пришлет сообщение 7 (ее запрос для сеанса 1). Конечно, Труди понятия не имеет, как на него ответить, поэтому она вновь проводит зеркальную атаку, отправляя запрос RA2 в сообщении 8. Алиса очень кстати шифрует RA2 в сообщении 9. Труди переключается на сеанс 1 и отправляет Алисе нужное число в сообщении 10. Откуда она берет это число? Очевидно, из сообщения 9, пришедшего от Алисы. С этого момента Труди может гордиться тем, что у нее есть два полностью аутентифицированных сеанса связи с Алисой.

Илл. 8.32. Зеркальная атака протокола, показанного на илл. 8.29

Эта атака приводит к несколько иному результату, нежели протокол с тремя сообщениями, который мы видели на илл. 8.31. На этот раз Труди удается установить сразу два аутентифицированных соединения с Алисой. В предыдущем примере одно такое соединение было установлено с Бобом. Опять же, если бы протокол удовлетворял всем четырем перечисленным требованиям, эту атаку можно было бы остановить. Различные типы атак и методы борьбы с ними подробно обсуждаются в работе Берда и др. (Bird et al., 1993). В ней вы также найдете описание планомерного построения протоколов, корректность которых можно доказать. Однако даже самый простой из них довольно сложен, поэтому далее мы рассмотрим другой класс протоколов, работающих ничуть не хуже.

Итак, новый протокол аутентификации показан на илл. 8.33 (Берд и др.; Bird et al., 1993). В нем используется код аутентификации сообщения на основе хеширования (Hashed Message Authentication Code, HMAC), гарантирующий целостность и подлинность сообщения. Простой и в то же время мощный код HMAC состоит из хеша на основе сообщения и общего ключа. Отправка HMAC вместе с сообщением не позволяет злоумышленнику изменить или подделать данные: смена любого бита приведет к неправильному хешу. Кроме того, сгенерировать корректный хеш невозможно, не располагая ключом. Коды HMAC привлекательны тем, что их можно очень эффективно генерировать (быстрее по сравнению с выполнением алгоритма SHA-2 с последующим применением к результатам алгоритма RSA).

Илл. 8.33. Аутентификация с применением кодов HMAC

Для начала Алиса отправляет Бобу случайно выбранное число RA (сообщение 1). Такие случайно выбранные числа, которые применяются в протоколах безопасности только один раз, принято называть нонсами (nonce); это сокращение от английского выражения «number used once» — «однократно используемое число». Боб при ответе выбирает собственный нонс RB и высылает его вместе с кодом HMAC. Этот код формируется путем построения структуры данных, состоящей из нонсов Алисы и Боба, их идентификаторов, а также общего секретного ключа KAB. Затем вся эта структура с помощью хеш-функции (например, SHA-2) помещается в HMAC. После приема сообщения 2 у Алисы имеется значение RA (она сама его выбрала), значение RB, полученное в виде открытого текста, два идентификатора и секретный ключ KAB, который она и так знала. С помощью этих данных она может вычислить HMAC самостоятельно. Если он совпадает с кодом HMAC в сообщении, она убеждается, что говорит с Бобом. Ведь Труди не знает KAB и, следовательно, не может угадать HMAC, который следует отослать. Алиса отправляет Бобу HMAC, содержащий только два нонса.

Вопрос: может ли Труди взломать такой протокол? Нет, поскольку она не может заставить ни одну из сторон зашифровать или хешировать выбранное ею значение, как было показано на илл. 8.31 и 8.32. Оба кода HMAC содержат значения, выбранные отправителем, и Труди не способна их контролировать.

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

8.9.2. Установка общего ключа: протокол обмена ключами Диффи — Хеллмана

До сих пор мы подразумевали, что у Алисы и Боба есть общий секретный ключ. Теперь предположим, что такого ключа нет (поскольку до сих пор не разработана универсальная инфраструктура PKI для создания подписей и распространения сертификатов). Как же его установить? Алиса может позвонить Бобу и передать ключ по телефону, но Боб, скорее всего, спросит: «Как вы докажете, что вы — Алиса, а не Труди?» Можно попытаться организовать встречу, на которую каждый придет с паспортом, водительскими правами и тремя кредитными картами. Однако, будучи занятыми людьми, Алиса и Боб могут месяцами искать удобную дату. К счастью, совершенно незнакомые люди могут установить общий секретный ключ среди бела дня, даже если злоумышленник старательно записывает каждое сообщение.

Протокол, позволяющий устанавливать общий секретный ключ людям, которые друг друга не знают, называется протоколом обмена ключами Диффи — Хелл­мана (Diffie — Hellman key exchange) (Diffie and Hellman, 1976). Он работает следующим образом. Алиса и Боб договариваются о двух больших простых числах, n и g, где (n – 1)/2 также является простым числом, кроме того, на число g накладываются некоторые дополнительные ограничения. Эти числа могут быть публичными, поэтому каждый просто устанавливает значения n и g и открыто сообщает о них собеседнику. Затем Алиса выбирает большое (например, двоичное 1024-разрядное) число x и держит его в тайне. Аналогично, Боб выбирает большое секретное число y.

Алиса запускает протокол обмена ключами, отправив Бобу сообщение (открытым текстом), содержащее (n, g, gx mod n), как показано на илл. 8.34. Боб отвечает ей сообщением, содержащим gy mod n. Алиса возводит присланное Бобом число в степень x и делит его по модулю на n, получая (gy mod n)x mod n. Боб выполняет аналогичные вычисления и получает (gx mod n)y mod n. Согласно законам модульной арифметики, оба вычисления должны быть равны gxy mod n. Таким образом, как по мановению волшебной палочки, у Алисы и Боба появляется общий секретный ключ gxy mod n.

Илл. 8.34. Протокол обмена ключами Диффи — Хеллмана

Конечно, Труди видит оба сообщения. Ей известны значения g и n из первого сообщения. Если бы она могла вычислить значения x и y, ей бы удалось получить секретный ключ. Беда в том, что, зная только gx mod n, найти значение x очень трудно. На сегодняшний день неизвестен алгоритм вычисления дискретного логарифма модуля очень большого простого числа.

Для примера возьмем значения n = 47 и g = 3 (абсолютно нереалистичные). Алиса выбирает значение x = 8, а Боб — y = 10. Эти числа хранятся в секрете. Сообщение Алисы Бобу содержит числа (47, 3, 28), так как 38 mod 47 = 28. Боб отвечает Алисе числом 17. Алиса вычисляет 178 mod 47 и получает 4. Боб считает 2810 mod 47 и тоже получает 4. Таким образом, независимо друг от друга, Алиса и Боб определили, что значение секретного ключа равно 4. Чтобы найти ключ, Труди придется решить уравнение 3x mod 47 = 28. Это можно сделать путем полного перебора при использовании небольших чисел, но не в случае чисел длиной в несколько сотен битов. Сегодня все известные алгоритмы требуют для этого вычисления гигантских временных затрат, даже при использовании сверхбыстрых суперкомпьютеров с десятками миллионов ядер.

Несмотря на всю элегантность алгоритма Диффи — Хеллмана, есть одна проблема: когда Боб получит три числа (47, 3, 28), как удостовериться в том, что их отправила Алиса, а не Труди? Нет никакого способа узнать это. К сожалению, Труди может воспользоваться этим, чтобы обмануть Алису и Боба (илл. 8.35). Пока Алиса и Боб устанавливают значения x и y, Труди выбирает свое случайное число z. Алиса отсылает Бобу сообщение 1. Труди перехватывает его и вместо него отправляет Бобу сообщение 2, используя правильные значения g и n (которые передавались открытым текстом), но со своим значением z вместо x. Она также отсылает сообщение 3 обратно Алисе. Позднее Боб отправляет Алисе сообщение 4, которое Труди снова перехватывает и хранит у себя.

Илл. 8.35. Атака посредника

Теперь все занимаются вычислением остатков от деления. Алиса вычисляет значение секретного ключа gxz mod n. Те же самые подсчеты производит Труди (для общения с Алисой). Боб вычисляет gyz mod n, что также делает и Труди (для общения с Бобом). Думая, что она общается с Бобом, Алиса устанавливает ключ сеанса (с Труди), и точно так же поступает Боб. Каждое сообщение, отправляемое Алисой в шифрованном сеансе, перехватывается Труди, сохраняется, изменяется, если нужно, и отсылается (по желанию Труди) Бобу. То же самое происходит в обратном направлении. Труди видит все сообщения и может менять их по своему усмотрению, в то время как Алиса и Боб полагают, что у них имеется защищенный канал для связи друг с другом. Подобные действия злоумышленника называются «атакой посредника» или атакой типа «человек посередине» (man-in-the-middle attack)43.

8.9.3. Аутентификация с помощью центра распространения ключей

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

Другой подход состоит в том, чтобы ввести в систему доверенный Центр распространения ключей (Key Distribution Center, KDC). Им может стать, к примеру, банк или какой-либо государственный орган. При такой схеме у каждого пользователя всего один ключ, общий с KDC. Через KDC проходят операции с сеансовыми ключами и ключами аутентификации. На илл. 8.36 представлена простейшая схема такого протокола аутентификации, где присутствуют две стороны и доверенный KDC.

Илл. 8.36. Первая попытка реализации протокола аутентификации на основе KDC

У этого протокола достаточно простой принцип действия: Алиса выбирает ключ сеанса KS и уведомляет KDC о том, что она хочет поговорить с Бобом, используя KS. Это сообщение шифруется секретным ключом KA, который известен только Алисе и KDC. KDC расшифровывает это сообщение и извлекает из него идентификатор личности Боба и ключ сеанса. Затем он формирует новое сообщение, которое содержит идентификатор личности Алисы и ключ сеанса, и отправляет его Бобу. Это сообщение зашифровывается секретным ключом KB (он известен только Бобу и KDC). Расшифровав сообщение, Боб понимает, что Алиса желает с ним поговорить, и узнаёт, какой ключ она хочет использовать.

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

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

Тем временем Труди возвращается к своим темным делам. Она копирует сообщение 2 (см. илл. 8.36) и запрос на перевод денег, следующий за ним. Затем она воспроизводит оба сообщения для Боба. Боб получает их и думает: «Должно быть, Алиса снова наняла Труди. Похоже, она хорошо справляется с работой». Боб перечисляет еще столько же денег со счета Алисы на счет Труди. Получив пятидесятый запрос на перевод, Боб выбегает из офиса, чтобы найти Труди и предложить ей кредит, чтобы она могла расширить свой чрезвычайно успешный бизнес. Атаки такого рода называют атаками повторного воспроизведения (replay attack).

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

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

Более продвинутый метод взаимной аутентификации состоит в использовании многостороннего запросно-ответного протокола. Хорошо известный пример — протокол аутентификации Нидхема — Шредера (Needham — Schroeder authentication protocol) (Needham and Schroeder, 1978). Один из его вариантов показан на илл. 8.37.

Илл. 8.37. Протокол аутентификации Нидхема — Шредера

Работа протокола начинается с того, что Алиса заявляет KDC о своем желании поговорить с Бобом. Это сообщение содержит в качестве нонса большое случайно выбранное число RA. KDC отсылает обратно сообщение 2 со случайным числом Алисы, ключом сеанса и удостоверением (ticket)44, которое она может передать Бобу. Цель отправки случайного числа RA состоит в том, чтобы убедить Алису, что сообщение 2 свежее, а не повторно воспроизведенное. Идентификатор Боба также помещается в сообщение 2 на случай, если Труди вздумает заменить его идентификатор в сообщении 1 на свой, чтобы KDC зашифровал удостоверение в конце сообщения 2 ключом KT (ключ Труди) вместо KB. Удостоверение, зашифро­ванное ключом KB, помещается в зашифрованное сообщение, чтобы Труди не смогла заменить его чем-то другим, пока сообщение 2 добирается до Алисы.

Затем Алиса отсылает Бобу удостоверение вместе с новым случайным числом RA2, зашифрованным ключом сеанса KS. В сообщении 4 Боб отправляет обратно KS(RA2 – 1), чтобы доказать Алисе, что она разговаривает именно с ним. Передавать обратно KS(RA2) бессмысленно, так как Труди могла украсть это число из сообщения 3.

Получив сообщение 4, Алиса убеждается, что разговаривает с Бобом и что до сих пор повторные сообщения не использовались. Между отправкой случайного числа RA2 и получением ответа на него в виде KS(RA2 – 1) проходит достаточно мало времени. Цель сообщения 5 — убедить Боба, что он действительно разговаривает с Алисой и что в этом сеансе связи также отсутствуют повторно воспроизведенные данные. Этот протокол исключает возможность атаки повторного воспроизведения ранее записанной информации, поскольку каждая сторона формирует запрос другой стороны и получает на него ответ.

Несмотря на кажущуюся солидность протокола, у него есть небольшой недостаток. Если Труди удастся как-то раздобыть старый ключ сеанса KS, она сможет инициировать новый сеанс с Бобом, повторно воспроизведя сообщение 3 с использованием скомпрометированного ключа, и выдать себя за Алису (Деннинг и Сакко; Denning and Sacco, 1981). На этот раз Труди может украсть деньги со счета Алисы, даже не выполнив никаких услуг.

Позднее Нидхем и Шредер опубликовали протокол для исправления этой ситуации (Needham and Shroeder, 1987). В том же выпуске журнала Отуэй и Рис (Otway and Rees, 1987) представили свой протокол, решающий проблему более коротким путем. На илл. 8.38 показан слегка видоизмененный протокол ­Отуэя — Риса (Otway — Rees protocol).

В протоколе Отуэя — Риса Алиса прежде всего формирует пару случайных чисел: R, необходимое в качестве общего идентификатора, и RA, которое Алиса будет использовать в качестве запроса для Боба. Получив это сообщение, Боб формирует новое сообщение из зашифрованной части сообщения Алисы и аналогичной собственной части. Обе части сообщения, зашифрованные ключами KA и KB, идентифицируют Алису и Боба: в них содержится общий идентификатор и запрос.

Илл. 8.38. Протокол аутентификации Отуэя — Риса (в слегка упрощенном виде)

KDC сравнивает общие идентификаторы R в обеих частях сообщения. Они могут не совпадать, если Труди подменила R в сообщении 1 или заменила часть сообщения 2. Если оба числа R совпадают, KDC считает сообщение от Боба достоверным. Затем он формирует ключ сеанса KS и шифрует его дважды: для Алисы и для Боба. Каждое сообщение содержит случайное число получателя как доказательство того, что эти сообщения сгенерировал KDC, а не Труди. К этому моменту Алиса и Боб обладают одним и тем же ключом сеанса и могут начать коммуникацию. После первого же обмена данными они увидят, что обладают одинаковыми копиями ключа сеанса KS, и процесс аутентификации можно будет считать завершенным.

8.9.4. Аутентификация при помощи протокола Kerberos

Во многих реальных системах (включая Windows) применяется протокол аутентификации Kerberos, основанный на варианте протокола Нидхема — Шредера. Он назван по имени трехглавого пса из древнегреческой мифологии Кербера (или Цербера), охранявшего выход из царства Аида. Kerberos был разработан в Массачусетском технологическом институте, чтобы предоставить пользователям рабочих станций надежный доступ к сетевым ресурсам. Его основное отличие от протокола Нидхема — Шредера — предположение о довольно хорошей синхронизации всех часов в сети. Было разработано несколько версий протокола. Версия V5 наиболее широко применяется в промышленности и описана в RFC 4120. От более ранней версии V4 окончательно отказались, после того как в ней были найдены серьезные недостатки (Юй и др.; Yu et al., 2004). V5 усовершенствована по сравнению с V4 — внесено множество мелких изменений и улучшены некоторые характеристики. Например, протокол больше не опирается на устаревший DES. Более подробные сведения можно найти в книге Суда (Sood, 2012).

В работе Kerberos помимо Алисы (клиентской рабочей станции) принимают участие еще три сервера:

1. Сервер аутентификации (Authentication Server, AS): проверяет личность пользователей при входе в систему.

2. Сервер выдачи удостоверений (Ticket Granting Server, TGS): предоставляет удостоверения, подтверждающие полномочия объекта.

3. Сервер, предоставляющий услуги Алисе (Боб).

AS похож на KDC тем, что у него есть общий секретный пароль для каждого пользователя. Работа TGS состоит в выдаче удостоверений, убеждающих другие серверы в том, что обладатель удостоверения действительно является тем, за кого себя выдает.

Чтобы начать сеанс, Алиса усаживается за произвольную публичную рабочую станцию и вводит свое имя. Рабочая станция передает введенное имя и название TGS открытым текстом на AS (сообщение 1 на илл. 8.39). В ответ она получает ключ сеанса и удостоверение KTGS(A, KS, t), предназначенное для TGS. Ключ сеанса зашифровывается секретным ключом Алисы, чтобы только она могла его расшифровать. Только после получения сообщения 2 рабочая станция запрашивает пароль Алисы, и никак не раньше. С помощью этого пароля формируется ключ KA, чтобы расшифровывать сообщение 2 и извлечь из него ключ сеанса.

Илл. 8.39. Работа протокола Kerberos V5

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

После регистрации в сети Алиса может сообщить рабочей станции, что она хочет вступить в контакт с файловым сервером, то есть Бобом. Рабочая станция отсылает TGS сообщение 3 с просьбой выдать удостоверение для этого взаимодействия. Ключевым элементом запроса является удостоверение KTGS(A, KS, t), которое зашифровано секретным ключом TGS и используется для подтверждения личности отправителя. В ответном сообщении 4 TGS передает созданный им ключ сеанса KAB, которым будут пользоваться Алиса и Боб. Он возвращает две версии этого ключа. Один ключ зашифрован ключом сеанса KS, чтобы его могла прочитать Алиса. Второй ключ представляет собой еще одно удостоверение, зашифрованное ключом Боба KB (чтобы его мог прочитать Боб).

Труди может скопировать сообщение 3 и попытаться использовать его снова, но в этом ей помешает временная метка t, отправляемая вместе с этим сообщением. Труди не может заменить временную метку на более новую, так как не знает ключа сеанса KS, которым пользуется Алиса для общения с TGS. Даже если Труди очень быстро воспроизведет сообщение 3, она все равно получит в ответ лишь сообщение 4, которое она не смогла расшифровать в первый раз и не сможет расшифровать во второй.

Теперь, с помощью нового удостоверения, Алиса может отправить Бобу ключ KAB, чтобы установить с ним сеанс. Эти сообщения также содержат временные метки. Возможный ответ (сообщение 6) подтверждает, что Алиса говорит именно с Бобом, а не с Труди.

После этой серии обмена сообщениями Алиса сможет взаимодействовать с Бобом, используя ключ сеанса KAB. Если после этого Алиса решит, что ей необходим другой сервер, например Кэрол (C, Carol), она может просто отправить TGS сообщение, аналогичное третьему, заменив в нем B на C (то есть идентификатор Боба на идентификатор Кэрол). В ответ TGS мгновенно пришлет ей удостоверение, зашифрованное ключом KC. Алиса передаст его Кэрол, для которой оно будет служить гарантией подлинности Алисы.

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

Поскольку разработчики Kerberos не рассчитывали, что весь мир станет доверять единственному серверу аутентификации, они предусмотрели существование нескольких областей (realms), каждая из которых имеет свой собственный AS и TGS. Чтобы получить удостоверение для сервера, расположенного в удаленной области, Алиса должна запросить его у своего TGS, чтобы оно было принято TGS нужной ей области. Если удаленный TGS зарегистрировался на локальном TGS (так же, как это делают локальные серверы), локальный TGS выдаст Алисе удостоверение, действительное на удаленном TGS. После этого она может получить у удаленного TGS удостоверения для серверов его области. Важно отметить, что для установления защищенного сеанса между двумя сторонами из разных областей необходимо, чтобы каждая из них доверяла TGS другой стороны. Иначе они просто не смогут работать вместе.

8.9.5. Аутентификация путем шифрования с открытым ключом

Взаимная аутентификация также может выполняться с помощью шифрования с открытым ключом. Сначала Алиса должна получить открытый ключ Боба. Если PKI реализована на основе сервера каталогов, выдающего сертификаты на открытые ключи, Алиса может запросить сертификат Боба (сообщение 1 на илл. 8.40). В ответе (сообщение 2) содержится сертификат X.509 с открытым ключом Боба. Проверив корректность подписи, Алиса может отправить Бобу сообщение со своим идентификатором и нонсом.

Илл. 8.40. Взаимная аутентификация с помощью открытого ключа

Когда Боб получает это сообщение, он не знает, от кого оно пришло — от Алисы или от Труди, — но делает вид, что все в порядке, и просит сервер каталогов выдать ему открытый ключ Алисы (сообщение 4). Вскоре он его получает (сообщение 5). Затем он отсылает Алисе сообщение 6, содержащее случайное число Алисы RA, свой собственный нонс RB и предлагаемый ключ сеанса KS.

Алиса расшифровывает полученное сообщение 6 своим закрытым ключом. Она видит в нем свое случайное число RA и очень этому рада: это подтверждает, что сообщение пришло от Боба, так как Труди не способна определить значение RA. Кроме того, RA свидетельствует о свежести этого сообщения. Алиса соглашается на установление сеанса (сообщение 7). Когда Боб видит свое случайное число RB, зашифрованное ключом сеанса (который он сформировал сам), он понимает, что Алиса получила сообщение 6 и проверила значение RA. Боб счастлив.

Может ли Труди обойти этот протокол? Она может сфабриковать сообщение 3 и спровоцировать Боба на проверку Алисы, но Алиса увидит число RA, которое она не отсылала, и не ответит. Труди не удастся убедительно подделать сообщение 7, так как она не знает содержимого запроса RB или ключа KS, и не может определить их, поскольку не располагает закрытым ключом Алисы. Удача не на ее стороне.

43 Также ее называют атакой по принципу пожарной цепочки (bucket brigade attack), поскольку она напоминает действия пожарной бригады прежних времен — передачу ведер с водой от пожарной машины к месту возгорания.

44 В литературе их также называют билетами. — Примеч. ред.