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

Основой для объединения множества сетей в Интернет является понятие автономной системы (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 и логарифмирования – он не нужен.)

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