Сеансовые ключи (DH) в трафике TLS

ksks7 (Техничная записка из области популярной криптологии, которая, думаю, будет полезна и на dxdt.ru.)

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

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

Когда говорят о прогрессивной секретности (PFS), которой позволяет добиться использование DH, то имеется в виду вовсе не то, что ключи невозможно восстановить после того, как сессия завершилась, а лишь то, что утечка долговременного ключа не раскрывает сессионных ключей. Не более того. Обычно, долговременный ключ в TLS – это ключ, используемый для аутентификации сервера, при помощи электронной подписи. Если прогрессивная секретность отсутствует, то восстановление сеансовых ключей, если у вас есть долговременный секретный ключ (это будет, соответственно, RSA) оказывается тривиальной задачей – просто расшифровываем исходные данные из трафика.

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

Для детального понимания ситуации нужно рассмотреть следующий случай: предположим, что стороны, обменивающиеся данными в рамках защищённой сессии, используют заранее известный им разовый (относительно сессии) набор секретных сеансовых симметричных ключей и, скажем, AES. То есть, симметричные ключи не генерируются при помощи обмена в рамках DH, а известны заранее. По каналу связи они не передаются, канал не используется для их генерации. (Аутентификацию оставим за скобками.) Пусть используется добротный режим потокового шифрования: генерируется ключевой поток (гамма), совпадающей по длине с открытым текстом, а шифротекст является результатом операции XOR над открытым текстом и ключевым потоком. Примерно так работает GCM (аутентификацию мы договорились оставить за скобками) и всякий другой “режим счётчика”. Так как полученный ключевой поток будет, вообще говоря, вычислительно неотличим от псевдослучайной функции, то для записавшей трафик стороны ситуация окажется, условно говоря, семантически неотличима от абсолютно стойкого шифрования.

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

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

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

()

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



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

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

Комментарии читателей блога: 6

  • 1. 29th July 2016, 14:51 // Читатель pash написал:

    Что-то Ваша мысль …дрейфовала в процессе написания и стала слишком непонятна для меня. Попробуйте написать abstract в 3 строки.

  • 2. 30th July 2016, 01:25 // Александр Венедюхин ответил:

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

  • 3. 2nd August 2016, 13:59 // Читатель pash написал:

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

    Ну… логично.

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

    Что существенное я упустил?

  • 4. 3rd August 2016, 16:31 // Александр Венедюхин ответил:

    Даже не то что “легче”, а в случае с DH – этот ключ можно вычислить из трафика.

  • 5. 3rd August 2016, 18:47 // Читатель pash написал:

    >в случае с DH – этот ключ можно вычислить из трафика.
    У нас есть 2 трафика:
    1. обмен DH (сводится к задаче дискретного логарифмирования)
    2. последующий интересный трафик, закрытый симметричным алгоритмом и ключом,
    а) известным снаружи (сводится к перебору)
    б) полученным из предыдущего DH

    Из какого трафика? DH? А точно дискретное логарифмирование будет существенно быстрее перебора тела интересного сообщения? Все-таки про сообщение можно сделать какие-то предположения, например, что это правильный http-запрос и первые его символы GET\s или POST\s…

  • 6. 4th August 2016, 09:18 // Александр Венедюхин ответил:

    Из всего записанного трафика, там будут и параметры DH. Перебор открытых текстов смысла не имеет – при правильном режиме использования шифра “подобрать” можно что угодно, подходящее по длине. Тут хороший пример – квантовый компьютер: если он есть, то просто берём значение DH из трафика и вычисляем секретный ключ.

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

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

Преграда для ботов: * Time limit is exhausted. Please reload CAPTCHA.

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