SRP

Протокол SRP позволяет пользователю идентифицировать себя на сервере, при этом не передавая своего пароля, то есть подтвердить тот факт, что он знает свой пароль, и только этот факт. Он имеет ряд полезных качеств:

• устойчив к атакам перебора по словарю при прослушивании канала (что часто может иметь место), что даже позволяет использовать слабо устойчивые к перебору пароли без риска ухудшения безопасности,
• предохраняет прошедшие сессии и пароли от будущего разглашения,
• работает при условиях наличия канала, не только не защищенного от прослушивания, но и не защищенного от подмены (в том смысле, что злоумышленник не может получить никакой дополнительной информации из возможности подмены, а лишь предотвратить коммуникацию),
• не требует наличия какого-либо дополнительного защищённого канала,
• пользовательские пароли хранятся в формате, не эквивалентном открытому тексту пароля, так что злоумышленник, каким-либо образом получивший базу данных сервера, не может использовать её непосредственно для получения пароля пользователя или ложного представления пользователя в диалоге с сервером.

SRP эффективно реализует Доказательство с нулевым разглашением между пользователем и сервером, хранящим информацию о его пароле. При прослушивании за один раз злоумышленником может быть проверена только одна версия пароля, начиная с версии 6 данного протокола. Данный протокол имеет много ревизий, на данный момент последняя ревизия — 6a.

В результате работы данного протокола обе стороны получают длинный секретный ключ, проверяемый на соответствие между сторонами после получения. В случаях, когда помимо аутентификации необходимо шифрование данных, SRP предоставляет более надёжные, чем SSH, и более быстрые, чем Diffie-Hellman, средства для достижения этой цели. Протокол SRP версии 3 описывается в RFC 2945. SRP версии 6 также используется для аутентификации в SSL/TLS и других стандартах, таких как EAP и SAML, и в данный момент стандартизуется IEEE P1363 и ISO/IEC 11770-4.

Введем обозначения, необходимые для рассуждения:

• q и N = 2q + 1 выбираются так, что N и q простые. N должно быть достаточно большим, чтобы дискретное логарифмирование по модулю N было практически неосуществимо.
• Вся арифметика выполняется по модулю N (поле ${\displaystyle \mathbb {F} _{N}}$).
• g — генератор мультипликативной группы ${\displaystyle \mathbb {Z} _{N}^{*}}$
• k — параметр, получаемый на обеих сторонах, например, k = H(N, g) в ревизии 6а (в ревизии 6 k было постоянным и равно 3).
• s — соль
• I — идентификатор пользователя в системе сервера (username).
• p — пароль пользователя, соответствующий I.
• H() — криптографическая хеш-функция, например, SHA-256
• x — секретный ключ, x = H(s, p).
• v — верификатор пароля на стороне сервера, v = g^x % N
• u — произвольный параметр для кодирования.
• a,b — секретные одноразовые числа

Понятия пароля и верификатора соответствуют общепринятым понятиям секретного и открытого ключей, с двумя оговорками: пароль, как правило, меньше секретного ключа, так как его помнит пользователь, а память у него небольшого размера; в свою очередь, верификатор по математическим свойствам схож с открытым ключом, так как он легко получается из пароля, а обратная операция является вычислительно неразрешимой. Однако вместо того, чтобы быть общеизвестным, верификатор хранится сервером в тайне. Способ аутентификации, который предполагает хранение сервером верификатора, но не пароля, называется основанным на верификации (verifier-based).

Из исходных параметров вычисляются A,B (см. ниже). Сервер хранит пароли, используя следующую формулу:

• x = H(s, p) (s выбирается произвольным образом)
• v = g^x (вычисление верификатора пароля)

После этого сервер хранит пару (I, s, v) в своей базе данных. Аутентификация происходит по следующей схеме:

1. Клиент -> Сервер: I, A = g^a (идентифицируется, a — произвольное)
2. Сервер -> Клиент: s, B = kv + g^b (посылает сохраненное s, произвольное b)

На обеих сторонах: u = H(A, B)

На стороне клиента:

1. x = H(s, p) (пользователь вводит пароль)
2. S = (B — kg^x)^{(a + ux)} (вычисляется ключ сессии)
3. K = H(S) (K — это искомый ключ для шифрования)

На стороне сервера:

1. S = (Av^u)^b (вычисление ключа сессии)
2. K = H(S) (K — это искомый ключ для шифрования)

Теперь обе стороны имеют общий секретный ключ K. Для завершения аутентификации, им необходимо свериться, что их ключи совпадают. Один из возможных способов:

Клиент -> Сервер: M = H(H(N) xor H(g), H(I), s, A, B, K) и проверка на стороне сервера

Сервер -> Клиент: H(A, M, K) и проверка на стороне клиента

Речь пойдет о простых типах алгоритмов аутентификации и их уязвимостях в сравнении с данным, что покажет преимущества SRP.

Самый простой способ аутентификации — передача незашифрованного пароля от клиента к серверу, после чего сервер сравнивает полученный пароль или его хеш с элементом базы данных. Очевидный недостаток — уязвимость для прослушивания.

Модифицируя первый алгоритм, получаем аутентификацию с запросом и подтверждением (challenge-response), где обмен происходит так:

• Клиент — Сервер: username+r, где r — произвольный текст
• Сервер — Клиент: с, где с — произвольный текст (challenge)

после этого клиент вычисляет хеш от трех величин: r, c, password, и посылает его обратно. Данный метод уязвим для перебора, так как злоумышленник, имея r, c, hash, может подобрать пароль клиента.

Анализируя первые два алгоритма, можно прийти к третьему, который защищен и от перебора по словарю. Семейство таких протоколов называется Encrypted key exchange (EKE). Суть этого алгоритма в том, что обе стороны генерируют свои открытые ключи для асимметричного шифрования, и обмениваются ими с помощью симметричного алгоритма, используя известный обоим пароль пользователя как ключ. Данное семейство протоколов имеет широкое распространение, с разными реализованными модификациями, добавляющими некоторые свойства:

1. При получении пароля злоумышленник не может расшифровать обмен данными, который уже состоялся, либо при получении сессионного ключа какого-либо сеанса он не может узнать пароль пользователя (даже полным перебором), однако, по-прежнему, на сервере хранится аналог открытого текста пароля, который может быть украден для получения собственно пароля (например, DH-EKE, SPEKE).
2. При получении информации из базы данных сервера, злоумышленник не может получить из них пароль, но теряется предыдущее свойство(например, A-EKE).
3. Модификация обладает свойствами 1 и 2 за счет введения дополнительного раунда обмена ключами, однако претерпевает сильную потерю в производительности из-за значительных дополнительных вычислений.

Для того, чтобы избежать всех указанных уязвимостей и получить алгоритм с хорошей скоростью работы, была разработана концепция AKE (Asymmetric key exchange), отличающаяся от предыдущих прежде всего тем, что при передаче данных отсутствует всякое шифрование, которое избавляет систему от ненужных затрат вычислительной мощности и возможных уязвимостей определенных алгоритмов шифрования. Одной из реализаций AKE и является SRP.

• Алгоритм Диффи—Хеллмана
• Password-authenticated key agreement

• http://srp.stanford.edu/design.html - краткое описание принципов работы  (англ.)
• http://srp.stanford.edu/ndss.html - основная статья автора протокола об этом протоколе  (англ.)
• RFC 2945 SRP RFC, детально описывает схему аутентификации SRP  (англ.)
• RFC 2944 Полное описание варианта Telnet Authentication для SRP, основанная на RFC 2941, Telnet Authentication  (англ.)
• RFC 5054 Использование SRP для TLS аутентификации и обмена ключами  (англ.)