Как отмечено ранее в разделе 10.4 про классификацию протоколов, к симметричным будем относить те протоколы, которые используют примитивы только классической криптографии на секретных ключах. К ним относятся уже известные блочные шифры, криптографически стойкие генераторы псевдослучайных чисел (КСГПСЧ) и хеш-функции.
Протокол Wide-Mouth Frog является, возможно, самым простым протоколом с доверенным центром. Его автором считается Майкл Бэрроуз (1989 год, англ. Michael Burrows, [21], 11.2). Протокол состоит из следующих проходов.
По окончании протокола у Алисы и Боба есть общий сеансовый ключ $K$.
У данного протокола множество недостатков.
Однако самой серьёзной проблемой протокола является возможность применения следующих атак.
В 1995 году Рос Андерсон и Роджер Нидхем (англ. Ross Anderson, Roger Needham, [5], рис 11.3) предложили вариант атаки на протокол, при котором злоумышленник (Ева) может бесконечно продлевать срок действия конкретного сеансового ключа. Идея атаки в том, что после окончания протокола злоумышленник будет посылать доверенному центру назад его же пакеты (перехваченные ранее), дополняя их идентификаторами якобы инициирующего абонента.
С точки зрения доверенного центра, шаги 1, 3 и 5 являются корректными пакетами, инициирующими общение абонентов между собой. Метки времени в них корректны (если Ева будет успевать вовремя эти пакеты посылать). С точки зрения легальных абонентов каждый из пакетов является приглашением другого абонента начать общение. В результате произойдёт две вещи:
Вторая атака 1997 года Гэвина Лоу (англ. Gavin Lowe, [63], рис. 11.4) проще в реализации. В результате этой атаки Боб уверен, что Алиса аутентифицировала себя перед доверенным центром и хочет начать второй сеанс общения. Что, конечно, не является правдой, так как второй сеанс инициирован злоумышленником.
В той же работе Лоу предложил модификацию протокола, вводящую явную взаимную аутентификацию абонентов с помощью случайной метки $R_B$ и проверки, что Алиса может расшифровать пакет с меткой, зашифрованной общим сеансовым ключом абонентов $K$ (рис. 11.5). Однако данная модификация приводит к тому, что протокол теряет своё самое главное преимущество перед другими протоколами – простоту.
Протокол Yahalom можно рассматривать как улучшенную версию протокола Wide-Mouth Frog из раздела 11.1.1. Данный протокол «перекладывает» генерацию нового сессионного ключа на сторону доверенного центра, а также использует случайные числа для защиты от атак повтором.
После того, как Боб провалидирует число $R_B$, присланное Алисой, стороны смогут использовать новый сессионный ключ $K$. Протокол, кроме генерации ключа, обеспечивает взаимную аутентификацию сторон:
Нужно отметить ([3]), что в рамках протокола Боб никак не продемонстрировал, что он успешно получил новый сессионный ключ $K$ и может им оперировать (не выполнена цель G8). Сообщение от Алисы на 4-м проходе могло быть перехвачено или модифицировано злоумышленником. Но никакого ответа Алиса от Боба уже не ожидает и уверена, что протокол завершился успешно.
Также на 3-м проходе Трент не включает случайное число $R_B$ в сообщение $E_B(A, K)$, что позволяет Алисе, действуя не из лучших побуждений, заставить Боба принять старый сессионный ключ (рис. 11.7).
Протокол Yahalom послужил основной большому количеству научных работ, связанных с автоматизированным анализом стойкости криптографических протоколов и имел несколько «улучшенных» вариантов. Однако о широком использовании данного протокола в реальных информационных системах неизвестно.
Протокол Нидхема — Шрёдера (англ. Roger Needham, Michael Shroeder, 1979, [79], рис. 11.8) похож на модифицированный протокол «Wide-Mouth Frog», но отличается тем, что доверенный центр (Трент) во время работы основной части протокола не общается со вторым абонентом. Первый абонент получает от доверенного центра специальный пакет, который он без всякой модификации отправляет второму абоненту.
Протокол удобен с точки зрения сетевого взаимодействия. И общение с доверенным центром, и с конечным участником (Бобом) начинается только по инициативе первого участника (Алисы). При возникновении любых проблем передачи пакетов их видит именно то лицо, которое заинтересованно в получении ключей и доступов
. И если бы общение шло с использование протокола TCP/IP, потребовалось бы всего 2 сессии протокола TCP для выработки ключа. Причём последнюю сессию можно не закрывать, а использовать для дальнейшего взаимодействия уже с ключом $K$.
Протокол обеспечивает и двустороннюю аутентификацию сторон, и, казалось бы, защиту от атак с повторной передачей (англ. replay attack). Последнее делается с помощью введения уже известных по модифицированному протоколу «Wide-Mouth Frog» случайных меток $R_A$ и $R_B$. Действительно, без знания ключа злоумышленник не сможет выдать себя за Алису перед Бобом (так как не сможет расшифровать пакет с зашифрованной меткой $R_B$).
Относительно мелкий недостаток протокола в том, что во втором пакете доверенный центр в зашифрованном виде передаёт $E_B \left( K, A \right)$, что потом сразу в следующем, в третьем шаге пересылается по открытому каналу от Алисы к Бобу. Отказ от бессмысленного повторного шифрования чуть уменьшит нагрузку на вычислительные ресурсы доверенного центра.
Но серьёзный недостаток связан с уязвимостью протокола к атаке с известным сеансовым ключом. Если злоумышленник сумеет в какой-то момент времени получить ранее использованный сессионный ключ $K$, он сможет убедить Боба, что он является Алисой, и что это новый сессионный ключ. Для этого ему понадобится переданный ранее по открытому каналу пакет из пункта 3 протокола (рис. 11.9).
Если в протокол Нидхема — Шрёдера добавить метки времени, тем самым ограничив время возможного использования сессионного ключа, а также исправить мелкий недостаток с двойным шифрованием, можно получить протокол, который лежит в основе распространённого средства аутентификации «Kerberos» для локальных сетей.
В данном разделе будет описан протокол аутентификации сторон с единственным доверенным центром. Сетевой протокол «Ker
Как и в протоколе Нидхема — Шрёдера, инициирующий абонент (Алиса) общается только с выделенным доверенным центром, получая от него два пакета с зашифрованным сессионным ключом – один для себя, а второй – для вызываемого абонента (Боба). Однако в отличие от Нидхема — Шрёдера в рассматриваемом протоколе зашифрованные пакеты содержат также метку времени $T_T$ и срок действия сессионного ключа $L$ (от англ. lifetime – срок жизни). Что позволяет, во-первых, защититься от рассмотренной в предыдущем разделе атаки повтором. А, во-вторых, позволяет доверенному центру в некотором смысле управлять абонентами, заставляя их получать новые сессионные ключи по истечению заранее заданного времени $L$.
Обратите внимание, что на третьем проходе за счёт использования метки времени от доверенного центра $T_T$ вместо случайной метки от Боба $R_B$ позволяет сократить количество проходов на один по сравнению с протоколом Нидхема — Шрёдера. Также наличие метки времени делает ненужным и предварительную генерацию случайной метки Алисой и её передачу на первом шаге.
Метка времени $T_A$ в сообщении $E_K \left( A, T_A \right)$ позволяет Бобу убедиться, что Алиса владеет текущим сессионным ключом $K$. Если расшифрованная метка $T_A$ сильно отличается от текущего времени, значит либо этот пакет из другого сеанса протокола, либо не от Алисы вообще.
Пакеты $E_A \left( T_T, L, K, B \right)$ и $E_B \left( T_T, L, K, A \right)$ одинаковы по своему формату. В некотором смысле их можно назвать сертификатами сессионного ключа для Алисы и Боба. Причём все подобные пары пакетов можно сгенерировать заранее (например, в начале дня), выложить на общедоступный ресурс, предоставить в свободное использование и выключить доверенный центр (он своё дело уже сделал – сгенерировав эти пакеты). И до момента времени $T_T + L$ этими «сертификатами» можно пользоваться. Но только если вы являетесь одной из допустимых пар абонентов. Конечно, эта идея непрактична – ведь количество таких пар растёт как квадрат от числа абонентов. Однако интересен тот факт, что подобные пакеты можно сгенерировать заранее. Эта идея нам пригодится при рассмотрении инфраструктуры открытых ключей (англ. public key infrastructure, PKI).