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

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

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

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

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

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

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

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

(Меня попросили описать в более или менее подробных деталях, какие ключи и как сейчас используются в 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) из корневой зоны.

Схема организации подписей и зон DNSSEC для dxdt.ru:

Картинка сгенерирована при помощи полезного сервиса DNSViz.

Кстати, довольно давно я завёл специально испорченную, в смысле DNSSEC, зону – dotsu.su. С её помощью удобно тестировать различные анализаторы DNSSEC. Текущая версия DNSViz выдаёт вполне корректную картинку для dotsu.su (раньше были сбои).

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

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

Небольшая подборка записок по теме TLS/SSL (и близким к ней), появлявшихся на dxdt.ru:

• HTTPS и “открытые веб-страницы”;
• Heartbleed, OpenSSL: работа над ошибками;
• Система прослушивания TLS/SSL от NSA. Часть 1;
• Система прослушивания TLS/SSL от NSA. Часть 2;
• Популярно о перехвате HTTPS;
• Цифровые нотариаты и административное значение TLS/SSL;
• Политика браузеров и история с SSL/TLS;
• Технология DANE: отличия от работы УЦ;
• Новинки безопасности, практикум: настройка DANE и dane.nox.su.

На фото ниже – момент транспортировки аппарата NASA Orion, незадолго до установки его на ракету-носитель. Штанга, направленная вверх, – это часть системы аварийного спасения аппарата (Launch Abort System), предназначенной для его экстренной эвакуации со стартовой площадки в случае возникновения проблем с ракетой-носителем.

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

(Источник фотографии – Universe Today.)

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

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

Бэкдор должен обладать свойством “отрицаемости”: то есть, в случае его обнаружения, разработчики должны иметь возможность аргументированно “доказать”, что никакого бэкдора и нет, а это всё “непреднамеренная ошибка”, “особенность протокола” или ещё что-то подобное.

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

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

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

Конечно, большинство практических бэкдоров лишены некоторых из перечисленных выше свойств. Но где-то могут быть и идеальные представители. Просто их не так легко обнаружить.

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

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