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

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

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

И это так и есть: представьте, что работает система спутниковой связи – приёмо-передатчик на спутнике и приёмо-передатчик на подвижном наземном аппарате (или на летательном аппарате, на малой высоте). Обе стороны используют узкие лучи, например, на стороне наземного аппарата такой луч создаёт компактный терминал с АФАР.

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

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

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

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

И поэтому всегда удивительно наблюдать, как, – в текущих реалиях, – на базовых станциях систем резервного питания явно не хватает, и всякая мало-мальски масштабная авария сетей обычного электроснабжения (аварии – уже не редкость) тут же приводит к тому, что не только пропадает свет в оптоволокне интернет-канала, заведённого в дом, но в округе и моментально тухнут только что доступные базовые станции GSM/LTE. Хотя – казалось бы. Но нет, это уже практика: времена поменялись – подходы скорректировали.

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

Момент первый: измерение параметров времени для TCP-соединения. Например, к некоторому веб-сервису подключается клиент, скажем, браузер. При помощи выполнения некоторых скриптов не очень трудно померить время “сетевой задержки” между средой веб-страниц этого браузера и серверной средой. То есть, это будет время доставки запроса, измеренное от контекста DOM в браузере до веб-сервера. Предположим, это 50 ms. Но это всё по HTTP, а HTTP-соединение использует TCP.

TCP-соединение устанавливается не с браузером, а с логически ближайшим к серверному сетевому стеку узлом. Это может быть клиентский компьютер, то есть, ОС на этом компьютере. Но может быть и выходной узел, выполняющий трансляцию адресов, например. Обычно – именно так и есть: клиентский компьютер редко стоит прямо за маршрутизируемым IP-адресом. Тогда, если измерять и задержку в браузере, и задержку на серверном TCP, то получится, скажем, что, в рамках одной логической HTTP-сессии, TCP-задержка – 10 ms, а браузерная задержка, до DOM в HTTP-клиенте, – 50 ms. Большая разница – 40 ms. Это означает, что от клиента транслированные запросы ещё где-то там внутри долго ходят, пока доберутся до выходного узла, который к нам по TCP подключился.

Если же выходной TCP-узел примерно совпадает с логическим узлом, где работает клиентский браузер, то разница между двумя задержками будет минимальной, например: 10 ms TCP и 11 ms – браузерная задержка, читай – Javascript в DOM-контексте. Здесь под “примерно совпадает” имеется в виду, что между клиентским компьютером и выходным узлом нет большого сетевого плеча: компьютер и выходной узел стоят технически рядом (простейший случай: локальный пограничный “роутер” с NAT и подключенный к этому “роутеру” по локальному порту компьютер в локальной IP-сети над Ethernet-ом).

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

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

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

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

Сюда же попадает и повсеместная путаница, связанная с распределением блоков IP-адресов (префиксов). У всякого IP-префикса есть администратор – автономная система (AS). Это верно. Но ещё есть маршрутизация и BGP. И вот в рамках BGP, технически, быть источником (origin) для данного IP-префикса может любая (подчёркиваю: технически – любая, даже с тестовым номером) автономная система. То есть, административно, префикс принадлежит одной AS, но анонсирует его в Интернет – совсем другая. Или даже несколько других AS – в зависимости от того, какой оператор из какой точки сети смотрит на BGP. Да, для штатного анонсирования префикса должно быть разрешение от его администратора, сейчас это даже подтверждается в RPKI. Да, конкретная ситуация с приёмом IP-пакетов зависит от фильтров, настроенных оператором. Но это только подчёркивает то, что одно дело – административная принадлежность, другое – BGP и маршрутизация в реальности.

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

В The Register пишут про не самый обычный прототип высокоскоростного (5.2 Gbps) канала связи, который японская корпорация Kyocera устроила на основе лазера. Якобы, схема подходит для подводной связи. Конечно, если бы было так, да без очевидных ограничений, то это оказалось бы прорывной технологией. К сожалению, прототип работает лишь на дистанции около метра, а тот вариант, который показали журналистам, ещё и через специально очищенную воду, без учёта возможных “турбулентностей” (ну, как говорится, это “такие себе” ограничения – пока что они сводят возможный практический эффект примерно к нулю).

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

В DARPA, кстати, некоторое время назад запускали программу, в которой высокоскоростной канал связи реализуется при помощи плавучего оптического кабеля.

В публикации на Ars Technica сокрушаются, что Китай, мол, начал интенсивно выводить на околоземную орбиту спутники своей новой сети. И сеть эта – “не просто другая версия Starlink”, но имеет потенциальные приложения для наблюдения за целями на земле и в воздухе, а вот в Штатах всё ещё не готова военная низкорбитальная сеть нового поколения (MILNET), да аналогичного назначения (которое, в отличие от китайской системы, тут прямо декларируется через СМИ).

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

Да, орбитальные сети из тысяч спутников – это принципиально новая платформа. Например, я недавно писал про изменение возможностей наблюдения:

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

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

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

Слушать эфир можно как каким-то одним из имеющихся радиотрактов (WiFi, Bluetooth/BLE, GNSS, GSM и т.д.) или всеми сразу. Современные радиомодули очень чувствительные и избирательные. Если использовать непосредственно функции прошивки радиомодуля, то, вообще говоря, принимать можно далеко не только “логический WiFi”, но и разнообразные другие сигналы, в том числе, сигналы радаров, спутниковых передачиков (подтверждается Starlink) и т.д., и т.п. Да, приниматься могут быть гармоники побочных утечек, но для данной задачи это не важно. Если сомневаетесь, то вспомните историю появления такого направления, как RTL-SDR – там аппаратной основной вообще послужил бюджетный ТВ-тюнер. (Замечу, в скобках, что даже если в пользовательском интерфейсе смартфона указано, что соответствующие радиомодули “отключены”, это не означает, что они реально отключены – реально отключить можно было бы только в специальной архитектуре, аппаратной кнопкой, но таким практически никто не пользуется, да и кнопка не даёт полной гарантии.)

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

Теперь на сервере, зная возможности приёма и принципы распространения радиоволн, можно вычислять где какие метки в эфире были видны – то есть, выполнять геолокацию идентификаторов. Устройства-наблюдатели ведь будут видеть и друг друга, и базовые станции сетей мобильной связи. Сопоставляя данные от разных мониторов, географические координаты которых известны точно, получится определить, где находились и устройства-наблюдатели, и источники радиосигналов, которые эти наблюдатели обнаружили в эфире. Метод основан на переборе конфигураций, в которых многие наблюдатели могли принимать одни и те же сигналы, чтобы в итоге получилась такая же картина, как та, что поступила с нескольких мониторов.

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

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

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

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

Если же у нас и несколько близких спутников всегда в поле зрения, и используется суперсовременная фазированная антенная решётка с электронным управлением лучами, то задача стабилизации совсем другая: электронный переброс лучей выполняется несравнимо быстрее, да и направлений для их переброса всегда несколько, так как несколько спутников. В общем, механическое сканирование для стабилизации сигнала вообще может и не требоваться. Это как раз вариант для Starlink. Точнее, для Starshield – для военной ветки данной системы, которая разрабатывается и работает для SDA (Space Development Agency).

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

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

Утечки по побочным каналам (ПЭМИН) возможны разные. Предположим, что есть некоторая портативная радиостанция (рация), которая штатно использует защищённый радиопротокол. Что-нибудь типа P25 – это тут не так важно, главное, чтобы использовался цифровой сигнал, а полезная информация передавалась в зашифрованном виде.

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

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

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

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

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

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

Пишут, что после очередного обновления iOS Apple на iPhone в Штатах появилась поддержка доступа к Starlink, как к “телефонному сервису”, через идентификаторы оператора T-Mobile. Что там в обновлении – не ясно: возможно, новая прошивка для радиомодуля, возможно – нет, и прошивка была обновлена заблаговременно, а теперь включили именно конкретные параметры для данного радиоканала.

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

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

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

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

На замену GPS/GNSS в авиации уже предлагают использовать “прочие”, сопутствующие, радиосигналы, в том числе, GSM, и, – что не совсем обычно, – сигналы разных других спутниковых систем (то есть, не GNSS): статья The Register. В качестве исследовательской платформы в статье по ссылке выбран шар-метеозонд, снабжённый радиоприёмным оборудованием.

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

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

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

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