Система прослушивания TLS/SSL от NSA. Часть 1

Интересно представить, как может работать гипотетическая система “тотального” прослушивания NSA защищённого интернет-трафика. Защищённый интернет-трафик, в подавляющем большинстве случаев, использует TLS/SSL, с теми или иными SSL-сертификатами. Самый известный пример такого использования – защищённая версия HTTP, HTTPS, его и возьмём в качестве примера. Другим источником сведений о гипотетической системе послужат скриншоты неких интерфейсов доступа и другие фрагменты презентаций, которые были опубликованы в СМИ. (Напомню, что я уже писал о перехвате HTTPS ранее.)

Итак, чтобы получить доступ к зашифрованной сессии того или иного пользователя Интернета, если известна точка подключения этого пользователя, NSA потребуется решить две задачи: получить доступ к трафику, возможно, в активном режиме, и либо расшифровать данные, либо предотвратить их шифрование.

Начнём со второй задачи, с расшифровки или предотвращения шифрования данных, предположив, что трафик уже перехвачен.

В принципе, протоколы TLS (HTTPS) проектировались из соображений, что канал передачи данных между пользователем и сервером может прослушиваться и перехватываться в активном режиме. Поэтому TLS, в теории, позволяет защитить данные от прослушивания и обнаружить активное вмешательство в канал. Что с этим можно сделать? Я уже не раз рассказывал о том, что есть возможность подмены серверного сертификата с дальнейшим перехватом соединения. Эта опция доступна, если с вами сотрудничает удостоверяющий центр, которому доверяет программное обеспечение пользователя. Но есть ещё один вариант: можно получить серверный закрытый ключ. В таком случае для перехвата можно использовать действующий сертификат сервера, он всем доступен, его достаточно просто скопировать. При наличии серверного ключа можно и проводить атаку типа “человек посередине”, и расшифровывать данные в пассивном режиме (если сервер настроен подходящим образом). Атака “человек посередине” предотвращает шифрование данных в точке перехвата.

Как получить серверный ключ? Если NSA внедряет закладки в программное и аппаратное обеспечение, то, вероятно, есть возможность вычислить секретный ключ за разумное время. Например, для самой популярной криптосистемы RSA достаточно знать разложение на простые множители модуля, используемого в данном секретном ключе. (Модуль – это, грубо говоря, число, задающее множество, в котором проводятся операции для даннной пары закрытый/открытый ключ.) Это не единственный способ, есть множество других. Закладка NSA с указанными свойствами приводит к уменьшению количества возможных ключей. В качестве наиболее вероятного рычага воздействия закладки принято называть генератор (псевдо)случайных чисел. Действительно, как бы хорошо не была реализована сама криптосистема, если практическое число возможных ключей, порождаемых генератором “неслучайных” чисел, не велико, то и от самой системы толка нет.

Тривиальный пример. Предположим, в NSA, воздействуя на производителей криптомодулей, на разработчиков программного обеспечения, добились того, что количество простых чисел, используемых в качестве одного из сомножителей в ключах RSA, которые генерируются “сертифицированными средствами”, не превышает 10^12 (триллион). Второе число может быть истино случайным, ведь тут важно не переборщить: чрезмерно малое разнообразие ключей будет быстро обнаружено наблюдателями (см. историю с ошибкой в Debian OpenSSL, которая, кстати, теперь уже и не кажется просто ошибкой). Зная структуру множества этих выбранных простых чисел, можно быстро вычислить секретный ключ простым перебором. Чуть более технично: пусть модуль ключа RSA представляет собой произведение двух простых чисел; если наш суперкомпьютер выполняет миллион пробных делений в секунду, то, исходя из 10^12 вариантов известных множителей, мы получим разложение для модуля не более чем через 278 часов; это означает, что факторизация будет обычно занимать чуть более недели. Заметьте, что серверные ключи традиционно существуют в неизменном виде годами.

Весьма занимательно, что в прошлом году было опубликовано исследование ключей TLS-серверов Интернета, в котором обнаружено заметное число разных ключей, имеющих общие простые множители.

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

Вычисленный ключ попадает в базу данных и становится доступен пользователям системы прослушивания HTTPS. Трафик можно начинать записывать сразу, не дожидаясь готовности ключа. Например, если взглянуть на те же веб-сервера Mail.ru, то они, как и подавляющее большинство других сервисов Интернета, не поддерживают прогрессивной секретности (forward secrecy) для HTTPS, это означает, что ранее записанный трафик можно расшифровать позднее, когда станет известен серверный ключ. (Подчеркну: я не вижу тут какой-то ошибки со стороны Mail.ru – они просто следуют сложившейся практике.)

Продолжение про перехват HTTPS – в следующей части, рассказывающей о перехвате трафика.

()
https://dxdt.ru/2013/09/10/6163/