Реализация протокола SRP на эллиптических кривых29.04.2025 09:31

Назначение протокола: безопасная аутентификация клиента на защищенных ресурсах. Защита клиента веб-сайта, даже после компроментации БД сайта.

Статус документа: запрос на обсуждение сообществом (Request For Comments).

ВНИМАНИЕ: Это учебный криптопротокол, не рекомендуется его реализовать на продуктивных системах до тех пор, пока он не пройдет экспертизу специалистами.

Назначение статьи: привлечь к первичному аудиту специалистов по эллиптическим кривым (профильных математиков и криптоаналитиков)

зачем менять оригинальный SRP? Оригинальный протокол SRPv6-a базируется на мультипликативных полях (возведение чисел в степень по простому модулю) — что требует от участников интенсивных вычислений. Так при использовании 2048-битного модуля N, операция возведения в степень требует до 3 мсек (на процессоре i3 2.6Gz). В процессе аутентификации веб-сервер вынужден делать больше вычислений, чем клиент (3 операции возведения в степень против двух у клиента), что создает угрозы отказа в обслуживании при массовом наплыве пользователей (уже от 100 пользователей/сек наблюдались проблемы с доступностью). Также это создает условия для проведения эффективных ДДОС атак. В то же время математика эллиптических кривых требует более легковестных вычислений при том же уровне стойкости, не требует использования/генерации простых чисел и более производительна (умножение точки на 256-битный скаляр занимает 25 мксек на том же оборудовании). По этим причинам автором была предпринята попытка реализовать аналог оригинального протокола на эллиптических кривых.

Участники взаимодействия: Алиса — клиент веб-сервера, Боб — веб-сервер (или его владелец) с ограниченным доступом, Ева (Eve) — пассивный слушатель сообщений, Меллори — активный злоумышленник, пытающийся вмешаться во взаимодействие Алисы и Боба, проксировать соединение, выдавая себя за Боба для Алисы, и за Алису для Боба.  Будем рассматривать наихудший сценарий, когда Меллори обладает некоторой важной информацией (он взломал Боба и теперь знает верификатор V Алисы) и полностью контролирует канал — может проксировать траффик через себя (как nginx).

Необходимые параметры взаимодействия:

i — идентификатор Алисы на сервере Боба. Это может быть логин, электронная почта или 128-битное  произвольно выбранное натуральное число .

x — секрет Алисы. Это может быть 128-битное случайно выбранное число или результат криптографического преобразования пароля Алисы: x = Scrypt (Password), где

Scrypt — адаптивная криптографическая функция формирования ключа на основе пароля, созданная офицером безопасности FreeBSD Колином Персивалем для противодействия атакам методом грубой силы.

V — точка-верификатор Алисы — точка эллиптической кривой Secp256k1, получаемая путем умножения секрета x Алисы на базовую точку кривой: V = [x]G  . Здесь и далее заглавными латинскими буквами будем обозначать точки кривой Secp256k1, а спереди, в квадратных скобках, скалярное выражение, на которое умножается точка. Например [2+6×4]G — точка, полученная путем умножения точки G на число 2+6×4 = 26.

G — базовая точка циклической подгруппы группы точек эллиптической кривой Secp256k1 (точка кручения).

HMACK (x) — функция криптографической подписи x ключом k на базе хеш-функции sha-256.

 Условия:

Предполагается, что Боб хранит точку V Алисы и её идентификатор i.

Протокол авторизации:

1. Алиса обращается к Бобу называя свой i.

2. В ответ Боб выбирает случайное 128-битное число b > 0 и направляет Алисе точку B = [b]G

3. Алиса также выбирает случайное 128-битное число a > 0, вычисляет точку A = [xa]G + [x]B = [xa + xb]G. Направляет Бобу точку A.

4.Боб вычисляет S = A — [b]V = [xa + xb]G — [bx]G = [xa]G.

5.Алиса на предыдущем шаге 3 также имеет точку S = [xa]G.

Точка S — это общая сеансовая точка связи.

Алиса и Боб генерируют сеаксовый ключ связи k = SHA-256(S.x | S.y). Здесь S.x — x-координата точки S, S.y — y-координата точки S, операция | — конкатенация параметров 256-битной функции SHA-256.

Обязательно. Теперь Алиса и Боб обмениваются доказательствами того, что они выработали одинаковый ключ k:

6. Алиса вычисляет и направляет Бобу m1 = HMACk (A|B|i|V)

7. Боб проверяет m1 вычисляет и направляет Алисе m2 = HMACk (A|B|m1)

8. Алиса проверяет m2 и если получает расхождение — разрывает связь. Боб тоже не посылает m2, разрывая связь, если он получил от Алисы иное значение m1

Поскольку A и B — это точки, то при вычислении m1 и m2 используются координаты точек: A.x, A.y и B.x, B.y.

Конец.

замечания

Фактически тут ключ сессии формирует Алиса, но передает его Бобу защищенным образом (это отличает схему от классической схемы обмена ключами Диффи-Хелмана). Также предложенная схема заставляет Алису доказать, что она реально знает x. Ибо если некий Крейг НЕ знает x, но имеет V Алисы, он сможет вычислить [xa]G = [a][x]G = [a]V, но передать Бобу корректное A не дает секретное b, т.к. далее нужно вычислить [xb]G = [b]V.

Как и прежде протокол требует 4 акта обмена информацией между Алисой и Бобом: (Алиса отправляет i, получает B, отправляет A и m1, получает m2)

Данная реализация протокола более легковесна. Теперь Боб выполняет меньше вычислений чем раньше и практически столько же, сколько и Алиса (два умножения скаляра на точку и одно сложение точек — они выполняют оба). Т.е. участники взаимодействия находятся абсолютно в равных вычислительных условиях. К тому же, математика эллиптических кривых несколько проще (в вычислительном плане) математики в мультипликативных полях, получаемые числа — меньше по порядку, а криптостойкость не меньше.

А что же Ева: сможет ли она украсть ключ сессии? Очевидно, что не зная x и V, не имея возможности извлечь скаляры a и b — Ева не сможет получить k.

Если Ева будет иметь V, то она не сможет получить ключ k. Единственный способ это сделать — повторить вычисления Боба: S = A — [b]V. Но необходимый скаляр b Боб спрятал за своей точкой B.

С другой стороны Меллори, зная V Алисы, сможет представиться перед Алисой как Боб, а вот перед Бобом выступить роли Алисы у него не получится. Здесь Меллори окажется в ситуации как с Крейгом — ему не удастся извлечь ключ сессии, который выбрала Алиса, а также он не сможет сформировать такую точку А для Боба, из которой последний мог бы извлечь корректно ключ сессии, который придумал Меллори, т.к. согласно протоколу Боб будет считать S = A — [b]V = A — [bx]G.Т. е. Меллори упрется в тот факт, что для передачи Бобу своего сессионного ключа, ему нужно знать исходное x.

Иными словами, если Меллори знает V и имеет возможность проксировать через себя весь таффик Алисы и Боба, то он НЕ сможет обмануть Боба, представившись Алисой. Но вот представиться Бобом перед Алисой он сможет.

 Многие годы последний сценарий развития взлома считался специалистами, если не невозможным, то очень маловероятным. Но с развитием облачных технологий вполне возможна ситуация, когда Меллори является владельцем датацентра, на виртуальной машине которого Боб размещает веб-сервер. Поэтому Меллори может получить верификатор V Алисы (ибо имеет прямой доступ к БД Боба) и при этом контроллировать канал взаимодействия Боба и Алисы. Но даже в этом случае протокол защищает участников.