Jump to content

Соглашение о ключах, подтвержденное паролем

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

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

Соглашение о ключах, проверяемых паролем, обычно включает в себя такие методы, как:

  • Сбалансированный обмен ключами с аутентификацией по паролю
  • Расширенный обмен ключами с аутентификацией по паролю
  • Получение ключа с аутентификацией паролем
  • Многосерверные методы
  • Многопартийные методы

В наиболее строгих моделях безопасности, основанных только на пароле, пользователю метода не требуется запоминать какие-либо секретные или общедоступные данные , кроме пароля.

Обмен ключами с аутентификацией по паролю (PAKE) — это метод, при котором две или более стороны, основываясь только на их знании общего пароля, [1] установить криптографический ключ с помощью обмена сообщениями, чтобы неавторизованная сторона (тот, кто контролирует канал связи, но не владеет паролем) не могла участвовать в этом методе и была максимально ограничена от подбора пароля методом перебора. (Оптимальный случай дает ровно одно предположение за один сеанс обмена.) Две формы PAKE — это сбалансированные и расширенные методы. [1]

Сбалансированный ПАКЕ

[ редактировать ]

Сбалансированный PAKE предполагает, что две стороны в ситуации клиент-клиент или клиент-сервер используют один и тот же секретный пароль для согласования и аутентификации общего ключа. [1] Примеры:

  • Зашифрованный обмен ключами (EKE)
  • ПАК и ППК [2]
  • SPEKE (Простой экспоненциальный обмен ключами для паролей)
  • Протокол безопасного удаленного пароля на основе эллиптической кривой (EC-SRP или SRP5) [3] Существует бесплатная реализация карты Java. [4]
  • Стрекоза — стандарт IEEE 802.11-2012, RFC 5931, RFC 6617.
  • CPace [5]
  • СПАК1 и СПАК2 [6] [7]
  • СЕСПАК – RFC 8133
  • J-PAKE (обмен ключами с аутентификацией паролем путем жонглирования) – ISO/IEC 11770-4 (2017), RFC 8236
  • МСЭ-Т Рекомендация X.1035
  • «Расширенное модульное рукопожатие для согласования ключей и дополнительной аутентификации» [8]

Дополненный ПАКЕ

[ редактировать ]

Расширенный PAKE — это вариант, применимый к сценариям клиент/сервер, в которых сервер не хранит данные, эквивалентные паролю. Это означает, что злоумышленник, укравший данные сервера, по-прежнему не сможет замаскироваться под клиента, если сначала не выполнит перебор пароля.Некоторые расширенные системы PAKE используют не обращающую внимания псевдослучайную функцию для смешивания секретного пароля пользователя с секретным значением соли сервера, так что пользователь никогда не узнает секретное значение соли сервера, а сервер никогда не узнает пароль пользователя (или значение, эквивалентное паролю) или последний ключ. [9]

Примеры включают в себя:

  • AMP
  • Дополненный-EKE
  • Б-СПИК
  • ПАК-Х [2]
  • рекомендуемая розничная цена [а]
  • АугПАКЕ [11]
  • НЕПАКОВЫЙ [12] [13] [14]
  • AuCPace [15]
  • СПАК2+ [16]
  • «Расширенное модульное рукопожатие для согласования ключей и дополнительной аутентификации» [8]

Получение ключа

[ редактировать ]

Получение ключа с аутентификацией по паролю — это процесс, в котором клиент получает статический ключ в ходе согласования на основе пароля с сервером, которому известны данные, связанные с паролем, например методы Форда и Калиски. В наиболее строгих условиях одна сторона использует только пароль в сочетании с N (двумя или более) серверами для получения статического ключа. Это выполняется таким образом, чтобы защитить пароль (и ключ), даже если N − 1 серверов будут полностью скомпрометированы.

Краткая история

[ редактировать ]

Первыми успешными методами согласования ключей с аутентификацией по паролю были методы зашифрованного обмена ключами, описанные Стивеном М. Белловином и Майклом Мерриттом в 1992 году. Хотя некоторые из первых методов имели недостатки, сохранившиеся и усовершенствованные формы EKE эффективно превращают общий пароль в общий пароль. ключ, который затем можно использовать для шифрования и/или аутентификации сообщения.Первые доказуемо безопасные протоколы PAKE были представлены в работах М. Белларе, Д. Пойнтчеваля и П. Рогавея (Eurocrypt 2000), а также В. Бойко, П. Маккензи и С. Пателя (Eurocrypt 2000). Безопасность этих протоколов была доказана в так называемой модели случайного оракула (или даже в более сильных вариантах), а первыми протоколами, безопасность которых была доказана при стандартных предположениях, были протоколы О. Голдрейха и Й. Линделла (Crypto 2001), которые служат доказательством правдоподобия, но неэффективно, а Дж. Кац, Р. Островский и М. Юнг (Eurocrypt 2001) — практично.

Первые методы получения ключей с аутентификацией по паролю были описаны Фордом и Калиски в 2000 году.

Значительное количество альтернативных безопасных протоколов PAKE было представлено в работах М. Белларе, Д. Пойнтчеваля и П. Рогауэя, вариации и доказательства безопасности были предложены в этом растущем классе методов согласования ключей с аутентификацией паролем. Текущие стандарты для этих методов включают IETF RFC 2945, RFC 5054, RFC 5931, RFC 5998, RFC 6124, RFC 6617, RFC 6628 и RFC 6631, IEEE Std 1363.2-2008, ITU-T X.1035 и ISO-IEC 11770-4. :2006.

Процесс выбора PAKE для использования в интернет-протоколах

[ редактировать ]

По запросу рабочей группы по интернет-инжинирингу IETF в 2018 и 2019 годах исследовательской группой криптофорума IRTF (CFRG) был проведен процесс выбора PAKE.Отбор кандидатов проводился в несколько туров. [17] В финальном раунде 2019 года победили четыре финалиста AuCPace, OPAQUE (расширенные корпуса) и CPace, SPAKE2 (сбалансированный PAKE). В результате процесса выбора CFRG два протокола-победителя были объявлены «рекомендованными CFRG для использования в протоколах IETF»: CPace и OPAQUE. [18]

См. также

[ редактировать ]
  1. ^ Разработано так, чтобы не быть обремененным патентами. [10]
  1. ^ Jump up to: Перейти обратно: а б с Хао, Фэн; Райан, Питер Ю.А. (2011). «Обмен ключами с аутентификацией паролем путем жонглирования» . Ин Кристиансон, Брюс; Малькольм, Джеймс А.; Матяс, Вашек; Роу, Майкл (ред.). Протоколы безопасности XVI . Конспекты лекций по информатике. Том. 6615. Берлин, Гейдельберг: Springer. стр. 159–171. дои : 10.1007/978-3-642-22137-8_23 . ISBN  978-3-642-22137-8 .
  2. ^ Jump up to: Перейти обратно: а б Бойко, В.; П. Маккензи; С. Патель (2000). «Надежный безопасный обмен ключами с аутентификацией паролем с использованием Диффи-Хеллмана». Достижения в криптологии — EUROCRYPT 2000 . Конспекты лекций по информатике. Том. 1807. Шпрингер-Верлаг. стр. 156–171. дои : 10.1007/3-540-45539-6_12 . ISBN  978-3-540-67517-4 .
  3. ^ Ван, Юнге (2006). «Анализ безопасности протокола аутентификации на основе пароля, предложенного в IEEE 1363» (PDF) . Теоретическая информатика . 352 (1–3): 280–287. arXiv : 1207.5442 . дои : 10.1016/j.tcs.2005.11.038 . S2CID   11618269 .
  4. ^ «Апплет карты Java EC-SRP» . Гитхаб . Март 2020.
  5. ^ Хаазе, Бьёрн; Гессен, Юлия; Абдалла, Мишель (2021). «OPAQUE: асимметричный протокол PAKE, защищенный от атак с предварительным вычислением» (PDF) . Достижения в криптологии – EUROCRYPT 2018 . Конспекты лекций по информатике. Том. 10822. стр. 456–486. дои : 10.1007/978-3-319-78372-7_15 . ISBN  978-3-319-78371-0 . S2CID   4046378 .
  6. ^ Абдалла, М.; Д. Поинтчеваль (2005). «Простые протоколы обмена ключами с шифрованием на основе пароля». Темы криптологии – CT-RSA 2005 (PDF) . Конспекты лекций по информатике. Том. 3376. Шпрингер Берлин Гейдельберг. стр. 191–208. CiteSeerX   10.1.1.59.8930 . дои : 10.1007/978-3-540-30574-3_14 . ISBN  978-3-540-24399-1 .
  7. ^ Лэдд, Уотсон (8 февраля 2022 г.). Кадук, Бенджамин (ред.). «СПАКЕ2, ПАКЕ (Черновик)» . IETF.
  8. ^ Jump up to: Перейти обратно: а б US11025421B2 , Фэй, Бьорн, «Расширенное модульное рукопожатие для согласования ключей и дополнительной аутентификации», выпущено 1 июня 2021 г.  
  9. ^ Мэтью Грин. «Давайте поговорим о ПАКЕ» .2018.
  10. ^ «Что такое СРП?» . Стэнфордский университет .
  11. ^ Шин, Сонхан; Кобара, Казукуни (июнь 2012 г.). «Эффективная расширенная аутентификация только по паролю и обмен ключами для IKEv2» . Рабочая группа по интернет-инжинирингу. Архивировано из оригинала 11 мая 2021 года.
  12. ^ Кравчик, Хьюго; Леви, Кевин; Вуд, Кристофер. «Протокол асимметричного PAKE OPAQUE (проект)» . Рабочая группа по интернет-инжинирингу .
  13. ^ Татьяна Брэдли (08.12.2020). «OPAQUE: лучшие пароли, никогда не покидайте свое устройство» . Блог Cloudflare .
  14. ^ Бурдрез, Даниэль; Кравчик, Хьюго; Леви, Кевин; Вуд, Кристофер А. (6 июля 2022 г.). «Асимметричный протокол PAKE OPAQUE (Интернет-проект)» . IETF.
  15. ^ Хаазе, Бьёрн; Лабрик, Бенуа (август 2010 г.). «AuCPace: эффективный протокол PAKE на основе верификатора, адаптированный для IIoT» (PDF) . ТЧЕС : 1–48. дои : 10.13154/tches.v2019.i2.1-48 . S2CID   4603454 .
  16. ^ Тауберт, Т.; Вуд, К. (5 мая 2022 г.). «SPAKE2+, расширенный PAKE (проект)» . IETF.
  17. ^ Репозиторий для процесса выбора CFRG Pake
  18. ^ Результаты процесса выбора CFRG PAKE

Дальнейшее чтение

[ редактировать ]
[ редактировать ]
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 2ac50389fe59ee25d9e61a004e772864__1720313160
URL1:https://arc.ask3.ru/arc/aa/2a/64/2ac50389fe59ee25d9e61a004e772864.html
Заголовок, (Title) документа по адресу, URL1:
Password-authenticated key agreement - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)