Картинка из прошлогодней записки про таблицу подстановок:

S-boxes

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

Нули и единицы разбивают всё пространство возможных значений на две равных части. Вот это и есть ключевой момент теоретико-информационного определения бита, про который нередко забывают даже при постоянной, – ручной, так сказать, – работе с битами/байтами: один бит информации соответствует уменьшению “неопределённости” в два раза, что бы там под “неопределённостью” ни подразумевалось. Если взять произвольный байт, то значений у него может быть 256 различных, это будет степень неопределённости. Если известен один бит, то возможных значений уже 128, если два бита, то 64, и так далее, перемещаясь по картинке вниз. А если эту концепцию наложить на идею непрерывности, то нетрудно увидеть целый набор фундаментальных математических объектов.



Комментировать »

Интересно, что Google Public DNS (8.8.8.8) при взаимодействии с зоной dnssec.pw, которую я на днях снабдил ключами с одинаковыми тегами, продолжает возвращать неконсистентные результаты, если спрашивать об отсутствующих в зоне записях. Например, при запросе TXT-записей в dnssec.pw теперь нередко приходят ответы со статусом SERVFAIL, “RRSIG with malformed signature…” – написано в пояснении. Однако есть и ответы со статусом NOERROR (примерно, половина, как ни странно), где, впрочем, пояснение тоже указывает на “RRSIG with malformed signature…”.

Возможно, конечно, что в данном сервисе на разных экземплярах узлов разное программное обеспечение, но есть и другое, несколько более занятное, объяснение: может так быть, что сервис ограничивает количество попыток проверки подписи для каждой итерации. В зоне четыре ключа ZSK, подпись RRSIG на NSEC – одна, на SOA – две. Соответственно, если у резолвера установлено некоторое предельное количество ошибок проверки подписи, то, когда предел достигнут, резолвер прекращает попытки перебора ключей и возвращает SERVFAIL. Если же ключ удалось угадать за меньшее количество попыток, то возвращается NOERROR. Подсчёт строк с сообщениями “RRSIG with malformed signature” в ответах – укладывается в эту гипотезу, но чтобы судить точнее – нужно собрать дополнительную статистику.



Комментировать »

DNSSEC-подписи, удостоверяющие адресную информацию, размещаются в RRSIG-записях. Ссылка на открытый ключ, нужный для проверки подписи, в RRSIG записывается в виде 16-битного тега (KeyTag), который вычисляется по достаточно простому алгоритму от данных ключа. Соответственно, ключи публикуются в DNSKEY-записях. Можно ли специально подобрать несколько валидных ключей так, чтобы у них были одинаковые теги? Очевидно – можно (ключей много больше, чем тегов). И подбор совсем нетрудно сделать. Более того – даже сохранятся валидные подписи и, условная, “корректность” зоны с точки зрения DNSSEC. “Корректность” тут в кавычках потому, что, вообще говоря, несколько ключей с одинаковыми тегами не должны бы присутствовать в DNS-зоне, поскольку это нарушает логику ссылок из RRSIG. И хорошо бы в таком случае выводить ошибку валидации, но возможен более мягкий подход, который и используется.

Посмотрите, в качестве примера, на DNS-зону dnssec.pw – там я разместил несколько ключей (ZSK – Zone Signing Key), которые имеют одинаковые теги со значением 12345. Два ключа из четырёх ZSK задействованы в подписывании записей, а поскольку подписи можно проверять методом перебора ключей, то и RRSIG – валидируются, если валидатор резолвера справляется с ситуацией. Пятый ключ – это KSK, точка входа. Схема показана на картинке (ниже), которую сформировал весьма полезный сервис DNSViz. Повторяющиеся идентификаторы (id = 12345) выглядят занятно, однако количество вершин графа соответствует количеству ключей, а рёбра – соответствуют структуре подписей. Так что DNSViz не сломался:

dnssec-pw DNSSEC graph

Другой, не менее полезный, сервис для анализа DNSSEC – DNSSEC Analyzer – проверки для данной зоны тоже выполняет корректно, но в таблице результатов совпадающие идентификаторы могут запутать несколько больше, чем на графе GraphViz:

dnssec.pw DNSSEC status

Валидирующие резолверы должны справляться с подобной конфигурацией ключей, однако Google Public DNS (8.8.8.8) возвращает в статусе информацию о “некорректном формате RRSIG”, но ответ всё равно снабжается флагом AD (Authentic Data), обозначающим, что проверка подлинности DNSSEC прошла успешно – впрочем, это соответствует действительности: подписи и цепочка в зоне dnssec.pw сейчас верные.



Комментировать »

В логах веб-сервера dxdt.ru тысячи записей о GET-запросах от некоторого ClaudeBot, как указано в User-Agent. Больше в User-Agent ничего не указано, хотя правила хорошего тона предполагают, как минимум, ссылку на страницу с описанием того, “что это, зачем и как оно приходит” – в HTTP это нетрудно сделать. Конечно, в User-Agent каждый может написать что вздумает, но данный ClaudeBot ещё и приходит за одними и теми же страницами (которые не изменялись), постоянно переключая IP-адреса. А IP-адреса там из пула AWS (амазоновский сервис), поэтому даже и обратная зона мало о чем говорит (ну, кроме того, что это AWS). Непонятно, имеют ли следы в логах, оставленные данным ботом, какое-то отношение к деятельности одноимённого продукта очередной AI/ИИ-компании, решения которой для российских пользователей заблокированы, но забавно уже то, что имя используется совпадающее; тем более, что на сайте компании не удалось найти ничего о том, как их боты оформляют свои запросы.



Комментировать »

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

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

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

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

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

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



Комментировать »

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



Комментировать »

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

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

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



Комментировать »

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



Комментировать »

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

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



Комментировать »

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

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



Комментировать »