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

Занимательная атака описана в работе Daniel Genkin, Adi Shamir и Eran Tromer – они раскрывают секретные ключи RSA (для конкретных программных реализаций алгоритма), анализируя утечку по акустическому каналу. То есть, прослушивая с некоторого расстояния (до нескольких метров) работающий компьютер, примерно за час восстанавливают побитно секретный ключ. Правда, для этого требуется, чтобы компьютер (ноутбук) расшифровывал выбранные атакующим шифротексты (стандартное направление атаки).

Нельзя сказать, чтобы связанные с работой электронного оборудования утечки по акустическим каналам являлись новинкой, но это конкретное применение к RSA выглядит весьма изящно. Отмечу, что помещения, где проводится компьютерная обработка секретной информации, стандартно защищаются и от акустических утечек. Конечно, это не отменяет того очевидного факта, что RSA постоянно используют без всякой подобной защиты.

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

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

Более того, особенность биткоинов в том, что они позволяют проводить, так сказать, обратную деанонимизацию. Blockchain не имеет срока давности и сохраняется в распределённой сети в течение всего срока её, сети, действия. Это означает, что если однажды удалось сопоставить конкретный кошелёк с конкретным интернет-пользователем, то можно извлечь полную информацию о всех его прошлых операциях, которые он, скажем, проводил несколько лет назад. А ввиду того, что blockchain публичен по определению, сделать это может всяк желающий, а не только сотрудник уполномоченных органов, имеющий соответствующий допуск, как в случае с классической платёжной системой или банком. Какая уж тут анонимность.

(Наверное, имеет смысл написать обзорную записку о том, как работают биткоины.)

Update (02.12.14): подробно про биткоины.

Сейчас, в связи с шумом вокруг перехвата трафика АНБ, наделали много “защищённых мессенджеров” (систем обмена короткими сообщениями) на “новых протоколах”, шифрующих всё и вся. Часто можно услышать, что конкретная система полностью защищена от перехвата “на уровне протокола”, потому что “всё шифруется на клиентском устройстве”. Речь, в общем-то, всегда идёт о том, обеспечивается ли совершенная защита канала “клиент-клиент” (отправитель-получатель). Читать и анализировать протоколы – занятие, требующее времени, доступное не всем пользователям. Между тем, существует весьма простой способ проверить, защищён ли, в действительности, данный мессенджер от перехвата сообщений третьей стороной: если есть некая “центральная” функция сброса/смены забытого пароля – значит мессенджер от потенциального перехвата заведомо не защищён.

Из Google сообщают об очередных недобросовестных SSL-сертификатах, выпущенных для гугловских доменов из-под промежуточного УЦ (который, в свою очередь, принадлежит некоему УЦ ANSSI). Сертификаты использовались в устройстве, перехватывающем HTTPS-трафик. Подробностей не сообщают.

Я раньше писал о том, что размещение в перехватывающем SSL-прокси сертификата промежуточного УЦ, выпущенного признаваемым браузерами удостоверяющим центром, – давно известная практика. Преимущество такой технологии в том, что перехват осуществляется прозрачно и стандартно настроенные браузеры не показывают предупреждений системы безопасности, поэтому не нужно менять параметры на клиентских машинах. Впрочем, в случае с браузером Chrome и сервисами Google, такой фокус не проходит: Chrome обнаруживает подмену, так как отпечатки верных ключей, а также другие криптографические параметры гугловских серверов, зашиты в его дистрибутив.

Несколько лет назад я писал о том, как может быть организована система, вычисляющая пользователей “анонимизированных” мобильных телефонов, а также обнаруживающая людей, которые передвигаются группой (по той или иной причине). По традиции – кто бы сомневался: NSA действует именно так. На сайте The Washington Post даже нарисовали неплохую инфографику, поясняющую технические детали. Соответствующая статья рассказывает о масштабах сбора данных, согласно очередным “документам от Сноудена”.

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

Есть такой небольшой проект – домен Nox.su, который я использовал для исследования и практической демонстрации технологии DNSSEC (это безопасное расширение DNS). Недавно, в конце ноября, исполнилось два года с момента внедрения DNSSEC в nox.su. (Я, как и прежде, полагаю, что это первый домен .su, подписанный DNSSEC.) Об очередной годовщине дал знать криптографический ключ KSK для зоны nox.su – он успел “протухнуть”. На смену ему уже заготовлен новый.

Нельзя сказать, что за пару лет DNSSEC “шагнула в массы”, а сейчас является штатным средством защиты в Рунете: в .ru, потенциально, подписано лишь что-то около двух сотен доменов (в статистике по ссылке ведётся учёт только DS-записей). Тем не менее, популярность DNSSEC набирает, но, конечно, слишком медленно.

(Отмечу, что я за это время подготовил ещё несколько ресурсов и публикаций, касающихся DNSSEC. Среди них, например: браузерный инструмент проверки поддержки DNSSEC; справочная страничка dnssec.pw и демонстратор DNSSEC + TLS 1d.pw.)

Популярная тема: давайте сделаем шифрование обязательным элементом HTTP. Речь, понятно, о новой версии протокола HTTP2 (2.0). Это такой способ борьбы с массовой “слежкой через Интернет”, которая сейчас регулярно фигурирует в газетных заголовках. Конечно, шифрование полезно. Но в случае с HTTP есть интересные моменты.

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

Что это означает? А вот что: за периметром, во внутренней сети, трафик всё равно будет нешифрованным. И тотальное введение шифрования HTTP всего лишь сузит круг тех организаций, которые смогут читать “шифрованный” трафик, резко подняв порог доступа. Да, не смогут работать провайдерские системы DPI, пытающиеся балансировать нагрузку и выявлять всякую вредоносную активность, а попутно – строить поведенческие профили пользователей. Но если для анализа трафика используется порт, установленный во внутренней сети крупного сервиса, проблем с анализом не будет. И, естественно, если сервис передаёт вам сеансовые ключи, то трафик можно расшифровывать самостоятельно, записывая его на любой доступной точке.

В Renesys нашли много подтверждений тому, что целевой перехват трафика в Интернете реализуется и путём подмены маршрутов через BGP. Странно, конечно, что они в заголовке называют такое явление “новой угрозой” (The New Threat) – подобные методы известны достаточно давно: например, я писал об одном из сценариев BGP-перехвата в начале 2010 года, это равно тот механизм, который пронаблюдали в Renesys. Но, похоже, сейчас к этой теме привлекут внимание.

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

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

Противодействуют перехвату маршрутов с помощью различных фильтров, вводимых в точках обмена трафиком. Это не слишком эффективный способ. Радикально решить проблему может глобальное введение особой системы электронных подписей анонсов маршрутов – инициатива называется RPKI, она более или менее активно развивается сейчас. Видимо, шумиха подстегнёт развитие.

(Кстати, а в материале Renesys, отчего-то, упоминаются белорусские сети, замеченные в описанной выше подмене маршрутов.)

В воскресенье – немного “рекурсивных” трактовок событий. История с “бэкдором NSA” в алгоритме генерации псевдослучайных чисел Dual_EC_DRBG, который был рекомендован к использованию NIST, снова всплыла пару месяцев назад, конечно, в связи с публикациями СМИ очередных данных из “документов Сноудена”. NIST рекомендацию отозвал. Крупные разработчики ПО и аппаратуры – от использования Dual_EC_DRBG открестились. Так поступили, например, в Cisco. Некоторые, фактически, повинились, среди них – RSA Security. Шуму, в общем, было немало.

Интересно, что больше всего эта история похожа на работу операции прикрытия, которую заготовили раньше. Дело в том, что о потенциальном бэкдоре в алгоритме Dual_EC_DRBG (полное название: Dual Elliptic Curve Deterministic Random Bit Generator) было хорошо известно давно, примерно, с 2007 года (вот в этой заметке Шнайера есть ссылки на публикации).

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

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

[Пара технических моментов: 1) алгоритм Dual_EC_DRBG можно использовать с собственными параметрами, отличными от рекомендованных, это закрывает упомянутый бэкдор; 2) из идейных соображений, этот алгоритм выглядит весьма интересным, так как основан на хорошо известной теоретико-числовой проблеме, да ещё и использует эллиптические кривые.]

Занимательно видеть, что, например, на сайтах российских автодилеров, где они стараются продавать автомобили, используется “Яндекс.Метрика”. Согласно пользовательскому соглашению, “Яндекс” может использовать данные, собираемые “Метрикой”, в своих целях. Соответственно, почему бы ему не использовать эти данные для повышения качества “таргетирования” рекламы в “Яндекс.Директе”? А в “Директе”, тем посетителям, которые ушли с сайта автодилера и теперь путешествуют по другим, даже не автомобильным сайтам, показывается реклама конкурентов. Лучше всего, если объявления содержат те же модели, которыми конкретный посетитель интересовался.

Риск, в общем-то, хорошо известный. Думаю, что и Google, и другие системы массовой статистики, могут поступать так же. Тем не менее, коды на “продающие сайты” ставят стандартно. Очень грубая оценка даст нам примерно 15-20% потерь клиентов в направлении конкурентов через данную схему. Забавно, что, в таком случае, на “закрытом” рынке, некий автодилер мог бы заработать при помощи сайта дополнительно эти самые 10-15%, всего лишь убрав со страниц внешние “шпионские счётчики”. Ну, окей, понятно, что нужно нормировать расчёт по выручке и так далее, что нужно ещё исследовать, уводит ли “Директ” посетителей таким образом, но сумма-то может выйти весьма заметной, не факт, что использование той же “Метрики” позволяет поднять продажи на сравнимую величину. А код – всё равно на сайтах.

Пару месяцев назад, в заметке о перехвате HTTPS, я писал:

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

Кто бы сомневался: Wired сообщает, что NSA буквально так и делает с трафиком Google.