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

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

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

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

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

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

Что касается проксирования трафика, встраиваемого Google в браузер Chrome, и как такая технология вообще может выглядеть в своём развитии.

1.

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

2.

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

3.

В описании конкретно той технологии, которую внедряет сейчас Google, отдельно сказано про сохранение некоторой “географической привязки” (GeoIP) – предполагается использовать для выходных узлов IP-адреса, “представляющие примерную геолокацию пользователя, в том числе, страну”. За этим вовсе не обязательно должен стоять комплект физических прокси, расставленных по разным странам в соответствии с геопривязкой входных узлов. “Геолокация” – это полностью независимый от IP-сети метод, в котором IP-адрес используется просто как “ключ для поиска”. Поэтому, например, Google может предоставить API, позволяющий получать геолокацию по выходным узлам их наложенной сети, или встроить “размытую геолокацию” в качестве дополнительного параметра запроса браузера (уже есть поддержка), или даже просто описать административную принадлежность в базах данных соответствующих IP-регистратур, но не менять сетевое расположение точек выхода. Сами же сетевые подключения уровня IP для выходных узлов могут находиться где угодно (заметьте, что адрес, административно приписанный к организации в той или иной стране, сейчас можно унести в любую точку Сети даже на уровне виртуализации каналов связи, то есть, ниже IP/BGP).

Пишут про перехват TLS-трафика сервиса Jabber.ru, без ведома администраторов: это практическая атака, судя по подробному описанию – там всё как положено: MITM в TLS и подмена серверного сертификата на тоже валидный. Как пишут, выпуск сертификата, скорее всего, проведён при помощи перехвата трафика, идущего на оригинальный сервер – подменные сертификаты попали в CT-логи, в описании есть на них ссылки (это сертификаты Let’s Encrypt, конечно).

Вообще, побороться с подобной подменой, когда возможен перехват трафика на уровне хостера (а это практически всегда так), весьма сложно. Единственный более или менее эффективный способ – прямая авторизация серверных ключей клиентом по отпечаткам, однако, это сложно, плохо масштабируется, ну и так далее. (Отмечу, что применительно к Jabber/XMPP – есть схемы с защитой точка-точка, между пользователями – OMEMO, например). Certificate Transparency (CT), CAA и подобные технологии, направленные на УЦ, от таких атак не особо защищают: CT, несомненно, полезно, но часто работает постфактум, потому что, как минимум, нужно клиентам проверять метки в сертификатах; и это, если вообще считать, что CT тут работает – технически, выпустить быстрый подменный сертификат УЦ может без меток логов, ничто этому не мешает; да и метки можно сделать без публикации в логах, если есть ключи от этих логов; но, конечно, это всё существенно усложняет процесс. Что касается CAA-записей: да, это полезно, но для УЦ, технически, отказаться от проверки CAA ещё проще, чем проигнорировать CT-логи и SCT-метки.

(Ссылка: описание инцидента от OpenNet на русском.)

Дополнение: понятно, что УЦ, в такой конфигурации атаки, ни при чём – УЦ не имеет возможности в рамках сетевых протоколов отличить подменный узел от настоящего с точностью, превышающей перенаправление сетевого трафика в локальной сети хостера; естественно, автоматически выпускаемые TLS-сертификаты для веба не могут служить инструментом защиты от подобных атак, это и не планировалось, никакие CT тут не помогут; возможность активного и полного перехвата трафика с подменой – автоматически приводит к возможности выпустить TLS-сертификат с соответствующим именем хоста через УЦ TLS; перехват трафика – позволяет подменить данные и при DNS-проверке, это даже в чём-то проще, но перехватывать нужно трафик к DNS-серверам и/или от них (и не должно быть поддержки DNSSEC, да).

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

Есть занятный, пусть и не самый точный, способ определения того, что какой-то глобальный и маршрутизируемый IP-адрес соответствует anycast-узлу: нужно измерить время ответа (ICMP) при помощи утилиты ping, но сделать это из двух базовых точек, заведомо находящихся в существенно разных регионах, а потом измерить ping между этими точками. Если сумма для времени от точек измерения до измеряемого узла существенно меньше, чем время между базовыми точками, то, скорее всего, тут присутствует anycast. Это неравенство треугольника, и оно тут при помощи anycast нарушается.

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

Один из самых старых способов скрытого получения доверенного доступа к не менее скрытым сервисам в Интернете (как IP-сети) это port knocking (метод “секретного портового стука”). Суть метода изложить не трудно: скрываемый сервис работает на закреплённом за ним номером порта, но доступ для TCP-соединений (например) к этому номеру порта открывается только для тех IP-адресов, которые выполнили установленный набор попыток подключений по другим номерам портов. Чуть более развёрнутое объяснение для тех, кто не сетевой инженер (опять же, используем TCP): TCP-соединение – это соединение “точка-точка”, на каждом из концов соединению соответствует IP-адрес и номер порта, где номер порта, можно считать, это просто 16-битное число; например, 10.11.12.13:14395 -> 10.101.102.103:22 – соединение клиента с номером порта 14395 на серверный номер порта 22 (это обычный номер для SSH); предположим, что доступ на сервере по порту 22 закрыт межсетевым экраном (брандмауэром), то есть, попытка соединения на этот номер порта будет проигнорирована сервером; но если некоторый клиент с IP 10.11.12.13 выполнит попытки TCP-подключения на другие номера портов сервера по заданной ключевой последовательности: 1011, 1022, 1033, то брандмауэр, который фиксирует у себя попытки подключения, откроет подключения по номеру порта 22, но только для соответствующего IP-источника.

Естественно, все номера тут могут быть любыми (из допустимых интервалов). Метод весьма полезный, я его использую для открытия доступа к шлюзам, ведущим в некоторую “закрытую” сеть: совершенно необязательно открывать конкретный сервис на конкретном узле, с тем же успехом можно открыть туннель.

Почему-то данный метод и известен не столь широко, как можно подумать, да и нередко его необоснованно относят к способам защиты из разряда Security through obscurity (“Безопасность через неясность”, в одном из переводов), которые, как бы, “заведомо слабые”, что как раз и есть хороший пример неверного обобщения “принципа Керкгоффса”. Однако данный метод хорош, если используется по назначению и в верном контексте. А если излишне настойчиво обобщать, то и авторизация SSH по ключу может показаться “безопасностью через неясность” – действительно, а как если бы он знал значения байтов секретного ключа и их последовательность? Впрочем, это лирическое отступление.

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

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

Raspberry Pi 5, как пишут, выйдет на новом чипсете: BCM2712 с четырёхъядерным Cortex-A76 и новым видеопроцессором; максимальный объём ОЗУ – те же 8Gb, но это выглядит достаточным для Rasberry Pi. А вот по питанию обещают существенно большее пиковое потребление – 12W (против заявленных 8W у Pi 4).

Я постоянно использую несколько Raspberry Pi нескольких поколений, начиная с первого (до сих пор работает, как ни странно) – эти одноплатные компьютеры успешно играют (или играли) вот такие роли: сервер для SDR-приёмника (радио-USB-Ethernet); управляющий сервер для бэкапов; выделенный лог-процессор (собирает с разных машин логи и периодически строит графики/диаграммы, которые можно просматривать браузером); в качестве контроллера погодной станции; в качестве WiFi-точки доступа с записью трафика. Список неполный – штука очень удобная, поскольку позволяет аппаратно разделить выполнение задач по, так сказать, разным темам. На dxdt.ru, впрочем, Raspberry Pi упоминается не так часто, но упоминается – например, в заметке про вычисления на разной аппаратуре или про модули LoRa.

Кстати, в продолжение предыдущей заметки. В исходной работе (почему-то по оригинальной ссылке её больше нет, но, думаю, можно найти) в качестве примера используется модификация аппаратного генератора (датчика) случайных чисел, которая приводит к снижению эффективной энтропии до значений, доступных для быстрого прямого перебора. Что это означает и как может работать на практике, а не в качестве примера? Конечно, если бы речь шла о прямой замене на максимальное количество в 2^32 различных значений для 128-битной разрядности, то такой дефект элементарно обнаружился бы: он не только быстро проявится на статистике, но и будет выглядеть максимально подозрительно даже для самых простых методов – 2^32 16-байтных значений сейчас влезает в ОЗУ некоторых ноутбуков. Поэтому речь идёт о другой схеме. Практическая реализация должна работать в другом контексте: предполагается, что сторона, которой известно секретное значение, по нескольким результатам выдачи генератора (задающие элементы – их может быть даже два или три) за 2^32 (например) операций вычислит внутреннее состояние генератора и получит следующее значение, которое генератор выдал (ну или получит 116 битов из 128, а остальные – подберёт на следующем шаге). Во многих протоколах значение случайного числа, которое выдал генератор, передаётся в открытом виде, так что его можно прочитать тем или иным способом. А дальше уже, из-за свойств симметричных шифров и/или хеш-функций, можно найти точные ключи перебором. При этом в выдаче всегда остаётся некоторая добавленная энтропия, – предположим, аппаратная, – которая мешает вычислительно отличить выдачу генератора от качественной, если не известен ключ.

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

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

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

Предположим, что квантовый компьютер, способный выполнить алгоритм Шора для чисел с разрядностью записи в 2048 битов, содержит миллионы физических “квантовых элементов”, обеспечивающих работу нужного количества (предположим, 6144) логических кубитов в регистрах, эти элементы и вспомогательные схемы содержат на порядки больше “квантовых элементов”, которые составляют материал самих используемых приборов. Не сделает ли уже само это количество устройство “классическим”? А если нет, то можно ли тогда просто начать реализовывать квантовые вычисления на обычных кирпичах, которые, как известно, внутри квантовомеханические? Что, если порог определяется по количеству состояний? Тогда 2^2048 может уже хватить. Именно эти моменты и мешают на практике (это известно, конечно же, если посмотреть за пределы популярных статей), но не ясно, насколько они преодолимы в принципе. Вообще, одним из ключевых моментов, приведших к формулированию квантовых механик (разных), как раз и были рассуждения о том, что при переносе предмета измерений на всё более и более “мелкие” частицы, средства выполнения измерений оказываются частью этих измерений – опять рекурсия (см. выше). Для квантовых компьютеров это означает, что реализация квантового преобразования Фурье в алгоритме Шора с нужной точностью для практических чисел потребует тысяч кубитов, которые чрезвычайно сложно уложить в малое, по квантовым меркам, пространство. При этом ошибки в представлении результата могут “квантоваться”, потому что это в уравнениях используются комплексные числа, но совсем не факт, что аксиома непрерывности должна прямо транслироваться в физику измерительного оборудования.

Существуют технологические элементы, которые не так-то просто скопировать именно на уровне логики разработки и создания цепочек производства. Естественно, это ключевые технологии и их мало. Некоторые вообще возможны только потому, что конкретные специалисты придумали, как там что-то удастся реализовывать. Это относится не только к чипам (посмотрите на криптографию, например), но в данном случае – пример именно про аппаратное устройство (где, естественно, многое ещё хитрее): в The Verge пересказывают статью WSJ о том, что собственный процессор радиоканала 5G для смартфона не получилось (пока что) сделать у Apple.

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

Apple found that employing the brute force of thousands of engineers, a strategy successful for designing the computer brain of its smartphones and laptops, wasn’t enough to quickly produce a superior modem chip.
(Apple обнаружила, что применение грубой силы из тысяч инженеров, – стратегия, сработавшая при проектировании компьютерной начинки её смартфонов и ноутбуков, – оказалось недостаточным для того, чтобы быстро выпустить превосходный чип модема.)

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