“Ключи на клиенте” и протокол Диффи-Хеллмана

Протокол Диффи-Хеллмана (DH) – одна из основ современной практической криптографии, да и не только современной: на этом же протоколе базируется и ряд предлагаемых постквантовых криптосистем. Сейчас часто приходится слышать, что, при использовании данного протокола, симметричные криптографические ключи “есть только у клиентов” – тут имеются в виду стороны, которые договариваются о симметричном ключе, используя некоторый центральный сервер. Если подходить к вопросу строго, то DH позволяет сторонам безопасно договориться об общем секрете через открытый канал, но протокол, сам по себе, вовсе не гарантирует, что эти самые стороны действительно смогут договориться. Прежде всего: протокол в чистом виде – уязвим для атаки посредника (человек посередине). То есть, если центральный сервер подменяет открытые сообщения, выдавая себя за каждую из сторон, то DH не позволяет этого обнаружить.

Поэтому стороны должны применять какие-то внешние средства, позволяющие проверить, что они действительно обменялись параметрами DH между собой. Правильный вариант такой проверки базируется либо на электронной подписи (подписываются параметры), либо на статических параметрах, которые распределяются заранее и по независимому от центрального сервера каналу, либо на использовании некоторого общего секрета (пароль или что-то подобное). (При наличии общего секрета, впрочем, необходимость применять ещё и DH обычно отпадает.) Есть также распространённый метод под условным названием “сравни картинку”, который состоит в том, что стороны, находясь рядом, могут визуально сравнить изображения, соответствующие полученному в результате обмена DH секрету. Можно сравнивать не изображения, а сами числа.

Всё это хорошо, а DH – замечательный протокол. Но, к сожалению, в большинстве практических реализаций, всё сводится не к доверию протоколу, а к доверию приложению: если приложение показывает двум пользователям одинаковые картинки, то это означает, что приложение показывает какие-то одинаковые картинки, а не то, что корректно выполнено согласование ключей по протоколу DH (о том, что ключи согласованы с кем-то, можно судить по факту успешного обмена сообщениями, но конкретные картинки – не обязательно прямо соответствуют реальным ключам).

Что касается самих ключей: опять же, строго говоря, открытая часть протокола DH доступна для записи, а в открытой части содержится достаточно информации для получения секрета. Стойкость протокола основана только на том факте, что не известно универсальных практических (то есть, работающих на доступном классическом компьютере) алгоритмов быстрого вычисления секрета на основе только открытых параметров DH. Но это не означает, что “ключи есть только на клиенте”. Если центральный сервер записывает трафик, то ключи, вообще говоря, есть и у него, но в представлении, которое сложно обратить (получить из открытого ключа секретный, эта задача, в случае широко используемых сейчас вариантов DH, называется дискретным логарифмированием). Сложно, но вовсе не невозможно. Более того, считается, что для конкретных параметров DH, обладающих определёнными свойствами, можно провести предварительные вычисления на специализированном суперкомпьютере, а потом очень быстро вычислять секретные ключи. Именно по этой причине рекомендуется при использовании DH генерировать полностью собственные параметры, а не применять заранее известные, которые, например, выдаёт центральный сервер. В случае классического DH (не эллиптического), основным параметром является простое число (модуль), задающее группу, в которой проводятся операции протокола. Это, впрочем, технические детали – я писал о них раньше, применительно к TLS. Главное наблюдение состоит в том, что информация о секретных ключах содержится в параметрах, которыми стороны обмениваются в открытом виде.

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

Про DH и связанные с этим протоколом ограничения я неоднократно писал раньше, например – здесь и здесь.

Адрес записки: https://dxdt.ru/2018/04/12/8487/

Похожие записки:



Далее - мнения и дискуссии

(Сообщения ниже добавляются читателями сайта, через форму, расположенную в конце страницы.)

1 комментарий от читателей

  • 1. 12th April 2018, 19:00 // Читатель sarin написал:

    вообще нынче всё как-то к цифровым подписям сползает. без них ничего не работает.

Написать комментарий

Ваш комментарий:

Введите ключевое слово "2DGGD" латиницей СПРАВА НАЛЕВО (<--) без кавычек: (это необходимо для защиты от спама).

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