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

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

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

Итак, список свойств. Некоторые из них совсем очевидны, некоторые – очевидны в меньшей степени, есть и неочевидные.

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

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

3. Идентификация аккаунта проводится по отпечатку некоторого криптографического ключа (или “токена”), секретная часть которого находится у пользователя. Этот принцип соблюдается далеко не всегда, но только такой вариант позволяет разделить “адресацию” на уровне сообщений пользователей и всю прочую адресацию (IP-адреса узлов, доменные имена, телефонные номера и пр.). Привязка идентификатора к реальному пользователю происходит за пределами мессенджера.

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

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

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

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

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

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

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

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

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

(Starlink Dishy Teardown.)

Под “спутниковыми интернетами” здесь подразумевается предоставление глобального “широкополосного” доступа к Интернету спутниковой группировкой. Таких систем предлагается несколько, а сами аппараты уже начали запускать: например, Starlink и OneWeb. Я уже писал, что подобная спутниковая система является отличной платформой для создания универсального орбитального радара, предназначенного для наблюдения за поверхностью Земли. В этот раз речь о другом: насколько легко будет обнаруживать наземные станции, используемые для доступа к данному спутниковому каналу связи?

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

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

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

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

Известная история гласит, что Интернет создавался для обеспечения связи в ситуации, когда большая часть сетей разрушена, выведена из строя (это только одна часть истории, но сейчас речь о другом). У DARPA есть программа TUNA (Tactical Undersea Network Architecture), цель которой – получение средств, позволяющих быстро наладить связь на больших расстояниях в море, при условии, что имеющиеся сети разрушены. Концепция подразумевает налаживание радиосвязи, но с использованием оптических линий между опорными узлами. То есть, в море выпускаются буи (например, сбрасываются с самолёта), между которыми под водой протягивается плавучая (это важно – кабель не опускается на дно) оптоволоконная линия, которая, как пишут, должна проработать до 30 дней. В новости по ссылке выше упоминают разработку лаборатории Вашингтонского университета – буй, который вырабатывает электричество, используя энергию морских волн.

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

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

DARPA заказывает перспективную разработку портативных излучателей электромагнитных волн сверхнизких частот (ниже 30 кГц, а особенно – на частотах от 300 Гц до 3 кГц). Так как на этих частотах длина волны очень велика (это сверхдлинные волны – десятки, сотни и тысячи километров), традиционные системы для их излучения оказываются огромными. При этом сверхдлинные волны подходят для подводной и подземной связи. Например, они используются для обеспечения связи с подводными лодками.

Предполагается, что в рамках программы AMEBA (A MEchanically Based Antenna) создадут механические излучатели, основанные на движении постоянных магнитов или заряженных диэлектриков – да, речь именно про механическое движение. Устройства-передатчики должны потреблять менее 20 ватт и весить менее 10 килограмм. То есть, передатчик можно установить на автомобиле или даже переносить силами одного человека. В идеале – это подводная/подземная рация.

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

Из-за небольшой частоты, доступная полоса обмена данными узка. На частотах ниже 3 кГц она, скорее всего, вообще будет измеряться битами в секунду. Но это не должно помешать передавать текстовые сообщения, особенно, если использовать специальное кодирование. Скажем, в случае с подводными лодками, всего несколько битов кодируют сообщения из специального словаря. Предположим, что мы можем надёжно (то есть, с коррекцией) передавать один бит в секунду, тогда за пять секунд можно передать один из 2⁵ = 32 символов, или одно из 32 возможных сообщений. Не так уж и мало.

Прототипы планируют получить в 2021 году.