Криптографические протоколы являются основой безопасных сетевых соединений и обмена конфиденциальной информацией.
Сегодня существует большое количество различных протоколов для самых разных целей.
Многие из этих протоколов (например, TLS, Kerberos) знакомы даже людям, не связанным тесно с криптографией.
Они повсеместно распространены и часто уже долгое время являются частью популярных информационных систем.
Однако существует тип протокола, который в последнее время становится все более популярным, но до сих пор не широко известен: протоколы генерации общих ключей с аутентификацией на основе пароля.
К таким протоколам относится российский протокол СЕСПАКЕ (Security Evaluated Standardized Password Authenticated Key Exchange), с появлением которого в России возникла необходимость рассмотреть особенности протоколов этого типа.
Цель данной статьи – скорее не дать очередное формальное описание нового протокола, а помочь читателю уловить его основную идею и особенности и понять, почему в нем присутствуют те или иные шаги, почему они важны и как этот класс протоколов отличается от всего, что было известно ранее.
Немного истории В 1976 году Уитфилд Диффи и Мартин Хеллман предложили простую, но гениальную идею разработки общего секретного ключа — известный протокол Диффи-Хеллмана.
Здесь
- какой-то финал мультипликативная группа ,
- ее приказ,
– порождающий элемент этой группы.
Ценности
И
– открытые ключи, передаваемые по открытому каналу связи,
– ключ, сгенерированный при выполнении протокола.
Сила этого протокола против пассивного противника основана на так называемом вызове.
CDH , которая считается вычислительно «сложной» (неформально говоря, эффективных алгоритмов решения такой задачи не существует).
Формулировка этой задачи такова: зная значения
,
, рассчитать значение
.
К сожалению, протокол Диффи-Хеллмана имеет один фундаментальный недостаток: он небезопасен, если на канале передачи присутствует активный противник (см.
Причина данной уязвимости кроется в отсутствии механизма аутентификации, т.е.
стороны не имеют возможности каким-либо образом проверить в ходе протокола, что общий ключ был разработан совместно с честным абонентом.
На сегодняшний день предложено несколько решений этой проблемы, вот некоторые из них: использование сертификатов и Калифорния , вводя в протокол третью доверенную сторону или используя заранее согласованный секрет. Последний подход является самым простым решением с точки зрения реализации.
Однако если протокол предполагает использование секрета, представляющего собой длинную битовую строку, которую человеку сложно запомнить, то возникает проблема надежного хранения этого секрета.
Возникает вопрос, можем ли мы использовать в качестве секрета короткий и легко запоминающийся пароль? ? Как только появляется слово «пароль», многие почти рефлекторно хотят сказать, что высокой безопасности априори добиться невозможно, т.к.
пароль можно быстро восстановить простым перебором или с помощью словаря.
Ниже мы покажем, что это не всегда так.
Для начала рассмотрим следующую схему получения ключей, которая добавляет в протокол Диффи-Хеллмана этап аутентификации с использованием секретного значения: 
Здесь
- некоторая хэш-функция,
– секретное заранее согласованное значение,
,
— информация, используемая для аутентификации.
Легко видеть, что секрет
никак не используется на этапе генерации открытого ключа.
Чем этот пример плох в случае, когда значение
это обычный пароль? Как правило, пароль представляет собой малоэнтропийное значение (т. е.
состоит из 4–6 символов, например ПИН), поэтому перебор всех возможных значений пароля — вполне посильная задача для злоумышленника.
Поэтому фундаментальным требованием к протоколам, использующим короткий пароль, является устойчивость к так называемому автономная атака по словарю .
Это свойство должно достигаться за счет того, что информация, которую может получить как пассивный, так и активный противник в ходе выполнения протокола, не дает критерия отклонения неверных паролей в автономном режиме, т.е.
для нас идеальный вариант это когда противник не может найти пароль, перепробовав все возможные значения, количество которых невелико, без взаимодействия с пользователем.
Возвращаясь к примеру, зададимся вопросом: Решая проблему аутентификации, даем ли мы противнику критерий отклонения пароля? ? Чтобы ответить на этот вопрос, рассмотрим следующую атаку: 
В данном примере противник действует следующим образом: он заменяет сторону
и взаимодействует с партией
, честно следуя протоколу.
Враг развивает общее
ключ
.
Далее он получает от субъекта
аутентификационная информация
, который зависит всего от одного неизвестного параметра — пароля с низкой энтропией.
.
Следовательно, злоумышленник получает критерий отклонения неверных паролей.
Однако если бы использование пароля было непосредственно встроено в генерацию ключа (процесс, неотделимый от его разработки), и противник смог бы получить общий
ключ
, только угадывая пароль во время взаимодействия, то эта атака будет неприменима, так как ему придется пробовать не только пароль, но и длинный ключ.
Эта идея легла в основу нового подхода, а именно протоколы генерации общего ключа с аутентификацией на основе пароля ( ПАКЕ ).
Протоколы PAKE Первый протокол, подобный PAKE, был предложен еще в 1992 году Стивеном Белловином и Майклом Мерриттом.
Этот протокол предполагал, что для решения проблемы аутентификации субъекты, желающие разработать общий ключ, используют некоторый легко запоминающийся пароль, известный только им.
Основное отличие протоколов типа PAKE от рассмотренного выше примера заключается в том, что пароль используется уже на этапе генерации открытого ключа.
При этом основными требованиями к такому протоколу являются:
- обеспечение аутентификации участников протокола;
- неспособность противника получить критерий для подбора пароля.
Для этого рассмотрим простейший пример прототипа протокола PAKE: 
Отличия от протокола Диффи-Хеллмана выделены синим цветом.
- еще один порождающий элемент группы
.
Давайте посмотрим, уязвима ли такая схема для офлайн-атаки по словарю.
Пассивному противнику, прослушивающему канал передачи, доступны следующие значения:
И
– Открытые ключи Диффи-Хеллмана, замаскированные по значению
и информация аутентификации
И
.
Пробуя пароли, он может «снимать» маски со значений.
И
, при этом получая ожидаемые значения
И
.
Но злоумышленник может получить критерий для подбора паролей только в том случае, если он знает, как решить вычислительно «сложную» проблему CDH для немаскированных значений.
И
, то есть по значениям
И
получить ключ
(критерием правильности пароля будет получение корректной аутентификационной информации
на проверенном ключе
).
В случае активного противника эта схема все же имеет определенные уязвимости.
Рассмотрим следующую атаку на схему, в которой известны дискретные логарифмы одного образующего элемента относительно другого.
Для простоты рассмотрим случай, когда
.
Как и в предыдущей атаке, здесь противник просто переходит на другую сторону.
.
Так как ему известна функция генерации ключей, которая зависит только от одного неизвестного параметра - низкоэнтропийного пароля.
, он получает возможность подобрать пароль простым перебором, подставив проверенный ключ в функцию генерации аутентификационной информации
.
Нетрудно заметить, что подобную атаку можно осуществить, если в протоколе используются разные порождающие элементы, но известен дискретный логарифм одного по основанию другого.
В этом случае в цепочке равенств значение этого логарифма будет выступать просто как некоторая константа.
Если мы используем разные генерирующие элементы, так что дискретные логарифмы одного относительно другого неизвестны, мы не сможем получить ключ как функцию только неизвестного пароля.
Действительно,
, Где
— высокоэнтропийная неизвестная величина.
Вывод №1: При формировании эфемерного открытого ключа и «маски» пароля необходимо использовать разные образующие элементы, причем дискретные логарифмы одного по основанию другого должны быть неизвестны.
Чтобы получить такие элементы, необходимо не только генерировать их случайным образом, но и уметь убедить всех остальных, что при их генерации все было чисто случайно.
Этого можно добиться, подбирая генерирующие элементы в соответствии с принцип доказуемой псевдослучайности .
Таким образом, для мультипликативной группы конечного поля
Можно привести следующий алгоритм генерации генераторов:
- Создать случайную строку
. - Помещать
. - Проверь это
– генерирующий элемент, иначе возвращаемся к шагу 1.
Любой специалист, разрабатывающий новый протокол, знает, что одним из важнейших требований к таким протоколам является обеспечение так называемой неявной аутентификации сгенерированного ключа.
Явная и неявная аутентификация по ключу Аутентификация по неявному ключу — это свойство протокола, в котором участник протокола может быть уверен, что ни одна другая сторона, кроме специально идентифицированного (законного) участника протокола, не сможет получить доступ к секретному ключу, сгенерированному в протоколе.
При этом нет никакой гарантии, что второй участник протокола действительно получил доступ к ключу, но точно известно, что никто, кроме него, не мог его получить.
Явная аутентификация по ключу — это свойство, которое выполняется, когда аутентификация по неявному ключу и проверка ключа (свойство, с помощью которого один участник протокола проверяет, что другой участник действительно имеет ключ, сгенерированный в протоколе) происходят одновременно.
В этом случае известно, что сгенерированный ключ на самом деле имеется у законной стороны, и ни у кого другого.
Для нас это требование означает, что разрабатываемый нами протокол должен предоставлять криптостойкий открытый ключ, отвечающий требованию неявной аутентификации, даже если мы используем протокол без явного этапа аутентификации.
Давайте вернемся к нашему прототипу и посмотрим, удовлетворяет ли он этому свойству.
Рассмотрим атаку в такой модели противника, где:
- обе стороны участвуют во взаимодействии;
- враг знает ключи
И
(например, из-за несанкционированного доступа, их использования в уязвимых криптоалгоритмах и т.п.).
Несмотря на то, что мы используем разные генерирующие элементы, если противник знает
И
, тогда, зная
И
, он сможет найти значение пароля
, используя критерий
.
Таким образом, перехватив и подменив сообщение, он действительно сможет получить критерий нахождения пароля.
Избавиться от этой уязвимости можно, используя в протоколе хэш-функцию: 
Действительно, поскольку хеш-функция, удовлетворяющая криптографическим требованиям, считается аналогом псевдослучайной функции, между ее выходными и входными данными не существует простых зависимостей, которые можно было бы эффективно использовать.
Таким образом, у злоумышленника больше нет критерия для поиска пароля и атака больше не применима.
Вывод №2: Хешируем сгенерированный ключ.
Итак, нам удалось построить простейший прототип протокола генерации ключей без перебора на основе паролей методом перебора.
Конечно, учет конкретных атак и использование известных методов защиты от них не гарантирует устойчивости разрабатываемого протокола, поскольку невозможно учесть все существующие, но еще неизвестные атаки.
В этом случае на помощь приходят методы математической криптографии, позволяющие получать оценки стойкости протоколов в определенных моделях безопасности.
Неформально говоря, для таких протоколов, как PAKE, данные оценки должны строго доказывать, что лучшая тактика для злоумышленника — попытаться ввести пароль во время попытки подключения, честно следуя протоколу.
Похожий оценки и были получены для протокола SESPAKE. Как уже говорилось выше, пароль – это малоэнтропийная величина, т.е.
в отличие от длинного ключа, вероятностью простого угадывания этого пароля нельзя пренебрегать.
Поэтому ценой использования паролей в качестве общего заранее согласованного секрета является реализация технических мер, таких как ограничение количества попыток установления соединения.
На практике Итак, мы узнали, какими свойствами должен обладать протокол генерации общего ключа на основе пароля с последующей аутентификацией.
Мы также видели пример одного такого протокола — протокол SESPAKE. Давайте теперь попробуем разобраться, действительно ли этот протокол нужен на практике и можно ли обойтись давно существующими решениями.
Протоколы этого семейства предоставляют широкие возможности для их использования в самых разнообразных информационных системах.
Чтобы понять, как работает протокол, обратимся к самой популярной области его применения и одному из важнейших вопросов информационной безопасности — проблеме безопасного хранения криптографических ключей.
Существует два основных типа носителей ключей, использующих пароль: пассивное хранилище и активный токен.
Пассивный носитель может только хранить ключ и передавать его приложению (обычно криптопровайдеру), работающему в операционной системе на стороне пользователя, которое затем решает, что с ним делать.
Неотъемлемым свойством пассивного хранилища является фундаментальная восстанавливаемость ключ: все операции, зависящие от ключа, выполняются приложением, работающим на машине пользователя, поэтому ключ неизбежно присутствует в оперативной памяти.
Конечно, только тот, кто знает пароль, сможет извлечь ключ.
Активные токены, как и носители информации, также хранят внутри себя ключ пользователя, но единственное, что пользователь может получить с этого носителя, — это результат выполнения криптографических операций с использованием сохраненного ключа.
В таких устройствах ключ не выходит за пределы памяти носителя, то есть несъемный .
Схема работы ключевых СМИ Медиа хранилище: 
Активный токен: 
Описанные выше свойства ключевых носителей обоих типов имеют достаточно жесткие условия для их использования, поскольку оба этих ключевых носителя нестабильны, если в канале связи находится злоумышленник.
В случае использования носителя информации злоумышленник просто видит ключ, а в случае активного носителя он не сможет получить доступ к ключу, но сможет узнать пароль и, следовательно, стать легитимным.
тема для носителя - кто знает пароль тот прав! В этом случае, если устройство будет украдено, злоумышленник сможет использовать токен для выполнения необходимых операций с ключом.
В криптографии такая угроза называется выборочной подделкой: злоумышленник может подписать нужные ему данные, не зная ключа.
FKN или SESPAKE вступает в игру Таким образом, возникает задача создания такого типа ключевого носителя, который был бы устойчив к противнику в канале связи между машиной и носителем и угрозе выборочной подделки, то есть фактически решал бы проблему аутентификации.
И благодаря появлению семейства протоколов PAKE мы можем создать такую среду.
Этот тип токена, отвечающий этим требованиям, называется функциональные ключевые носители (сокращенно ФКН ).
Схема работы функционального ключевого носителя (ФКН) Общая схема их работы FKN выглядит так: 
Эти носители, как и рассмотренные выше активные носители, предоставляют пользователю возможность получить только результат вычислений, в которых участвует ключ.
Однако их отличие состоит в том, что пароль не передается непосредственно по каналу связи, а устанавливается защищенное соединение по протоколу PAKE, то есть по каналу связи передаются только данные, из которых на практике никаких выводов быть не может. рисуется либо о пароле, либо о ключе.
Здесь в дело вступает протокол SESPAKE, который, по сути, обеспечивает возможность такого сценария взаимодействия.
Использование этого протокола позволяет математически строго обеспечить защиту от противника в канале.
Таким образом, злоумышленник, имеющий возможность читать и заменять сообщения в канале, не сможет узнать пароль или даже попробовать пароли неинтерактивно, то есть без контроля со стороны токена.
Протокол SESPAKE Протокол SESPAKE был разработан с учетом всех описанных выше требований.
Обычно обоснование стойкости такого протокола, как PAKE, дается в модели, которая учитывает стандартную угрозу того, что злоумышленник узнает хотя бы некоторую информацию о сгенерированном ключе.
Однако данная модель не совсем естественна, поскольку рассматривается вне контекста протокола.
Действительно, сгенерированные ключи после завершения работы протокола будут впоследствии использованы для защиты данных, что сразу же даст возможность злоумышленнику осуществить угрозу.
Проще говоря, сила этих протоколов анализируется в некоторой упрощенной модели их использования, что часто приводит к ситуациям, когда после введения расширений, позволяющих использовать протокол в конкретных случаях на практике, он оказывается нестабильным.
Таким образом, обоснование надежности протокола SESPAKE основано на модели противника, которая учитывает еще одну более серьезную угрозу — угрозу ложной аутентификации.
Разработка протокола SESPAKE берет свое начало не из абстрактной математической модели, в которой давно существуют известные механизмы обоснования сопротивления, а связана с конкретным практическим случаем: необходимостью защиты канала между носителем ключа и провайдером.
.
Таким образом, новая модель противника, представленная ее разработчиками, позволила одновременно учесть все важные для практики технические аспекты (например, работу со счетчиками) как в протоколе, так и в его обосновании.
Более подробно с его обоснованием вы можете ознакомиться в отдельном материале.
статья , попробуем разобраться в сути протокола.
Конечно, схема такого «боевого» протокола гораздо сложнее, чем рассматриваемые нами примеры, а сам протокол основан на группах точек.
эллиптические кривые , которые при одинаковой длине ключа позволяют добиться большей криптостойкости по сравнению с конечными полями.
Однако теперь даже неопытный читатель сможет уловить ее суть, ведь основные принципы, на которых она основана, остались прежними.
На представленной выше схеме работы протокола его ключевые и уже знакомые точки выделены тремя цветами, аналогично тем, которые описаны в построенном выше прототипе:
- Количества
И
похожий
И
,
И
выступать в роли «маски» (
), ценности
,
похоже на ценности
,
. - Протокол SESPAKE учитывает контакт №2, поэтому сгенерированный общий ключ хешируется.
- Как и в нашем прототипе, протокол состоит из двух этапов: генерации открытого ключа и аутентификации.
Здесь вместо хеширования ключа
на этапе его подтверждения сторонами рассчитывается код аутентификации сообщения
по сгенерированному ключу из сформированного определенным образом линии .
(набор точек, которые можно использовать в протоколе для формирования маски, индекса (
), который выбирается перед началом этапа генерации ключа) относительно генерирующего элемента
и относительно друг друга неизвестно.
При этом задача вычисления этой кратности на практике неосуществима, т.е.
ее сложность сравнима со сложностью решения сложной задачи дискретного логарифмирования в группе точек используемой эллиптической кривой.
Выбор точки на эллиптической кривой, определенной в форме Вейерштрасса (
), можно сделать следующим образом:
- Создать случайную строку
. - Помещать
. - Если значение
не является квадратичным вычетом по модулю
, перейдите к пункту 1. - Помещать
.
– порядок поля, по которому строится группа точек эллиптической кривой, а так же
можно использовать, например, хеш-функцию ГОСТ Р 34.11-2012. Отметим, что протокол SESPAKE является одним из наиболее эффективных, поскольку предполагает минимально возможное количество передач между сторонами.
Заключение В конце 2015 года технический комитет по стандартизации ТК26 В качестве методических рекомендаций принят протокол генерации общего ключа с аутентификацией по паролю – протокол SESPAKE. Примерно в то же время протокол начал рассматриваться Рабочей группой по исследованию криптографии.
КФРГ (Исследовательская группа Crypto Forum), часть организации IETF/IRTF, занимающаяся вопросами международной стандартизации.
В настоящее время в CFRG ведутся обсуждения по стандартизации требований к таким протоколам, как PAKE, а также по выбору протокола в качестве международной рекомендации для использования.
Среди трех основных кандидатов рассматривается протокол SESPAKE, проект RFC который сейчас активно разрабатывается российскими специалистами.
Ознакомившись с такими протоколами, вы теперь можете предлагать свои идеи, участвуя в таких обсуждениях.
Теги: #Криптография #информационная безопасность #протокол #аутентификация #генерация пароля #CFRG #tk26 #информационная безопасность #криптография #ИТ-стандарты #математика #Разработка систем связи
-
Турецкий Язык
19 Oct, 24 -
Для Кого Созданы Супермаркеты?
19 Oct, 24 -
Генерация Паролей Для Игр Road Rash 1 И 2
19 Oct, 24 -
И Exalead Тоже Ищет
19 Oct, 24 -
3 Легендарных Харизматика
19 Oct, 24
