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

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

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

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

TCP предоставляет некоторое количество новых сигналов: что-то можно специально добавить, да ещё и на разных этапах установления соединения (см. SYN-куки и т.д.), при этом сам процесс установления сессии позволяет выделить дополнительные особенности – сдвиги по меткам времени, характеристики из заголовков, взятые по разным сигналам. Отдельный новый базис TCP – это номера портов, а точнее, их изменение: тут экзотические методы использования, – вроде port knocking, – вообще могут позволить узнать конкретный источник сессии без всякой привязки к IP-адресу или к параметрам протоколов более высоких уровней.

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

Пишут, что в Сан-Франциско активисты блокируют автомобили-роботы при помощи пластиковых дорожных конусов, которые просто устанавливают на капот автомобиля: с конусом автомобиль ехать не может, вероятно, из-за проблем с обзором; а снять конус с капота – некому. Вообще, автомобиль мог бы сбивать такие помехи специальным водомётом, который водомёт ещё и для разгона зазевавшихся пешеходов полезен. Это, впрочем, оставлено на будущее. Процитирую свою недавнюю записку по теме:

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

(via)

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

(Найдено на Hackaday.com.)

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

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

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

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

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

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

Обновил страницу с избранными записками – добавлено пять записок:

• Алгоритм Шора в фантастической машине превращения вероятностей
• Алгоритм Шора и Вселенная кубиками
• Симметричные ключи, аутентификация и стойкость в TLS
• Детектирование текстов, сгенерированных ИИ
• Открытые “исходники” и “бинарный” код с точки зрения ИБ

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

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

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

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

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

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

Я ранее уже писал на dxdt.ru про идентификацию по цепочкам: например, про применение для деанонимизации мобильных телефонов (2010 год), про идентификацию людей по географическим координатам (2009 год) и не только.

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

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

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

В июне 2023 года на dxdt.ru снова вышло достаточное количество записок, чтобы некоторые из них отметить отдельно, а именно:

• Кибератаки, самоуправляемые автомобили и бот в смартфоне;
• Пифагорейские идеи и доказательство теоремы Ферма;
• Реплика: слух человека и преобразование Фурье;
• Геопривязка в персональных цифровых финансах;
• Open Source и добавление “вредоносного кода”.