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

Интересное видео с роботом Atlas от Boston Dynamics: андроид передвигается по снегу, открывает двери, перемещает коробки, несмотря на помехи, создаваемые человеком с клюшкой.

(Видео.)

Шумная история: Apple отказывается помочь ФБР подобрать пароль разблокировки для конкретного аппарата iPhone. В предписании судьи сказано, что требуется как-то модифицировать программную (а возможно – аппаратную, но упор сделан на программную) часть конкретного устройства, чтобы можно было простым перебором раскрыть пароль (вероятно, речь об обычном цифровом пароле, который пользователи устанавливают на аппарат). В штатной конфигурации iPhone может удалить пользовательские данные (точнее: удалить ключ и сделать остальные данные недоступными) после нескольких неверных попыток ввода пароля.

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

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

Типичный способ сравнения возможностей бортовых РЛС истребителей – сопоставление по таким характеристикам, как дальность обнаружения цели и количество одновременно обстреливаемых или сопровождаемых целей. Результаты сравнения переносятся на сам истребитель. (Конечно, речь тут идёт не только об РЛС, а о системе управления вооружением в целом.) Оба параметра (и “дальность”, и “число целей”) – довольно размыты и лукавы.

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

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

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

Превосходство конкретной РЛС в числе одновременно обстреливаемых целей – очень условная характеристика. В том числе, и по соображениям эффективности. Пусть условный F-22 может взять с собой шесть ракет “воздух-воздух” большой дальности. Скорее всего, для поражения одной цели на большой дальности ему потребуется не менее двух ракет. Почему? Реальной статистики нет, но мало кто сомневается, что едва ли какая-нибудь ракета имеет вероятность поражения хотя бы близкую к 100%, потому что даже по мишеням такого не наблюдается. Тем более, если речь идёт о больших дальностях: чем дальше, тем вероятность меньше. Поэтому, примем, что вероятность 0.6 (это очень неплохо). То есть, чтобы иметь заметные шансы уничтожения цели – хотя бы две ракеты нужно в её направлении отстрелить (кстати, вероятность поражения при обстреле двумя ракетами, в наилучшем случае, составит 0.84 – это если события независимы, что, вообще говоря, не так). Шесть ракет – три цели. Но F-22 теперь остался безоружным (пушку – оставим за скобками: как вариант неподходящий, особенно для данного самолёта). Таким образом, смысл режима обстрела десятка целей возникает только в случае, если действует группа самолётов: один видит – другие обстреливают общую цель (оставаясь в пассивном режиме). В этом режиме нет ничего концептуально нового – реализовано в советской системе “Заслон” (МиГ-31), ещё в 80-е годы прошлого века. Соответственно в такой тактике, кроме характеристик по количеству целей конкретной РЛС, важно как применяется группа истребителей.

Что касается второго показателя – дальности обнаружения. Благодаря тому, что сейчас доступны большие вычислительные мощности, можно на одной и той же РЛС средней мощности сделать дальность и 400, и 1400 км. Дело за цифровой обработкой сигнала. Пусть, опять же, для условного истребителя заявлено 500 км в качестве характеристики “дальность обнаружения цели”. Что такое 500 км? Это около половины боевого радиуса (по типичным современным типам самолётов). Требуется ли истребителю видеть цели, расположенные так далеко (относительно лётных способностей)? Ведь существуют системы AWACS, которые всё равно видят дальше. Более того, засветив цель с 500 км – истребитель её скорее всего спугнёт, а догнать не сможет, потому что боевой радиус не позволяет.

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

(Чтобы самолёт мог не обнаруживать себя в процессе обнаружения целей – требуется использовать сложный для детектирования внешним наблюдателем зондирующий сигнал. Здесь есть отдельная наука, направление называется LPI – Low Probability of Intercept. Однако реализация LPI требует больше времени на обработку сигнала, при прочих равных, а также снижает полезную мощность, которую можно использовать для измерения характеристик цели.)

Другой важный вопрос – ракеты сверхбольшой дальности. Для системы управления вооружением, обнаруживающей цели на (условной) дальности 500 км, требуются соответствующие ракеты. Идея, что дальновидящий истребитель, оставаясь незамеченным, поражает воздушную цель с огромной дистанции – очень старая. Но с подобными ракетами, подходящими для истребителя, – до сих пор проблемы (хотя некоторые образцы создавались). Во-первых, такая ракета обязательно будет большой, во всех измерениях, читай: длинной и тяжёлой. Если платформой служит малозаметный истребитель с размещением вооружения во внутреннем отсеке, то этот отсек должен быть огромным. У F-22, например, здесь есть проблема. Во-вторых, 500 км со средней скоростью M=3 (очень быстро) лететь более восьми минут: многие цели успеют развернуться и уйти за боевой радиус. А истребитель останется без ракеты (которую, правда, можно перенацелить).

Неверно считать, что число обстреливаемых одновременно целей или дальность обнаружения – неважные характеристики. Однако современные бортовые РЛС тут в любом случае находятся близко к пределу разумной эффективности, поэтому сравнивать показатели нужно с осторожностью.

В рамках проекта КЦ и ТЦИ “Домены Россиии” (statdom.ru) – мы добавили статистику TLS по российским зонам. (Официальная новость.) Приведено несколько основных отчётов, позволяющих понять, как развивается HTTPS: общая статистика, а также данные по алгоритмам и ключам. Данные собираются именно для HTTPS – то есть, это 443/tcp. Приведены результаты, начиная с июля прошлого года (2015). У меня на dxdt.ru есть некоторые данные по TLS/SSL в Рунете за 2011 год, это почти пять лет назад (да и методика сбора там другая). За это время, например, число самоподписанных сертификатов сократилось более чем в два раза: 52173 (тогда) против 23931 (сейчас). А ECDSA тогда просто не было.

Если посмотреть в выборку по корректным HTTPS-узлам (это узлы, вернувшие валидный сертификат, совпавший по имени), то видно, как стремительно растёт проникновение HTTPS: за семь месяцев в зоне .RU число HTTPS-узлов выросло почти, примерно, на 21 тыс. с 34205 до 55781. Из новинок: Let’s Encrypt – добавляет почти по тысяче в месяц, это видно в отчёте по Top 10 удостоверяющих центров.

Методика кратко описана на соответствующей странице statdom.ru.

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

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

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

Кстати, что касается Windows XP, которая, якобы, “управляет британскими подводными лодками с ядерным оружием”: возможно, эта система и работает на каких-то компьютерах, находящихся на борту, но вряд ли чем-то на лодке управляет. Дело в том, что Windows XP – не является системой реального времени: с ней всегда были проблемы при попытках управления тем или иным оборудованием. Соответственно, встроенные системы используют другие ОС, обычно, это UNIX-подобные (из-за POSIX, но это детали) ОС реального времени.

Вообще, если речь идёт о системах из 90-х годов прошлого века (это означает, что разрабатывались-то они в конце 80-х), можно было бы поверить, что на борту есть управляющие вычислительные машины, работающие под MS-DOS. Это маловероятно, но такое можно представить, потому что под MS-DOS приложения реального времени работают хорошо, мне, в 90-х, приходилось такие видеть лично. Но XP – это что-то журналисты напутали (особенно, если учитывать, что система выпущена в 2001).

На фотографии из коллекции Библиотеки Конгресса – кормовой отсек подводной лодки, которая обозначена как германская. Как пишут, фотография сделана около 1915 года. Видны двигатели, гребные валы (два) и прочее оборудование.

(Та же картинка – в более высоком разрешении.)

Появился новый робот, быстро собирающий кубик Рубика – он справляется примерно за секунду (по ссылке с картинки – видео на Youtube.com):

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

Если я не путаю, то сейчас известно, что из любой конфигурации кубик (3×3) собирается не более, чем за 26 ходов, если ходом называется поворот грани на 90 градусов. При этом большинство конфигураций лежат на два-три хода ближе к собранному кубику. Для оценки точное число ходов не так важно. Примем, что типичная сложная конфигурация – 25 ходов. То есть, если поворачивать грань за 10 миллисекунд на 90 градусов, то с преобразованиями конфигурации можно уложиться в 250 мс (плюс затраты на “переключение” граней – но не будем их учитывать). 10 мс – это 9000 градусов или 25 оборотов в секунду. Сама по себе, скорость вращения не очень большая, добротный кубик её наверняка выдержит. Заметные потери времени при “миллисекундном разрешении” будут связаны с разгоном грани – отсюда и идеи с механическим зацеплением. Для немодифицированного кубика быстрый разгон при начале вращения грани составит серьёзную техническую проблему.

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

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

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

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

Основа практической работоспособности криптовалюты Биткоин – вычислительная мощность сети узлов-майнеров, которые вычисляют заголовки блоков. Если посмотреть на статистику по текущему распределению (предполагаемому) мощности сети на сайте blockchain.info, то нетрудно подсчитать, что около 60% этой мощности контролируют китайские пулы (AntPool, F2Pool и BTCC Pool). (Пулы – это объединения майнеров, действующих согласованно, и делящих полученную от майнинга биткоин-прибыль.)

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

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