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

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

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



Comments Off on Помехи, помехопостановщики и рекурсия

TLS на dxdt.ru

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

dxdt.ru TLS

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

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



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

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

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



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

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

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

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

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

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



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

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

Конечно, продвинутые спецслужбы имеют доступ (легальный и не очень легальный) к служебному трафику операторов связи, опять же, по всему миру. Такой доступ позволяет получать информацию о регистрации телефонов в сети и другие, не менее полезные, сведения. Например, у АНБ, вероятно, есть весьма полные базы данных по всем мировым операторам связи – их оборудованию, адресному пространству, топологии сети и так далее (пример документа по теме – PDF, 27 MB).

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

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

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



Comments Off on Слежение за смартфонами GSM по всему миру

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

Во-вторых, нагрузка на сервер выросла, Apache ест несколько больше памяти, но виртуальная машина из Amazon EC2, как и прежде, вполне себе справляется. То есть, тут проблем нет. Однако время загрузки веб-страниц увеличилось, хотя и осталось в разумных пределах (менее секунды). Виной здесь не столько переход на HTTPS, сколько то, что в результате этого перехода поломался полезный плагин для WordPress: W3 Total Cache. Этот плагин заметно сокращал время генерации страниц CMS, за счёт кэширования (в Memcached). После замены протокола, кэш на сайте перестал автоматически сбрасываться при добавлении новых заметок, приходилось передёргивать его руками. В деталях я пока с этим явлением не разбирался, а просто удалил плагин, что, собственно, и привело к замедлению работы сайта.

В-третьих, с SSL-сертификатом COMODO, выпущенным от корня AddTrust CA через пару промежуточных сертификатов, возникли некоторые проблемы. По неясной мне причине, браузер Safari под Mac OS на некоторых “макбуках” данному сертификату доверять отказывается: в списке доверенных корней этой линейки браузеров нет подходящего корня (AddTrust или чего-нибудь иного, но с тем же ключом, да). Я уверен, что на сервере у меня всё правильно настроено: отдаются и серверный, и необходимые промежуточные сертификаты. Что происходит с некоторыми образцами программно-аппаратных продуктов компании Apple – ещё предстоит разобраться (у меня нет “макбука” – значит, для тестов мне нужно его у кого-то отобрать, да ещё и в подходящей комплектации). Замену SSL-сертификата, тем не менее, пока не планирую.



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

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



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

Аппарат NASA Orion успешно завершил испытательный полёт. Сложно не согласиться, что это весьма заметный шаг на пути создания новых пилотируемых систем для освоения космоса, хотя, конечно, насчёт “пути на Марс” NASA немного преувеличивает.



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

Chains(Меня попросили описать в более или менее подробных деталях, какие ключи и как сейчас используются в DNSSEC. Думаю, что описание заслуживает публикации на dxdt.ru – потому что до сих пор нередко путают ключи, зоны, цепочки делегирования и прочие важные моменты.)

Посмотрим на то, как используются ключи DNSSEC, взяв для примера зону .org. Предположим, что мы справшиваем SOA-запись для .org у корневого сервера. Тогда, вместе с адресами NS-ов домена org, если последний делегирован безопасно, то есть, с DNSSEC, мы получим от корневого сервера DS-запись (или несколько – сейчас, например, их для .org две) и RRSIG-запись для DS (важно – именно для DS). То есть, главная интересующая нас подпись содержится в корне, это RRSIG over DS (RRSIG от DS). Напомню, что DS-запись содержит значение хэш-функции ключа, относящегося к делегируемой зоне (то есть, в случае нашего примера, к .org). Подпись RRSIG сгенерирована при помощи корневого ZSK (Zone Signing Key, ключа подписи зоны), который опубликован в корневой зоне, и его нужно будет оттуда получить, чтобы проверить подпись на DS. (Ключ также может уже находиться в кэше резолвера, тогда запрашивать его у корневых серверов не нужно.)

В дальнейшем, информацию, полученную с сервера имён (NS) домена org, мы проверяем ключами, которые опубликованы в этой же зоне (в .org). То есть, RRSIG-и из данной зоны проверяются ключами, которые в той же зоне и расположены. Для связывания ключей из разных зон в цепочку доверия служат DS-записи, которые также подписываются.

Посмотрим чуть ближе на реальное устройство DNSSEC для .org, как всё выглядит сейчас:

1.

В корне (в корневой зоне) мы видим два ключа (я буду их обозначать реальными идентификаторами, которые я взял из DNS) – 22603 (ZSK) и 19036 (KSK – кстати, не менялся с 2010 года, потому что забыли придумать, как его поменять). Для ключа 22603 в корневой зоне есть RRSIG, сгенерированная от ключа 19036. 19036 – это и есть тот самый главный, корневой, рутовый KSK, открытая часть которого изначально находится у нас в резолвере (пусть ключ и опубликован в DNS, но в резолвер он должен попасть каким-нибудь другим доверенным путём, не черезе DNS). После того, как мы проверили RRSIG от ключа 22603 этой открытой частью ключа KSK (19036) и всё сошлось, мы добавляем ключ 22603 в доверенные ключи. И можем пойти дальше.

2.

В корне же мы видим DS-записи для ORG, а также RRSIG для них. Подпись (RRSIG
over DS) сделана от ключа 22603 (то есть, от ZSK, см. выше). Ключ 22603 мы только
что добавили в доверенные. Проверяем подпись на DS-записи, если всё сошлось, то можем пойти дальше, записав себе значение DS.

3.

На серверах, поддерживающих .org, мы видим четыре ключа – 9795, 21366 (эти два – KSK)
и 60764, 11112 (а эти два – ZSK; KSK от ZSK отличаются значением одного бита в поле типа ключа). Хэш от ключа 21366 соответствует значению DS-записи, опубликованной в корне (см. выше). Эту запись мы только что (ну или некоторое время назад, см. TTL) получили от корневого сервера, вместе с подписью, которую проверили – значит, DS-у доверяем.

4.

На серверах .org мы также видим записи (их сейчас три) RRSIG для набора DNSKEY. Эти три записи RRSIG сгенерированы от трёх ключей: 9795, 21366 и 11112 – обратите внимание, каждая из этих RRSIG подписывает все ключи, опубликованные в зоне (ключи публикуются в записях DNSKEY). То есть, у нас четыре ключа подписаны при помощи трёх других. Один из этих подписывающих ключей – 21366 – соответствует DS-записи, полученной из корня, поэтому мы можем добавить его в список доверенных ключей. Теперь записям, подписанным этим ключом, мы тоже будем доверять. После того, как мы убедились, что подпись от ключа 21366, сделанная для RRSIG DNSKEY в зоне
.org, – валидная, мы добавляем и три других ключа (9795, 11112, 60764) в список доверенных. Почему? Потому что RRSIG over DNSKEY удостоверяет и их тоже – она для всех ключей зоны общая.

5.

Итак, мы решили получить SOA-запись (это главная запись в любой DNS-зоне) от .org и проверить её. Нет ничего проще: получаем SOA, вместе с ней приходит RRSIG, сгенерированная от ключа 11112, этот ключ есть у нас в списке доверенных, поэтому проверяем подпись – если сходится, то верим данным из SOA-записи. (Аналогично – для А-записей и для прочих.)

Обратите внимание, что мы не проверяли подписи на адресах NS-ов (серверов имён .org) – этого и не нужно делать, если только мы не хотим проверить именно значения NS-ов. Хитрость в том, что в DNSSEC не имеет значения, откуда были получены подписанные данные – с легитимных серверов или ещё откуда-нибудь: главное, чтобы подписи сходились.

Резюме: информацию, получаемую с серверов .org, мы проверяем ключами, полученными с тех же серверов, а вот убедиться, что это правильные ключи, нам позволяет подпись (RRSIG over DS) из корневой зоны.



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