PAKEs — протоколы обмена ключами с парольной аутентификацией | OTUS
⚡ Подписка на курсы OTUS!
Интенсивная прокачка навыков для IT-специалистов!
Подробнее

Курсы

Программирование
C++ Developer. Professional
-5%
Scala-разработчик
-8%
Backend-разработчик на PHP
-9%
Алгоритмы и структуры данных
-9%
Team Lead
-6%
Архитектура и шаблоны проектирования Golang Developer. Professional
-5%
HTML/CSS
-11%
C# ASP.NET Core разработчик
-5%
Kotlin Backend Developer
-8%
iOS Developer. Professional
-8%
Java Developer. Professional Web-разработчик на Python MS SQL Server Developer Android Developer. Basic Разработчик программных роботов (RPA) на базе UiPath и PIX Microservice Architecture Unity Game Developer. Basic Разработчик голосовых ассистентов и чат-ботов React.js Developer Node.js Developer Интенсив «Оптимизация в Java» Супер-практикум по использованию и настройке GIT Symfony Framework Java Developer. Basic Unity Game Developer. Professional Супер-интенсив Azure
Инфраструктура
Инфраструктурная платформа на основе Kubernetes
-6%
Экспресс-курс «IaC Ansible»
-10%
Administrator Linux.Basic
-10%
Мониторинг и логирование: Zabbix, Prometheus, ELK
-10%
Экспресс-курс «CI/CD или Непрерывная поставка с Docker и Kubernetes»
-30%
Administrator Linux. Professional
-6%
Экcпресс-курс «ELK»
-10%
Экспресс-курс по управлению миграциями (DBVC)
-10%
Базы данных Network engineer Cloud Solution Architecture Highload Architect Разработчик голосовых ассистентов и чат-ботов VOIP инженер Супер-практикум по работе с протоколом BGP Супер - интенсив по паттернам проектирования Супер - интенсив по Kubernetes Супер-интенсив "Tarantool"
Специализации Курсы в разработке Подготовительные курсы
+7 499 938-92-02

PAKEs — протоколы обмена ключами с парольной аутентификацией

Crypto_Deep_16.5_site-5020-5bfb05.png

Сегодня мы поговорим о Пэйках (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.

PAKE_Setup-36085-849647.png

Клиент генерирует пароль passwd и «солевое» значение salt (случайное значение небольшой по сравнению с passwd длины). Сервер сохраняет значение соли и «зашифрованный» результат хэширования пароля с солью.

PAKE_Step1-36085-b6e911.png

Клиент и сервер генерируют общий пароль K.

PAKE_Step2-36085-d916a3.png

В конце протокола клиент и сервер проверяют, действительно ли они получили одинаковое значение сессионного ключа K. Способов такой проверки может быть несколько, вот один из них:

PAKE_verification-36085-aa817d.png

Есть два значительных недостатка протокола SRP: – отсутствие доказательства стойкости протокола, следовательно нет внятно сформулированной проблемы для криптоанализа; – невозможность реализации протокола на эллиптических кривых.

Альтернативой протоколу SRP является более эффективный протокол OPAQUE. Несмотря на свои преимущества, протокол идёт в пакете с доказательством и адаптивен к эллиптическим кривым, OPAQUE не столь широко распространен, как SRP. Однако среди практиков безопасности сети есть мнение, что OPAQUE ничем не лучше существующих решений для веб серверов.

На этом пока всё. Не забывайте оставлять свои комментарии!

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

Автор
0 комментариев
Для комментирования необходимо авторизоваться