Сейчас могут наблюдаться проблемы с доступом к dxdt.ru из сетей российских провайдеров. По возможности, используйте ссылки только с прямым указанием HTTPS (в принципе, только такие ссылки и должны бы быть, сайт давно использует HTTPS в качестве основного протокола, но кое-где остались и небезопасные).



Comments Off on Возможные проблемы с доступом

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

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

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

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

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

Про DH и связанные с этим протоколом ограничения я неоднократно писал раньше, например – здесь и здесь.



Комментарии (1) »

Ракета ко Дню Космонавтики.

(А. Соколов.)



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

Cloudflare официально запустили сервис DNS-резолвинга 1.1.1.1 (это IP-адрес, второй: 1.0.0.1). Резолвер работал под этим адресом уже некоторое время, но Cloudflare широко заявили о нём только первого апреля (такая вот шутка). Особенности сервиса: заявлена поддержка и DNS-over-TLS, и даже DNS-over-HTTPS (есть и такой новый протокол). По адресу 1.1.1.1 – доступен веб-сайт. При этом 1.1.1.1 в глобальной Сети нередко фильтруется или используется нерадивыми сетевыми администраторами в качестве “локального” IP-адреса, для внутренних тестов (не все готовы поверить, что это “обычный адрес”). Соответственно, сервис Cloudflare может быть недоступен из некоторых сетей. А вот адрес 1.0.0.1 – может трактоваться как синоним 1.1 (да, в короткой записи, две единицы), что позволяет прямо так и обращаться к узлу: $ ping 1.1

(В контексте DNS-over-TLS, напомню, что пару лет назад “Яндекс” занялся встраиванием в свой браузер другой технологии обеспечения безопасности DNS – DNSCrypt, но, похоже, DNSCrypt оказался неверным выбором.)



Комментарии (3) »

Новая версия протокола TLS 1.3 в ближайшее время получит статус рекомендации (статус уже одобрен). Я написал статью с обзором этого нового протокола. Он действительно новый, потому что от TLS 1.2 отличается радикально. Статья – TLS 1.3: на пути к внедрению.



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

Пишут, Израиль официально подтвердил, что в 2007 году нанёс удар по “ядерному объекту” на территории Сирии. Речь про удар 6 сентября 2007 года, когда разрушили большое защищённое строение. С этим событием связана первая волна сообщений о сверхсовременных средствах РЭБ, которые использовали израильские ВВС для противодействия силам ПВО: обсуждалось, что эти комплексы РЭБ не просто позволяют ставить активные помехи, но даже “перехватывать управление” комплексом. Правда, подразумевались сильно устаревшие советские комплексы. Я, кстати, писал на сходную тему, но позже, в 2010 году: Сигнатуры, ПВО и утечки информации по побочным каналам.



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

Немного теорий заговора. Сетевого уровня.

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

Интересно, как можно обнаруживать подобные действия?

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

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

IP или, например, UDP, оказываются универсальными в силу того, что работают на общем для всех узлов IP-сети логическом уровне. При этом другие протоколы спускаются на несколько уровней ниже. Так, есть инструменты VLAN (виртуальные сети) и другие логические элементы, невидимые для IP. Связанные с ними протоколы также можно было бы использовать для передачи недокументированных сигналов. Однако из-за того, что свойства даже соседствующих сетей на соответствующих уровнях очень сильно разнятся, тут встречаются трудности. С другой стороны, можно представить ситуацию, когда использование расширений стандарта Ethernet (например) позволяет скрывать от анализаторов трафика, работающих параллельно маршрутизаторам, целый пласт ходящих по физической линии связи данных. Элементарный пример, понятный каждому: представим, что для анализа трафика используется обычный компьютер и Wireshark, но продвинутая сетевая карта – игнорирует часть пакетов, например, обнаружив в заголовке Ethernet некоторый заранее зашитый в процессор карты индекс (заметьте, что такое поведение аналогично штатной функции, позволяющей разграничивать VLAN-ы). Понятно, что Wireshark в таком случае не будет видеть часть трафика, и обнаружить, что видны не все пакеты, вряд ли получится. Конечно, пакеты могло бы прятать и ядро ОС, но аппаратная фильтрация сетевой картой – куда как более эффективна: зафиксировать передачу данных теперь можно только при помощи логического анализатора, подключенного непосредственно к проводам. А вот уже представить себе логический анализатор, который прячет сигналы, гораздо сложнее, чем только что описанную конфигурацию с продвинутой сетевой картой. Но многие ли мониторят сети при помощи логических анализаторов? (Вопрос даже не риторический, а скорее похож на шутку.)

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



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

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

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

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



Комментарии (2) »

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

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

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



Комментировать »
Навигация по запискам: « Позже Раньше »