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

У постановки помех GPS – история давняя. Это интересная тема. Вообще, что касается именно вопроса точной навигации, то блокирование сигнала GPS имеет свои ограничения: дело в том, что есть инерциальные системы навигации, они автономные, а GPS для них полезна лишь в том смысле, что позволяет скорректировать накопленную ошибку. Но если навигационный сигнал недоступен только на небольшой территории, то ограничения для инерциальных систем становятся не так актуальны: ошибка просто не успеет накопиться.

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

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

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

А вот “пропадание навигации” в смартфоне – всего лишь побочный эффект.

(Развитие темы: подделка сигнала GPS, GPS-спуфинг.)

Больше и больше пишут про “квантовые каналы” связи, которые “абсолютно” защищены “квантовой криптографией”, и только они смогут спасти от “квантового компьютера”. Здесь интересны несколько моментов.

1.

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

2.

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

3.

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

4.

Квантовые компьютеры. Симметричные системы (шифры), вроде AES, сохраняют стойкость: сейчас считается, что появление квантовых компьютеров достаточной мощности приведёт лишь максимум к “квадратичной” оптимизации перебора. Это очень оптимистичная, в отношении квантового компьютера, оценка, потому что речь идёт о квантовых операциях, реализующих алгоритм поиска – а это совсем другое дело, по сравнению с классическим CPU. То есть, для сохранения стойкости, разрядность ключа симметричного шифра нужно будет увеличить в два раза. Соответственно, AES с 256-битным ключом обеспечит достаточную степень защиты (эквивалентную 128 битам). Если стороны успели в защищённом режиме обменяться гигабайтом ключевого потока, то его, даже при расточительном использовании в качестве ключей AES, хватит надолго. (256 бит – это 32 байта, которые можно смело использовать для шифрования AES примерно 2^32 блоков, каждый блок – это 16 байтов, то есть, одного ключа хватит для 16 * 2^32 ≈ 64 гигабайт передаваемых данных; и это только один ключ, 64 байта из гигабайта).

5.

Квантовые компьютеры достаточной разрядности – полностью побеждают распространённые сейчас асимметричные криптосистемы. Если только такие компьютеры возможны. Как ни странно, первыми падут суперсовременные криптосистемы на эллиптических кривых: это связано с тем, что они имеют малую разрядность, а способность квантового компьютера взламывать такие системы находится в прямой зависимости от числа доступных кубитов. То есть, компьютера, взламывающего ECDSA с ключами в 256 бит, ещё недостаточно для того, чтобы атаковать RSA с разрядностью в 2048 бит. Так что тут у RSA есть преимущество. Другое дело, что как только сумеют построить квантовый компьютер с разрядностью в 256 кубитов, масштабирование на 2048 – вряд ли потребует долгих лет.

6.

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

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

7.

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

^* Примечание от 04/11/2021: здесь речь идёт про TLS в вебе, в HTTPS, но TLS применяется не только в вебе, а исключение составляют варианты использования TLS с заранее распределённым секретным ключом (схемы PSK), которые, впрочем, встречаются довольно редко.

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

Одно из современных направлений в развитии технологий связи – это сверхкомпактные, экономичные модули, обеспечивающие передачу данных на большие расстояния. Основная область применения: различные датчики, управляющие устройства и прочие “умные” компоненты. LoRa – как раз относится к таким технологиям связи: миниатюрный модуль, радиомодем, потребляющий минимальную энергию и делающий возможной передачу данных на расстояние в километры (вплоть до десятков километров). LoRa – похоже, лидер по дальности. Однако данная область не исчерпывается одним протоколом: здесь также действуют ZigBee, Bluetooth 4.0, Sigfox и др. Но эта заметка о том, как LoRa работает в реальности, на живом примере пары бюджетных модулей от NiceRF. (С картинками.)

Читать полностью

Update (19/02/2019): реализовал преобразования блока на ассемблере для платформы x86-64/amd64, это даёт прирост производительности в несколько раз – доступна новая версия, использовать лучше её.

Продолжение реализации шифра “Кузнечик” (ГОСТ Р 34.12-2015) на языке Go. Я заменил в предыдущей реализации побайтовые XOR на 64-битные, это дало прирост производительности примерно в семь раз. Кроме того, я довольно существенно изменил код, дописав функции, реализующие операции шифрования/расшифрования с уже развёрнутыми наборами ключей – это необходимо для использования шифра в потоковом режиме.

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

• новая реализация “Кузнечика” на Go – kuznec.go;
• достаточно детальный пример использования “Кузнечика”, вместе с небольшим тестом производительности – test_grasshoopper.go;
• всё в одном архиве.

Небольшая справка: GCM – Galois/Counter Mode – режим счётчика с аутентификацией Галуа: это режим аутентифицированного шифрования, который, к тому же, поддерживает аутентификацию дополнительных данных (передаются в открытом виде). В англоязычной литературе это называется AEAD – Authenticated Encryption with Associated Data. В ГОСТовой криптографии такого режима как раз не хватает. Аутентифицированное шифрование позволяет обнаружить изменения сообщения до его расшифрования, для этого сообщение снабжается специальным кодом аутентификации (в русскоязычной традиции также называется имитовставкой). GCM позволяет защитить кодом аутентификации не только шифрованную часть сообщения, но и произвольные прикреплённые данные – это полезно, потому что в этих данных может быть записан, например, адрес получателя или другая открытая информация, которую, вместе с тем, требуется защитить от искажений/подмены. Я планирую как-нибудь написать в подробностях про шифры и режимы шифрования, в том числе, про GCM, скорее всего, в рамках дополнения к описанию TLS.

(Отдельно замечу, что данная реализация “Кузнечика” является лишь примером возможного использования данного шифра. Зато в режиме GCM можно, так сказать, полноценно шифровать большие файлы.)

Англоязычное пояснение:

This is the next implementation of GOST R 34.12-2015 Kuznyechik cipher in Golang. With optimized XOR and some other improvements the performance is about seven times better. Also it is now possible to use GOST R 34.12 package with crypto/cipher, particularly in GCM operation mode. New code has new name – kuznec.go. More comments – in Go source code for Kuznyechik (and see links in Russian text above).

Update (20/02/19): реализовал преобразования блока на ассемблере для платформы x86-64/amd64, это даёт прирост производительности в несколько раз – доступна новая версия, использовать лучше её.

“Кузнечик” это новый российский блочный шифр, в прошлом году стандартизованный ГОСТ Р 34.12-2015. Шифр работает с блоками в 128 бит, ключ имеет длину 256 бит. (Текущим аналогом является шифр AES.) На досуге я реализовал “Кузнечик” на языке Go. Это, конечно, реализация пока далёкая от оптимальной и строгой (в смысле “криптокода”). Например, работа с блоками написана “побайтово”, не используются другие достаточно очевидные оптимизации и штатные языковые конструкции Go (я пока не очень освоился с данным языком). Так сказать, альфа-версия. Приветствуются комментарии, поправки. Возможно, имеет смысл развивать дальше.

Исходники выкладываю на dxdt.ru:

исходный код модуля grasshopper (Kuznyechik, GOST R 34.12-2015);
небольшая программа для проверки работоспособности (реализован стандартный вектор проверки и один дополнительный);
оба файла в .tar.gz.

(Внутри исходников комментарии на английском.)

Некоторые технические пояснения. Работу данного шифра можно ускорить, если использовать достаточно большие таблицы с предвычисленными преобразованиями. Именно этот вариант и реализован. Впрочем, функций Decrypt – две. Одна версия использует все таблицы, вторая – только одну, в которой содержатся предвычисленные значения линейного преобразования. Сами таблицы не содержатся в исходном коде, а вычисляются вызовом функции инициализации. В Go есть штатная библиотека, реализующая режим аутентифицированного шифрования GCM. Обычно этот режим используют в связке с AES, но годится и другой шифр подходящей разрядности. Соответственно, есть идея реализовать связку Kuznyechik-GCM, которая уже является практически полезным инструментом (update: реализовал режим GCM).

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

Англоязычное пояснение:

This post describes GOST R 34.12-2015 Kuznyechik reference implementation in Golang. More comments – in Go source code for Kuznyechik. There is a different version available.

GAO (это такой контролирующий правительственный орган в США) опубликовали отчёт, касающийся перспектив обновления государственных информационных систем. В нём, в частности, сказано, что в минобороны США до сих пор используют 8-дюймовые дискеты, в системе, связанной с планированием и управлением ракетно-ядерными силами. Тему дискет (которые сейчас принято считать 3D-принтерными версиями иконки Save из интерфейсов офисных программ), конечно, подхватили СМИ. При этом некоторые схожие системы в других странах (в США, впрочем, наверняка тоже) до сих пор используют перфокарты. И в этом нет ничего особо страшного. Строго говоря, большая дискета с низкой плотностью записи, при правильном использовании, достаточно надёжна. Но перфокарта, несомненно, лучше, потому что хранит данные чисто механическим способом.

Кстати, в GAO не упустили повода и заметили, что “современный флеш-накопитель по объёму хранимых данных эквивалентен более чем 3,2 млн дискет”. Сложно было бы придумать более банальное пояснение. Ну, ясное дело, если вы передаёте полётное задание для МБР на подводную лодку, очень важно упаковать его в какую-нибудь новомодную софтверную обёртку из встроенных процедур и свернуть вместе с NoSQL-СУБД и прочим ПО в контейнер Docker, который как раз влезет на флешку, если, конечно, удастся грамотно подобрать окружение. (Да, естественно, в отчёте названа и основная актуальная проблема дискет – их “сейчас сложно достать”.) Если вы военная система и передаёте примерно тысячу октетов в качестве полётного задания, то использовать вместо дискеты флешку, только потому, что это модно среди пользователей “офисных пакетов”, несколько неразумно. Я бы вернулся к перфокарте, но реализованной на современном уровне.

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

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

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

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

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

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

Исследователи реализовали программу, которая распространяется между промышленными микроконтроллерами Siemens SIMATIC S7-1200 – есть публикация, описывающая принцип работы червя. Схема, отчасти, напоминает старые времена, когда небольшие вирусы распространялись между ПК, под управлением MS-DOS – правда, для появления действительно массовых вариантов потребовалось внедрение Windows, тогда появились решения, распространяющиеся без малейшего участия пользователя, просто передавая пакеты по сети. Собственно, описанный в статье червь для микроконтроллеров именно так и действует. А главная особенность в том, что для распространения не требуется ПК.

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

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

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

В общем, поле промышленных систем (АСУ ТП) – непаханое, и тут отлично подходят методы атак, которым 15-20 лет.

В бета-версии “Яндекс.Браузера” появилась поддержка DNSCrypt. Посмотрим, как она работает. Для активации – нужно включить опцию “Всегда использовать … DNSCrypt” в настройках браузера (опция, похоже, доступна только в версии под Windows). После этого браузер начинает использовать сервер “Яндекс.DNS”, с IP (в моём случае) 77.88.8.78, отправляя запросы DNSCrypt по UDP на номер порта 15353. Сессия DNSCrypt, согласно протоколу, начинается с отправки пакета, содержащего в открытом виде имя сервера и версию протокола: 2.dnscypt-cert.browser.yandex.net. Данный запрос необходим для получения сертификата сервера и генерации криптографического контекста, который далее будет использоваться клиентом и сервером для шифрования запросов/ответов. Вообще, протокол DNSCrypt не ставит задачи сокрытия самого факта использования DNSCrypt, поэтому может быть легко блокирован с использованием системы DPI. Трафик DNSCrypt “Яндекс.Браузера”:

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

Естественно, в реализации DNSCrypt могут быть уязвимости, начиная от некорректной аутентификации сервера (протокол предусматривает двухстороннюю аутентификацию, вопрос в том, как она реализована в браузере “Яндекса”) и до различных дефектов и утечек, связанных с генерацией и использованием ключей.

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

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

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

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

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