WikiDer > Протокол безопасного удаленного пароля
В Протокол безопасного удаленного пароля (SRP) является дополненным обмен ключами с аутентификацией паролем (PAKE) протокол, специально разработанный для обхода существующих патентов.[1]
Как и все протоколы PAKE, перехватчик или человек посередине не может получить достаточно информации, чтобы иметь возможность угадать перебором пароль или применить словарная атака без дальнейшего взаимодействия со сторонами для каждой догадки. Более того, поскольку это расширенный протокол PAKE, сервер не хранит данные, эквивалентные паролю.[2] Это означает, что злоумышленник, который крадет данные сервера, не может маскироваться под клиента, если сначала не выполнит поиск пароля методом грубой силы.
С точки зрения непрофессионала, во время аутентификации SRP (или любого другого протокола PAKE) одна сторона («клиент» или «пользователь») демонстрирует другой стороне («серверу»), что они знают пароль, без отправки самого пароля или каких-либо другая информация, из которой может быть получен пароль. Пароль никогда не покидает клиента и неизвестен серверу.
Кроме того, серверу также необходимо знать пароль (но не сам пароль), чтобы установить безопасное соединение. Это означает, что сервер также аутентифицируется для клиента, не полагаясь на то, что пользователь разбирает сложные URL-адреса, что предотвращает фишинг.
Обзор
Протокол SRP имеет ряд желательных свойств: он позволяет пользователю аутентифицировать себя на сервере, он устойчив к словарные атаки монтируется перехватчиком и не требует доверенная третья сторона. Он эффективно передает подтверждение пароля с нулевым разглашением от пользователя к серверу. В 6-й версии протокола можно угадать только один пароль за попытку подключения. Одним из интересных свойств протокола является то, что даже если один или два из используемых им криптографических примитивов подвергнутся атаке, он по-прежнему безопасен. Протокол SRP пересматривался несколько раз и в настоящее время находится на пересмотре 6a.
Протокол SRP создает большой закрытый ключ, совместно используемый двумя сторонами аналогично Обмен ключами Диффи – Хеллмана на стороне клиента, имеющей пароль пользователя, а на стороне сервера - криптографический верификатор, полученный из пароля. Общий открытый ключ получается из двух случайных чисел, одно сгенерированное клиентом, а другое сгенерированное сервером, которые уникальны для попытки входа в систему. В случаях, когда требуется шифрованная связь, а также аутентификация, протокол SRP более безопасен, чем альтернативный SSH протокол и быстрее, чем при использовании Обмен ключами Диффи – Хеллмана с подписанными сообщениями. Он также не зависит от третьих лиц, в отличие от Kerberos. Протокол SRP версии 3 описан в RFC 2945. SRP версии 6 также используется для надежной парольной аутентификации в SSL / TLS[3] (в TLS-SRP) и другие стандарты, такие как EAP[4] и SAML, и стандартизируется в IEEE P1363 и ISO / IEC 11770-4.
Протокол
В этом описании протокола версии 6 используются следующие обозначения:
- q и N = 2q + 1 выбраны так, чтобы оба были простыми (что делает q а Софи Жермен прайм и N а безопасный прайм). N должен быть достаточно большим, чтобы вычисление дискретных логарифмов по модулю N невозможно.
- Вся арифметика выполняется в кольце целых чисел по модулю N, . Это означает, что ниже гИкс следует читать как гИксмод N
- г это генератор мультипликативной группы .
- ЧАС() это хэш функция; например, SHA-256.
- k - параметр, полученный обеими сторонами; в СРП-6, k = 3, а в SRP-6a он получается из N и г : k = ЧАС(N, г). Он используется для предотвращения догадки 2 к 1, когда активный злоумышленник выдает себя за сервер.[5][6]
- s это маленький поваренная соль.
- я идентифицирующее имя пользователя.
- п это пароль пользователя.
- v верификатор пароля хоста, v = гИкс где как минимум Икс = ЧАС(s, п). Так как Икс вычисляется только на клиенте, можно выбрать более сильный алгоритм. Реализация могла бы использовать Икс = ЧАС(s | я | п) без влияния на какие-либо шаги, требуемые от хоста. Стандарт RFC2945 определяет Икс = ЧАС(s | ЧАС ( я | ":" | п) ). Использование я в пределах Икс предотвращает возможность вредоносного сервера узнать, два пользователя используют один и тот же пароль.
- А и B случайные одноразовые эфемерные ключи пользователя и хоста соответственно.
- | (вертикальная черта) обозначает конкатенацию.
Все остальные переменные определяются в их терминах.
Во-первых, чтобы установить пароль п с сервером Стивом клиентка Кэрол выбирает небольшой случайный поваренная соль s, и вычисляет Икс = ЧАС(s, п), v = гИкс. Стив магазины v и s, проиндексировано я, как верификатор пароля Кэрол и соль. Кэрол не должна делиться Икс с кем-либо, и должны безопасно стереть его на этом этапе, потому что это эквивалент к паролю в виде открытого текста п. Этот шаг выполняется до того, как система будет использоваться как часть регистрации пользователя у Стива. Обратите внимание, что соль s совместно используется и обменивается для согласования ключа сеанса позже, чтобы значение могло быть выбрано любой стороной, но это делает Кэрол, чтобы она могла зарегистрироваться я, s и v в одном запросе на регистрацию. Передача и аутентификация запроса на регистрацию в SRP не предусмотрены.
Затем, чтобы выполнить подтверждение пароля позже, используется следующий протокол обмена:
- Кэрол → Стив: генерировать случайное значение а; Отправить я и А = га
- Стив → Кэрол: генерировать случайное значение б; Отправить s и B = кв + гб
- И то и другое: ты = ЧАС(А, B)
- Кэрол: SКэрол = (B − кгИкс)(а + ux) = (кв + гб − кгИкс)(а + ux) = (кгИкс − кгИкс + гб)(а + ux) = (гб)(а + ux)
- Кэрол: KКэрол = ЧАС(SКэрол)
- Стив: SСтив = (Среднийты)б = (гаvты)б = [га(гИкс)ты]б = (га + ux)б = (гб)(а + ux)
- Стив: KСтив = ЧАС(SСтив) = KКэрол
Теперь у двух сторон есть общий надежный сеансовый ключ. K. Для завершения аутентификации им необходимо доказать друг другу, что их ключи совпадают. Один из возможных способов:
- Кэрол → Стив: M1 = ЧАС[ЧАС(N) XOR ЧАС(г) | ЧАС(я) | s | А | B | KКэрол]. Стив проверяет M1.
- Стив → Кэрол: M2 = ЧАС(А | M1 | KСтив). Кэрол проверяет M2.
Для успешного олицетворения этого метода требуется угадать больше общего состояния, чем просто ключ. Хотя большая часть дополнительного состояния является общедоступным, во входные данные хэш-функции можно безопасно добавлять личную информацию, например закрытый ключ сервера.[требуется разъяснение]
В качестве альтернативы при проверке только паролем вычисление K можно пропустить и поделиться S доказано:
- Кэрол → Стив: M1 = ЧАС(А | B | SКэрол). Стив проверяет M1.
- Стив → Кэрол: M2 = ЧАС(А | M1 | SСтив). Кэрол проверяет M2.
При использовании SRP для согласования общего ключа K который будет использоваться сразу же после переговоров, этапы проверки M1 и M2 можно пропустить. Сервер отклонит самый первый запрос от клиента, который он не может расшифровать. Пропуск этапов проверки может быть опасным.[нужна цитата]
Обе стороны также используют следующие гарантии:
- Кэрол прервется, если получит B = 0 (мод N) или ты = 0.
- Стив прервет работу, если получит А (мод N) = 0.
- Кэрол должна предъявить доказательство K (или S) первый. Если Стив обнаруживает, что доказательство Кэрол неверно, он должен прервать операцию, не предъявляя собственного доказательства. K (или S)
Пример реализации на Python
# Пример аутентификации SRP# ВНИМАНИЕ: Не используйте для реальных криптографических целей, кроме тестирования.# ПРЕДУПРЕЖДЕНИЕ. В приведенном ниже коде отсутствуют важные меры безопасности. Он не проверяет, что A, B и U не равны нулю.# на основе http://srp.stanford.edu/design.htmlимпорт хэшлибимпорт случайныйdef global_print(*имена) -> Никто: Икс = лямбда s: ["{}", "0x{:Икс}"][hasattr(s, "настоящий")].формат(s) Распечатать("".присоединиться("{} = {} п".формат(имя, Икс(глобалы()[имя])) для имя в имена))# Примечание: str преобразуется как есть, str ([1,2,3,4]) преобразуется в "[1,2,3,4]"def ЧАС(*аргументы) -> int: "" "Односторонняя хеш-функция." "" а = ":".присоединиться(ул(а) для а в аргументы) вернуть int(хэшлиб.Sha256(а.кодировать(«УТФ-8»)).hexdigest(), 16)def криптранд(п: int = 1024): вернуть случайный.SystemRandom().getrandbits(п) % N# Большое безопасное простое число (N = 2q + 1, где q простое число)# Вся арифметика выполняется по модулю N# (сгенерировано с использованием "openssl dhparam -text 1024")N = "" "00: c0: 37: c3: 75: 88: b4: 32: 98: 87: e6: 1c: 2d: a3: 32: 4b: 1b: a4: b8: 1a: 63: f9: 74: 8f: ed: 2d: 8a: 41: 0c: 2f: c2: 1b: 12: 32: f0: d3: bf: a0: 24: 27: 6c: fd: 88: 44: 81: 97: aa: e4: 86: a6: 3b: fc: a7: b8: bf: 77: 54: df: b3: 27: c7: 20: 1f: 6f: d1: 7f: d7: fd: 74: 15: 8b: d3: 1c: e7: 72: c9: f5: f8: ab: 58: 45: 48: a9: 9a: 75: 9b: 5a: 2c: 05: 32: 16: 2b: 7b: 62: 18: e8: f1: 42: bc: e2: c3: 0d: 77: 84: 68: 9a: 48: 3e: 09: 5e: 70: 16: 18: 43: 79: 13: a8: c3: 9c: 3d: d0: d4: ca: 3c: 50: 0b: 88: 5f: e3 "" "N = int("".присоединиться(N.Трещина()).заменить(":", ""), 16)г = 2 # Генератор по модулю Nk = ЧАС(N, г) # Параметр множителя (k = 3 в устаревшей SRP-6)Распечатать(«#. H, N, g и k известны заранее как клиенту, так и серверу:»)global_print("ЧАС", "N", "г", "к")Распечатать("0. сервер хранит (I, s, v) в своей базе паролей")# Сервер должен сначала сгенерировать верификатор пароляя = "человек" # Имя пользователяп = "пароль1234" # Парольs = криптранд(64) # Соль для пользователяИкс = ЧАС(s, я, п) # Закрытый ключv = пау(г, Икс, N) # Средство проверки пароляglobal_print("Я", "п", "s", "Икс", "v")Распечатать(«1. клиент отправляет на сервер имя пользователя I и общедоступное эфемерное значение A»)а = криптранд()А = пау(г, а, N)global_print("Я", "А") # клиент-> сервер (I, A)Распечатать("2. сервер отправляет клиенту соль пользователя и общедоступное эфемерное значение B")б = криптранд()B = (k * v + пау(г, б, N)) % Nglobal_print("s", "B") # сервер-> клиент (ы, B)Распечатать(«3. клиент и сервер вычисляют случайный параметр скремблирования»)ты = ЧАС(А, B) # Случайный параметр скремблированияglobal_print("u")Распечатать(«4. клиент вычисляет сеансовый ключ»)Икс = ЧАС(s, я, п)S_c = пау(B - k * пау(г, Икс, N), а + ты * Икс, N)K_c = ЧАС(S_c)global_print("S_c", «Кіц»)Распечатать(«5. сервер вычисляет сеансовый ключ»)S_s = пау(А * пау(v, ты, N), б, N)K_s = ЧАС(S_s)global_print("S_s", «Кіс»)Распечатать(«6. клиент отправляет на сервер подтверждение сеансового ключа»)M_c = ЧАС(ЧАС(N) ^ ЧАС(г), ЧАС(я), s, А, B, K_c)global_print("M_c")# клиент-> сервер (M_c); сервер проверяет M_cРаспечатать(«7. сервер отправляет клиенту подтверждение сеансового ключа»)РС = ЧАС(А, M_c, K_s)global_print("РС")# сервер-> клиент (M_s); клиент проверяет M_s
Выходы
#. Н, N, г, и к заранее известны как для клиента и сервера: H =N = 0xc037c37588b4329887e61c2da3324b1ba4b81a63f9748fed2d8a410c2fc21b1232f0d3bfa024276cfd88448197aae486a63bfca7b8bf7754dfb327c7201f6fd17fd7fd74158bd31ce772c9f5f8ab584548a99a759b5a2c0532162b7b6218e8f142bce2c30d7784689a483e095e701618437913a8c39c3dd0d4ca3c500b885fe3g = 0x2k = 0xb317ec553cb1a52201d79b7c12d4b665d0dc234fdbfd5a06894c1a194f818c4a0. сервер хранит (I, s, v) в пароль databaseI = personp = password1234s = 0x23c52769f89b02c0x = 0x28a914ef69978f5fe544f030bea89eab675bcaa2ec79cd36efa1d410d27d5215v = 0xa636254492ec0f7391d6b596ec926b91866775072dfd758c6ebc51bf7277ec6ca97f6cf0316d7fa90a2b9e87366cf813a53dcdc6ab303fcc932a5783f62affb7e0275189f165b8b919a2067404e6f2aa0534c99a3224a6365c1367dcd9ef005376d6f20a2b300c307f7afcedea08fb2d7a3340f13b5b9e35d52f0b82670ab17e1. клиент отправляет имя пользователя I и общественное эфемерное значение А к = Persona Сервера = 0x48147d013e3a2e08ace222a0ab914a7ed67c704b2480716b53f9d229243d1725473cf4451904658597f487b0fa8bc7d544671b25563f095bad384cbb8da7f58f7f13c8fa8bb9d6aade5fe02df288f2b38d71d51036ede52802645f82cd7216535c0c978f90230e0f878163a638cf57ad11968169c26e467b8ee14eb2ca5b16142. Сервер отправляет пользователь соль с и общественным эфемерным значением B для клиентов = 0x23c52769f89b02c0B = 0x709f340738e62e46184634acd2cd7c861a7d92c5fde9eb43ac120226a0eb6601ee5d1a0b92ffb6254170d91fb451c3c02bbf8b41f9e7e3e885d709f0dc4808048e595c68448a2111b45eefaa1e2d6a4814d99ae038a5f2371c753b312c529cada66b23e6512c7ef814683f4cfe2a4c5413c434e21bc689d869fc969141b84a613. клиент и сервер вычисляют случайный параметр скремблирования u = 0x78e4f2723b9ee5f69c7225469c70263cb39580dd4414b82ab9960def0ac9ef684. клиент вычисляет сеанс keyS_c = 0x94ea4b72b61d4330cf44f31e5c710491d41abdd6dd5b66b277bc517addbe89d9aa002645897567ae7796d1574f5d7f62cf96d2246dabfbc919cf1444d69097ceaf5476bc3964cacd52697e346f5e5a424c2c89b661d2eba34e5c7195573442195611497f606fa49639f873f385d0f6cdb9308fe2b0777d1a89bbaebe9df237a4K_c = 0x3f1e089e02b3770a5e4ab27b3a04415e54826fe4b729cd37b86fbe59b9e0d3c65. Сервер вычисляет сеанс keyS_s = 0x94ea4b72b61d4330cf44f31e5c710491d41abdd6dd5b66b277bc517addbe89d9aa002645897567ae7796d1574f5d7f62cf96d2246dabfbc919cf1444d69097ceaf5476bc3964cacd52697e346f5e5a424c2c89b661d2eba34e5c7195573442195611497f606fa49639f873f385d0f6cdb9308fe2b0777d1a89bbaebe9df237a4K_s = 0x3f1e089e02b3770a5e4ab27b3a04415e54826fe4b729cd37b86fbe59b9e0d3c66. клиент отправляет подтверждение сеансового ключа серверу M_c = 0x21d1546a18f923907b975091341316ca03bacf9cfd61b33f66d87e07eacff187. сервер отправляет подтверждение сеансового ключа клиенту M_s = 0x937ee2752d2d0a18eea2e7d4c5aa0dd0df54970f4c99fc13c75c5db3bba45643
Реализации
- OpenSSL версия 1.0.1 или новее.
- Ботан (криптобиблиотека C ++) содержит реализацию SRP-6a
- TLS-SRP набор шифров для безопасность транспортного уровня который использует SRP.
- SRP-клиент Реализация SRP-6a в JavaScript (совместим с RFC 5054), Открытый исходный код, Общественная лицензия Mozilla (MPL) лицензировано.
- В Криптографическая библиотека JavaScript включает реализацию протокола SRP на JavaScript, с открытым исходным кодом, BSD лицензированный.
- GNU Crypto обеспечить Ява реализация под лицензией Стандартная общественная лицензия GNU с «исключением библиотеки», которое разрешает его использование в качестве библиотеки вместе с несвободным программным обеспечением.
- Легион Надувного Замка предоставляет Java и C # реализации в рамках Лицензия MIT.
- Нимбус SRP - это библиотека Java, обеспечивающая генератор верификатора, клиентские и серверные сеансы. Включает интерфейсы для настраиваемого ключа пароля, процедур сообщения свидетельств клиента и сервера. Никаких внешних зависимостей. Выпущено под Лицензия Apache 2.0.
- srplibcpp является базой реализации C ++ на МИРАКЛ.
- ДраконSRP модульная реализация C ++ в настоящее время работает с OpenSSL.
- Json2Ldap обеспечивает аутентификацию SRP-6a для LDAP серверы каталогов.
- csrp Реализация SRP-6a в C.
- Крипта-SRP Реализация SRP-6a в Perl.
- pysrp Реализация SRP-6a в Python (совместим с csrp).
- py3srp Реализация SRP-6a в чистом виде Python3.
- srptools Инструменты для реализации аутентификации Secure Remote Password (SRP) в Python. Проверенные совместимые библиотеки.
- Метеор Система учетных записей веб-платформы реализует SRP для аутентификации по паролю.
- SRP-RB Реализация SRP-6a в Рубин.
- Фалькмюллер демо SRP-6a реализация Стэнфорд Дизайн протокола SRP в JavaScript и PHP под Лицензия MIT.
- srp-6a-demo Реализация SRP-6a в PHP и JavaScript.
- тонкий автобус-SRP-JS Реализация SRP-6a в JavaScript. Поставляется с совместимым Ява классы, которые используют Нимбус SRP демонстрационное приложение с использованием Весенняя безопасность. Существует также демонстрационное приложение, выполняющее аутентификацию на PHP сервер. Выпущено под Лицензия Apache.
- Стэнфордская криптографическая библиотека JavaScript (SJCL) реализует SRP для обмена ключами.
- узел-SRP - это клиентская и серверная (node.js) реализация SRP JavaScript.
- SRP6 для C # и Java реализация на C # и Java.
- ALOSRPAuth является Objective-C реализацией SRP-6a.
- Go-SRP представляет собой Go реализацию SRP-6a.
- tssrp6a представляет собой TypeScript-реализацию SRP-6a.
использованная литература
- ^ "Что такое SRP?". Стэндфордский Университет.
- ^ Шерман, Алан Т .; Ланус, Эрин; Лисков, Моисей; Зиглар, Эдвард; Чанг, Ричард; Голашевский, Энис; Внук-Финк, Райан; Bonyadi, Cyrus J .; Яксетиг, Марио (2020), Нигам, Вивек; Бан Киригин, Таджана; Талкотт, Кэролайн; Гутман, Джошуа (ред.), «Формальные методы анализа протокола защищенного удаленного пароля», Логика, язык и безопасность: очерки Андре Щедрову к 65-летию со дня рождения, Конспект лекций по информатике, Cham: Springer International Publishing, стр. 103–126, Дои:10.1007/978-3-030-62077-6_9, ISBN 978-3-030-62077-6, получено 2020-12-02
- ^ Тейлор, Дэвид; Том Ву; Никос Маврогианнопулос; Тревор Перрин (ноябрь 2007 г.). «Использование протокола защищенного удаленного пароля (SRP) для аутентификации TLS». RFC 5054
- ^ Карлсон, Джеймс; Бернар Абоба; Генри Хаверинен (июль 2001 г.). «Протокол аутентификации EAP SRP-SHA1». IETF. Проект.
- ^ Ву, Том (29 октября 2002 г.). «SRP-6: Улучшения и уточнения протокола безопасного удаленного пароля».
- ^ «Дизайн протокола SRP».
Смотрите также
- Аутентификация запрос – ответ
- Соглашение о ключах с аутентификацией паролем
- Механизм аутентификации с ответом на соленый вызов (КАТИСЬ)
- Обмен простым экспоненциальным ключом паролей
- Подтверждение пароля с нулевым разглашением
внешние ссылки
- Официальный веб-сайт
- Лицензия SRP—BSD как открытый код.
- US6539479 - Патент SRP (истек 12 мая 2015 г. из-за неуплаты сборов за обслуживание (согласно патентам Google). Первоначально истек в июле 2018 г.).
Страницы руководства
- pppd (8): Демон протокола точка-точка
- srptool (1): Простой инструмент пароля SRP
RFC
- RFC 2944 - Аутентификация Telnet: SRP
- RFC 2945 - Система аутентификации SRP и обмена ключами (версия 3)
- RFC 3720 - Интерфейс малых компьютерных систем Интернета (iSCSI)
- RFC 3723 - Защита протоколов блочного хранилища через IP
- RFC 3669 - Руководство для рабочих групп по вопросам интеллектуальной собственности
- RFC 5054 - Использование протокола защищенного удаленного пароля (SRP) для аутентификации TLS
Прочие ссылки
- IEEE 1363
- Слайды SRP интеллектуальной собственности (декабрь 2001 г. - возможно, не рекомендуется) Срок действия упомянутых патентов EKE истек в 2011 и 2013 годах.