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

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

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

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

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

В алгоритме 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, но считаются как бы обособленными и самостоятельными.

Много публикаций про систему ИИ от Google, которая предсказывает погоду. Интерес СМИ широкого профиля и журналистов тут вполне понятен: комбинация “Google, AI, weather/climate”, в направлении “Технологии”, сейчас одна из мощнейших. Исходная статья достаточно занятная, учитывая “хайп”: там рассказывается, что методы машинного обучения, использующие массив исторических данных погодных измерений, позволили сделать систему предсказания погоды, которая, по некоторым параметрам, превосходит имеющиеся “детерминированные” системы “численного моделирования”. Однако если вы захотите взглянуть на минимально содержательные детали, о которых там речь в действительности, то читать нужно не “заглавную статью”, а Supplementary Materials (но 132 страницы с таблицами и картинками, да).

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

Нейросеть с ИИ YaGPT2 (сайт ya.ru) на вопрос “По какому коридору идёт Штирлиц?” отвечает, что Штирлиц идёт по “коридору власти” (и выдаёт какие-то пояснения про то, что Штирлиц – это персонаж художественных произведений). Это, конечно, не тест Тьюринга, но как тест на знание некоторых культурных реперов – вполне себе используется. Ответ YaGPT2 в 2023 году выглядит, так сказать, несколько странно, потому что не особенно-то отличается от “говорилок”, доступных и десять-пятнадцать лет назад (это когда “преобразуем входной вопрос в SQL-запрос”).

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

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

В атаке с перехватом трафика 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, например), если только реализации не подразумевают достаточно сложных механизмов защиты ключей. При этом понятно, что никакой “полной защиты” от гипервизора тут быть не может.

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

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

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

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

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

(Я уже писал о полностью зашифрованных протоколах раньше, в том числе, про распределение ключей и влияние TLS.)

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

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

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

А так, конечно, “компьютер не может ошибаться“.