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

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

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

Итак, для перечисления интернет-пользователей всякой популярной системы достаточно 32 бит или четырёх байтов (2^32 это примерно 4,2 млрд), поэтому запись идентификаторов для контактов заданного пользователя потребует 4*10=40 байтов за сутки. Добавляем сюда отпечатки времени – 3 байта на запись (с точностью до секунд в сутках + служебные биты). Получаем: 40+3*10=70 байтов за сутки. Очень мало. (Можно легко засунуть сюда и тип используемых сервисов, кстати.)

Рассмотрим другое, более технологичное, представление, где контакт – это пара идентификаторов и метка времени (ID1,ID2,T): 4+4+3=11 байтов на запись, а записи хранятся в единой БД, общим потоком. Если посмотреть на такую структуру данных, взятую “по модулю” одного пользователя, то получим оценку в 110 байтов в сутки на пользователя (естественно, тут есть простор для оптимизации). То есть, за 180 дней (примерно шесть месяцев): 180*110=19800 – около 20 килобайт данных за сутки на каждого пользователя. Для десяти миллионов – всего-то 200 гигабайт (без оптимизации кодирования, заметьте).

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

Другое дело, если требуется хранить подробный лог, в котором, например, отражено, как именно взаимодействовали пользователи, куда каждый из них ходил, сколько сообщений отправил, что нажимал, сколько времени провёл за тем или иным занаятием. В таком случае необходимый объём данных легко вырастет на два порядка. А ведь занятно, что и 20 терабайт (200Gb*100) – тоже не выглядят пугающе.

На сайте Ruward.ru публикуют некое исследование безопасности CMS, сравнивают коробочные (коммерческие) CMS и бесплатные CMS. Методика не ясна, но это другой разговор (с методиками вообще проблема в исследованиях, как известно).

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

Проиллюстрирую ситуацию сугубо практическим примером, основанным на наблюдениях за взломом сайтов на хостингах. Возможен тиражный взлом – это когда одна шаблонная уязвимость используется для того, чтобы автоматом заразить кучу ресурсов. Применительно к CMS, здесь видна следующая тенденция. Если у атакующего есть уязвимость, позволяющая ломать WordPress, то он может рассчитывать на заражение автоматом миллионов сайтов. Уязвимость коммерческой CMS, используемой на пяти тысячах сайтов, позволяет только эти пять тысяч и заразить. Думаю, понятно, какая уязвимость привлекательнее для массового взлома.

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

Вот.

Используя сервис RIPE NCC Atlas, я провёл пару простых измерений доступности сайта зимней Олимпиады www.sochi2014.com из разных регионов мира. Методика несложная: узлы сети Atlas “пингуют” (ICMP) хост, доступный под адресом www.sochi2014.com. Различие между измерениями в том, что в первом случае IP-адрес при помощи запроса в DNS определяет управляющий сервер (который раздаёт задания), а во втором – опрос DNS происходит на самих тестирующих узлах. Поэтому в результатах можно хорошо видеть, как работает балансировка, использующая DNS, в CDN Akamai.

Здесь, на картинке выше, определение имени проводил сервер, находящийся в Европе (вероятно, в Амстердаме), поэтому был получен IP-адрес для европейских пользователей, соответственно, для Штатов наблюдается большое время “отклика” (красные отметки). Типичные пользователи так с сервисом не работают, в Штатах должны использоваться местные DNS-резолверы.

На этой картинке – результаты второго измерения, метод скорректирован: определение IP-адреса для www.sochi2014.com проводится на тестирующем узле. Теперь всё окей: время отклика стабильно минимальное, в том числе, в Штатах. Это показывает, что работает хорошо распредлённая сеть серверов.

Отмечу, что для тестируемого имени используется большое количество IP-адресов, то есть, в ответ на запрос в DNS их возвращается несколько – “пинговался” же только один адрес из полученного списка.

Другой момент. Балансировка при помощи DNS имеет следующую особенность: вероятное местоположение пользователя, фактически, определяется про адресу DNS-резолвера, который его обслуживает. Так, запросы в DNS из, например, дата-центра в Дублине – возвращают для www.sochi2014.com одни адреса; выполнив запрос из московского дата-центра – получаем другие; а в случае использования Google Public DNS из Москвы – третьи. (Понятно, что опрос Google Public DNS из Штатов – даёт ещё один вариант.) Таким образом, если пользователь находится в Твери, но использует европейский DNS-резолвер, его браузер будет соединяться с европейскими серверами Akamai. Впрочем, в современном Интернете это чрезвычайно редкая конфигурация, так что её можно не принимать в расчёт.

(На картинках есть серые метки – это узлы Atlas, для которых запрос ICMP Echo в сторону олимпийского сайта не сработал. Такая ситуация вполне нормальна, и не означает, что недоступен сайт: “пинги” могут не ходить по сети, где установлен измеряющий узел, по самым разным причинам.)

По статистике сайта Blockchain.info, крупнейший пул GHash.IO приближается к 40% мощности всей сети Биткоин. Пул – это объединение узлов, занимающихся “майнингом” (добычей) биткоинов, то есть, обеспечивающих проведение транзакций. Захват большей части вычислительной мощности позволяет контролировать Сеть, так устроен протокол (подробнее о том, что и как – в отдельной заметке о биткоинах).

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

Так что, вероятно, близок очередной кризис биткоинов, а он будет сопровождаться шумихой в прессе, что добавит интереса теме. Посмотрим.

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

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

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

На сайте Der Spiegel опубликовано несколько материалов о специальном направлении внутри АНБ, которое занимается решением задач “целевого проникновения” в различные информационные системы (TAO – Tailored Access Operations). Вообще, речь там идёт о технических средствах разного назначения и различной степени специализации: упоминаются и устройства, предназначенные для дистанционного съёма информации через электромагнитные утечки, и специальные базовые станции GSM, для перехвата телефонных переговоров, и замаскированные анализаторы радиоэфира, и много всего другого. Есть и чисто программные средства (“трояны”).

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

Каких-то удивительных устройств или революционных решений, о которых ничего не было слышно ранее, в материалах Der Spiegel нет. Но подборка весьма занятная, так или иначе. Особенно интересно внимание, которое уделяется технике преодоления периметра в случае физически изолированных компьютерных систем (в англоязычной литературе – air gap; буквально: “воздушный зазор”). В качестве решения предлагаются аппаратные закладки, формирующие радиоканал, по которому происходит утечка информации: то есть, “неподключенный к Интернету” отдельный компьютер – оказывается к этому Интернету подключен против воли владельца, через соседний такой же физический сервер, у которого канал в глобальную сеть имеется. Для этого оба сервера должны быть оснащены специальными “радиозакладками” от АНБ.

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

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

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

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

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

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

Возможно, такие приложения уже где-то есть.

Эта заметка – популярный обзор того, как работает сеть Биткоин и соответствующая ей валюта. Основные темы: логика протокола, blockchain, некоторые расхожие мифы, связанные с биткоинами, “майнинг” и перспективы системы.

Читать полностью

Одной из основных особенностей протокола сети Биткоин является то, что транзакции и всю сеть контролирует тот, кто контролирует большую часть вычислительной мощности – грубо говоря, работает “правило 51%”. Попробуем прикинуть, сколько стоит захват сети Биткоин.

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

Заявленная мощность сети (blockchain.info/stats) на данный момент – 9333937,66 GH/s, пусть будет чуть больше – 9500000 гигахэшей в секунду. Есть специализированные устройства, позволяющие вычислять биткоин-хэши очень быстро, это так называемые “майнеры” (от англ. mining – добыча; такое название дано потому, что “майнеры” позволяют “добывать” и вводить в оборот новые биткоины). Так вот, если верить сообщениям производителей этих устройств, то стоимость “майнера”, имеющего мощность около 3 терахэшей (3000 гигахэшей) в секунду – от 8 до 12 тыс. долларов США (с доставкой, заметьте). Мы будем покупать много, и у нас, допустим, есть грузовик, поэтому пусть – 8 тыс. за три терахэша в секунду. Нам нужно чуть более половины мощности всей сети, то есть примерно столько же, сколько есть сейчас.

Итак, считаем: 9500000/3000 * 8000 = 25,3 млн долларов США (примерно). Наши узлы, захватывающие сеть, должны обмениваться информацией с другими участниками, поэтому для размещения оборудования потребуется место в дата-центре, каналы связи, услуги монтажников и бригады инженеров. Увеличим затраты примерно в два раза. Итого: 50 млн долларов и – сеть под контролем. Сумма немалая, но, например, в бюджете АНБ она наверняка могла бы просто затеряться среди “прочих расходов”.

Update (22/12/13): мне подсказывают, что есть ещё пара показательных моментов, касающихся этой темы. Во-первых, вполне вероятно, что АНБ могут быть известны некоторые оптимизации для SHA-256, позволяющие, для известных типов входных данных, вычислять эту функцию быстрее в несколько раз (это как раз случай с биткоинами). Если это так, то вычислительных мощностей потребуется меньше, но аппаратуру придётся конструировать свою: доступная на открытом рынке не учитывает секретных оптимизаций. Во-вторых, только за внедрение нужного алгоритма генерации псевдослучайных чисел АНБ заплатило $10 млн компании RSA. В общем, это показывает, сколько может стоить сеть Биткоин, выступающая в качестве платёжной системы.

(Продолжаем криптографическую серию заметок.) Оказывается, в Firefox версии 26 включили поддержку OCSP staplig. Что это такое? OCSP (Online Certificate Status Protocol) – это протокол, позволяющий клиенту (браузеру) в режиме онлайн проверить не был ли представленный сервером SSL-сертификат отозван. Напомню, что отзыв сертификата – это специальная процедура, позволяющая исключить из списка доверенных сертификат, срок действия которого ещё не истёк. Это требуется, например, в том случае, если скомпрометирован закрытый ключ, соответствующий сертификату.

Логика OCSP довольно проста: получив сертификат, браузер обращается с запросом, содержащим серийный номер сертификата, по адресу специального ответчика (“респондера”), обычно работающего на серверах удостоверяющего центра (УЦ), и может получить ответ о том, не отозван ли этот сертификат. А может и не получить – дело в том, что ответчики OSCP некоторых УЦ работают не так надёжно, как хотелось бы. У OCSP есть и ещё одна особенность: владельцы ответчика получают информацию о том, какие пользователи ходят на сайты, где установлены соответствующие сертификаты (очевидно, что эту информацию передают браузеры, запрашивающие проверку отзыва сертификата).

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

Я некоторое время назад наладил демонстрационный сервер под доменом 1d.pw, там поддерживается и OCSP stapling – только сертификат там не EV, а простой. Посмотреть на работу OCSP stapling можно при помощи OpenSSL, вот так:

$ openssl s_client -connect 1d.pw:443 -tlsextdebug -status

В выдаче отыскиваем строки, следующие за “OCSP response”:

OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)

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

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