DH против DHE, или хитрости реализаций криптографии
В свете недавно выявленной уязвимости TLS – Logjam возник интерес к отличиям различных версий и реализаций алгоритма Диффи-Хеллмана. Вообще, современное состояние дел с криптографией в Интернете таково, что вместо небольшого набора простых и понятных протоколов, используется огромная куча спецификаций, в которых, по историческим причинам, наворочено много разных тонкостей. Одна из таких тонкостей – отличие шифронаборов, содержащих в своём обозначении DH, от шифронаборов с DHE (добавлен суффикс E).
DH – обозначает Диффи-Хеллмана. E – Ephemeral (почему-то сейчас в переводе используют “эфемерный”, хотя лучше подошло бы “краткосрочный” или “единовременный”). Обычно пишут, что вариант DH – не обладает прогрессивной секретностью (то есть, записанный ранее трафик можно раскрыть через какое-то время, если удалось получить секретный ключ сервера), а DHE – обладает. В чём же различия?
Вспомним, что алгоритм Диффи-Хеллмана использует следующие общие параметры: P – модуль (большое простое число, задающее группу, в которой производятся вычисления – (mod P), дальше это обозначение опускаю); G – “генератор” (число, элемент выбранной группы). Это публичные параметры. Условный “открытый ключ” сервера образуется при помощи вычисления A = G^a, где a – секретная часть ключа (экспонента). Клиент выбирает своё значение b, вычисляет B = G^b и передаёт на сервер. Для получения общего секрета сервер и клиент вычисляют, соответственно, s = B^a = (G^b)^a = G^(ba) и s = A^b = (G^a)^b = G^(ab). Обратите внимание на параметры со стороны сервера: P,G,A.
В случае реализации DH предполагается, что параметры сервера (P,G,A) – заранее подписаны неким внешним ключом, что позволяет клиенту проверить их подлинность. Это означает, что параметры фиксированы от сессии к сессии, а сервер может использовать только одну экспоненту (a), которая соответствует G^a = A. Самое важное, что фиксируется именно экспонента a – сервер должен её сохранять в долговременной памяти, так как она связана с открытой частью ключа A. Есть старые рекомендации, предписывающие включать параметры DH в состав сертификата. Впрочем, на практике такие вещи не встречаются. Понятно, что если секретные ключи сервера, а именно – значение a, оказались раскрыты, то они позволят вычислить сеансовые ключи (s) для всех записанных сессий, так как теперь аналитику известна величина a и он может определить s = B^a = G^(ab) (значение B – сохранено в записи трафика, так как его в открытом виде передаёт клиент). Очевидно, что точно так же можно раскрыть трафик, если аналитику известен секретный параметр на стороне клиента (b) – например, этот параметр утёк из браузера.
Итак, основная особенность: в случае DH – заранее предполагается, что секретный параметр алгоритма Диффи-Хеллмана сохранён на диске и может быть доступен третьим лицам. Дело в том, что само по себе использование одинакового параметра для разных сессий никак не гарантирует его раскрытия.
В случае DHE – как минимум a и G^a = A – генерируются сервером заново для каждой сессии, и, как считается, значения не сохраняются на долгое время. А для того, чтобы клиент мог провести аутентификацию параметров, они подписываются ключом сервера (тот же ключ используется в SSL-сертификате). Это нормальный современный вариант использования алгоритма Диффи-Хеллмана в TLS.
Но здесь есть хитрость, про которую почему-то редко упоминают. Хитрость в том, что математически обе схемы (DH и DHE) не отличаются. Различается лишь реализация управления секретом на сервере – в случае DH он обязательно сохраняется, так как строго определён для всех сессий, а в случае с DHE – сохраняться секрет не должен. Но если вдруг секретный сессионный параметр DHE как-то записывается, например, в дампе внутреннего трафика, или в “снапшоте” памяти сервера, или – благодаря особой утечке, связанной с ошибкой в программном коде, то никакой “прогрессивной секретности” уже не получится: DHE становится равен DH, а записанный ранее трафик можно расшифровать.
Адрес записки: https://dxdt.ru/2015/06/02/7479/
Похожие записки:
- Централизованные мессенджеры и многообразие мест хранения сообщений
- Совпадения тегов ключей DNSSEC и парадокс дней рождения
- Занятный замок Fichet 787
- Реплика: история с сертификатом Jabber.ru и "управление доверием"
- Техническое: связь SCT-меток с логами Certificate Transparency
- Техническое: занимательный пример из практики DNS в Интернете
- Новые корневые сертификаты на audit.statdom.ru
- Chrome и проверка веб-страниц в браузере
- Браузерная реклама от Firefox
- Как правильно "показать TLS-сертификат", рекомендации
- Таблицы подстановок: картинка
1 комментарий от читателей
1 <t> // 2nd June 2015, 19:31 // Читатель Дмитрий Белявский написал:
Хочу добавить, что по умолчанию, кажется, openssl будет повторно использовать эти ключи, там надо в контекст какой-то флаг ставить.