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

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

Кстати, очередной пример, почему ssh forwarding не такой безопасный вариант использования ключей на удалённых системах, как может показаться: при желании, через ssh-agent обратно может приехать исполнение кода на локальной системе, впрочем, с некоторыми дополнительными “плясками” – CVE-2023-38408. Авторы, естественно, не забывают упомянуть ASLR, PIE и NX:

“Surprisingly, by chaining four common side effects of shared libraries from official distribution packages, we were able to transform this very limited primitive (the dlopen() and dlclose() of shared libraries from /usr/lib*) into a reliable, one-shot remote code execution in ssh-agent (despite ASLR, PIE, and NX)”.

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

Так, если взять в качестве примера привычную запись текста на естественном языке, то простой шифр алфавитной замены (“А” -> “Д”, “Б” -> “Э” и т.д.: буквы заменяются на буквы по перестановке того же алфавита, ключом является перестановка) не обладает только что описанным свойством: если попросить “коробочку” зашифровать слово “длинношеее”, то результат, очевидно, получится угадываемым (ну, конечно, в той степени, в какой вообще можно поверить в случайные биты).

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

Интересно, что внесение дополнительного слоя сохранения некоторых статистических характеристик является одной из теоретических областей создания алгоритмических закладок/бэкдоров в шифрах. Представьте блочный шифр. То есть, такой шифр, который на вход получает, предположим, строго 256 битов и 256-битный ключ, а выводит тоже строго 256 битов шифротекста. Многие современные шифры так работают. Если шифр идеальный, то вывод будет равновероятным, а для успешного поиска нужно будет перебирать, хотя бы, 2^255 вариантов.

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

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

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