Назначение протокола: безопасная аутентификация клиента на защищенных ресурсах. Защита клиента веб-сайта, даже после компроментации БД сайта.
Статус документа: запрос на обсуждение сообществом (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 Алисы (ибо имеет прямой доступ к БД Боба) и при этом контроллировать канал взаимодействия Боба и Алисы. Но даже в этом случае протокол защищает участников.