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

Общедоступный технологический фундамент крепнет – энтузиасты теперь могут строить хитрые системы, ранее принципиально им недоступные.

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

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

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

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

(Надо заметить, что мне уже пару раз присылали описания проектов похожих систем. Наверное, что такое уже может быть сделано.)

Пожалуй, вынесу сюда из комментариев – читатель с ником AA пишет про закладки в микросхемах:

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

Специфические микрухи для закладывания изотопов – высокоскоростные и многоканальные АЦП, DSP.

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

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

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

Практическое проявление описанных различий сейчас хорошо видно на веб-сайтах, которые бодро перешли на кириллицу в адресах. Например, документ с описанием домена РФ на сайте Координационного центра (администратора этого домена) имеет вот такой URL: http://кц.рф/ru/domains/domenrf/. Посмотрите сами, где здесь домены и где “файлы”, которые уже давно допускают использование многоязычия.

Это я не к тому, что адреса на кириллице плохо. Просто ситуация – сильно отличается от случая с именами файлов.

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

Интересно, что навязать пользовательскому компьютеру такие вычисления можно и без доступа к системе обновлений. Логичное решение – посещаемый веб-сайт. Конечно, можно что угодно запрограммировать на JavaScript и отправлять результаты подсчётов на сервер после загрузки страницы, или даже считать всё время, пока страница загружена, а результаты отправлять асинхронно, с помощью AJAX. Но JavaScript – медленный, да и решение получается слишком банальное.

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

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

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

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

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

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

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

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

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

Понятно, что время нужно измерять от момента обнаружения угрозы сенсорами до момента, в который защищаемый объект (танк там, или самолёт) будет поражён. Предположим, что сенсоры обнаруживают подлетающий снаряд (гранату, ракету) на расстоянии в 1000 метров. Тогда, при средней скорости подлёта в 500 м/с, остаётся аж две секунды на всё про всё, можно хорошо прицелиться и так далее.

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

Более практичное расстояние – 100 метров. Получаем 0.2 сек. = 200 мс при средней скорости подлёта 500 м/с. 200 миллисекунд – это 200 тыс. тактов процессора, работающего на частоте 1 Мгц. 200 тыс. операций – как оценка, выглядит достаточной для вычисления параметров перехвата. При этом, 1 Мгц – по нынешним меркам очень медленно даже для военной специальной ЭВМ. Нужно, впрочем, скинуть время, необходимое для актививрования бортового перехватчика (поджиг ускорителей и т.п.) и передачи в этот перехватчик данных целеуказания.

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

Ускорители со специальным топливом – они срабатывают очень быстро, хватит 5-10 мс плюс ещё 10 мс накинем на выполнение разворота. Тут, впрочем, кроется весьма хитрое “ноу-хау”: нужно так устроить корректирующие двигатели, чтобы они точно дозировали создаваемый момент, иначе противоракета будет разворачиваться с ошибкой, что сделает всю систему бесполезной. В используемом нами масштабе, заметным становится время, за которое противоракета достигнет точки перехвата. Предположим, что противоракета также показала среднюю скорость 500 м/с (очень такой прикидочный расчёт). Получается, что через 20 мс (10% от общего интервала в 200 мс) противоракета пролетела 10 метров. С запасом хватает для наземной бронированной техники (с точки зрения защиты пехоты перехват должен осуществляться как можно ближе к танку; у самолётов – там ситуация иная, но это для другой записки).

Время на передачу данных по проводам: похоже, им можно пренебречь (примем, что около 4 нс на метр, при использовании оптоволокна в качестве среды распространения). Также не рассматриваем задержки на распространние сигнала радара. Загрузка данных в противоракету: несколько байтов, несколько десятков тактов, получается – в пределах миллисекунды, при условии, что данные передаются по интерфейсу с основной частотой в 1 Мгц.

Промежуточный итог: для медленных целей (500 м/с) времени на вычисление параметров и на сам перехват – целый вагон (у нас специально занижена потенциальная производительность ЭВМ). Выглядит всё реально.

Теперь предположим, что появились упомянутые в комментах гиперзвуковые кинетические снаряды. Скорость такого боеприпаса – 1500 – 2000 м/с. То есть, времени меньше в четыре раза (скорость в четыре раза выше). Но, собственно, для вычислительной части времени всё равно достаточно (мы же взяли самую медленную ЭВМ) и даже задержки на передачу данных опять не заметны. Если противоракета продолжает тратить 40 мс на прибытие в точку встречи, то гиперзвуковой снаряд за это время пролетает всего 80 метров, что укладывается в предложенную схему (дистанция 100 метров). Так что, в теории, не так всё плохо. А ведь есть ещё лазеры. Для перехвата.

Обсуждали тут аудит программного кода. Речь вот о чём: программное обеспечение, которое предназначено для решения каких-либо критичных задач, подвергают аудиту. Цели аудита: обнаружение возможных “закладок” и нехороших особенностей.

Для аудита можно использовать исходные коды. И их используют, потому что так удобнее. Есть разные автоматизированные инструменты и вообще – обкатанные подходы. Пример, который на слуху, аудит разработок Microsoft, для допуска к специальным компьютерам. Эта корпорация предоставляет исходники своих продуктов, на особых условиях.

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

Более того, известно, что вполне себе тщательно (но независимо) проверенный в “исходниках” компилятор, после применения к, опять же, проверенным исходным кодам, может дать на выходе (в исполняемом “бинарнике”) результат с неожиданными дырами и “закладками”. Добротный результат можно получить, если проверять совместно весь набор: и компилятор “в исходниках”, и “исходники” компилируемого продукта.

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

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

В конце мая Google, наконец-то, реализовал доступность поиска по HTTPS – https://www.google.com/. Правда, пока не все поисковые направления работают по защищённому протоколу, например, не поддерживает HTTPS поиск по изображениям. Да и вообще всё в статусе беты. Тем не менее, это важный шаг.

Так, у Google нашлось достаточно вычислительных мощностей, чтобы перевести на HTTPS один из самых своих массовых сервисов: нужно учитывать, что вычислительные затраты на работу по шифрованному каналу заметно больше, если сравнивать с простым HTTP. При работе с многими миллионами запросов – проблема с дополнительной нагрузкой встаёт в полный рост.

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

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

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

При этом криптография активно внедряется и на уровне DNS – это DNSSEC, – и на уровне IP (здесь планируется сертификация маршрутов и автономных систем, с подписыванием ЭЦП анонсов BGP – об этом, наверное, нужно отдельную записку написать). Новый Интернет должен сформироваться уже лет через пять. Помимо перехода на HTTPS, важным моментом будет проталкивание поддержки DNSSEC на клиентские машины.

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

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

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

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

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

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

Почему недостаточно хорошо работает этот “продвинутый” метод? Потому что отсутствует добротная аутентификация со схемой запрос-ответ. Не используется “обратная связь”, хотя она есть, как упомянуто в самом начале заметки.

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

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

Злоумышленник может организовать гипотетическую атаку типа “человек посередине”, пытаясь имитировать работу автомобильного блока в ответ на старт сеанса связи. Но так как, в отличие от GSM, здесь авторизация начинается только по нажатию кнопки владельцем автомобиля, успех – скорее призрачен. Хотя, есть варианты. Да и никто не гарантирует, что в конкретной реализации алгоритма не обнаружат дыр.

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

Итог: микроконтроллеры сейчас научились выпускать довольно мощные и очень компактные, с минимальным энергопотреблением. Микроконтроллеры при этом дешёвые. Алгоритмы защиты – известен. Вопрос такой: а защищены ли на практике все современные автосигнализации от перехвата команд?