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

Всякая беспроводная технология предоставляет множество дополнительных направлений для скрытых дистанционных атак. В этот раз продолжают эксплуатировать вектор Bluetooth для беспроводных клавиатур и прочих HUD: возможность обойти авторизацию/аутентификацию позволяет подключиться к устройству с правами локальной клавиатуры, дальше – и так понятно. В большинстве случаев – проблема кардинально и без существенных дополнительных трудностей решается проводами, но это мало кому интересно. Кстати, даже древний ИК-порт тут сильно лучше защищён, потому что требует прямой видимости, но ИК-порты давно вышли из моды.

Радиомодуль (процессор радиоканала) в смартфоне является “вещью в себе”: то есть, это автономный, аппаратно обособленный вычислитель с аналоговой подсистемой для радиосигналов, достаточно мощный, со своим встроенным программным обеспечением, который другим модулям предоставляет некоторый интерфейс “радиомодема”. (Тут ещё не нужно забывать про WiFi, Bluetooth и пр., конечно.) Например, как недавно сообщали, даже в Apple почему-то не смогли пока что разработать собственный процессор радиоканала. Аппаратные и программно-аппаратные недокументированные возможности для смартфонов можно придумать весьма занимательные – например, несколько лет назад я описывал гипотетический вариант со схемой получения информации по акустическому каналу, потенциально устойчивый к исследованию ПО и схемотехники. Особенно интересно могут выглядеть недокументированные возможности, встроенные в процессор радиоканала – потому что это устройство видит радиоэфир.

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

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

Добавил на экспериментальный (тестовый) сервер TLS 1.3 разбор и вывод расширения ECH (Encrypted Client Hello). Это расширение присылают свежие версии браузера Chrome/Chromium, раньше сервер просто узнавал тип расширения, но не выводил содержание. Для того, чтобы браузер прислал ECH (GREASE) в качестве сигнала – поддержка ECH на TLS-сервере или в DNS не требуется. Расшифровать ECH не получится, потому что в таком варианте просто нечего расшифровывать: это сигнальный вариант ECH, ключа у сервера нет, да и основное содержание ECH должно быть представлено байтами со случайными значениями. Однако это не мешает проверить формат и вывести значения полей.

Адрес сервера: https://tls13.1d.pw/. Если успешно подключились свежим Chrome, то ECH нужно искать по “ECH /DRAFT/” (идентификатор 0xFE0D).

В алгоритме ECDSA есть число, обычно обозначаемое k, которое используется при вычислении значения подписи, а именно – k определяет параметр r из пары (r,s) подписи. Значение r из этой пары необходимо для того, чтобы сошлась формула проверки. В исходном алгоритме k предлагается выбирать случайным образом (но без повторов, и держать в секрете). Дело в том, что если третья сторона знает k, то она может элементарным способом вычислить секретный ключ по сообщению с подписью; повторное использование k для разных сообщений, при прочих равных, так же приводит к раскрытию секретного ключа.

Можно встретить мнение, что такая особенность заложена в ECDSA специально (оставлено за скобками то, что такой подход использовался и в других, предшествующих ECDSA, криптосистемах). Действительно, если, например, k вычисляется по некоторому алгоритму генерирования псевдослучайных чисел “с секретом”, то если третьей стороне известны скрытые особенности данного алгоритма, эта сторона может раскрыть секретный ключ ECDSA, быстро подобрав k под открытое значение r, которое можно взять из подписи. (Это хрестоматийный теоретический подход к созданию бэкдоров методом “алгебраического разбиения”.)

Вообще, на этом направлении весьма легко ошибиться в программном коде, без всякого бэкдора. Либо подведёт аппаратура, обеспечивающая выдачу случайных значений. Либо вмешается тот или иной гипервизор – сейчас повсеместно используется виртуализация для размещения программного кода, вычисляющего ECDSA-подписи, с этим сложно что-то поделать, как и с тем, что инженеры DevOps обожают делать “снапшоты” виртуальных машин, а потом их восстанавливать (так себе решение) или множить (ещё хуже). Заметьте, кстати, что всё это полностью применимо и к современной ГОСТ-подписи – там математически эквивалентная схема.

Так что проблем с псевдослучайным параметром в ECDSA много. На практике, в алгоритм вычисления k так или иначе подмешивают дополнительные значения, не ограничиваясь лишь выдачей генератора псевдослучайных чисел. Это полумера. Однако есть и полностью детерминированный вариант (“deterministic ECDSA“), в котором значение k вычисляется для конкретного сочетания сообщения и секретного ключа (например, такой алгоритм поддерживается свежим OpenSSL 3.2).

Практика использования детерминированного варианта сопряжена с ещё одним занятным моментом. Если сообщение подписывается обычной ECDSA (или ГОСТ-подписью), то значение подписи будет каждый раз разным, даже для одного сообщения и одного подписывающего ключа. То есть, значение подписи псевдослучайное, и этот факт вполне может использоваться приложениями (хотя, вообще говоря, не должен бы). Соответственно, “фиксирование” значения подписи в таком приложении может что-то сломать. Но детерминированный вариант, конечно, всё равно лучше.

На OpenNET пишут про RFC для децентрализованной системы имён GNS:

“Использование Curve25519 воспринимается некоторыми как весьма странный шаг, так как для ECDSA применяют другие типы эллиптических кривых, а в паре с Curve25519 обычно используют алгоритм цифровых подписей Ed25519, более современный, более безопасный и более быстрый, чем ECDSA. С точки зрения криптостойкости в том числе вызывает сомнение выбор размера закрытого ключа – 32 байта вместо 64 байт”

В GNS, действительно, используют ECDSA на кривой Curve25519. Это может, конечно, показаться странным. Однако алгоритм ECDSA работает в группе точек и вообще не зависит от выбора кривой (да, даже про “суперсингулярные кривые” тут есть занятные уточнения). Поэтому ничто не мешает взять Curve25519 вместо, например, более привычной P-256. Какие-то сугубо математические свойства Curve25519, типа наличия кофактора и т.п., вовсе и не являются необычными – такие кривые вполне себе подходят и для ECDSA. Так что, если нет доверия той же P-256, но нужен именно алгоритм ECDSA – можно взять Curve25519. Использование же Ed25519 в данном протоколе невозможно из-за особенностей преобразования ключей, о чём, собственно, сказано в RFC. Насчёт “более быстрого” алгоритма Ed25519 – это, в основном, определяется как раз параметрами кривой (поле и т.д.).

Что касается странного дополнения про 32-байтовый и 64-байтовый ключи: тут, наверное, что-то перепуталось на каком-то этапе пересказывания. В Ed25519 секретный ключ – 32-байтовый. И в ECDSA на P-256 (например) – тоже 32-байтовый. Потому что разрядность в 256 бит (32 байта) делает бессмысленным использование секретных ключей большей длины: всё равно значение сократится. А 64 байта – это общий размер подписи, а не ключа.

Можно предположить, что тут ещё сыграло следующее популярное заблуждение, которое нередко наблюдается в отношении SSH-ключей: многие считают, что, например, поскольку открытый ключ Ed25519 короче, чем ECDSA на той же P-256, он поэтому и менее “криптостойкий”. Действительно, для ECDSA/P-256 открытый ключ обычно записывается в 64 байта (иногда чуть меньше, иногда – чуть больше, зависит от кодирования), а в Ed25519 – только в половину, в 32 байта. Однако эти 64 байта ECDSA математически эквивалентны 32 байтам, там половина байтов приносит только один бит дополнительно: открытый ключ представляет собой точку на кривой, у точки – две координаты (X,Y), каждая по 32 байта, и вот полная форма записи ключа ECDSA подразумевает указание объединения X и Y, откуда и получается 64 байта; однако можно указывать только одну координату (X), а вторую (Y) – вычислять из уравнения кривой при необходимости. В такой схеме, для ECDSA, потребуется сохранить дополнительно знак, это один бит, и получается тоже около 32 байтов для записи открытого ключа. А вот в Ed25519 алгоритм предписывает всегда использовать только одну координату (ну, строго говоря, там есть ещё некоторые преобразования, но здесь они не важны). То есть, математически эти ключи совпадают по представлению, отличие тут чисто прикладное, поэтому дополнительные 32 байта записи для ECDSA не делают даже открытый ключ в два раза длиннее “криптографически” – он всё равно 256-битный (по разрядности кривой).

Надо сказать, я несколько лет назад отмечал, что интересно будет посмотреть, внедрит ли Google поддержку ESNI в свой браузер. Интерес, на мой взгляд, тут происходил из того, что Google последовательно отказывался поддерживать такие технологии обеспечения безопасности, которые использовали тот или иной независимый инструмент управления криптографическими ключами в TLS. Примеров два: изгнание из веба DANE (отпечатки ключей/сертификатов в DNS, для сверки с предъявляемыми сервером) под предлогом замены на Certificate Transparency (которая хоть и полезная, но о другом, так как не может предотвратить использование валидного подменного сертификата в момент соединения); отключение HPKP (запоминание отпечатков серверных ключей клиентом, как в SSH).

И вот я предположил, что, вероятно, ESNI тоже не будет в Google Chrome. Но сейчас вышло иначе: вместо исходного варианта ESNI – Google Chrome (Chromium) всё же поддержал ECH, а это развитие ESNI, гораздо более продвинутое. Впрочем, думаю, что в этой “продвинутости” и состоит причина поддержки: всё же, ECH далеко ушла от первоначальной идеи ESNI – позволяет реализовать доступ к скрытым сервисам, при этом наследует доверие системе хорошо известных удостоверяющих центров (“имени CA/B-форума”); впрочем, ECH и ключи для дополнительной защиты внутри TLS позволяет публиковать, например, в DNS, то есть, не централизованным способом, который, формально, не зависит от браузера (но нельзя забывать о встроенной поддержке DNS-over-HTTPS с заданными провайдерами). В общем, поддержка внешних ключей появилась, но теперь нужно посмотреть, как будет она развиваться: ведь доверенные ключи для ECH могут приезжать и вместе с браузером – это важная особенность.

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

Браузеры очень распространены, это один из основных источников трафика обычных пользователей – если привычный браузер перестанет работать “из коробки”, то, для таких пользователей, это окажется эквивалентно исчезновению доступа к Интернету. Однако, чтобы использовать наложенную сеть, программа-клиент не обязательно должна быть браузером: механизм доступа конкретно к браузеру не привязан – там достаточно универсальное туннелирование. Впрочем, похоже, что будет требоваться Google-аккаунт и аутентификация при доступе, но этот момент тоже переносится в другие приложения.

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

Кстати, одним из весьма вероятных вариантов развития систем пропуска пользовательского трафика через (условный) Интернет является пропуск маршрутизаторами только пакетов, подписанных ключами доверенных приложений; либо это могут быть подписанные сессии – тут зависит от выбранного подхода. Интересно, что в описании европейского цифрового удостоверения личности (eID – European Digital Identity), которое недавно прошло очередной этап утверждения, можно уже увидеть что-то подобное, пусть и в общих чертах: приложение на устройствах, привязанное к оплате телекоммуникационных услуг – понятно, что задача идентификации интернет-пользователя там давно заявлена, но, развивая контекст по заданному направлению, нетрудно предположить, что соответствующие приложения появятся и у провайдеров на BRAS (это инженерное название для систем управления массовым клиентским доступом); даже есть занятная оговорка, что, мол, некоторое программное обеспечение, из реализующего работу eID, можно будет не публиковать в открытых исходниках (последний момент, конечно, не стоит переоценивать, но всё же).

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

Рассмотрим ситуацию на примере колонки – они очень популярны. Понятно, что “умная” колонка через встроенный микрофон (микрофоны) может постоянно прослушивать помещение и, например, узнавать людей по голосам. Так как есть центральный сервер, то много колонок в разных помещениях могут определять, где бывает тот или иной “носитель голоса”. Тут стационарность колонки составляет преимущество, по сравнению со смартфоном. Однако колонка ещё может взаимодействовать с приложением в смартфоне, который находится рядом: во-первых, штатными способами (это управление и прочие привычные функции – через центральный сервер, напрямую через локальный WiFi/Bluetooth); во-вторых – через дополнительный акустический канал, поскольку у колонки есть не только микрофон, но и динамики. Акустический канал может быть хорошо замаскирован для человеческого слуха – годится и ультразвук, и сокрытие наложенным сигналом. Особенность акустического канала в том, что колонка может взаимодействовать с приложением, которое официально никак с колонкой не связано. И, естественно, нужное приложение может автоматически “приехать” и в смартфон, и в колонку.

Кстати, если вдруг придумают алгоритм быстрой факторизации больших полупростых чисел, сломав тем самым RSA, то, конечно, “популярной мотивации” для создания универсального квантового компьютера станет сильно меньше: на этом направлении всегда пишут про алгоритм Шора. А вот с необходимостью перехода на постквантовые криптосистемы, в этом случае, есть интересные особенности.

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

В атаке с перехватом трафика Jabber.ru использовался активный сетевой прокси с MITM. Однако если процесс, реализующий TLS, исполняется в виртуальной машине, а гипервизор контролируется провайдером хостинга, то можно проводить полностью пассивную атаку с рашифрованием TLS-трафика, да так, что из виртуальной машины атаку видно не будет. Это существенно сложнее прокси, терминирующего TLS с подменным сертификатом, и ограничивает возможности по расширению атаки до активной (с вмешательством в трафик), но является куда как более изящным методом. Для реализации требуется доступ к функции копирования (“дампа”) памяти гипервизора, а кроме того, естественно, доступ к сетевому трафику виртуальной машины (либо тоже на уровне “виртуализации” гипервизора, либо на уровне “внешней” сети).

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

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

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

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

Ключи и секрет могут быть замаскированы в памяти приложением (обычно, XOR с псевдослучайной маской, маска хранится отдельно или вычисляется по необходимости специальной функцией). Такое решение встречается нередко. Однако для того, чтобы ключи использовать – их всё же придётся раскрыть для операций хеш-функций и шифров, поэтому достаточно угадать момент выполнения дампа памяти. (Можно предложить алгоритмы с дополнительным непрерывным перемешиванием адресации и масок на уровне реализации шифров/хеш-функций, но вряд ли такое где-то встречается на практике.)

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

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

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