Комментарии 19
Secure Remote Password) — протокол парольной аутентификации, который позволяет пользователю вообще не отправлять пароль на сервер
Не мог понять зачем для этого такой сыр-бор городить. Аутентификация это подтверждение что клиент есть тот за кого он себя выдает, здесь - что он знает пароль. Это можно сделать проще, много вариантов challenge response protocol, не открывающих пароля. Да хоть просто случайный challenge и ответ содержащий крипто-хеш от (challenge+пароль).
Сходив в Вики, понял что это не аутентификация, а аутентифицированный паролем обмен ключом, что всё объясняет.
А чем им стандартный RSP не подошёл, что они свой вариант стали городить?
Вы правы, SRP относится к семейству Challenge Response Protocol.
В стандарте SRP (RFC 5054, который датирован 2007 годом) предусмотрено, например, использование устаревшей SHA1.
Специалисты Proton, по всей вероятности решили сделать свою реализацию более безопасной. Они используют современную SHA-512 и алгоритм Bcrypt, чтобы усложнить подбор.
Вот здесь подробнее об их подходе к реализации протокола.
Что касается варианта со случайным challenge — если я правильно вас понимаю, чтобы сличить хеш ответа, сервер все же должен хранить пароль или хеш.
SRP позволяет ни на каком этапе не показывать пароль серверу, ни во время регистрации, ни дальше. Это отличает его от простых Challenge Response протоколов.
Заметил интересные моменты в алгоритме, может не прав.
2. Сервер в ответ направляет клиенту «закреплённые» за ним параметры:
— модуль
— генератор
— соль
В этот момент Ева (Man-in-the-Middle) может подсунуть клиенту более слабые параметры.
3. Клиентское приложение генерирует приватный ключ a из допустимого диапазона 2, …, N-2 и вычисляет публичный ключ
(A не равно нулю) и отправляет его на сервер.
Тут клиент выполняет вычисления с новым слабым приватным ключом и со слабыми параметрами. Результат отправляет Еве, которая может восстановить этот слабый приватный ключ и пока просто сохранить его.
5. Чтобы убедиться, что ни одну из сторон не подменили в процессе, клиент и сервер обмениваются проверочными значениями.
Сама проверка происходит на пятом шаге. Но если посмотреть внимательнее на все вычисления, то клиент просто проводит всякие хеширования уже со своим паролем и с параметрами, которые установила или знает Ева. Потом результат снова отправляется Еве.
Вроде не критично, т.к. это не сам пароль, а обычный хеш от него, но все равно как-то не очень все выглядит.
Если клиент получит неверное значение N, на шаге сверки проверочных сообщений значения (M и M1) не сойдутся, и сессия оборвется.
В каждом сеансе связи клиент создает новый приватный ключ, поэтому параметр u — а за ним S и M будут каждый раз новые. Сохранять что-то для следующего сеанса нет смысла.
Хеш от пароля не передается. Но даже если бы Ева его получила, восстановить пароль по хешу практически невозможно — Proton использует надежную хеш функцию.
При желании клиент может записать значения N и s, которые использовались при регистрации, и сравнивать их при получении этих данных на 1-2 шагах. Но, видимо, создатели протокола посчитали это избыточным.
Чтобы сократить возможности для атак на сетевом уровне ProtonMail использует SSL Pinning.
Приватный ключ нам нужен только для следующего шага. Попробую объяснить свои мысли на грубом примере:
Ева пропускает через себя весь трафик и ждет идентификатор жертвы.
Если дождалась нужного клиента, отправляет ему, например, N=5 (можно отправлять не такое очевидное число). Т.к. клиент заходит с нового браузера, то не может проверить какие числа были при регистрации. Например, для случая N=5 у клиента небольшой выбор, это выбрать в качестве приватного ключа a=2 или a=3.
Клиент выбрал и отправил Еве публичный ключ, по нему Ева однозначно понимает какой приватный ключ выбрала жертва для текущего сеанса, т.к. остальные параметры для вычисления тоже отправляла ему Ева.
Теперь клиент хочет убедится, что этот сеанс у него с сервером. А Ева ему прислала в ответ еще один слабый параметр B (может быть тоже не таким очевидным).
Клиент вычисляет хеш М1, используя все что получал только от Евы и свой пароль. Потом отправляет этот хеш Еве.
Ева таким образом получила известный хеш от пароля жертвы даже не взламывая БД и вообще не общаясь с сервером ProtonMail.
Теперь Ева ничего не отвечая клиенту, просто разрешает ему начать новую сессию с сервером напрямую и уже не вмешивается.
Сама в это время запускает параллельные переборы на кластере.
Ладно, концовку я нафантазировал, но на самом деле, если есть ресурсы и жертва важна, журналист там или информатор ничего не заметят. Просто куча лишних действий, если твое положение дошло до того, что ты не доверяешь обычному https и хешам в базе, то такая схема тебя тоже не спасет.
Спасибо за пояснение.
Такая атака действительно возможна, и от неё есть защита: сообщение сервера с параметром N подписано долговременным приватным ключом сервера. Клиент проверяет подпись с помощью публичного ключа, который зашит в код клиента. У Евы нет к нему доступа. Это защита от подмены сообщения.
Таким образом пароль защищён даже от теоретической возможности компрометации.
У вас всегда g = 2 при разных N. Вообще g - обязан быть примитивным корнем из N, а не просто какое то там простое число. И не для любого простого N = 2q+1 число 2 является примитивным корнем.
Почему вы не взяли значения модулей и генераторов из официального RFC, протокола (из. приложений)? А решили, что все знаете, и имеете право самовольно менять протокол? Вы хоть осознаете, что внося даже мельчайшие нюансы в реализацию в криптопротокола, вы можете серьезно нарушить его стойкость? Обратите внимание, что автор оригинального протокола не с первой попытки закончил его проектировать. Понадобилось аж 6 редакций. И независимая проверка его коллегами. Текущая вессия протокола - 6a. Почитайте оригинальную статью проф. Ву, где он обосновывает те или иные принятые им решения. Вот скажите, зачем в протоколе был принят скремблер u = H(A,B)? какую роль он играет? И почему форма модуля была выбрана автором как N = 2q+1 (где q - тоже простое число)?
Где исследования вашей переделки в профессиональном сообществе криптографов? Или вы свято верите, что ваши специалисты по криптографии самые крутые в мире, что могут вот так левой пяткой не приседая со штангой изобрести новый протокол ? Как вы формировали N? они точно все простые (или раскладываются внезапно на делители - как это проверяли) ? Вы хоть знаете сколько таких вот историй взлома было, когда разработчики забивали на ньансы протоколов и получали эпические фейлы. Как думаете почему защиту Sony взломали? Потому что конкретный программист забил болт на требование генерации уникального k, в момент формирования полписи. Он решил, что чуть умнее тех людей, кто алгоритм ECDSA придумал. Оказалось - он глупее.
Выше вам человек отписал, чем опасны игры с произвольными N. И это только поверхностный анализ вашей переделки. А если копнуть еще глубже...
Вы абсолютно правы в том, что криптографические протоколы требуют строгого соблюдения стандартов. Отклонения от рекомендованных значений без должного анализа могут привести к уязвимостям. И мне очень льстит, что вы приняли меня за разработчика ProtonMail версии протокола SRP, но это не так :)
В своей статье я описывал существующую реализацию SRP от ProtonMail на языке Go. А сама статья возникла в результате портирования Go-реализации на C# для использования в нашем почтовом клиенте, чтобы поддерживать ProtonMail. Эта реализация уже включала определённые изменения по сравнению с оригинальным протоколом SRP-6a, такие как использование bcrypt вместо SHA-1, генератор g=2 и другие параметры. Эти решения были приняты командой ProtonMail с целью повышения безопасности и соответствия их внутренним стандартам безопасности.
Если вы хотите более подробно ознакомиться с обоснованием выбора параметров в реализации ProtonMail, рекомендую прочитать статью на официальном блоге ProtonMail: Encrypted Email Authentication.
Если у вас всё ещё останутся вопросы к реализации ProtonMail, прошу задать их напрямую на GitHub с их реализацией: ProtonMail Go SRP.
Ещё раз благодарю за ваш отзыв и за то, что подчеркнули важность точности в вопросах криптографической безопасности.
А в чём преимущество над стандартным TLS?
защита от MitM? Кажется, что эта схема не может быть лучше.
защита от слива базы? Эта схема позволяет имея только «серверные» данные узнать, является ли тот или иной пароль правильным. Ну а дальше делается обычный брутфорс, не вижу особенных преимуществ над обычными хорошо солеными хешами.
защита от недоверенного сервера? TLS гарантирует аутентичность, а дальше если хоть какие данные в нешифрованном виде вдруг бывают на недоверенном сервере, то можно их смело считать раскрытыми. Тут только всё шифрование на клиенте выполнять — но про это как раз в конце сказали.
Разве что здесь строго доказано, что брутфорс нельзя облегчить какой-нибудь уязвимостью в алгоритме хеширования. Но стоит ли оно того? Если вдруг злоумышленник получил доступ к базе с паролями, то имеет смысл считать, что все менее защищенные данные уже скомпрометированы. Тут остается только попытаться защитить сам пароль пользователя, но если он вдруг использует один на нескольких сервисах, то надёжность этого пароля определяется надёжностью самого уязвимого сервиса.
TLS и SRP все же не взаимозаменяемые протоколы. Задача TLS обеспечить безопасное соединение, но он не гарантирует, что пересылаемые данные не опасны сами по себе. SRP позволяет клиенту не пересылать опасные данные.
Если присмотреться к спецификации SRP, можно увидеть, что он не призван заменить TLS. Наоборот, его дополняет и усиливает, заменяя собой устаревшие протоколы аутентификации. Собственно ProtonMail использует TLS автоматически при подключении через https.
Прелесть SRP в том, что пароль никогда не попадает на сервер и все вычисления выполняются на клиенте. Обычная парольная аутентификакция предполагает, что хеш не только хранится, но и вычисляется на сервере — то есть в момент регистрации сервер видит пароль. Ни один протокол не защищает от всех видов атак. Конечно, если у злоумышленников есть база с паролями, украденная с менее защищенного сервера, то их задача на этом этапе решена. Тут вы правы.
Но SRP значительно повышает уровень доверия к серверу. Вот, что пишет ProtonMail на эту тему (в вольном переводе):
«Наша основная гипотеза состоит в том, что все серверы могут быть скомпрометированы. Рано или поздно ProtonMail также будет скомпрометирован. Такие инциденты не единичны и постепенно станут нормой в течение следующего десятилетия. Это фундаментальная философия нашей архитектуры с нулевым разглашением. Даже если ProtonMail скомпрометирован и действует злонамеренно, информация, эквивалентная паролю, никогда не раскрывается. Таким образом, с SRP безопасность Proton Mail значительно усилена против MITM-атак».
Таким образом, в конечной группе с умножением обратная операция представляет собой «сложную вычислительную задачу», которую можно решить только самым неэффективным способом — полным перебором всех возможных вариантов n.
Для полей вычетов по простому модулю расширенный алгоритм Эвклида быстро считает обратные значения. Вот, прям только вчера в одной комбинаторной ACM задачке использовал (в комбинаторных ACM задачах часто итоговый ответ надо выразить по модулю простого числа - а тогда деление приходится заменить на умножение на обратное). Для других групп и умножений зачастую тоже есть способы быстрее полного перебора и/или нет доказательства, что таких алгоритмов нет.
Вы правы, для многих задач есть более эффективные способы решения, нежели полный перебор. Для решения задачи дискретного логарифмирования, факторизации и других есть алгоритмы с экспоненциальной и субэкспоненциальной сложностью. Но мы в начале предупредили, что статья не для специалистов, и будут упрощения. Хотелось объяснить основные принципы на простых примерах и сохранить объем статьи в разумных пределах.
Малая теорема Ферма: p^(n-1)(mod m) = 1. Используйте для вычисления обратных чисел в поле F(m)
Принципиальное решение возможно в децентрализованной архитектуре, где факт владения приватным ключом и есть аутентификация. Никакие параметры не привязаны к профилю в базе данных — ни профиля, ни базы, ни сервера не существует.
если сервера нет, где тогда хранятся письма?
Eppie — работает в одноранговой p2p сети. То есть все подключенные устройства участвуют в хранении и пересылке писем.
Письмо шифруется, разбирается на фрагменты, и отправляется в сеть. Зашифрованные фрагменты хранятся на случайных узлах сети (в том числе на устройствах пользователях). Самый известный пример такой архитектуры — торренты. Но есть и другие технологии, работающие по этому принципу, например IPFS (https://ipfs.tech/).
Дальше получатель письма с помощью своего приватного ключа может скачать фрагменты из сети, восстановить письмо и расшифровать его.
В идеале вся нагрузка по передаче и хранению распределяется между устройствами пользователей. Они и есть инфраструктура. Но на практике, например, мобильные устройства не могут участвовать в этом процессе на равных с десктопами. Поэтому, чтобы компенсировать недостающий для функционирования сети объём хранилища, мы будем запускать служебные ноды (в том числе IPFS) на арендованной инфраструктуре. C технической точки зрения это будут такие же клиенты сети, как любой живой пользователь.
Доказательство с нулевым разглашением на примере реализации SRP в ProtonMail