Протокол Station-to-Station (STS)

Протокол «Станция—станция» (STS) (Диффи, ван Оорсхот, Винер, 1992) разработан для обеспечения аутентифицированного согласования ключа без доверенной третьей стороны. Неаутентифицированный обмен по Диффи—Хеллману не обеспечивает аутентификацию: злоумышленник посередине может подменить значения DH, установив отдельные сеансы с каждой стороной, так что обе будут считать, что используют общий ключ. STS объединяет DH с цифровыми подписями и сертификатами открытых ключей, обеспечивая взаимную аутентификацию. Стороны аутентифицируют друг друга, подписывая стенограмму обмена DH и связывая ключ сеанса со своими идентичностями. STS напрямую повлиял на разработку IKE (обмена ключами для IPsec) и SSH.

Протокол STS выполняется следующим образом. Алиса и Боб согласуют группу DH (простое число p, образующий элемент g). (1) Алиса отправляет Бобу g^a mod p. (2) Боб отправляет Алисе g^b mod p, Cert_B, Sig_B{g^b, g^a}. Боб подписывает конкатенацию обоих значений DH своим закрытым ключом. (3) Алиса проверяет сертификат и подпись Боба, затем отправляет Cert_A, Sig_A{g^a, g^b}, зашифрованные ключом сеанса K = (g^ab mod p). Идентичность Алисы и её подпись зашифрованы, что обеспечивает защиту идентичности Алисы: пассивные подслушивающие не могут связать Алису с этим сеансом. Обе стороны вычисляют K = g^ab mod p и взаимно аутентифицируются с помощью подписей.

Сравнение STS с неаутентифицированным DH показывает, что даёт аутентификация. В обычном DH Мэллори перехватывает g^a и g^b, подменяет их на g^m при обмене с Алисой и на g^m при обмене с Бобом, устанавливая K1 = g^am и K2 = g^bm. Мэллори расшифровывает весь трафик. В STS Боб подписывает {g^b, g^a} — эта подпись вычислена для точных значений DH в данном сеансе. Даже если Мэллори подменит g^b на g^m, он не сможет подделать корректную подпись с помощью ключа из сертификата Боба. Алиса отклоняет сеанс. Главный вывод: аутентификация при обмене ключами должна охватывать стенограмму обмена DH, а не только заявления об идентичности.

STS обеспечивает PFS, поскольку ключ сеанса выводится из эфемерных значений DH (g^a, g^b), которые уничтожаются после сеанса. Даже если долговременный ключ подписи Боба будет позднее скомпрометирован, ранее записанные сеансы STS нельзя расшифровать: атакующему нужны эфемерные показатели степени DH a и b, которые никогда не сохранялись. Это то же свойство, которое ценится в TLS с наборами шифров ECDHE. Без эфемерного DH (например, при использовании транспортировки ключа RSA, когда ключ сеанса шифруется статическим ключом RSA сервера) компрометация долговременного ключа позволяет расшифровать все прошлые сеансы.

STS шифрует сертификат Алисы и подпись на шаге 3, обеспечивая защиту идентичности отвечающей стороны от пассивных подслушивающих. Пассивный наблюдатель видит только значение DH Алисы и сертификат Боба (который Боб отправляет в открытом виде на шаге 2). Идентичность Алисы скрыта от пассивного наблюдения. Активные злоумышленники, проводящие MITM, обнаруживаются по ошибке проверки подписи. Эта асимметрия (идентичность инициатора раскрывается активному злоумышленнику, а идентичность отвечающей стороны защищена от пассивного подслушивающего) является осознанным компромиссом проектирования: полная защита идентичности обеих сторон от активных злоумышленников требует дополнительной сложности протокола (предварительного обмена значениями DH или использования анонимных элементов группы).

IKE (обмен интернет-ключами), протокол управления ключами для IPsec, непосредственно основан на STS. IKEv1 (RFC 2409) реализовывал аутентификацию подписями в стиле STS в основном режиме. IKEv2 (RFC 7296) представляет собой более чистую переработанную версию с четырьмя потоками сообщений: IKE_SA_INIT (обмен DH, одноразовые значения), IKE_AUTH (идентичность, сертификат, подпись по стенограмме IKE_SA_INIT). Формат подписи таков: AUTH = PRF(SK_pi, transcript) при использовании PSK либо цифровая подпись над октетами IKE_SA_INIT при аутентификации по сертификату. IKEv2 также поддерживает расширяемый протокол аутентификации (EAP) для устаревшей аутентификации на основе паролей, аналогично поддержке STS различных методов аутентификации.

Аутентификация SSH по ключу использует механизм, похожий на шаг 3 STS. После обмена ключами DH (SSH_MSG_KEXDH_REPLY содержит открытый ключ сервера, значение DH и подпись над хешем обмена) клиент проверяет ключ узла сервера. При аутентификации клиента (SSH_MSG_USERAUTH_REQUEST с методом publickey) клиент подписывает {session_id, username, service, method, key_algo, public_key} своим закрытым ключом. Идентификатор сеанса выводится из стенограммы обмена DH, связывая аутентификацию с этим конкретным сеансом и предотвращая подделку между сеансами, которая была проблемой NS. SSH не использует сертификаты по умолчанию, но поддерживает их с помощью ssh-keygen -s (подписывания сертификатов) при крупных развертываниях.

STS относится к семейству SIGMA (подпись и MAC) протоколов аутентифицированного обмена ключами (AKE), формализованных Хьюго Кравчиком. SIGMA добавляет к STS MAC: каждая сторона подписывает стенограмму и вычисляет MAC своей идентичности с ключом сеанса: MAC(K, identity). MAC связывает идентичность с ключом сеанса, предотвращая конкретную атаку, при которой злоумышленник может связать подписи из разных сеансов. SIGMA-I (защита идентичности инициатора), SIGMA-R (защита идентичности отвечающей стороны) и SIGMA-0 (без защиты идентичности) — варианты этого протокола. IKEv2 и X3DH протокола Signal относятся к семейству SIGMA. Формализм SIGMA обеспечивает строгое доказательство безопасности для разработок, подобных STS.

STS уязвим к атаке KCI (имитации при компрометации ключа): если долговременный ключ Алисы скомпрометирован, атакующий может выдать себя за любую сторону перед Алисой в новом сеансе (поскольку может подделать подпись Алисы над любой стенограммой). Это означает, что компрометация ключа одной стороны позволяет злоумышленнику выдавать себя за других перед этой стороной. Атака KCI свойственна протоколам AKE на основе подписей: защита от неё требует, чтобы ключ сеанса зависел от вкладов обеих сторон таким образом, который не позволяет скомпрометированной стороне выполнять подмену. HMQV (хешированный вариант протокола Менезеса—Ку—Ванстоуна) и NAXOS обеспечивают устойчивость к KCI ценой дополнительной сложности.

STS обеспечивает неотказуемость: подписи с криптографической достоверностью доказывают, кто что сказал. Это иногда нежелательно: в частных беседах участники могут не хотеть, чтобы криптографическое доказательство их высказываний можно было представить в суде. Обмен сообщениями без записи (OTR) и двойной храповик Signal обеспечивают отрицаемость: вместо подписывания сообщений они используют ключи MAC, которыми владеют и отправитель, и получатель. После разговора обе стороны могут утверждать, что другая сторона сфабриковала сообщения, поскольку у каждой есть ключ для создания MAC. Компромисс заключается в следующем: отрицаемость приносит в жертву неотказуемость. Разработки, подобные STS, подходят там, где требуется подотчётность; OTR и Signal — там, где важна отрицаемость.

Безопасность STS была неформально проанализирована в исходной статье, но формально доказана Белларе и Рогаве (1993, 1994) в их основополагающей модели безопасности AKE. Они определили, что означает безопасность протокола обмена ключами: сеансовые ключи должны быть неотличимы от случайных, даже если злоумышленник может регистрировать стороны, раскрывать ключи сеансов, раскрывать долговременные ключи (за исключением целевого сеанса) и управлять сетью. Эта основанная на моделировании модель безопасности, расширенная Канетти—Кравчиком, а позднее UC (универсальной композицией), теперь является стандартной для доказательства безопасности протоколов AKE. TLS 1.3, Signal и Noise имеют формальные доказательства в различных версиях этой модели.

Почему STS требует включать оба значения DH (g^a и g^b) в подписываемый транскрипт?

STS объединяет эфемерный обмен ключами DH с цифровыми подписями, обеспечивая аутентифицированное согласование ключей без TTP. Обе стороны подписывают транскрипт DH, связывая аутентификацию с сеансом. STS обеспечивает совершенную прямую секретность (эфемерный DH), взаимную аутентификацию (подписи) и защиту идентичности ответчика (данные Алисы шифруются до отправки). STS непосредственно повлиял на IKEv2 и аутентификацию ключами в SSH. SIGMA формализует STS с помощью идентификационных кодов аутентификации сообщений и доказательств безопасности. KCI — присущая STS уязвимость, которую смягчают HMQV/NAXOS. Отрицаемость, как в Signal, требует заменить подписи на коды аутентификации сообщений для обеспечения аутентичности на уровне сообщений.