Материал из РУВИКИ — свободной энциклопедии

MQV

MQV (Менезес-Кью-Ванстоун) — это аутентификационный протокол, базирующийся на алгоритме Диффи-Хеллмана. MQV предоставляет защиту против активных атак путём сочетания статического и временного ключей. Протокол может быть модифицирован для работы в произвольной конечной коммутативной группе, и, в частности, в группах эллиптических кривых, где известен как ECMQV.

MQV изначально был предложен Альфредом Менезесом, Мингхуа Кью и Скоттом Ванстоуном в 1995. Был модифицирован в 1998. Существуют одно-, двух- и трёхходовые разновидности алгоритма.

MQV включен в проект по стандартизации криптосистем с открытым ключом — IEEE P1363.

Патенты на некоторые разновидности MQV принадлежат компании Certicom [1].

MQV имеет некоторые слабости, которые были исправлены алгоритмом HMQV в 2005 [2]; см. [3], [4], [5].

Оба алгоритма MQV и HMQV имеют уязвимости, которые были исправлены протоколом FHMQV (см. [6])

Описание[править | править код]

Алиса имеет статическую ключевую пару (), где её открытый ключ и её секретный ключ. Боб имеет статическую ключевую пару (), где его открытый ключ и его секретный ключ. Определим . Пусть будет точкой на эллиптической кривой. Тогда , где и есть порядок используемого генератора точки . Таким образом, есть первые битов координаты для . Кроме того введем кофактор , определённый как , где есть порядок группы , причем следует учесть, что по техническим причинам должно выполняться требование: [1].

Шаг Операция
1 Алиса создает ключевую пару () генерируя случайно и вычисляя =, где  — точка на эллиптической кривой. После этого она посылает временный открытый ключ Бобу.
2 Боб создает ключевую пару () генерируя случайно и вычисляя =. После создания пары он посылает свой временный открытый ключ Алисе.
3 Алиса проверяет, что временный открытый ключ принадлежит группе , а также то что не является нулевым элементом. После этого вычисляет групповой элемент , как , где и . Если , Алиса отклоняет данные, полученные от Боба. В противном случае, она принимает вычисленный результат, как общий секретный ключ.
4 Боб проверяет, что временный открытый ключ принадлежит группе , а также что не является нулевым элементом. Вычисляет групповой элемент , как , где и . Если , Боб отклоняет данные, полученные от Алисы. В противном случае, он принимает вычисленный результат, как общий секретный ключ.

Базовый протокол является привлекательным решением из-за нескольких причин:

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

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

Корректность[править | править код]

Вычисления Боба:.

Вычисления Алисы:.

Таким образом, ключи действительно эквивалентны ключу [3].

Возможные атаки[править | править код]

Самый простой вариант, которым может воспользоваться злоумышленник (криптоаналитик) — получить сертификат(идентификатор), ассоциирующий его имя с открытым ключом, находящимся у Алисы. Если он заменит идентификатор Алисы своим собственным идентификатором в данном протоколе, существует значительная вероятность, что Боб примет данный идентификатор, не заметив подмены, в действительности думая, что общается с Алисой. Приведём атаку, основанную на подмене источника. Данная атака указывает на необходимость наличия требований к владению ключом: запрашивающая сторона должна знать секретный ключ для того, чтобы получить идентификатор, соответствующий открытому ключу. В принципе, центр идентификации мог бы устроить проверку на дубликат открытых ключей, однако этот шаг является непрактичным решением, так как влечёт за собой участие большого количества центров идентификации. Таким образом, злоумышленник должен получить идентификатор для нового открытого ключа , такого, чтобы существовало соответствие секретному ключу , и такого, чтобы Боб вычислил бы такой же общий секретный ключ при взаимодействии со злоумышленником, какой вычислился бы при взаимодействии Боба и Алисы. Следующая реализация удовлетворяет всем вышеописанным целям. Обозначим злоумышленника как Еву[3].

Шаг Операция
1 Ева перехватывает временный открытый ключ Алисы на пути ключа к Бобу.
2 Ева выбирает целое принадлежащее промежутку и вычисляет временный открытый ключ , как (заметим, что Ева не знает соответствующий секретный ключ ). Если , Ева повторяет этот шаг с другим целым .
3 Ева вычисляет статическую пару , как ,

.

4 Ева получает идентификатор для её статического открытого ключа . Таким образом, она знает соответствующий секретный ключ . Следовательно, она удовлетворяет требованиям владения ключа.
5 Ева инициирует запуск протокола с Бобом, посылая свой временный открытый ключ .
6 Ева получает Временный открытый ключ Боба и передает его Алисе.

В результате данной атаки, Алиса проверит идентификатор Боба и вычислит общий секретный ключ , в то время как Боб получит и проверит идентификатор Евы и вычислит общий секретный ключ , как , где определён ранее и .

Ключ Боба будет таким же, каким бы он был, если бы Боб взаимодействовал с Алисой.

.

Ева должна получить идентификатор для её статического открытого ключа во время запуска протокола со стороны Алисы. Таким образом, Алиса может заметить задержку между временем отправки её временного открытого ключа и временем получения идентификатора Боба.

Меры противодействия атакам[править | править код]

Прежде всего, первым шагом необходимо включить в протокол операцию, которая будет зарезервирована для проверки наличия ключа. Данный совет относится ко всем протоколам аутентификации. Таким образом, для прохождения верификации Боба, Еве нужно будет пройти дополнительную проверку. Другой вариант противодействия, который может быть введен в протокол — создание обмена между участниками односторонними хэшами от их временных открытых ключей перед обменом временными ключами. Механизм обмена в данном случае действительно важен. Каждая сторона должна быть уверенна, что другой член действительно получил «посылку» перед тем, как отправлять ему временный открытый ключ. Подтверждение данного факта может быть получено соответствующей последовательностью. К примеру, Алиса посылает её подтверждение, Боб получает его и посылает его подтверждение. Алиса получает подтверждение Боба и посылает свой ключ. Когда же Боб получает ключ Алисы, он посылает его собственный ключ. Без такой последовательности, к примеру, если Боб и Алиса будут делать пересылку одновременно, данный протокол будет уязвимым для некоторых видов атак[4].

Приведём иные меры противодействия.

  1. Детектор задержек — альтернативный вариант, не использующий криптографию. Реализация так называемого «проверщика» задержек. Сторона (Боб или Алиса) прекратит работу протокола, если время ответа другой стороны будет превышать заданное в реализации протокола допустимое значение. Таким образом, когда Ева запрашивает идентификатор, этот шаг может потребовать дополнительного времени (однако существуют возможности обойти эту сложность). Причём, дополнительное время будет сравнимо с временем прочих операций, задействованных в протоколе. Однако данная контрмера не поможет в случае атаки в несколько шагов.
  2. «Идентификатор давности». Получатель может запросить подтверждение давности идентификатора. Недавно полученный идентификатор может быть воспринят, как доказательство атаки. После чего канал связи со злоумышленником будет закрыт.
  3. Идентификация участников через сообщения. Главный принцип дизайна протоколов — сообщения должны нести достаточно информации, чтобы избежать неправильной интерпретации. Соответственно, сообщения, защищенные с общим секретным ключом, должны идентифицировать участников, вовлеченных в передачу. Такая идентификация препятствовала бы возможности возникновения неправильной интерпретации.

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

См. также[править | править код]

Примечания[править | править код]

  1. Kaliski, 2001, p. 277.
  2. Kaliski, 2001, p. 278.
  3. 1 2 Kaliski, 2001, p. 280.
  4. Kaliski, 2001, p. 281.

Литература[править | править код]

  • Burt Kaliski. An unknown key-share attack on the MQV key agreement protocol. ACM Trans. Inf. Syst. Secur. 4(3) //  (англ.). — 2001.
  • Laurie Law, Alfred Menezes, Minghua Qu, Jerry Solinas, Scott A. Vanstone, An Efficient Protocol for Authenticated Key Agreement. Des. Codes Cryptography 28(2): pp. 119—134 (2003)
  • Peter J. Leadbitter, Nigel P. Smart: Analysis of the Insecurity of ECMQV with Partially Known Nonces. ISC 2003: pp. 240—251
  • A. Menezes, M. Qu, and S. Vanstone, Some new key agreement protocols providing implicit authentication, Preproceedings of Workshops on Selected Areas in Cryptography (1995).
  • D. Hankerson, A. Menezes, and S.A. Vanstone, Guide to Elliptic Curve Cryptography, Springer-Verlag, 2004.

Ссылки[править | править код]