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

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

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

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

(Starlink Dishy Teardown.)

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

За прошедший год на dxdt.ru записок появлялось мало (интересно, что я далеко не первый год сетую на это, но – куда деваться?), с другой стороны – я дописал и выпустил обновление описания TLS, исправил кое-какие недочёты и ошибки в тестовом сервере TLS 1.3, ну и, всё же, какие-то записки выходили, например, про Starlink, о протоколе ECDH “в числах”, и другие.

Да, чуть не забыл: с наступающим Новым годом! Спасибо, что читаете.

Перенёс dxdt.ru на другой сервер (другой экземпляр сервера). Это потребовалось для того, чтобы перевести всё под управление ОС Debian 10. Вроде, всё работает в новой конфигурации, но был небольшой перерыв при замене адресов.

В блоге Cloudflare подробная статья, рассказывающая популярно про технологию сокрытия имени сервера в TLS: Encrypted Client Hello (ECH).

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

(Как работает ESNI – можно посмотреть на моём тестовом сервере https://tls13.1d.pw/, а вот поддержку ECH я ещё не собрался дописать.)

На сайте ТЦИ опубликована моя статья с результатами измерения распространённости поддержки TLS 1.3 на HTTPS-узлах Рунета. Под Рунетом подразумеваются имена второго уровня в зонах .RU, .SU, .РФ. Измерялось наличие поддержки TLS 1.3 для TCP-соединений на номере порта 443 (это номер HTTPS). TLS 1.3 уже довольно широко поддерживается, несмотря на относительную новизну протокола. Описание методики и результаты – в статье.

Немного занимательных математических основ криптографии.

Российская криптосистема электронной подписи (ГОСТ 34.10-2012) работает в группе точек эллиптической кривой над конечным полем, как и криптосистема ECDSA, широко используемая в TLS и в других протоколах защиты информации. Можно ли устроить так, чтобы открытый и секретный ключи для ГОСТ-подписи и ECDSA – совпадали? Дело в том, что если ключи одинаковые, то это добавляет удобства: например, можно использовать некие унифицированные сертификаты. Естественно, это чисто теоретической вопрос, но он довольно занятный. Если вынести за скобки криптографические параметры и способ интерпретации битовых строк, то главное отличие между ГОСТ-подписью и ECDSA состоит в уравнениях, используемых этими криптосистемами. Упростим ситуацию и рассмотрим лишь уравнения вычисления значения подписи:

ECDSA: s = k^(-1)(h + rd)

ГОСТ: s = (rd + kh)

Здесь использованы общие буквенные обозначения: h – это подписываемое значение (можно считать, что это значение хеш-функции от сообщения – натуральное число); k – случайный параметр (натуральное число); r – значение х-координаты вычисляемой на основе k “случайной” точки кривой (это элемент конечного поля, но и его в нашем случае можно понимать как натуральное число), d – секретный ключ (натуральное число). Здесь везде опущены упоминания того, что значения вычисляются по модулю порядка группы точек, связанной с точкой-генератором G, но, опять же, это нисколько не помешает изложению.

Итак, сразу видно, что секретные ключи d для обоих вариантов математически эквивалентны, так как секретный ключ – это натуральное число. Это так и есть на практике, с оговоркой, что значение секретного ключа должно лежать в некотором интервале, но это технические детали. На практике, вряд ли имеет смысл использовать небольшое значение d, которое может оказаться угадываемым. То есть и для ГОСТ-подписи, и для ECDSA в качестве секретного ключа можно использовать одно и то же значение. Если оно находится в подходящем интервале, то в работе алгоритмов, реализующих криптосистемы, равным счётом ничего не поменяется.

Как быть с соответствующими открытыми ключами? С открытыми – уже не так просто. Открытый ключ в обоих криптосистемах – это точка кривой, полученная в результате “умножения” точки-генератора G на число d (значение секретного ключа): открытый ключ Q == dG. “Умножение” здесь взято в кавычки по той причине, что для точек кривой никакого умножения не определяется, но есть “повторное сложение” точек: так, 3*A == A + A + A, где A – точка кривой. Повторное сложение и позволяет ввести умножение на скаляры (на целые числа). Итак, открытый ключ – точка кривой Q – это пара координат (x, y). Значения координат, x и y, – элементы поля, над которым рассматривается кривая. Именно здесь и кроется отличие: штатно, обсуждаемые криптосистемы используют разные кривые и разные поля, поэтому полученные значения открытого ключа будут различными, если, конечно, мы хотим сохранить корректность прочих операций (а корректность сохранить необходимо).

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

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

Важный момент про DNS-over-TLS (DoT) и DNS-over-HTTPS (DoH): в случае, когда валидацию DNSSEC проводит внешний рекурсивный резолвер, использование DoT/DoH на “последней миле” позволяет эффективно продолжить цепочку доверия DNSSEC до клиента; правда, через дополнительный шаг – аутентификацию сервера в рамках TLS. То есть, если некоторый клиентский stub-резолвер использует гугловый сервис 8.8.8.8 и доверяет его валидации DNSSEC, но сам валидацию не проводит, то, в классическом случае, никто не мешает на транзитном узле вмешиваться в трафик и присылать фиктивные ответы от имени 8.8.8.8, в которых будет что угодно. Использование же DoT/DoH позволяет клиенту аутентифицировать узел (DNS-сервер) и проверять подлинность ответов, что распространяет доверие к валидации DNSSEC на случай, когда клиент не верит транзитным узлам (а им верить давно нельзя).

(Первоначально опубликовано на Facebook.com, 22/11/2019.)

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

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

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