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

На фото – штатовский истребитель F-35C, во время испытаний:

(Фото: Lockheed Martin.)

Это посадка на авианосец, с аэрофинишёром. Хорошо виден тормозной гак, современной конструкции (с гаком, как известно, были проблемы: его пришлось исправлять).

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

Неясно, как так могло получиться, но атаковавшим ICANN удалось получить администраторский доступ к некоторым сервисам. Это удивительно потому, что авторизация в системах подобного уровня должна бы быть защищена от простого перехвата почты сотрудников. Хотя, конечно, никто не застрахован от ошибок. В итоге, из сервиса Centralized Zone Data System – это полезный инструмент, позволяющий получать файлы зон доменов New gTLD, – утекли контактные данные пользователей, а также пароли, но в хэшированном виде.

(Кстати, самое громкое дело было бы, если бы у ICANN, а точнее – у IANA и VeriSign, утянули бы секретный корневой ключ KSK от DNSSEC. Понятно, что, в текущей ситуации с поддержкой DNSSEC, катастрофы бы не случилось, но случай был бы весьма показательный. Дело в том, что до сих пор не разработана процедура ротации корневого ключа KSK, так что DNSSEC, разве что, оставалось бы просто выключить.)

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

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

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

Одна из хитростей состоит в том, что если в родительской (делегирующей) доменной зоне присутствует DS-запись для дочерней (делегируемой) зоны, и родительская зона безопасна (то есть, подписана DNSSEC), то это означает, что дочерняя зона тоже должна быть безопасной. То есть, валидирующий резолвер ожидает, что дочерняя зона содержит, во-первых, подходящие к DS ключи, нужные для проверки подписей, во-вторых – сами подписи на ответах об адресации внутри зоны. Соответственно, если DS-запись присутствует, а дочерняя зона не подписана, валидирующий резолвер будет возвращать сообщение об ошибке. Это совершенно правильное поведение, потому что иначе смысла в DNSSEC нет: подделать ответы без подписей не составляет труда; если резолвер не имеет возможности отличить подписанную зону от неподписанной по наличию DS-записи в доверенной (безопасной) зоне, то подписи можно вообще не проверять.

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

Если для дочерней (делегируемой) зоны DS-записи нет, ответ авторитативного сервера содержит подписанное подтверждение тому, что эта запись действительно отсутствует. Это позволяет валидирующему резолверу убедиться в том, что дочерняя зона не является безопасной и записи из неё можно использовать, но только как неаутентифицированные (если такое допускается).

Google Public DNS для зон, имеющих DS-запись, но не подписанных, возвращает ошибку (SERVFAIL), вне зависимости от того, какова природа этих DS-записей. Другие валидирующие резолверы ведут себя иначе. Например BIND, обнаружив неизвестный алгоритм генерации DS, считает, что DS-записи в родительской зоне вовсе нет (что не совсем корректно, но с практической точки зрения оправдано, и, конечно, соответствует рекомендациям RFC). Пример такого поведения можно наблюдать для зоны dotsu.su – здесь в .su специально указаны DS-записи с неизвестным алгоритмом (9).

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

(Исходное фото: Lockheed Martin.)

На страницах dxdt.ru немало заметок про РЛС. Правда, сейчас новые заметки на эту тему появляются всё реже. Нужно будет попытаться исправить ситуацию. А пока что – небольшая подборка из опубликованного:

• Интеллектуальные помехи комплексам ПВО;
• “Малозаметные” радары – преимущество приёмника;
• Сигнатуры, ПВО и утечки информации по побочным каналам;
• Радиолокация и уязвимости DNS;
• Бистатическая радиолокация против астероидов.

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

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

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

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

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

В текущей конфигурации полезный сервис Qualys SSL Labs присваивает dxdt.ru высшую оценку A (Grade A – update: уже Grade A+, так как добавлен заголовок HSTS):

То есть, TLS на сервере настроен современным образом. Например, для всех распространённых браузеров поддерживается “прогрессивная секретность“. Этот момент, вкупе с настройкой наборов шифров на сервере, приводит к тому, что сайт недоступен для браузеров IE7 и IE8, работающих под Windows XP – они не поддерживают нужных наборов шифров и, соответственно, не смогут договориться с сервером. Но это настолько устаревшая конфигурация, что за неё можно не беспокоиться. (Под Windows XP, если вдруг эта устаревшая система оказалась на персональном компьютере в 2014 году, обычно используют другие браузеры, а с ними проблем быть не должно.)

Update: добавил заголовок HSTS (HTTP Strict Transport Security – предписывает браузерам использовать только HTTPS для данного сайта), теперь оценка A+.

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

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

Предположим, подземный робот самостоятельно проник в нужный район и должен там остаться на длительное время. Естественно, под землёй. Естественно, скрытно, чтобы не обнаружили и не извлекли на поверхность. После наступления условленного часа или получения специального сигнала – робот активируется и, скажем, наконец-то выполняет свою главную задачу. Сколько лет такой робот может спать?

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

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

Куда больше проблем доставят механические части. Ведь, по условиям задачи, робот должен самостоятельно проникнуть в район ожидания. Соответственно, ему нужно будет не менее самостоятельно законсервировать свои движители и двигатели. Это не так просто сделать для устройств, расположенных снаружи основного корпуса. Детали могут оказаться в воде, либо, того хуже, в контакте с какой-нибудь агрессивной породой, способной за всего-то пять-семь лет наглухо заблокировать сочленения и приводы. И тут выход только один: рассчитывая на десятилетия ожидания, проектировать робота так, чтобы выполнение главной задачи не требовало начала движения.

Но таких задач, к сожалению, не так много.