A и B — Алиса и Боб;

R_{ — оклик, где индекс означает его отправителя;

K — ключи, где индекс означает владельца ключа;

K_S — ключ сеанса.

Последовательность сообщений нашего первого протокола аутентификации с общим ключом показана на рис. 8.28. В первом сообщении Алиса посылает свое удостоверение личности, A, Бобу тем способом, который ему понятен. Боб, конечно, не знает, пришло ли это сообщение от Алисы или от злоумышленника, поэтому он выбирает большое случайное число R_B и посылает его в качестве оклика «Алисе» открытым текстом (сообщение 2). Затем Алиса шифрует это сообщение секретным ключом, общим для нее и Боба, и отправляет шифрованный текст K_AB(R_B) в сообщении 3. Когда Боб видит это сообщение, он понимает, что оно пришло от Алисы, так как злоумышленник не должен знать ключа K_AB, и поэтому он не смог бы сформировать такое сообщение. Более того, поскольку оклик R_B выбирался случайно в большом пространстве чисел (например, 128-битных случайных чисел), очень маловероятно, чтобы злоумышленник мог уже видеть этот оклик и ответ на него в предыдущих сеансах.

Рис. 8.28. Двусторонняя аутентификация при помощи протокола оклик-отзыв

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

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

Лучше ли этот протокол, чем предыдущий? С одной стороны, да: он короче. Но, к сожалению, пользоваться таким протоколом не рекомендуется. При некоторых обстоятельствах злоумышленник может атаковать этот протокол способом, известным под названием зеркальная атака (reflection attack). В частности, Труди может взломать его, если ей будет позволено одновременно открыть несколько сеансов связи с Бобом. Такое вполне возможно, если, скажем, Боб — это банк, позволяющий устанавливать несколько одновременных соединений с банкоматами.

Схема зеркальной атаки показана на рис. 8.30. Она начинается с того, что Труди, объявляя себя Алисой, посылает оклик R_T. Боб, как обычно, отвечает своим собственным окликом R_B. Теперь, казалось бы, Труди в тупике. Что ей делать? Она ведь не

^знает K_Ab^(Rb⁾.

Рис. 8.30. Зеркальная атака

Злоумышленник может открыть второй сеанс сообщением 3 и подать в качестве оклика Бобу оклик самого Боба, взятый из второго сообщения. Боб спокойно шифрует его и посылает обратно K_Ab(R_b) в сообщении 4. Теперь у Труди есть необходимая информация, поэтому она завершает первый сеанс и прерывает второй. Боб теперь уверен, что злоумышленник — это Алиса, поэтому предоставляет Труди доступ к банковским счетам Алисы и позволяет перевести деньги с ее текущего счета на секретный счет в швейцарском банке без каких-либо колебаний.

Мораль этой истории такова:

Разработать корректный протокол аутентификации сложнее, чем это может показаться.

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

1.    Инициатор сеанса должен подтверждать свою личность прежде, чем это сделает отвечающая сторона. Это помешает злоумышленнику получить ценную для него информацию, прежде чем он подтвердит свою личность.

2.    Следует использовать два раздельных общих секретных ключа: один для инициатора сеанса, а другой для отвечающего, K_Ab и K’_Ab.

3.    Инициатор и отвечающий должны выбирать оклики из различных непересекающихся наборов. Например, инициатор должен пользоваться четными номерами, а отвечающий — нечетными.

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

Если нарушается хотя бы одно из этих правил, протокол оказывается уязвимым. В приведенном примере были нарушены все четыре правила, что привело к разрушительным последствиям.

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

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

Рис. 8.31. Зеркальная атака протокола, показанного на рис. 8.28

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

во втором сеансе. Сеанс 1 можно закрыть, переправить в сеансе 2 какое-нибудь старое число и получить в итоге заверенный сеанс связи с Алисой.

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

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