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

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

Raspberry Pi 5, как и обещано, существенно быстрее Pi 4. Сравнил при помощи ассемблерной реализации шифра “Кузнечик” для ARM64 – показатели такие:
Pi 4 vs Pi 5 (обе версии с 8Gb RAM)

 Encryption: ~28 MB/sec vs ~93 MB/sec
 Decryption: - ~24 MB/sec vs ~70 MB/sec
 Режим GCM: ~18 MB/sec vs ~50MB/sec

То есть, в три с лишним раза быстрее.

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

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

Посмотрим, насколько хорошо удастся “исследовать” вопросы из записки про “шампанское и хлопок” при помощи GigaChat (через бота в Telegram). Результат, конечно, получше, чем у YandexGPT из прошлой записки по теме, однако с уровнем “интеллекта” – проблемы:

Намного ли прочнее обычного хлопок от шампанского?
GigaChat:
Шампанское — это игристое вино, которое обычно изготавливается из трех сортов винограда: шардоне, пино нуар и пино менье. Оно имеет высокую кислотность и низкую концентрацию сахара, что делает его более прочным, чем обычный хлопок. Однако, прочность шампанского зависит от многих факторов, включая его состав, способ производства и хранения. Поэтому, если вы хотите узнать, насколько прочно конкретное шампанское, лучше всего обратиться к производителю или специалисту в этой области.

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

Так что, если вы не знали, обратите внимание: “высокая кислотность и низкая концентрация сахара” – вот что делает шампанское более прочным, чем обычный хлопок.

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

Добавил arm64 в свою реализацию шифра “Кузнечик” (ГОСТ Р 34.12-2015) на ассемблере для Go. Новые функции – для платформы arm64 со 128-битной арифметикой. Попутно немного изменил состав библиотеки, так что название теперь новое (см. исходники ниже). Раньше ассемблер был только для amd64 с AVX, на остальных платформах – компилировалось с “заглушкой”, в которой операции шифра реализованы просто на конструкциях Go – ассемблер, понятно, быстрее.

ARM – весьма и весьма распространённая архитектура, а использование ассемблера, как обычно, даёт прирост производительности во много раз, если сравнивать с “обычным” Go-шным вариантом (тоже оптимизированным, конечно). Однако я всё проверял на Raspberry Pi4 (RPi4), потому что другого варианта ARM-аппаратуры под рукой сейчас не оказалось (а техники Apple у меня вообще нет). Зато на Linux/arm64 в RPi4 – прирост более чем в двадцать раз. Было: примерно мегабайт в секунду для “обычной” реализации. Стало: около 23 мегабайтов в секунду для ассемблерной. Думаю, что должно работать и на других ARM-платформах, и гораздо быстрее, чем на RPi4, но пока не проверял: если кто-то использует, и обнаружит существенные несовместимости (см. ниже) – пишите, пожалуйста, в комментарии здесь или пишите почтой. Вообще, написанный ARM-код ещё есть куда оптимизировать: например, в arm64 имеется “векторная” инструкция, реализующая XOR сразу для трёх входных регистров, что тут очень полезно, но эта инструкция недоступна в процессоре RPi4 (Cortex-A72/BCM2711).

Новая версия кода “Кузнечика”, так как отличается от предыдущей, называется GOSThp. Исходный код публикую ниже. Возможно, потом оформлю в виде полноценного модуля для Golang и выложу копию на Github, а возможно – не оформлю и не выложу. Но использовать в составе проекта на Go этот пакет нетрудно: достаточно скопировать директорию gosthp (см. ещё детали ниже). Работает со старыми версиями Go (проверено для 1.7).

Файлы:

gosthp.tar.gz – всё вместе в одном архиве.
SHA-256: b3f860f15d43814db2f2becfb4c72272de6d3b49f9b0dec70712438af0a6e085
(Update, 20/01/2024: архив перезагружен – изменено описание платформ в +build, даты в комментариях, и даты создания файлов; код – без изменений.)

Внутри архива:

cmd/
	| gostrun.go		- файл с примерами и тестами.
gosthp/	- это сама библиотека.
	| docipher_amd64.go	- объявления функций для amd64.
	| docipher_amd64.s	- код на ассемблере для amd64.
	| docipher_arm64.go	- объявления функций для arm64.
	| docipher_arm64.s	- код на ассемблере для arm64.
	| docipher.go		- универсальная реализация для прочих платформ (см. +build внутри: могут быть расхождения).
	| gosthp.go		- основной модуль.
go.mod
README

Основное дополнение – docipher_arm64.s, собственно, реализация шифра для архитектуры arm64/AArch64.

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

$ cd cmd
$ go build -o ~/my-builds/gostrun gostrun.go

Go самостоятельно выберет нужные файлы в соответствии с целевой платформой. Внутри исходников – много комментариев (англ.).
Саму библиотеку можно использовать в среде Go в составе других проектов простым копированием gosthp/, разместив её либо в директорию сборки, либо в общую директорию для пакетов.

Ассемблерная реализация для ARM от x86 отличается в некоторых деталях, не алгоритмических: во-первых, очевидно, другие инструкции; во-вторых, используется больше регистров и основные операции XOR собраны в общий блок; в-третьих, изменён способ вычисления смещений для обращения к таблице значений.

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

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

Что касается совместимости. И amd64, и arm64 – достаточно широкие понятия. В этой реализации шифра “Кузнечик” используются регистры и команды для разрядности 128-бит, которая соответствует разрядности шифра – в этом, собственно, смысл. Уже использование команд “длинной” арифметики из SSE4.1 для amd64 означает, что некоторые старые процессоры, полностью попадающие в amd64, не смогут, тем не менее, исполнять скомпилированный код, поскольку не поддерживают нужных команд. То же самое относится и к arm64 (например, выше я уже упомянул, что не использую “трёхрегистровую” команду XOR по этой же причине). Данная библиотека поддержку команд не проверяет, так что, вообще говоря, это нужно отслеживать отдельно, используя механизмы детектирования свойств аппаратуры, и, соответственно, либо заменять вызываемые функции, либо выводить предупреждение пользователю.

Кстати, ещё немного про Go (Golang). Одна из самых странных особенностей Go – это использование комментариев для управления компиляцией. Например, вот такая директива:

// +build !amd64

– это “обычный” комментарий в исходном коде, но его читает препроцессор и использует указание +build для того, чтобы определить платформу (всё, что не amd64; скажем, так сделано у меня в исходниках ассемблерной реализации “Кузнечика”; современный вариант: “//go:build“). Идея снабдить комментарии двойным дном – довольно богатая, в лингвистическом, так сказать, смысле.

Формально, “// +build !amd64” – это, действительно, комментарий. То есть, здесь обозначено, что строка не относится к, собственно, исходному коду. Это верно. А то, что там потом будет копаться препроцессор – ну так, как бы, и в комментариях бывает написано, что “данная функция нужна только для 8-битной конфигурации, поэтому здесь вызов спрятан в комментарий”. Неявно предполагается, что роль препроцессора играет непосредственно разработчик, а в случае “+build” в Golang – просто этот процесс автоматизируется. Это, конечно, не какой-то там особенный и исключительный случай использования комментариев: вспомните что-нибудь типа “#!/usr/bin/perl”. Тем не менее, ситуация, когда содержание комментария непосредственно влияет на процесс сборки, всё же выглядит необычно.

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

Очень многие мнемоники команд заменены на собственные мнемоники go-ассемблера, причём, трансляция не всегда очевидная, результат замены отличается от платформы к платформе, а сама замена сопровождается неожиданными дополнительными ограничениями.

Например, на arm64 go-ассемблерное “ADD $8, RSP, R2” соответствует оригинальному “ADD X2, SP, #0x8”. RSP превращается в SP потому, что ассемблер Go использует псевдорегистры, среди которых есть SP (и не только), поэтому совпадающие по названию аппаратные регистры переименованы. Псевдо-SP – это, как бы, указатель стека, но с хитростями: псевдо-SP может иногда совпадать по значению с аппаратным SP, в частности, если на подходящей платформе указана нулевая длина “собственного” стека ассемблерной процедуры (но это детали). При этом, ссылки с использованием смещения от значения псевдорегистра SP должны (это прямо строгое требование Go) оформляться с символьными именами, вот так: len-8(SP), где “минус” это не совсем вычитание, а len – это даже не “синтаксический сахар”, но что-то вроде комментария наоборот, поскольку никакой языковой интерпретации len здесь не имеет, ничего из len не вычитается, да и вовсе не обязательно, чтобы эта строка совпадала с именем аргумента в определении прототипа функции или ещё с чем-то совпадала (или не совпадала). Но если не указать произвольный символьный префикс – компилятор выдаст ошибку. Этому, естественно, имеется историческое объяснение, которое называется Plan 9.

Отрицательные и положительные смещения для SP – тоже отдельная забавная история: если SP совпадает с аппаратным регистром по семантике, – что задаётся правилами определения процедуры и входа в процедуру, – то, на некоторых платформах, можно использовать привычные положительные смещения, вот так: len+8(SP), однако где-то в документации написано (попробуйте найти), что “при ручном кодировании” необходимо использовать (только) “отрицательные смещения”. Да. Ну или наоборот, потому что лучшей документацией тут оказывается исходный код – как самого Golang, так и генерируемый компилятором.

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

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

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

Кстати, есть весьма полезный пример, показывающий различие между формулами, компьютерами и интерпретацией формул. Его удобно приводить в качестве иллюстрации к объяснениям про “компиляторы, регистры, транзисторы и ячейки с битами”. Отчасти относится к предыдущей заметке. Сравним запись (a == b) с записью ((a – b) == 0). Например, в контексте записи и компиляции исходного кода на том или ином языке программирования: if (a == b) {…} и if ((a – b) == 0) {…} – известно, что результаты вычисления условий в таких if-ах на практике могут различаться; причём то, как именно они различаются, зависит и от языка, и даже от используемого системного окружения.

Наивная арифметическая логика тут такая: “a равно b, когда a-b == 0”. Но тут многое спрятано внутри. Во-первых, никто же не сказал, какого типа объекты a, b; во-вторых, не определено, что это за операция “-“; в-третьих, с равенством, как понятием, вообще говоря, тоже есть масса тонкостей. Так, в записи использован двойной знак равенства “==” – он означает какую-нибудь “эквивалентность”?

Знак “=” – один из самых сложных, с точки зрения машинной интерпретации. Собственно, поэтому и возникли “==”, “===”, “:=” и прочие сочетания. Вот если написано “f = m+n”, то что тут имеется в виду? Что “f” – это “формула” (или даже “функция”), имеющая вид _ + _? Или запись обозначает, что имя “f” нужно использовать как синоним для строки “mn”? Или это условие, которое обозначает проверку того, что число под именем “f” равно сумме чисел под именами “m” и “n”? Или какой-то другой вариант?

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

Однако, если не заходить далеко в орнитологическую область, а остаться с компьютерами, то и тут не нужно даже вспоминать теоретическую математику, чтобы символ “==” начал расплываться: достаточно того, что компьютеры, через языки высокого уровня, работают и со строками символов (что бы это ни значило). Сравнение строк требует дополнительных соглашений, с которыми сталкивались даже многие пользователи персональных компьютеров. Причём процесс тут двунаправленный, приводящий к занимательным эффектам: вспомним, что во многих случаях заглавные и строчные буквы ASCII считаются одинаковыми. Тогда строка “AbC”, выходит, равна строке “ABc”, пусть тут и некоторое видимое свойство перешло на соседнюю букву; но это означает, что “ABC” является повторением “Abc”, и хоть битов для записи нужно больше, ничто не мешает на каком-то этапе обработки переписать “ABC” как “abc” – что сплошь и рядом делается в программировании, а побочный эффект используется для защиты DNS-запросов, сколь бы странным это ни показалось.

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

Вот и вернёмся к языкам программирования и представлению чисел в компьютерах. Известно, что уже в языке Python попытка признать (a-b) == 0 и a == b эквивалентными наталкивается на тот самый, занимательный, эффект:

import math
a = math.pow(5, 55)
b = 5 ** 55

print(a == b)
print((a - b) == 0)

Эта нехитрая программа печатает следующий результат (Python 3.9, Debian 11):

False
True

Так что здесь a хоть и не равно b, но зато (a – b) равно нулю. Что происходит? Происходит вычислительное сравнение, на которое влияет представление чисел внутри Python, переполнение и автоматическое (неявное) преобразование типов:

a == 2.7755575615628914e+38
b == 277555756156289135105907917022705078125

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

import math
a = math.pow(5, 55)
b = 5 ** 55

print(a == float(b))
print((a - b) == 0)

За простыми на вид компьютерными формулами часто скрываются хитрые трактовки и скрытые структуры, которые хоть и подразумеваются, но это подразумевание бывает с двойным (“==”), а то и с тройным дном (“===”).

Занимательное программирование. Почему вместо первого фрагмента кода (см. ниже) предлагается писать второй фрагмент (см. ещё ниже)?

Первый фрагмент:

if(matched != 0)
	// passwords match
else
	//passwords don't match

Второй фрагмент:

if(matched == 0x69d61fc8)
	// passwords match
else
	//passwords don't match

Потому что так предлагается защищаться от дефектов аппаратуры, приводящих к переключению битов в результате rowhammer-атак. Примеры взяты из исходной работы, где соответствующие “гаджеты” (то есть, способы сравнения в if) для проверки реквизитов доступа обнаруживаются в OpenSSH, sudo и др. Логика, стоящая за словом 0x69d61fc8, такая: rowhammer позволяет при помощи интенсивных операций с ячейками памяти переключать биты в соседних (физически) ячейках; поэтому, если используется условие “не равно нулю”, то достаточно перещёлкнуть один произвольный бит в нулевом значении переменной, чтобы равенство нарушилось и “пароли совпали” (passwords match); условие же “равно 0x69d61fc8” (или ещё какому-нибудь “перемешанному” значению) перещёлкиванием битов подогнать “несколько сложнее”.

Вообще, с точки зрения “просто программирования”, вариант matched != 0 – верный, работает, его можно использовать, никакой проблемы тут нет. А вот если подойти с точки зрения информатики и потребовать учитывать дефекты аппаратуры, то != 0 вдруг оказывается подвержено проблемам “аппаратурной” оптимизации ничуть не меньше, чем реализации алгоритмов, использующие строго фиксированное количество операций (вне зависимости от значений битов входных данных – constant-time, но не перепутайте с соответствующим классом сложности). Впрочем, в отличие от атак, измеряющих сдвиги времени исполнения, управляемое перещёлкивание произвольных битов – это, конечно, никакая не физическая особенность, а именно аппаратный дефект. Исправлять его, как и многие похожие, предлагается программно, а исправление приводит к не самым очевидным эффектам в коде на языке высокого уровня (ЯВУ) – потому что выбор значений констант для флагов таким образом, чтобы они оказывались далеко друг от друга в смысле rowhammer-метрики, это не очень близко к логике ЯВУ, да и нужно учитывать, что оптимизирующий компилятор может всё переписать на те же нули, но уже в машинном коде.

(Описание на OpenNET.)

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

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

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

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

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

DNSSEC предоставляет механизм удостоверения адресной информации в DNS, что требует подтверждения факта отсутствия ответа на запрос. Собственно, это особенность не столько DNSSEC, сколько любой подобной криптографической системы: необходима возможность криптографического подтверждения, что какие-то записи действительно отсутствуют, потому что иначе активный аткующий может просто удалить из DNS-ответов записи, обеспечивающие безопасное делегирование (DS-записи), тем самым сымитировав отсутствие DNSSEC в атакуемой зоне. Отсутствию записей и имён в терминах DNS соответствует NXDOMAIN (нет имени) и NODATA (нет данных записи запрошенного типа). NXDOMAIN – это когда спросили имя test.example.com, а его в зоне example.com нет. NODATA – спросили TXT-запись для test.ru, имя test.ru есть, но ему не соответствует TXT-записи (NODATA это ANSWER:0 со статусом NOERROR, если в терминах BIND).

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

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

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

При полностью динамической работе DNS на стороне авторитативного сервера всякое противодействие индексации зоны требует динамических подписей. Однако в таком случае обработка NXDOMAIN быстро превращается в проблему, поскольку требуются дополнительные вычисления. Особенно, если в зоне много имён. Грубо говоря, если у вас есть миллион записей с именами хостов в некоторой базе данных, то уже для обнаружения соседних имён придётся строить какой-то индекс и так далее. Если же состав записей постоянно изменяется, а ответ зависит и от видимых характеристик клиента, и от текущего состояния большей системы на стороне сервера, то вычисление NXDOMAIN может вылететь в копеечку (в том числе, из-за большого размера ответа с подписями). Оригинальное решение тут первыми применили в Cloudflare, ещё в 2016 году. Решение основано на модификации логики обслуживания DNSSEC – предлагается, фактически, исключить понятие отсутствующего имени или отсутствующей записи, что позволит генерировать виртуальные подписи на лету (но, обратите внимание, это не отменяет кэширования сгенерированных ответов).

Иными словами – сервер выдаёт “нечестные” ответы. Например, сервер не отвечает резолверу со статусом NXDOMAIN вообще, а вместо этого использует вариант NODATA: на запрос о реально не существующем в зоне имени сервер отвечает, что есть имя, состоящее из префикса \000., приписываемого к запрошенному имени, то есть, это как бы граница (которой в реальной зоне нет), а ответ поэтому содержит одну NSEC-запись; подпись же вычисляется на лету. Для случая “настоящего” NODATA – всё работает аналогично: сервер отвечает, что есть все мыслимые ресурсные записи, кроме той, которую запросил резолвер. Например, если резолвер спрашивает A-запись, то авторитативный ответ будет содержать указание в NSEC на существование NS, SOA, TXT, LOC, SRV и прочих DNS-записей, но не A-записи. Это тоже позволяет генерировать ответы динамически. То есть, авторитативный сервер “обманывает” резолвер, но делает это для того, чтобы экономить вычислительные ресурсы (поэтому механизм называется black lie – вместо white lie, однако это детали литературной терминологии).

Всё это несложно сейчас увидеть снаружи на примере Cloudflare: попробуйте взять dig и проверить самостоятельно на той или иной зоне, поддерживающей DNSSEC на авторитативных серверах Cloudflare. Такая реализация не только позволяет работать с динамической DNS, но и экономит место в ответах (другой существенный способ экономии – ECDSA, которую только и использует Cloudflare, так как ECDSA-подписи короче RSA).

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

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