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

В Let’s Encrypt собираются внедрить (англ.) новый метод проверки права управления доменом (DCV), который, при помощи публикации специальной TXT-записи, привязывает DNS-зону к ACME-аккаунту, а не к коду валидации, и при этом такая привязка становится “постоянной” – видимо, с точностью до того, как сервер будет запрашивать TXT-записи и фиксировать факт удаления соответствующего кода. Метод называется DNS-PERSIST-01.

Довольно занятное начинание. Например, в описании от Let’s Encrypt (по ссылке выше) имеется пространная “мотивировочная часть”, где несколько раз утверждается, что, мол, “во многих конфигурациях реквизиты доступа к DNS API распределяются через “пайплайны” выпуска и обновления [сертификатов], увеличивая количество мест, в которых атакующий может их [реквизиты] скомпрометировать”. Так, конечно, делать нельзя – нельзя раздавать реквизиты доступа к DNS “пайплайнами” по многим местам – ACME этого не требует. Но забавный момент тут в другом: предлагаемая схема, предположим, уходит от “раздачи реквизитов” от DNS, но зато привязывает всю защиту и безопасность к ключу от ACME-аккаунта!

То есть, ACME-аккаунт в этой схеме строго привязывается к DNS-имени, поэтому, если атакующая сторона получила доступ к ACME-аккаунту, то доступ к DNS уже вообще не нужен. Многие ли DevOps и системные администраторы вообще знают, что в ACME-клиенте есть секретный ключ от аккаунта, которым подписываются запросы, и о том, где этот ключ хранится? Не раздаётся ли этот ключ через “пайплайны” по резервным копиям? Вопросы, впрочем, риторические. Но должно же быть очевидно, что замена одной потенциальной “точки взлома” (доступы к DNS) на единственную другую (ACME-ключ клиента) – не даёт каких-то новых преимуществ с точки зрения безопасности. Но нет – приводят в пример. (Все эти моменты, кстати, описаны в черновике RFC для DNS-PERSIST-01. Но это – и черновик, и вряд ли многие прочитают.)

ACME-аккаунт – контролируется УЦ; можно предположить, что это не важно – УЦ и так выпускает какие хочет сертификаты; однако на практике, если используется одноразовый код подтверждения через DNS, есть небольшая надежда, что модуль проверки права управления доменом – как-то отвязан от модуля авторизации ACME-запросов; в случае же нового варианта – достаточно контроля над обработкой ACME-запросов.

И если, на практике, на стороне, которая заказывает TLS-сертификаты, управление DNS ещё как-то понятно администраторам, то ACME-клиент – совсем мутная вода.

Естественно, для того, чтобы публиковать коды ACME-подтверждения в DNS, не требуется раздавать реквизиты от этой DNS по куче мест. То есть, понятно, что такое регулярно происходит на практике, тут у Let’s Encrypt всё верно написано: это, как раз, один из побочных эффектов всей этой “автоматической истории” с ACME – раскидывание CNAME и тому подобные нехорошие варианты. Но управление DNS проще реализовать правильно и надёжно, чем управление ACME-клиентом: например, машина, которая является источником обновлений DNS-зоны, может сама ходить за кодами на точку раздачи, подтверждая потом публикацию ACME-клиенту, и так далее – вариантов много. В теории, наверное, и для ACME-ключа можно придумать серьёзную защиту. Проблема тут совсем в другом: многие знают, что DNS нужно защищать, а то будут проблемы; о том, что защищать нужно ACME-аккаунт – ну, может, кто-то и подумал, но даже если и подумал, то, скорее всего, решил: “а зачем? всё равно же DNS-доступ нужен для выпуска сертификата”. И не забывайте, что доступ к DNS, действительно, всё так же позволяет выпустить TLS-сертификат, только теперь ещё и доступа только к ACME-аккаунту становится достаточно.

Кстати, про схемы генерирования криптографических параметров и при чём здесь NUMS (Nothing Up My Sleeve – “Ничего в моём рукаве”). Опасения всегда связаны вот с чем: предположим, что сильный атакующий разработал специальные “секретные теоремы высшей алгебры” и, например, может эффективно взламывать асимметричные криптосистемы для чисел специального вида, но какой там “вид” – это секрет. Те, кто “секретные теоремы” ещё не узнал, взламывать не могут. Но чтобы схема работала, стандартные параметры должны состоять из тех самых чисел специального вида. (Конечно, схема имеет фундаментальную проблему: как только “секретные теоремы” перстают быть “секретными” – криптосистема ломается для всех. С одной стороны – это очень плохо. С другой стороны – сейчас уже обстановка достаточно странная для того, чтобы подумать: “кому какая разница? просто возьмите другую криптосистему”.)

Использование специальных параметров, если они подобраны хорошо и в соответствии с математикой криптосистемы, – это не обязательно бэкдор в самой криптосистеме, как ни странно. Дело в том, что и так есть много требований к выбору параметров, чтобы эти параметры были стойкими. Например, в “мультипликативном” варианте протокола Диффи-Хеллмана модуль P должен быть простым числом, но таким, что (P-1)/2 – тоже простое число. Или, для классических схем на эллиптических кривых, с дискретным логарифмом, нельзя выбирать кривые определённого вида, например, суперсингулярные с малой степенью вложения. И так далее, и тому подобное: есть много требований к RSA, есть требования к ML-DSA и пр. Начать с того, что элементарное требование на минимальную битовую длину записи – это требование к стойкости числового параметра, которое является универсальным и для симметричных, и для асимметричных криптосистем. Другими словами – у конкретных реализаций криптосистем есть типовые параметры, эти параметры должны быть выбраны так, чтобы не было “сомнений в добрых намерениях”. “Специальный” же вид – лишь добавляет “секретное” свойство, которое прямо в требованиях не указано.

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

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

Конечно, существуют сложные детерминированные схемы с хеш-функциями, цифровыми подписями, доказательствами с нулевым разглашением и заголовками новостей в газетах, взятыми на день генерации параметров по модулю вершины блокчейна биткойнов. Но это именно что сложные схемы. А вот в упоминавшемся недавно RFC 7919 – описана простая схема получения неслучайных и надёжных простых чисел. В этой схеме используется запись числа e (основание натурального логарифма). Чем такая схема хороша?

Во-первых, в полученных таким способом числах есть дополнительная структура. Это важный момент: нельзя говорить, что это числа, в которых дополнительной структуры быть не может. Структура там есть, и она как раз состоит в том, что часть битов двоичной записи соответствует цифрам записи числа e с определённой позиции, согласно опубликованной формуле. В этом и смысл: конечно, e – иррациональное, а в его бесконечной записи можно найти запись любого простого числа (возможно, потребуется подобрать систему счисления, но это совсем технические детали, оставим их); однако формула выбора гарантирует, что будет взято первое слева подходящее число. Это число вполне конкретное, предопределённое. Его нельзя заранее подогнать под требования закладки. Да, данное число определяется структурой, но эту структуру заложили давно, когда определяли математическую константу e. Сложно предположить, что Бернулли и Эйлер придумали алгоритмы вычисления e с учётом непростых криптографических реалий начала 21 века.

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

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

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

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

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

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

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

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

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

Корень глобальной DNS сейчас подписан, в рамках DNSSEC, криптосистемой RSA. В ICANN – организации, определяющей требования к работе глобальной DNS, – некоторое время назад запустили процесс перехода корневой зоны с RSA на ECDSA (P-256/SHA-256, это алгоритм номер 13 в DNSSEC). В текущей версии предложения ICANN планируется переход в течение четырёх лет. То есть, переход должен завершиться в 2030 году (традиционная дата, да).

Сейчас среди зон ниже первого уровня мало что подписано, мало где есть DNSSEC. Например, в .RU – это какие-то доли процента. Тем не менее, DNSSEC касается всех валидирующих резолверов, и если DNSSEC сломается, то сломается всё дерево ниже подписанной точки, в которой DNSSEC отвалилась. Например, так как подписана сама зона .RU, то когда в .RU сломались подписи DNSSEC, отвалились абсолютно все домены второго (и ниже) уровня внутри .RU, вне зависимости от того, есть в каком-то из этих доменов DNSSEC или нет. Ещё раз подчеркну, это касается только валидирующих резолверов, однако сейчас самые массовые публичные резолверы (Google Public DNS, Cloudflare и др.) – валидирующие. Да и вообще – в 20-х годах 21 века нужно использовать только валидирующий резолвер. Соответственно, если отвалится DNSSEC в корневой зоне – DNS сломается, фактически, для всего Интернета.

DNSSEC в корне DNS полностью внедрили в 2010 году, естественно, на RSA. Так как при вводе DNSSEC в эксплуатацию никто не озаботился тем, чтобы не только согласовать процесс ротации корневого ключа, но и хотя бы предусмотреть такой процесс, замена корневого ключа состоялась только в 2018 году. Впрочем, вряд ли это как-то повлияло на практическую стойкость: практические возможности по взлому RSA-ключей из подписей – сильно расходятся с теоретическими предположениями. А тем более эффект сомнителен, если учитывать реальность использования DNS и DNSSEC и схему подписывания самой корневой зоны. Для подписи зоны используются дополнительные ключи, которые, в свою очередь, удостоверяются корневым. Процесс генерирования новых ключей подписи зоны и удостоверения этих ключей изначально предполагал серьёзные шаги по обеспечению безопасности криптографических данных: защищённые помещения, доверенные люди, физические сейфы, физические ключи, аппаратные модули (HSM) и так далее.

Однако в 2020 году вообще просто взяли и нагенерировали и подписали доверенные ключи для корневой зоны заранее, на будущее, сделав участие “криптоофицеров” дистанционным (да! это через эти же “подписываемые интернеты”), чтобы лишний раз не собираться – после этого уже стала окончательно понятна вся театральность действий по “защите” корня DNS, включающая посещение хранилищ и не менее церемониальную работу с аппаратными модулям при помощи отвёртки и молотка – и это не преувеличение. Ритуалы и уровень их исполнения – выходят на первый план, да. Прямо из ICANN и корня DNS. Театр, как социальное явление, очень важен. Главное, понимать, где именно театральное действо переходит в цирковое.

И всё же, вернёмся к ключам DNSSEC. Cледующая ротация корневого ключа намечена на октябрь 2026, но это опять будет RSA. Потому что, как нетрудно догадаться, механизма замены криптосистемы в корне DNS тоже не предусмотрели. Механизм разрабатывают сейчас.

Самое занятное, что в рамках перехода на ECDSA имеющиеся ключи RSA собираются сократить. Да. Собираются уменьшить их разрядность с 2048 бит до 1536 бит. Как бы, по нынешним временам, 1536 бит не считаются стойким вариантом. (Заметьте, впрочем, что для атаки на гипотетическом-фантастическом квантовом компьютере – 1536 битов RSA всё равно сильнее, чем 256 бит ECDSA, потому что теоретические алгоритмы квантового взлома прямо оперируют разрядностью, и для записи 256 бит может потребоваться меньше кубитов.) Естественно, снижение разрядности RSA обусловлено стремлением удерживать максимальный размер DNS-ответа ниже границы, доступной в UDP-транспорте: ниже 1232 байтов. Это позволяет избежать перехода на TCP со стороны резолверов. (DNS требует перехода на TCP в тех случаях, когда ответы не проходят по размеру в UDP.)

Согласно плану, уменьшение длины RSA-ключа в корне DNS намечено на 2027 год. А в первой четверти 2028 года запланирована публикация ECDSA-подписей. При этом, сами ECDSA-ключи в зоне публиковать сразу не собираются. Тоже занятное решение, обусловленное, скорее всего, тем, что DNSSEC требует подписывать зону всеми обозначенными криптосистемами, но не всеми ключами. Поэтому ключи опубликуют позже, во второй четверти 2027 года, когда ECDSA-подписи уже побывают в зоне. RSA-ключи отзовут в 2030. Если по плану. Потому что документ предварительный и пока что выставлен для публичного обсуждения.

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

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

Как такое вообще возможно? Это возможно, так сказать, по определению, так как задача генератора кода – генерировать код, проходящий тесты, а не решать высокоуровневые задачи при помощи программирования. Чтобы применять программирование к высокоуровневым задачам, а не просто генерировать код, демонстрируя последнюю стадию “кодерства”, нужна та самая “ментальная модель” системы. А в случае применения новомодных LLM – такой модели нет ни у кого, так как задача, еще раз, состоит в генерировании кода. Её так и понимают апологеты перевода разработки ПО на LLM. Типа, если преподаватель студентам задал написать эссе, то, мол, преподавателю нужно эссе и именно эссе составляет смысл процесса обучения, поэтому, раз эссе может сгенерировать LLM, то нужно такое упражнение убрать из курсов. (Сейчас, кстати, вообще совсем не модно понимать картину, которая больше, чем некоторая деталь механизма, кем-то предоставленного.)

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

Второй этап – тесты. Unit-тесты, допустим, пишутся до разработки самого кода. Как же может не работать правильно код, который прошёл тесты? Тесты же для того и написаны, чтобы логически строго сформулировать требования к правильной работе. Да-да, всё так и могло бы быть, если бы написание тестов, как и код, не отдали на откуп LLM-генератору. Это ключевой момент. Кроме того, в тестах, в том числе, написанных человеком, нередко бывают ошибки. Тестам свойственна существенная неполнота, пусть и задумывались они как почти полные. Это нормально. Вот только LLM натренирована на преодоление тестов, пусть и через обнаружение в них ошибок и через выявление неполноты, а не на создание корректно работающего ПО. В случае, когда ИИ/LLM везде, такому преодолению эта LLM помогает с двух направлений, корректируя тесты под дефекты генератора кода, а код – под вносимые дефекты тестов.

И это кроме того, что сервис LLM ещё и объединяет весь код в общую “базу” для всех пользователей: на результаты разработки компании “Имярек А” влияют тесты компании “Имярек Б”, которые компании друг о друге не знают, но используют один и тот же новомодный ИИ/LLM-сервис.

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

Идея, что WhatsApp может выборочно и задним числом получать доступ к содержанию [зашифрованных в режиме “точка-точка”] индивидуальных чатов, представляет собой математическую невозможность. (Оригинал: “idea that WhatsApp can selectively and retroactively access the content of [end-to-end encrypted] individual chats is a mathematical impossibility”).

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

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

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

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

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

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

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

Нередко приходится слышать и читать, что в ECDSA значение “параметра k” должно вырабатываться криптографически стойким генератором (псевдо)случайных чисел, для каждой операции подписи. Например, так написано в английской “Википедии”, и практически то же самое написано в стандарте FIPS 186 (но обратите внимание, что в современном стандарте уже есть и другой вариант). Нельзя сказать, что это уж совсем неверно, но есть занятные тонкости с трактовкой слова “должно”.

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

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

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

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

Кстати, всё это непосредственно применимо и к современной ГОСТ-подписи: там есть такой же “параметр k”, точно так же влияющий на выдачу криптосистемы подписи и на стойкость реализации.

В DNS есть несколько штатных способов создать циклы, которые сделают обычный рекурсивный опрос невозможным. Самый привычный способ – использование субординатных NS. То есть, пусть зона example.com делегирована на два авторитативных NS – ns1.example.com, ns2.example.com. Оба имени находятся в исходной зоне example.com, откуда и название “субординатные”. Чтобы найти A-запись в зоне example.com – резолверу нужно опросить хотя бы один из авторитативных NS-ов, а чтобы опросить NS, нужно знать его IP-адрес (A- или AAAA-запись), а чтобы узнать IP-адрес – нужно опросить авторитативный NS зоны example.com, ну и так далее.

Если бы не glue-записи с IP-адресами, то разрешить такой цикл было бы невозможно. Glue-записи – это специальный способ предоставить резолверу IP-адреса узлов, которые, из-за циклов в адресации, невозможно найти обычным рекурсивным опросом. Эти записи передаются авторитативными серверами в специальной секции DNS-ответа и, в случае примера выше, сразу содержат IP-адреса для имён ns1.example.com, ns2.example.com. Без glue-записей практическая DNS работать не будет. И не только по причине наличия только что описанного элементарного цикла: есть случаи и посложнее.

Один из таких случаев – “кросс-делегирование”. Предположим, что зона example.net делегирована на ns1.example.com, ns2.example.com. Обратите внимание: из зоны .net – делегируется на имена в .com. При этом зона example.com – делегирована на ns1.example.net, ns2.example.net.

Теперь предположим, что резолвер ищет A-запись для example.com. Как резолвер мог бы действовать:

(0) для обнаружения нужной A-записи резолверу необходимо найти авторитативные серверы зоны example.com;

(1) на авторитативных серверах делегирующей зоны .com резолвер узнаёт, что NS для example.com – ns1.example.net, ns2.example.net;

(2) теперь резолвер должен определить A-записи для этих имён серверов (ns1.example.net, ns2.example.net);

(3) но для этого нужно найти авторитативные серверы зоны example.net;

(4) на серверах делегирующей зоны .net резолвер узнаёт, что имена этих серверов – ns1.example.com, ns2.example.com;

(5) теперь, чтобы узнать A-записи ns1.example.com, ns2.example.com, резолверу нужно определить авторитативные серверы зоны example.com, но это – шаг (1); получился цикл.

Естественно, настраивать так зоны, мягко говоря, не очень хорошо, даже несмотря на то, что данный цикл разрешается с использованием glue-записей. В случае использования glue-записей, их должна предоставлять каждая делегирующая зона, но в составе этих записей уже будут имена из другой зоны. То есть, в случае простого примера с субординатными NS для example.com – glue-записи содержат адреса серверов внутри example.com (ns1, ns2); в случае “кросс-делегирования” – адреса уже будут для имён в example.net.

Это далеко не все варианты создания циклов. Есть и ещё более сложное “петлевое” делегирование, и постоянно неверно используемая запись CNAME. Что касается CNAME, то это самая проблемная запись в DNS. CNAME предназначена для перезапуска процесса рекурсивного опроса. Вдумайтесь: в DNS изначально заложен сигнал, который, при штатном использовании, заставляет резолвер “начать заново”. Можно ли предложить лучшую основу для DoS? Вряд ли. Потому что если резолвер, отправив запрос про test.ru, получил CNAME с указанием на example.com, то он должен “забыть” исходное test.ru и начать опрос DNS для example.com. И так далее. CNAME можно указать для любого имени. Стоит ли говорить, что нетрудно построить цикл из нескольких CNAME? Нет, не стоит – это очевидно, а такой цикл может быть сколь угодно сложным.

Естественно, DNS-резолверы вынуждены отслеживать все эти особенности, чтобы не зависнуть.

Из серии “Кто бы сомневался!”: в Project Zero публикуют описание того, как, проэксплуатировав две уязвимости (CVE-2025-54957, CVE-2025-36934), им удалось выполнить на android-устройстве произвольный код с правами ядра ОС. Тут самое интересное не уязвимости, а то, что данную атаку на уровень 0-click (то есть, без участия пользователя) переводит наличие в смартфоне ИИ-агента, читающего входящие сообщения.

Вектор атаки требует, чтобы библиотека кодека прочитала специально подготовленный звуковой файл. Для этого нужно открыть и почитать вложение к входящему сообщению SMS/RCS. Раньше для этого пользователь должен был кликнуть на сообщение и попытаться открыть его. Но теперь за пользователя всё удачно делает ИИ-агент, встроенный в гугловый сервис и выполняющий транскрибирование всех голосовых сообщений.

Вот поэтому попадает в серию “Кто бы сомневался!”. Как говорится: эти ИИ-агенты – они и эксплоиты будут вместо пользователя на его устройстве запускать. Максимальная автоматизация.

(Описание на OpenNET.)

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

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

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

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

Рассмотрим практические особенности схемы с выделенной файлообменной машиной.

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

Естественно, установление SSH-соединения требует не только уровня подключения с управлением сессией (TCP, в данном случае), но и двунаправленного взаимодействия с сервером на уровне SSH: сервер должен ответить, прислать ключи и так далее. Так что однонаправленным соединение оказывается только на самом высоком логическом уровне. Тем не менее, SSH-сервер, обычно, является типовым элементом и уже есть в операционной системе (например, через него ходят администраторы), поэтому тут не добавляется ничего принципиально нового, а вот имеющееся – можно и урезать (см. ниже).

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

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

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

Почему-то часто считают, что SSH-доступ всегда эквивалентен локальному шелл-доступу к основной системе. Но это не так. Понятно, что, – по нынешним-то временам, – путь от локального аккаунта до суперпользователя не так долог, как хотелось бы (возможно, теоретически, это не так под чем-нибудь вроде хорошо настроенной FreeBSD, но речь про практическую ситуацию). Однако, никто ведь не сказал, что и SSH-сервер, и шелл, предназначенные исключительно для реализации обмена файлами, нельзя изолировать локально, выкинув всё лишнее, и не только под FreeBSD. Нет, вовсе не обязательно использовать тот же сервер и тот же шелл, которые нужны DevOps для управления. Напротив – подключаемся, заходим, а там изолированная директория и, вместо полноценного шелла, только урезанный набор из ls, mkdir, cat, (s)cp и mv (rename), предположим. То есть, для атакующего – опять дополнительные шаги и локальные хопы (loopback какой-нибудь использовать и пр.), а каждый хоп, не забывайте, тоже повышает шансы обнаружения вторжения.

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

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

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

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

Регулярно теперь попадаются упоминания про то, что нужно и разрешить использование, и немедленно реализовать, внедрить “ИИ-агентов/LLM” там, где раньше допускалось лишь строго “детерминированное” программное обеспечение, например, в бортовые системы боевых самолётов. Типа, такое внедрение ИИ даст “невиданные преимущества”, “качественный скачок” и т.д., и т.п. – следует набор типичных для “ИИ-хайпа” журналистских штампов.

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

Одно дело, когда речь идёт действительно об алгоритме, выдающем труднопредсказуемый для внешнего наблюдателя результат, но, при этом, сам алгоритм вполне себе может быть записан и задокументирован, а совсем другое дело – когда в “недетерминированность” превращается принципиальная недоступность внутреннего устройства системы ИИ для понимания даже разработчиком.

“Недетерминированный” алгоритм, но в классическом понимании, может выдавать такую последовательность отклонений органов управления летательного аппарата, которая приводит к движению по сложной, псевдослучайной траектории, ведущей, тем не менее, в заранее заданную точку – давно известный подход, применяемый на практике. Кстати, применяется не только для управления полётом, но и в случае радиосигналов, как для защиты от помех, так и для затруднения обнаружения.

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

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

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

Но, если возможность всё же есть, то что же это получается – это тогда никакой не “интеллект”? Получается так, да.

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

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

С одной стороны, схему, когда “не всё известно точно”, можно обозначить как то, что допускается использование “недетерминированных систем”. Типа, условный ИИ-агент может действовать различными способами, а человек-инженер не имеет возможности предсказать точно, какие именно действия совершит этот ИИ-агент, как не знает и деталей работы той или иной аппаратуры. Вот и вся диспозиция. Если допуск таких ИИ-агентов разрешается, предположим, в бортовые системы управления самолётом, то вот и самолёт теперь с “недетерминированной системой”. С другой стороны, в реальности, за этими ИИ-агентами всё равно стоит детерминированная аппаратура. Просто – теперь понимание устройства системы перешло к каким-то другим инженерам.

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

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