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

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

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

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

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

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

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

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

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

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

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

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

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

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

Попалась интересная публикация о том, как насаждаемые везде и всюду ИИ/LLM реально повлияют на безопасность компьютерных систем, с примерами (англ.): AI will compromise your cybersecurity posture (“ИИ скомпрометирует ваш подход к обеспечению кибербезопасности”).

По ссылке – разобраны расхожие “хайп-заявления” про ИИ/LLM – типа, “ИИ взломает 51% паролей за секунды”, “ИИ самостоятельно успешно написал эксплоиты к 87% описаний CVE” и пр., – а потом, на примерах, показано, как ИИ-системы реально повлияют на процессы обеспечения информационной безопасности: неконтролируемый доступ через LLM-агентов, некотролируемый поток ошибок в коде, навязываемое встраивание внешних систем, про которые даже их разработчики не знают, как они устроены, ну и так далее.

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

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

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

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

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

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

В продолжение предыдущей записки. Ещё один занятный момент про сверхкороткие TLS-сертификаты.

Понятно, что если сертификаты действуют недолго, то на заданном интервале времени сертификатов будет больше. Например, больше сертификатов будут попадать в логи Certificate Transparency (CT-логи). Возникнет дополнительное зашумление: если для домена example.com за месяц выпущено десять сертификатов вместо двух, как раньше, то запутаться с обработкой и мониторингом проще.

Если вы вдруг посчитали, что этот эффект надуман, да и вообще – быть такого не может, чтобы мониторы CT-логов что-то потеряли, то вспомните недавнюю весьма странную историю с сервисом 1.1.1.1 и Cloudflare. В той истории CT-логи непосредственно самой корпорации Cloudflare получили от внешнего удостоверяющего центра (УЦ) информацию о том, что – без санкции Cloudflare! – этим УЦ выпущены TLS-сертификаты для 1.1.1.1 (а это важнейший сервис Cloudflare), но даже корпорация Cloudflare, – без всякого сраказма: технологический лидер направления, – целый год ничего подозрительного в тех самых своих CT-логах каким-то образом не замечала. А теперь представьте, что сертификатов стали выпускать в десятки раз больше.

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

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

TLS-сертификаты в современном вебе неуклонно превращаются в токены, разрешающие доступ клиентов к веб-сайтам. Я неоднократно об этом писал раньше, но есть смысл вернуться к данному процессу, посмотрев на него подробнее. Тем более, что это касается не только веба.

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

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

Итак, представим, что TLS-сертификаты для доменных имён и IP-адресов выпускаются со сроком действия три дня максимум (сейчас уже есть шестидневные сертификаты). Что это означает с технической точки зрения? Например, штатно работающий браузер не станет показывать пользователю контент на веб-сайте, у которого, – внимание! – на сервере не установлен TLS-сертификат с подходящим сроком действия (до подписей мы ещё не добрались даже).

Тут можно возразить, что браузер и так имеет возможность заблокировать любой сайт, просто по имени хоста сервера, по URL, ещё как-то. Получается, ничего нового, в плане возможностей, для пользователя и браузера не появляется. Это не совсем так.

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

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

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

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

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

Let’s Encrypt начали поэтапно сокращать максимальный срок действия выпускаемых TLS-сертификатов с 90 дней (как сейчас) до 45 дней (в 2028 году обещают). Так что, скорее всего, браузеры тоже подтянутся и – сокращать срок действия придётся всем остальным УЦ. Сертификаты движутся по пути превращения в короткоживущие токены, разрешающие клиентам доступ к веб-ресурсу.

В IETF и вокруг сейчас происходит небольшой технический скандал, непосредственно связанный с внедрением рекомендаций по использванию негибридных криптосистем ML-KEM в TLS.

Если очень кратко, то переход на постквантовую криптосистему ML-KEM, как единственный механизм получения сеансового секрета, может восприниматься как попытка протолкнуть в TLS некий бэкдор, который отсутствует в X25519 (сейчас X25519 используется вместе с ML-KEM, в составе гибридной криптосистемы, поэтому бэкдор в ML-KEM, для гибрида, только лишь снизит стойкость в два раза).

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

Что имеется в виду? Вот что: якобы, если множество вариантов параметров криптосистемы достаточно маленькое, чтобы перебрать его за обозримое время, то бэкдор там негде прятать – его можно будет обнаружить простым перебором. И вот в ML-KEM, как бы, это множество – всего 34 бита. Как бы, утверждение верное, вот только оно сильно слабее, чем предположение о бэкдоре: бэкдор может находиться непосредственно в алгоритмах, поэтому, для его обнаружения прямым перебором, нужно будет мощность множества параметров возвести в некоторую большую степень (это, примерно, как идея моделирования квантовых вычислений, когда у вас все 2^34 варианта участвуют в расчётах на каждом шаге).

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

Вообще, конечно, история, в которой ML-KEM почему-то начинают тщательно “обелять”, доказывая, что там нет бэкдора – несколько подозрительная.

Снова попалось утверждение, что “биометрию”, в отличие от физического пропуска, “нельзя потерять или передать другому человеку”. Вообще-то, основная особенность всякой “биометрии” совсем в другом. Она в том, что биометрические показатели очень сложно, практически невозможно поменять. А вот потерять или “передать другому человеку” – это как раз запросто.

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

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

IACR – это Международная ассоциация криптологических исследований (International Association for Cryptologic Research). Результаты очередных выборов руководства и секретариата этой организации не могут расшифровать, потому что одним из доверенных лиц потерян ключ. Для расшифрования результатов голосования нужны ключи трёх доверенных лиц, однако есть ключи только двух, третий ключ – утрачен “в результате человеческой ошибки”, поэтому подсчитать результаты голосования не представляется возможным.

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

Выборы в IACR планируют провести заново. Только смущает один забавный момент: голосование проводится в некой системе “электронного голосования” Helios. Но если зайти на сайт этой системы и попытаться найти там раздел технической документации, то можно обнаружить, что ссылка на эту документацию – не открывается: в DNS просто отсутствует адресная запись для домена, который заявлен в качестве адреса для документации. Так-то вот.