PAKEs — протоколы обмена ключами с парольной аутентификацией
Сегодня мы поговорим о Пэйках (PAKE, Password Authenticated Key Exchange) — протоколах обмена ключами с парольной аутентификацией. Заметка основана на статье «Should you use SRP» Мэтью Грина и на оригинальной статье Томаса Ву «SPR-6: Improvements and refinements to the secure remote password protocol».
Зачем нужны Пэйки?
Возьмём север, хранящий пароли пользователей в хэшированном виде. При логине, пользователь вводит свой пароль, сервер вычисляет его хэш-значение и сверяет результат с тем, что хранится на сервере. В таком подходе есть очевидная дыра: сервер «видит» пароль пользователя в открытом виде при каждом доступе! Даже если сервер и не сохраняет пароли в открытом виде (а такое происходило), передача подразумевает наличие защищённого канала (TLS).
Криптографический примитив, позволяющий пользователю не отправлять свой пароль на сервер в открытом виде, называется PAKE. Самая распространённая реализация PAKE — SRP (Secure Remote Password), предложенная Томасом Ву в 1998 году. SRP, имеющий прототипом протокол Diffie-Hellman, используется в TLS. Ниже мы расскажем в деталях, как работает протокол SRP.
Как работает PAKE?
PAKE — особая форма протокола обмена ключами, в результате которого клиент (пользователь) и север генерируют на основе открытых данных общий ключ, используемый затем в качестве симметричного ключа. Популярный пример такого протокола -- обмен ключами Diffie-Hellman, в своей примитивной форме страдающий от атак «человек по середине». Протоколы PAKE не уязвимы к такого рода атакам и позволяют пройти аутентификацию зарегистрированному на сервере пользователю без отправки пароля.
PAKE состоит из двух шагов:
– Регистрация (sign up): новый клиент отправляет на сервер проверочный материал для своего пароля. Сервер сохраняет в базе полученный материал для данного Id. – Генерация ключа/логин: клиент и сервер генерируют общий сессионный ключ.
По сути протокол реализует доказательство с нулевым разглашением (zero-knowledge proof). SRP решает два шага PAKE следующим образом. Перед началом общения клиент и сервер располагают общими параметрами: большим простым числом N (вида N = 2*q +1, где q — простое число), g — генератором мультипликативной группы по модулю N и хэш-функцией H(). Значение k равно 3. Все вычисления проводятся по модулю N.
Клиент генерирует пароль passwd и «солевое» значение salt (случайное значение небольшой по сравнению с passwd длины). Сервер сохраняет значение соли и «зашифрованный» результат хэширования пароля с солью.
Клиент и сервер генерируют общий пароль K.
В конце протокола клиент и сервер проверяют, действительно ли они получили одинаковое значение сессионного ключа K. Способов такой проверки может быть несколько, вот один из них:
Есть два значительных недостатка протокола SRP: – отсутствие доказательства стойкости протокола, следовательно нет внятно сформулированной проблемы для криптоанализа; – невозможность реализации протокола на эллиптических кривых.
Альтернативой протоколу SRP является более эффективный протокол OPAQUE. Несмотря на свои преимущества, протокол идёт в пакете с доказательством и адаптивен к эллиптическим кривым, OPAQUE не столь широко распространен, как SRP. Однако среди практиков безопасности сети есть мнение, что OPAQUE ничем не лучше существующих решений для веб серверов.
На этом пока всё. Не забывайте оставлять свои комментарии!
