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

Опубликована исходная работа, описывающая создание DoS-атак на резолверы при помощи специально сконструированных зон с коллизиями (совпадениями) идентификаторов ключей. Совпадение – это именно тот случай, который я недавно описывал на примере конкретной зоны. Там, конечно, не только совпадающие идентификаторы/теги используются, но они имеют определяющее значение, поскольку заставляют валидирующий резолвер перебирать большое количество ключей. Цитата:

Evaluating KeySigTrap, we set up a zonefile with 582 colliding DNSSEC keys and 340 signatures.

Это CVE-2023-50387.

(via)

Добавил в DNS-зону dnssec.pw, которая из недавней записки про совпадающие теги (KeyTag), несколько дополнительных ключей и подписей, чтобы создать минимальное разнообразие криптосистем: была только RSA, добавил ECDSA на P-256, плюс ECDSA KSK (ключ для подписывания ключей) с тегом 12345, как у прочих (кроме SEP-ключа). В общем, ключей теперь много, так что зона разрослась. Зато несколько удобнее тестировать приложения. (Кстати, в зоне сейчас нет A-записей; кроме DNSSEC-записей там только SOA и NS, возможно, другие записи появятся позже.)

Интересно, что Google Public DNS (8.8.8.8) при взаимодействии с зоной dnssec.pw, которую я на днях снабдил ключами с одинаковыми тегами, продолжает возвращать неконсистентные результаты, если спрашивать об отсутствующих в зоне записях. Например, при запросе TXT-записей в dnssec.pw теперь нередко приходят ответы со статусом SERVFAIL, “RRSIG with malformed signature…” – написано в пояснении. Однако есть и ответы со статусом NOERROR (примерно, половина, как ни странно), где, впрочем, пояснение тоже указывает на “RRSIG with malformed signature…”.

Возможно, конечно, что в данном сервисе на разных экземплярах узлов разное программное обеспечение, но есть и другое, несколько более занятное, объяснение: может так быть, что сервис ограничивает количество попыток проверки подписи для каждой итерации. В зоне четыре ключа ZSK, подпись RRSIG на NSEC – одна, на SOA – две. Соответственно, если у резолвера установлено некоторое предельное количество ошибок проверки подписи, то, когда предел достигнут, резолвер прекращает попытки перебора ключей и возвращает SERVFAIL. Если же ключ удалось угадать за меньшее количество попыток, то возвращается NOERROR. Подсчёт строк с сообщениями “RRSIG with malformed signature” в ответах – укладывается в эту гипотезу, но чтобы судить точнее – нужно собрать дополнительную статистику.

Немного занимательной математики и глобальной DNS.

Насколько велика вероятность, что в доменах первого уровня глобальной DNS совпадут теги разных ключей DNSSEC? Нередко приходится слышать, что так как тег 16-битный, то и вероятность, примерно, 1/65535 (за вычетом особенностей алгоритма вычисления значения тега и пр.). Это не верно. Если рассматривать совпадения внутри набора ключей DNS, то получаем хрестоматийный пример парадокса дней рождения: нам не важно, чтобы повторилось конкретное, заданное значение тега, напротив – требуется совпадение любого значения внутри любой пары, а это совсем другая история, поскольку количество всевозможных пар велико даже в небольших наборах ключей. Поэтому вероятность совпадения тегов DNSSEC-ключей, на практике, очень велика. Иногда ключи просто обязательно совпадут по тегам. Например, в списке доменов первого уровня (корневой зоны DNS) сейчас 1452 имени, то есть, можно составить 1053426 пар (больше миллиона). А это количество (практически) гарантирует, что будут совпадения тегов ключей.

И действительно, если собрать DNSKEY-записи из доменов первого уровня, то окажется, что значений повторяющихся тегов, – то есть, значений, которые встречаются для разных ключей в разных зонах, – сильно больше сотни: у меня получилось 129 таких тегов. Обратите, кстати, внимание, что некоторые ключи разных зон TLD имеют одинаковые теги потому, что это просто одинаковые ключи. Такие повторы отбрасывались. Потому что корректно – сравнивать именно сами значения ключей (как и в прочих случаях использования тегов). Например, различные DNSSEC-ключи с одинаковыми тегами опубликованы в зонах cab и today, в зонах agency, weber и temasek, и во многих других.

(Дополнение: естественно, выше предполагается, что ключи для различных зон генерируются независимо, случайным образом.)

DNSSEC-подписи, удостоверяющие адресную информацию, размещаются в RRSIG-записях. Ссылка на открытый ключ, нужный для проверки подписи, в RRSIG записывается в виде 16-битного тега (KeyTag), который вычисляется по достаточно простому алгоритму от данных ключа. Соответственно, ключи публикуются в DNSKEY-записях. Можно ли специально подобрать несколько валидных ключей так, чтобы у них были одинаковые теги? Очевидно – можно (ключей много больше, чем тегов). И подбор совсем нетрудно сделать. Более того – даже сохранятся валидные подписи и, условная, “корректность” зоны с точки зрения DNSSEC. “Корректность” тут в кавычках потому, что, вообще говоря, несколько ключей с одинаковыми тегами не должны бы присутствовать в DNS-зоне, поскольку это нарушает логику ссылок из RRSIG. И хорошо бы в таком случае выводить ошибку валидации, но возможен более мягкий подход, который и используется.

Посмотрите, в качестве примера, на DNS-зону dnssec.pw – там я разместил несколько ключей (ZSK – Zone Signing Key), которые имеют одинаковые теги со значением 12345. Два ключа из четырёх ZSK задействованы в подписывании записей, а поскольку подписи можно проверять методом перебора ключей, то и RRSIG – валидируются, если валидатор резолвера справляется с ситуацией. Пятый ключ – это KSK, точка входа. Схема показана на картинке (ниже), которую сформировал весьма полезный сервис DNSViz. Повторяющиеся идентификаторы (id = 12345) выглядят занятно, однако количество вершин графа соответствует количеству ключей, а рёбра – соответствуют структуре подписей. Так что DNSViz не сломался:

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

Валидирующие резолверы должны справляться с подобной конфигурацией ключей, однако Google Public DNS (8.8.8.8) возвращает в статусе информацию о “некорректном формате RRSIG”, но ответ всё равно снабжается флагом AD (Authentic Data), обозначающим, что проверка подлинности DNSSEC прошла успешно – впрочем, это соответствует действительности: подписи и цепочка в зоне dnssec.pw сейчас верные.

Официальное сообщение КЦ .RU/.РФ о вчерашней проблеме с DNSSEC: “возникшая коллизия ключей, в причинах которой в настоящее время продолжают разбираться специалисты Технического центра интернет (ТЦИ) и MSK-IX, привела к временной недоступности зоны .RU для части интернет-пользователей”.

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

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

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

Небольшое продолжение записки про извлечение секретных криптографических ключей из дампов памяти (оперативной). Ключи в памяти могут быть замаскированы – тогда не работает простой и универсальный метод, основанный на полном прямом переборе последовательностей байтов с пробным расшифрованием или с пробным вычислением открытого ключа асимметричной криптосистемы. То есть, предположим, что ключ ECDSA разрядности 256 бит находится в памяти в виде записанных последовательно 32 байтов. При этом известен открытый ключ, соответствующий искомому секретному. Тогда можно последовательно двигаться по дампу памяти, выбирать очередные 32 байта, вычислять открытый ключ и сравнивать его с проверочным. Если значения совпали, то секретный ключ найден. Это и есть прямой перебор. Вычисление открытого ключа ECDSA – достаточно быстрая процедура, так что проверка нескольких гигабайтов памяти даже на обычном настольном ПК не займёт много времени.

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

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

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

Постепенное раскрытие ключей при штатной работе подходит и для симметричных шифров. Например, в AES можно замаскировать при помощи XOR основной ключ и раскрывать его частично в ходе вычисления ключей раундов, которые, соответственно, тоже маскируются по мере разворачивания, при этом маска подмешивается в реализацию основного преобразования шифра, уже к ключам раундов.

Защита ключей в памяти важна и используется, но сложности, подобные описанным только что, вряд ли имеют первоочередное значение в ситуации доступа к виртуальной машине из гипервизора, как в исходной записке. Тем не менее, некоторые варианты защиты со сложными алгоритмами вполне полезны для аппаратных устройств, где маскирующее значение, например, может находиться в отдельном модуле памяти, который сложнее прочитать, чем оперативную память.

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

Пример: есть база данных (БД), в которой записан рост людей из комнаты, с точностью плюс/минус пять сантиметров; хорошо ли эти данные помогают различать людей в рамках воображаемой комнаты? Вообще, разнообразие роста велико, но есть некоторый интервал, в который попадает очень много людей. Поэтому, в комнате окажется много людей как бы одинакового роста, в терминах нашей БД, тем более, что рост, по условиям, укладывается в плюс/минус пять сантиметров. Однако, если в комнате присутствует человек ростом 205 сантиметров, то, если это не встреча баскетболистов, скорее всего, персону нетрудно будет связать с записью из базы – интервал от 200 до 210 сантиметров не слишком-то заселён. Теперь, если в базе присутствовали данные о росте (плюс/минус – для “обезличивания”) и, скажем, фамилия, имя и отчество, то можно будет подойти, и к человеку высокого роста обратиться точно по имени. (Понятно, что знание ФИО вообще позволяет устроить перекличку, но Константинов Каретиных, предположим, может оказаться несколько.)

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

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

Понятно, что различительная способность резко возрастает, когда к одним данным добавляются другие.

Данный мысленный эксперимент не является универсальным, но неплохо работает и для других видов данных, вплоть до сведений о покупке деловых костюмов, – попробуйте сами.

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

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

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