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

У DARPA есть программа Gremlins, в рамках которой разрабатывают методы возвращения групп беспилотников на борт самолёта-носителя, который находится в воздухе. То есть, сперва большой транспортник (в программе речь про C-130), находящийся за пределами досягаемости ПВО, выпускает множество беспилотников, они отправляются выполнять задачи, а потом транспортник (возможно, другой) подбирает вернувшиеся. Всё это происходит в воздухе, что обеспечивает системе гибкость. При этом беспилотники можно использовать несколько раз.

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

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

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

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

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

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

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

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

1.

MitM – атака “Человек посередине”. Это атака уровня аутентификации, а не “шифрования”. Смысл атаки, в случае TLS (на клиентской стороне), состоит в том, что подменяется узел, с которым клиент пытается устанавливать соединение. А для того, чтобы клиент не догадался о подмене – используется сертификат, выпущенный для имени исходного узла. История с сертификатами в основном касается как раз TLS, для других протоколов ситуация может быть иной.

2.

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

3.

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

4.

Тем не менее, при устройстве тотального MitM – много чего сломается: например, перестанут работать сервисы, использующие клиентскую авторизацию; возникнут проблемы с различными VPN; перестанут работать решения, которые используют привязку к конкретным открытым ключам на стороне сервера (это относится к приложениям для смартфонов, к различным клиентам онлайн-сервисов, начиная от месcенджеров, интернет-телефонии, систем телеконференций и заканчивая клиентами онлайн-игр).

5.

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

6.

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

7.

Инфраструктура сертификатов и УЦ в современном Интернете развивается. Как раз в сторону повышения прозрачности. Соответственно, внедрение MitM будет быстро обнаружено. Для того, чтобы подтвердить факт MitM, тот или иной пользователь может просто опубликовать (отправить, скажем, в Google или в, условный, Facebook) подменный сертификат. Этот сертификат пользователю легко извлечь – в браузере, например, для этого есть функция экспорта. Подделать такой сертификат не выйдет (ну, если бы некий пользователь решил дезинформировать Google), потому что он обязательно содержит электронную подпись, которую можно проверить.

(Про перехват HTTPS я подробно писал в другой заметке.)

Основой для объединения множества сетей в Интернет является понятие автономной системы (AS). В случае Интернета, а точнее, в случае IP, автономная система – это вовсе “не вычислительная система, способная работать автономно”, а, фактически, набор маршрутизаторов, формирующих видимую для Интернета IP-сеть, которая находится под единым управлением. В рамках этого управления определяется то, как внутри этой сети доставляются пакеты. (В терминологии IP – группа маршрутизаторов с общей собственной политикой маршрутизации). Очень важная оговорка: этот “набор маршрутизаторов” подключен к другим автономным системам. То есть, определение автономной системы (AS) обладает некоторой занятной рекурсивностью: нельзя определить понятие AS, если нет других AS. Почему? Потому что “единое управление маршрутизацией” определяется с внешней точки зрения. Грубо говоря, подключающиеся к данной AS через пограничный узел сеть – видят внутреннюю политику маршрутизации как единую. Как ни странно, эта политика не обязана являться единой, если вы вдруг влезли внутрь AS и исследуете взаимосвязи между составляющими её узлами. Определение автономной системы – не столько техническое, сколько административное. Автономные системы в Интернете пронумерованы, и за каждой из них закреплено некоторое подмножество адресного пространства IP (так называемые IP-префиксы, обозначающие “непрерывные” блоки адресов), а смотрят они друг на друга, используя BGP.

BGP – или Border Gateway Protocol – это строго описанный формальный интерфейс, который автономные системы используют для формирования представления о маршрутах в Интернете. Фундамент BGP – обмен информацией о возможностях доставки пакетов. То есть, это внешний протокол взаимодействия между AS. Элементарную основу такого взаимодействия составляет распространение информации о желании автономных систем, являющихся соседними, доставлять пакеты в адрес того или иного IP-префикса. Под “соседними” подразумевается, что пограничные маршрутизаторы этих AS взаимодействуют непосредственно (заметьте, это не означает, что маршрутизаторы физически соединены напрямую). На логическом стыке между маршрутизаторами появляется понятие анонса: одна автономная система анонсирует префикс, а вторая – принимает или не принимает данный анонс. Отсюда же вырастают все другие конструкции, определяющие пути пакетов в глобальной Сети. Самой известной такой конструкцией является таблица Full View – глобальная сводная таблица путей (маршрутов), построенная для той или иной точки Сети.

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

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

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

Весной этого года ФБР спорило с корпорацией Apple по поводу “взлома” защиты аппаратов iPhone, для того, чтобы получить доступ к одному из таких аппаратов (АНБ из каких-то своих соображений заявило, что помочь не может). Обсуждались самые разные способы получения доступа, в том числе, при помощи физического копирования модуля памяти устройства (NAND mirroring). Почему-то насчёт этого варианта высказывались сомнения относительно реализуемости. Сергей Скоробогатов (Sergei Skorobogatov) продемонстрировал на практике, что задача решаема даже без использования сверхсложного лабораторного оборудования: The bumpy road towards iPhone 5c NAND mirroring – в работе подробно рассмотрены все этапы, начиная от извлечения чипа и до реализации перебора пароля доступа с использованием клонированной памяти (Apple, оказывается, использует некоторые методы аппаратной защиты от такого клонирования, но их можно обойти). Весьма интересно, рекомендую.

Обновил раздел “Избранные записки“. Добавил пять ссылок, вот они:

• Беспроводная технология малой мощности LoRa и модули NiceRF SX1276
• Техническое: DNSCrypt на примере “Яндекс.Браузера”
• Анонимность криптовалют и проблемы регулирования
• Двухфакторная аутентификация
• Число целей, дальность и сравнение истребителей

Я существенно расширил техническое описание TLS в новой версии. Добавил: раздел про симметричные шифры (с описанием AES), описания криптосистем RSA и ECDSA, существенно расширил описание протокола Диффи-Хеллмана; кроме того – дополнил и актуализировал весь текст целиком. Объём вырос почти в два раза – и, да, там много информации, но зато хорошо охвачены технические моменты. На мой взгляд, теперь это одно из самых полных и детальных описаний TLS на русском. Естественно, есть что дописать в следующей версии: расширенное описание атак, подробности про шифры, приложение с глоссарием по математическому аппарату (тут мне оказалось довольно сложно заморозить версию: исходники всё время обрастают новыми деталями, которые я потом отношу к “слишком техничным”), приложение с примерами конфигураций серверов (надеюсь, что в самом обозримом будущем) и другие дополнения. Это кроме того, что скоро должна выйти из состояния draft новая версия спецификации – TLS 1.3 (или 2.0, или как её обозначат), в которой куча радикальных изменений, а поэтому придётся добавить отдельную главу (сейчас я уже внёс некоторые оговорки по тексту, акцентирующие внимание на запланированных отличиях в новой версии).

И, да, наверное нужно сделать там хорошую навигацию – пока добавил только содержание, – и гипертекст.

Надеюсь, что это полезный текст. Вот ссылка: “Как работает ТLS, в технических подробностях“.

(Добавлять ли раздел, посвящённый постквантовым криптосистемам?)

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