Yahalom (Yahalom)

Криптографические обозначения, используемые в протоколах проверки подлинности и обмена ключами

$A$	Идентификаторы Алисы (Alice), инициатора сессии
$B$	Идентификатор Боба (Bob), стороны, с которой устанавливается сессия
$T$	Идентификатор Трента (Trent), доверенной промежуточной стороны
$K_{A},K_{B},K_{T}$	Открытые ключи Алисы, Боба и Трента
$K_{A}^{-1},K_{B}^{-1},K_{T}^{-1}$	Секретные ключи Алисы, Боба и Трента
$E_{A},\left\{...\right\}_{K_{A}}$	Шифрование данных ключом Алисы, либо совместным ключом Алисы и Трента
$E_{B},\left\{...\right\}_{K_{B}}$	Шифрование данных ключом Боба, либо совместным ключом Боба и Трента
$\left\{...\right\}_{K_{B}^{-1}},\left\{...\right\}_{K_{A}^{-1}}$	Шифрование данных секретными ключами Алисы, Боба (цифровая подпись)
$I$	Порядковый номер сессии (для предотвращения атаки с повтором)
$K$	Случайный сеансовый ключ, который будет использоваться для симметричного шифрования данных
$E_{K},\left\{...\right\}_{K}$	Шифрование данных временным сеансовым ключом
$T_{A},T_{B}$	Метки времени, добавляемые в сообщения Алисой и Бобом соответственно
$R_{A},R_{B}$	Случайные числа (nonce), которые были выбраны Алисой и Бобом соответственно

Yahalom — симметричный протокол распределения ключей с доверенным сервером. Протокол Yahalom можно рассматривать как улучшенную версию протокола Wide-Mouth Frog. Данный протокол «перекладывает» генерацию нового сессионного ключа на сторону доверенного центра, а также использует случайные числа для защиты от атак повтором.

Описание

Взаимодействие участников протокола Yahalom

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

${\textstyle (1)Alice\to \left\{A,R_{A}\right\}\to Bob}$

${\textstyle (2)Bob\to \left\{B,E_{B}(A,R_{A},R_{B})\right\}\to Trent}$

${\textstyle (3)Trent\to \left\{E_{A}(B,K,R_{A},R_{B}),E_{B}\left(A,K\right)\right\}\to Alice}$

${\textstyle (4)Alice\to \left\{E_{B}(A,K),E_{K}(R_{B})\right\}\to Bob}$

Первым сообщение Алиса инициирует сеанс, пересылая Бобу свой идентификатор $A$ и некоторое случайное число $R_{A}$:

$(1)Alice\to \left\{A,R_{A}\right\}\to Bob$

Получив сообщение от Алисы, Боб объединяет идентификатор Алисы $A$, случайное число Алисы $R_{A}$ и своё случайное число $R_{B}$ и шифрует созданное сообщение общим с Трентом ключом. После добавления к этому сообщению своего идентификатора $B$ Боб отправляет полученное сообщение Тренту:

$(2)Bob\to \left\{B,E_{B}(A,R_{A},R_{B})\right\}\to Trent$

Трент расшифровывает сообщение сообщение Боба и создаёт два сообщения. Первое сообщение включает в себя идентификатор Боба $B$, сгенерированный Трентом сессионный ключ $K$, случайное число Алисы $R_{A}$ и случайное число Боба $R_{B}$. Данное сообщение шифруется общим с Алисой ключом. Первое сообщение имеет вид:

$\left\{E_{A}(B,K,R_{A},R_{B})\right\}$

Второе сообщение шифруется общим ключом для Трента и Боба и включает в себя идентификатор Алисы　$A$ и сгенерированный Трентом сессионный ключ　$K$. Второе сообщение имеет вид:

$\left\{E_{B}(A,K)\right\}$

Трент пересылает Алисе оба созданные сообщения:

$(3)Trent\to \left\{E_{A}(B,K,R_{A},R_{B}),E_{B}\left(A,K\right)\right\}\to Alice$

Алиса получает два сообщения от Трента и расшифровывает первое из них. Расшифровав сообщение, Алиса извлекает сессионный ключ $K$ и убеждается, что случайное число переданное Трентом $R_{A}$ совпадает со случайном числом переданным Бобу на первом этапе　. После этого Алиса отправляет два сообщения Бобу. Первое сообщение является полученное от Трента сообщением, зашифрованным общим ключом для Трента и Боба. Данное сообщение состоит из идентификатора Алисы $A$ и сессионного ключа $K$:

$\left\{E_{B}(A,K)\right\}$

Второе сообщение является зашифрованным с помощью сгенерированного Трентом сессионного ключа　случайное число Боба $R_{B}$:

$\left\{E_{K}(R_{B})\right\}$

Оба сообщения Алиса отправляет Бобу:

$(4)Alice\to \left\{E_{B}(A,K),E_{K}(R_{B})\right\}\to Bob$

Боб расшифровывает первое сообщение и извлекает сессионный ключ $K$. С помощью извлечённого сессионного ключа Боб расшифровывает второе сообщение и получает случайное число $R_{B}$. Боб сверяет полученное от Алисы число со случайным числом отправленным на втором этапе.　После описанных действий стороны могут использовать новый сессионный ключ $K$}.

Протокол Yahalom помимо генерации сессионного ключа обеспечивает аутентификацию сторон:

• Аутентификация Алисы перед Бобом происходит на четвёртом этапе $(4)$, когда Боб может проверить возможность Алисы зашифровать известные только ей и Тренту случайное число $R_{A}$ на ключе $K$.

• Аутентификация Боба перед Алисой происходи на третьем этапе $(3)$, когда Трент показывает Алисе, что он получил случайное число $R_{A}$ именно от Боба (поскольку в сообщении присутствует идентификатор Боба $B$).

В результате протокола Yahalom Алиса и Боб убеждены, что общаются друг с другом, а не с неизвестной третьей стороной. В отличие от протокола Wide-Mouth Frog стороны имеют возможность убедиться, что промежуточный сервер генерирует общий секретный ключ именно для них двоих, а не для какой-то третьей стороны (хотя от полной компрометации доверенной стороны этот протокол не защищает).

Уязвимости протокола

Протокол Yahalom имеет ряд уязвимостей, которыми могут воспользоваться злоумышленники.

• В рамках протокола Боб никак не продемонстрировал, что он успешно получил новый сессионный ключ $K$ и может им пользоваться. Сообщение от Алисы на четвёртом этапе $(4)$ могло быть перехвачено или изменено злоумышленниками. Но никакого ответа Алиса от Боба уже не ожидает и уверена, что протокол завершился успешно.

• На третьем этапе $(3)$ Трент не включает случайное число $R_{B}$ в сообщение $\left\{E_{B}(A,K)\right\}$, что позволяет Алисе заставить Боба принять старый сессионный ключ. При этом протокол будет выглядеть следующем образом:

$(1)Alice\to \left\{A,R_{A}\right\}\to Bob$

$(2)Bob\to \left\{B,E_{B}(A,R_{A},R_{B})\right\}\to Trent$

Трент генерирует новый сессионный ключ $K$

$(3)Trent\to \left\{E_{A}(B,K,R_{A},R_{B}),E_{B}(A,K)\right\}\to Alice$

Алиса использует старый сессионный ключ $K^{*}$ и отправляет сообщение

$E_{B}(A,K^{*})$ из старого сеанса протокола$(4)Alice\to \left\{E_{B}(A,K^{*}),E_{K}(R_{B})\right\}\to Bob$

Модификация протокола

В статье 1989 году Берроуз (англ. Michael Burrows), Абади (англ. Martin Abadi), Нидхэм (англ. Roger Needham) предложили свой вариант протокола Yahalom:

$(1)Alice\to \left\{A,R_{A}\right\}\to Bob$

$(2)Bob\to \left\{B,R_{B},E_{B}(A,R_{A})\right\}\to Trent$

$(3)Trent\to \left\{R_{B},E_{A}(B,K,R_{A}),E_{B}\left(A,K,R_{B}\right)\right\}\to Alice$

$(4)Alice\to \left\{E_{B}(A,K,R_{B}),E_{K}(R_{B})\right\}\to Bob$

В данном варианте протокола нет необходимости использовать несертифицированный ключ, поскольку своевременность последнего сообщения гарантируется случайным числом $R_{B}$. Исчезает необходимость шифрования случайного числа Боба $R_{B}$ на втором этапе $(2)$ и в первом сообщении третьего этапа $(3)$. В результате получается тот же результат, но с меньшим количеством шифрования.

Литература

• Владимиров С.М. и др. Учебное пособие по защите информации кафедры радиотехники и систем управления МФТИ  (рус.) (6 сентября 2013).
• Шнайер Б. Прикладная криптография. Протоколы, алгоритмы, исходные тексты на языке Си = Applied Cryptography. Protocols, Algorithms and Source Code in C. — Триумф, 2002. — 816 с. — ISBN 5-89392-055-4.
• Lawrence. Relations Between Secrets: Two Formal Analyses of the Yahalom Protocol (англ.) // Journal of Computer Security. — Computer Laboratory, University of Cambridge, Pembroke Street, Cambridge CB2 3QG, UK., 2001. — Vol. 9, iss. 1 July 2001, no. 3. — P. 197—216. — doi:10.3233/JCS-2001-9302.
• M. Burrows, M. Abadi, R. Needham. A Logic of Authentication (англ.). — Digital Equipment Corp. Systems Research Center, 1989.