dxdt.blog: занимательный интернет-журнал

1.

MitM – атака “Человек посередине”. Это атака уровня аутентификации, а не “шифрования”. Смысл атаки, в случае TLS (на клиентской стороне), состоит в том, что подменяется узел, с которым клиент пытается устанавливать соединение. А для того, чтобы клиент не догадался о подмене – используется сертификат, выпущенный для имени исходного узла. История с сертификатами в основном касается как раз TLS, для других протоколов ситуация может быть иной.

2.

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

3.

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

4.

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

5.

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

6.

Технически, выпускать подменные сертификаты может тот или иной хорошо известный УЦ, то есть, УЦ, корневые ключи которого включены в стандартный дистрибутив браузера. Однако попытка массово реализовать подобное для большого числа ничего не подозревающих пользователей – скорее всего приведёт к тому, что ключи УЦ будут отозваны из браузеров. Тем не менее, УЦ попадались на подобных штуках.

7.

Инфраструктура сертификатов и УЦ в современном Интернете развивается. Как раз в сторону повышения прозрачности. Соответственно, внедрение MitM будет быстро обнаружено. Для того, чтобы подтвердить факт MitM, тот или иной пользователь может просто опубликовать (отправить, скажем, в Google или в, условный, Facebook) подменный сертификат. Этот сертификат пользователю легко извлечь – в браузере, например, для этого есть функция экспорта. Подделать такой сертификат не выйдет (ну, если бы некий пользователь решил дезинформировать Google), потому что он обязательно содержит электронную подпись, которую можно проверить.

(Про перехват HTTPS я подробно писал в другой заметке.)

Основой для объединения множества сетей в Интернет является понятие автономной системы (AS). В случае Интернета, а точнее, в случае IP, автономная система – это вовсе “не вычислительная система, способная работать автономно”, а, фактически, набор маршрутизаторов, формирующих видимую для Интернета IP-сеть, которая находится под единым управлением. В рамках этого управления определяется то, как внутри этой сети доставляются пакеты. (В терминологии IP – группа маршрутизаторов с общей собственной политикой маршрутизации). Очень важная оговорка: этот “набор маршрутизаторов” подключен к другим автономным системам. То есть, определение автономной системы (AS) обладает некоторой занятной рекурсивностью: нельзя определить понятие AS, если нет других AS. Почему? Потому что “единое управление маршрутизацией” определяется с внешней точки зрения. Грубо говоря, подключающиеся к данной AS через пограничный узел – видят внутреннюю политику маршрутизации как единую. Как ни странно, эта политика не обязана являться единой, если вы вдруг влезли внутрь AS и исследуете взаимосвязи между составляющими её узлами. Определение автономной системы – не столько техническое, сколько административное. Автономные системы в Интернете пронумерованы, и за каждой из них закреплено некоторое подмножество адресного пространства IP (так называемые IP-префиксы, обозначающие “непрерывные” блоки адресов), а смотрят они друг на друга, используя BGP.

BGP – или Border Gateway Protocol – это строго описанный формальный интерфейс, который автономные системы используют для формирования представления о маршрутах в Интернете. Фундамент BGP – обмен информацией о возможностях доставки пакетов. То есть, это внешний протокол взаимодействия между AS. Элементарную основу такого взаимодействия составляет распространение информации о желании автономных систем, являющихся соседними, доставлять пакеты в адрес того или иного IP-префикса. Под “соседними” подразумевается, что пограничные маршрутизаторы этих AS взаимодействуют непосредственно (заметьте, это не означает, что маршрутизаторы физически соединены напрямую). На логическом стыке между маршрутизаторами появляется понятие анонса: одна автономная система анонсирует префикс, а вторая – принимает или не принимает данный анонс. Отсюда же вырастают все другие конструкции, определяющие пути пакетов в глобальной Сети. Самой известной такой конструкцией является таблица Full View – глобальная сводная таблица путей (маршрутов), построенная для той или иной точки Сети.

Вот. При чём же здесь связность? Дело в том, что исследование BGP – подчеркну: внешнего протокола маршрутизации, – выливающееся, например, в анализ взаимной “видимости” AS по таблице Full View, это не более чем исследование BGP. Связность Сети – существенно сложнее. Например, распространена ситуация, когда некоторые операторы устраивают между собой широкий канал, который, между тем, никак не анонсируется наружу: в общедоступном BGP его нет, а соответствующие автономные системы, хоть и имеют прямой канал между собой, используют его только чтобы друг к другу ходить. Пример (реальный): сеть роботов поисковой системы и тот или иной крупный хостер. Хостеру нередко выгодно напрямую подключить поисковик к своим фермам, чтобы он индексировал сайты, чем платить кому-то за транзит того же трафика. Это пример лучшей реальной связности, по сравнению с глобальной картиной.

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

При этом, сам по себе анализ BGP является очень полезным инструментом. Но его эффективность велика только при “локальном” применении, когда результат используется в разрезе информации о внутренней топологии сети, например, берётся в связке с данными мониторинга трафика (NetFlow и эквиваленты). При глобальном же использовании – нельзя забывать, что таким образом проводится лишь анализ таблиц BGP, а вовсе не оценка связности Интернета.

Весной этого года ФБР спорило с корпорацией Apple по поводу “взлома” защиты аппаратов iPhone, для того, чтобы получить доступ к одному из таких аппаратов (АНБ из каких-то своих соображений заявило, что помочь не может). Обсуждались самые разные способы получения доступа, в том числе, при помощи физического копирования модуля памяти устройства (NAND mirroring). Почему-то насчёт этого варианта высказывались сомнения относительно реализуемости. Сергей Скоробогатов (Sergei Skorobogatov) продемонстрировал на практике, что задача решаема даже без использования сверхсложного лабораторного оборудования: The bumpy road towards iPhone 5c NAND mirroring – в работе подробно рассмотрены все этапы, начиная от извлечения чипа и до реализации перебора пароля доступа с использованием клонированной памяти (Apple, оказывается, использует некоторые методы аппаратной защиты от такого клонирования, но их можно обойти). Весьма интересно, рекомендую.

Обновил раздел “Избранные записки“. Добавил пять ссылок, вот они:

• Беспроводная технология малой мощности LoRa и модули NiceRF SX1276
• Техническое: DNSCrypt на примере “Яндекс.Браузера”
• Анонимность криптовалют и проблемы регулирования
• Двухфакторная аутентификация
• Число целей, дальность и сравнение истребителей

Я существенно расширил техническое описание TLS в новой версии. Добавил: раздел про симметричные шифры (с описанием AES), описания криптосистем RSA и ECDSA, существенно расширил описание протокола Диффи-Хеллмана; кроме того – дополнил и актуализировал весь текст целиком. Объём вырос почти в два раза – и, да, там много информации, но зато хорошо охвачены технические моменты. На мой взгляд, теперь это одно из самых полных и детальных описаний TLS на русском. Естественно, есть что дописать в следующей версии: расширенное описание атак, подробности про шифры, приложение с глоссарием по математическому аппарату (тут мне оказалось довольно сложно заморозить версию: исходники всё время обрастают новыми деталями, которые я потом отношу к “слишком техничным”), приложение с примерами конфигураций серверов (надеюсь, что в самом обозримом будущем) и другие дополнения. Это кроме того, что скоро должна выйти из состояния draft новая версия спецификации – TLS 1.3 (или 2.0, или как её обозначат), в которой куча радикальных изменений, а поэтому придётся добавить отдельную главу (сейчас я уже внёс некоторые оговорки по тексту, акцентирующие внимание на запланированных отличиях в новой версии).

И, да, наверное нужно сделать там хорошую навигацию – пока добавил только содержание, – и гипертекст.

Надеюсь, что это полезный текст. Вот ссылка: “Как работает ТLS, в технических подробностях“.

(Добавлять ли раздел, посвящённый постквантовым криптосистемам?)

При выборе криптографических средств защиты информации важно определить, в течение какого времени эти информация нуждается в защите. Вот интересная иллюстрация. Предположим, требуется механизм защиты сигнала GPS (или другой спутниковой системы навигации) от подделки (спуфинга). Можно предложить использовать ECDSA, с ожидаемым сроком защиты в десятилетия. Но на практике оказывается, что достаточно использовать некую “сигнальную” криптосистему, обеспечивающую стойкость всего лишь в течение нескольких часов. (Например, это может быть решение, основанное на статистике сигнала.) Казалось бы, криптосистема, которую можно взломать за несколько часов, никуда не годится. Но посудите сами: защита от спуфинга подразумевает, что GPS-приёмник может определить подлинность сигнала, принимаемого в данный момент; какой смысл в подделке аутентификации сигнала GPS, если результат будет отставать на час или два, при том что время здесь учитывается с микросекундной точностью? Никакого смысла. Даже если приёмник и получит такой сигнал, рассогласование по времени позволит его отбросить. (Естественно, остаются варианты с полным переносом атакуемого приёмника в окружение, где время сместилось на “интервал взлома”, но это совсем уж теоретические варианты – вряд ли кто-то, озаботившийся защитой от спуфинга, будет так искажать собственное время в приёмнике. Ну, разве что, если в приёмник пробрался зловред.)

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

Технологии развиваются. Не только в направлении создания утечек. Интересно, что такое контринтуитивное, фантастическое, в области защиты информации, можно будет реально увидеть в обозримом будущем? Думаю, это дистанционное навязывание программного кода. Речь о варианте, в котором возможно дистанционное несанкционированное внедрение программного кода в ту или иную изолированную компьютерную систему, лучше всего – персональный компьютер, при помощи некоторого излучения. Вроде бы, фантастика, но обсуждается много лет, хоть и на грани “разумного допущения”.

Конечно, сходные схемы давно реализованы в разном виде: например, передали зловреда через WiFi. Но прорывным вариантом было бы как раз прямое навязывание в память. Когда целевая компьютерная система штатно не использует каких-то контролируемых атакующим способов связи, а код, достаточного объёма, тем не менее, “наводится” в компьютерной памяти и исполняется. Каким образом? Фундаментальных запретов, как ни странно, нет: например, можно направлять заряженные частицы в ячейки памяти, они станут перещёлкивать значения битов. Отправили нужный поток – получили нужный код. Используя достаточно сложный источник частиц (что-то вроде ускорителя), нужный поток можно сгенерировать. Информацию о расположении модулей памяти компьютера, – а тут потребуется очень точная трёхмерная реконструкция, – берём из технической документации (предполагается, что компьютер типовой). Тут есть огромное количество технических проблем, конечно. Но и способ, наверняка, не единственный.

DNS Privacy – актуальная тема. Речь здесь о том, как снизить утечки информации об использовании интернет-сервисов, происходящие через DNS. Как именно и какая информация утекает? В типичной пользовательской конфигурации, DNS служит базой данных, хранящей соответствие символьных имён и IP-адресов, а поиск в этой базе данных осуществляет рекурсивный резолвер интернет-провайдера (несколько реже – корпоративный рекурсивный резолвер).

Есть два основных потока утечек. Первый – это сведения об узлах, для которых запрашивались имена; во многих случаях эти данные близки к списку посещаемых веб-сайтов, но содержат и другие разнообразные сведения. Второй поток – “помеченный” трафик, характерный для конкретного браузера и конкретных веб-страниц. Ко второму случаю, например, относятся известные способы деанонимизации пользователей при помощи создания уникальных имён ресурсов, ссылки на которые встраиваются в код веб-страницы. Браузер, пытаясь извлечь ресурс по ссылке, отправит уникальный идентификатор страницы на сервер имён, поддерживающий зону DNS, которая послужила базисом в системе деанонимизации. Обычно маркером служит уникальное имя, созданное для конкретного запроса, например: kf356askg.example.com (уникальный идентификатор здесь – kf356askg). Интересно, что если вы просматриваете пользовательский DNS-трафик, то идентифицирующие маркеры можно распознавать и без использования серверов имён: они будут передаваться в открытом виде.

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

При штатной работе DNS, резолвер всегда начинает опрос серверов с полным именем искомого ресурса в составе запроса. На минуточку предположим, что в нашем простом случае исчезло кеширование. Тогда, если пользователь, например, задумал обратиться на www.example.com, то об этом имени, сопоставленном с IP-адресом используемого резолвера, узнают и корневые серверы глобальной DNS, и корневые серверы .COM, и серверы имён зоны EXAMPLE.COM. Так устроен протокол. При этом, если исходить из необходимости получения А-записи для www.example.com, знать о полном имени запроса нужно только серверам зоны EXAMPLE.COM (строго говоря, серверам WWW.EXAMPLE.COM, но эти детали мы опустим). Борьба с данной утечкой называется QNAME Minimization – есть RFC 7816, со статусом Experimental. Основная идея состоит в том, чтобы резолверы направляли запросы, минимизируя утечки информации. В случае с www.example.com – можно спрашивать корневые серверы сразу об именах серверов имён (NS) зоны .COM, и так далее.

DNS-трафик ходит в открытом, незащищённом виде. Незащищённый вид, в случае использования валидирующего резолвера, не касается зон, подписанных DNSSEC, но данное сочетание пока что практически не встречается в дикой природе. Открытость и незащищённость позволяет третьей стороне не только просматривать содержание запросов и ответов, но и подделывать ответы, подменяя адреса серверов на более удобные. Подмена, естественно, требует активного вмешательства в канал, но прелесть DNS тут в том, что вовсе необязательно находиться на “последней миле” – если вы получаете информацию об отправленных запросах DNS, то ответить в адрес резолвера можно из любой точки Сети, главное, чтобы поддельный ответ был доставлен быстрее, чем настоящий.

Защите DNS-трафика от прослушивания и, частично, подмены, посвящена технология DNS over TLS, описанная в свежем RFC 7858. Мало кто ожидает, что в ближайшее время при помощи TLS будут защищены все DNS-транзакции, но технология позволяет это сделать. Параллельное решение – DNSCrypt, про который я рассказывал не так давно. Вариант с TLS выглядит несколько более предпочтительным, так как вписан в существующую технологическую архитектуру Сети, где TLS является основной для защиты трафика.

Я уже как-то писал на эту тему: сенсорам автомобилей-роботов можно ставить активные помехи. Собственно, до этой задачи потихоньку добрались публично – Wired рассказывает о том, как исследователи ставят помеху радару автомобиля Tesla, а также и ультразвуковым датчикам препятствий этого же автомобиля. (Не ясно, почему выбрали Tesla – возможно, из-за максимальной медийной узнаваемости.)

Эта тема имеет историю в несколько десятков лет. Правда, она касается не автомобилей, а военных радиолокационных комплексов самого различного назначения. Помехи ставили и ставят бортовым РЛС истребителей и радарам наземных комплексов ПВО. В тексте Wired, впрочем, ничего про военные системы не сказано, но это не отменяет истории разработок. Постановка помех – довольно хитрая область, где наряду с передовыми методами обработки сигналов и сложной микроэлектроникой применяется такая математическая дисциплина, как теория игр. В случае с военной техникой от искусственных помех специально пытаются отстраиваться (про естественные – и так понятно). Например, радары могут использовать сигналы сложной структуры (и во временной, и в частотной области), которые сложно обнаружить (LPI) и, соответственно, сложно поставить активную помеху, вводящую систему в заблуждение. Для автомобильной техники этот вариант, скорее всего, просто не рассматривается: максимум, система управления учитывает естественные помехи и пытается обнаружить ситуацию потери точности измерения, чтобы сигнализировать об “отключении автопилота” (именно так действует Tesla из статьи). Проблема в том, что активный помехопостановщик может создать картинку, неотличимую от настоящей, с точки зрения системы управления. И это большая проблема, потому что автомобиль с таким помехопостановщиком может находиться в потоке транспорта, хоть это и похоже на сюжет из киберпанковского кинофильма.

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

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

В экспериментальной версии Google Chrome добавлена поддержка “постквантовых” алгоритмов в TLS. “Постквантовая криптография” – это собирательный термин, обозначающий криптосистемы и отдельные алгоритмы, для которых не известно быстрых методов взлома на квантовом компьютере, либо доказано, что таких методов нет (строгое требование доказанного отсутствия возможности “квантового взлома” не является обязательным).

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

Вообще, пока никто не продемонстрировал на практике для сколь-нибудь мощных квантовых компьютеров работу алгоритмов, составляющих угрозу для асимметричных криптосистем. Таких компьютеров просто нет (устройства D-Wave не считаются, так как они не подходят). Учитывая, что вся вычислительная мощь данных алгоритмов кроется в физических свойствах окружающей действительности, нельзя исключать, что задача создания подходящего квантового компьютера окажется несравнимо труднее, чем принято считать сейчас: до сих пор нельзя со полной уверенностью сказать, что компьютер с 1024 кубитами вообще возможен практически. С другой стороны, одно дело – полная уверенность, а совсем другое – быстрое развитие прикладной науки. Так что угроза появления квантового компьютера достаточной мощности считается реальной уже сейчас, по этому поводу есть публикации NIST.

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

В Chrome добавили постквантовый протокол с рабочим названием New Hope, позволяющий сторонам договориться о сеансовых ключах. Вообще, в основе этой схемы (являющейся вариантом Ring-LWE, где LWE – это алгоритм Learning With Errors, реализованный для решётки, а кольцо там появляется из-за используемой арифметики и коэффициентов; но технические подробности я оставляю для другой записки) лежит та же математическая идея, что и в протоколе Диффи-Хеллмана. Однако принципиально иной фундамент позволяет добиться требуемой постквантовой стойкости. Почему для эксперимента выбрана схема получения сеансовых ключей? Отложенные атаки важны только для защиты ключей шифрования, а не для защиты аутентификации. Действительно: какой смысл во взломанной спустя год схеме аутентификации? Подменить узел постфактум – не получится. А вот раскрытие ключей симметричного шифра позволяет прочитать трафик. И, кроме того, с постквантовой аутентификацией ситуация обстоит несколько хуже, чем с алгоритмами распределения ключей.

Пока не понятно какие именно постквантовые схемы войдут в состав TLS и когда это произойдёт. Для полноценной замены имеющихся инструментов потребуется схема аутентификации, вместо RSA и ECDSA в SSL-сертификатах. Тут квантовый компьютер превращает сложившуюся практику в “тыкву”: раскрыв секретный ключ сервера, можно активно перехватывать сессии в его направлении. Не исключено, что поменяется сама логика распределения ключей.

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

(Техничная записка из области популярной криптологии, которая, думаю, будет полезна и на 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 и логарифмирования – он не нужен.)