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

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

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

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

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

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

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

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

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

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

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

Собственно, добавил в зону dxdt.ru TLSA-запись, содержание которой соответствует отпечатку (SHA-256) серверного сертификата – это означает, что для dxdt.ru теперь заработала поддержка DANE (технологии, позволяющей с помощью DNSSEC защитить домен от подмены SSL-сертификата). Вот бы ещё DANE, наконец-то, стали поддерживать браузеры.

После того, как я перевёл dxdt.ru на HTTPS, можно сказать, что на сайте используются обе современные ключевые интернетовские технологии обеспечения безопасности. Вторая – это DNSSEC: домен dxdt.ru подписан с декабря 2012 года (пора, наверное, поменять ключи). Для полноты картины осталось добавить запись DANE TLSA, как это сделано на тестовом сервере 1d.pw.

(Кстати, предлагали сразу добавить SPDY – это разработанный с подачи и при ключевом участии Google перспективный протокол, оптимизирующий загрузку веб-страниц через TLS-соединение. На мой взгляд, хоть SPDY и поддерживают современные браузеры, но это всё ещё экзотика, не хуже DANE или даже DNSSEC, так что можно подождать HTTP/2.)

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

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

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

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

Занятно, что 64-битная версия Regin не использует модулей, устанавливаемых как системные драйверы – в 32-битной версии такой метод используется. В Symantec объясняют это тем, что для 64-битной ОС Windows драйверы, подключаемые в ядро, должны быть подписаны электронной подписью. Выходит, разработчики продукта не смогли получить нужных ключей. Или – не захотели вводить в свой продукт единую точку блокировки.

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

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

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

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

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

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

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