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

Кстати, очередной пример, почему 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-запросы, конечно, можно и не напоминать.

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

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

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

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

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

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

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

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

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

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

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

В статье из 2019 года, посвящённой блокировкам и блокированию протоколов в Интернете, я писал вот что:

Среди перспектив развития систем контроля трафика (именно контроля) можно отметить пропуск только авторизованного трафика. Конечно, такой вариант пока кажется фантастикой. Авторизация трафика — это развитие схемы с белыми списками. В этом случае доступ по спискам IP-адресов и имен не ограничивается, но промежуточные узлы пропускают только трафик, который содержит специальные криптографические маркеры, подтверждающие его легитимность.

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

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

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

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

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

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

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

Часто попадаются в публикациях СМИ утверждения, что, якобы, это особенность “open source” в том, что в такие библиотеки и другое ПО включают “вредоносные возможности”. Но это не так. Модель распространения ПО никак не связана с возможностью добавления “вредоносного кода”: добавить такой код можно и в исходники, и в скомпилированный исполняемый код, а добавить что-то такое в скомпилированный код даже может быть проще, поскольку исходники ещё собирать кто-то будет и “зловредная нагрузка” может не собраться, собраться не так или не попасть в исполняемый код.

В подобных сообщениях СМИ, конечно, перепутаны подходы и термины. Открытый исходный код (Open Source) – это открытый исходный код. ПО, поставляемое с открытым исходным кодом, может быть проприетарным и коммерческим. Проблемы, о которых изначально шла речь, связаны с моделями и способами разработки кода, под открытостью тут подразумевается даже не свободная лицензия, а то, что, потенциально, любой желающий может предложить доработки и изменения. Но не факт, что предложенное будет принято безо всякой проверки. При этом в разных проектах устроены различные процессы проверки, той или иной степени защиты.

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

Самое интересное, что сейчас во многих и многих программных продуктах, распространяемых в “бинарном исполняемом коде”, даже с закрытыми (условно) исходниками, всё равно присутствуют различные библиотеки из Open Source. Это касается и операционных систем, да даже и Windows. Про то, как можно рассматривать открытые исходники и “бинарный код” с точки зрения ИБ – я недавно публиковал отдельную записку. Но главное, не нужно смешивать “открытые исходники” (Open Source) с проблемами неконтролируемого добавления кода в некоторых способах коллективной разработки, равно как и с самой возможностью добавления “вредоносного кода” – такой код добавить можно и в виде “бинарной” вставки (то есть, фрагмента машинного кода).

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

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

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

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

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

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

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

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

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