SPEKE

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

SPEKE (Простой обмен экспоненциальным ключом пароля ) - это криптографический метод для аутентификации по паролю ключевое соглашение.

Содержание
  • 1 Описание
  • 2 История
  • 3 Патенты
  • 4 Стандарты
  • 5 Ссылки
  • 6 Внешние ссылки
Описание

Протокол состоит немного больше, чем обмен ключами Диффи-Хеллмана, где генератор Диффи-Хеллмана g создается из хэша пароля .

Вот одна простая форма SPEKE :

  1. Алиса и Боб соглашаются использовать соответственно большое и случайно выбранное безопасное простое число p, а также хэш-функцию H ().
  2. Алиса и Боб соглашаются общий пароль π.
  3. Алиса и Боб оба составляют g = H (π) mod p. (Возведение в квадрат создает ga-генератор подгруппы простого порядка из мультипликативной группы целых чисел по модулю p.)
  4. Алиса выбирает секретное случайное целое число a, затем отправляет Бобу g mod p.
  5. Боб выбирает секретное случайное целое число b, затем отправляет Алисе g mod p.
  6. Алиса и Боб каждый прерывают выполнение, если их полученные значения не находятся в диапазоне [2, p-2], чтобы предотвратить атака с ограничением подгруппы.
  7. Алиса вычисляет K = (g mod p) mod p.
  8. Боб вычисляет K = (g mod p) mod p.

И Алиса, и Боб придут к одному и тому же значение для K тогда и только тогда, когда они используют одно и то же значение для π. После того, как Алиса и Боб вычислили общий секрет K, они могут использовать его в a, чтобы доказать друг другу, что они знают один и тот же пароль π, и получить общий секретный ключ шифрования для отправки друг другу безопасных и аутентифицированных сообщений. Использование протокола подтверждения ключа необязательно, как указано в стандартах IEEE P1363.2 и ISO / IEC 11770-4.

В отличие от неаутентифицированного Диффи-Хеллмана, SPEKE предотвращает атаку «злоумышленник в середине» путем включения пароля. Злоумышленник, который может читать и изменять все сообщения между Алисой и Бобом, не может узнать общий ключ K и не может сделать более одного предположения для пароля при каждом взаимодействии со стороной, которая его знает.

В общем, SPEKE может использовать любую группу первичного порядка, подходящую для криптографии с открытым ключом, включая криптографию с эллиптической кривой. Однако, когда SPEKE реализуется с использованием криптографии с эллиптической кривой, протокол существенно изменяется, требуя дополнительного примитива, который должен безопасно отображать пароль в случайную точку на обозначенной эллиптической кривой. (Этот примитив называется функцией IOP или целочисленной передачей в IEEE P1363.2 и ISO / IEC 11770-4.)

История

SPEKE - одна из старых и хорошо известных известные протоколы в относительно новой области обмена ключами с аутентификацией паролем. Впервые он был описан в 1996 году. В этой публикации Яблон также предложил вариант, в котором на шаге 2 протокола g вычисляется как g = g q с постоянной g q. Однако эта конструкция оказалась небезопасной для атак по словарю и поэтому больше не рекомендовалась в исправленной версии статьи. В 1997 году Jablon усовершенствовал и усовершенствовал SPEKE с дополнительными вариациями, включая расширенный метод согласования ключей с аутентификацией паролем под названием B-SPEKE. В статье, опубликованной Маккензи в 2001 году, на основе модели случайного оракула представлено доказательство того, что SPEKE является безопасным протоколом PAKE (с использованием несколько смягченного определения), основанным на варианте решения Диффи-Хеллмана. Однако доказательство рассматривает функцию подтверждения ключа в SPEKE как обязательную, а SPEKE не определен в стандартах IEEE P1363.2 и ISO / IEC 11770-4.

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

В 2014 году были выявлены две атаки на протокол SPEKE, как указано в исходной статье Jablon за 1996 год и в стандартах IEEE P1363.2 (D26) и ISO / IEC 11770-4 (2006). Первая атака позволяет активному злоумышленнику выдать себя за пользователя, не зная пароля, путем запуска двух параллельных сеансов с жертвой. Вторая атака позволяет злоумышленнику типа «человек посередине» манипулировать сеансовым ключом между двумя честными пользователями, не будучи обнаруженным. Первая атака указывает на практическую слабость протокола, в то время как вторая атака имеет теоретические последствия для доказательств безопасности SPEKE. Во время встречи ISO / IEC JTC 1 / SC 27 в Мехико в октябре 2014 года эти две атаки обсуждались техническим комитетом в ISO / IEC SC 27 / Work Group 2, и было решено, что спецификация SPEKE в ISO / IEC 11770-4 (2006) следует пересмотреть, чтобы устранить выявленные проблемы. Предлагаемый патч включает явное определение идентификаторов сеансов и включение этих идентификаторов в функцию получения ключа таким образом, чтобы не изменять симметрию протокола. Исправленный SPEKE был опубликован в ISO / IEC 11770-4 (2017). Однако спецификация SPEKE в IEEE P1363.2 остается без исправлений.

Патенты

США Патент 6,226,383 описывает несколько вариантов способа. Срок действия этого патента истек в марте 2017 года.

Стандарты

Стандарты, описывающие SPEKE, включают IEEE P1363.2 и ISO / IEC 11770-4. В последнем стандарте ISO / IEC 11770-4 (2017) спецификация SPEKE изменена по сравнению с предыдущей версией ISO / IEC 11770-4 (2006), чтобы устранить две атаки, о которых сообщили Хао и Шахандашти в 2014 году.

Ссылки
Внешние ссылки
Последняя правка сделана 2021-06-06 04:06:49
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте