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

Небольшое продолжение истории с алгоритмом генерации псевдослучайных чисел Dual_EC_DRBG (можно, кстати без подчёркиваний – Dual EC DRGB, что означает Dual Elliptic Curve Deterministic Random Bit Generator). Некоторое время назад я написал про данный алгоритм, – реализация которого, как было объявлено, могла содержать бэкдор от NSA, – буквально следующее:

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

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

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

Известно, что при NASA до сих пор существует, – вроде бы, вполне официальная, – программа по созданию “варп-двигателя”. То есть, по созданию двигателя, который обеспечит космическому кораблю сверхсветовую скорость, благодаря локальному искривлению пространства. Это хорошо проработанная в научной фантастике тема, которая, конечно, пока что так и звучит совершенно фантастически. Тем не менее, периодически появляются “варп-новости”, в которых нет физики, но есть занятные картинки. Очередной свежий вариант корабля с “варп-двигателем” – в заметке io9.com и в галерее на Flickr.com.

На dxdt.ru образовалось некоторое затишье. Так как за годы работы сайта накопилось много записок, то я придумал, что затишье можно немного разбавлять подборками записок по той или иной теме. Удобно, когда материала много. Сегодня – записки про телефоны, телефонию и смартфоны, в разных их проявлениях (в скобках – год публикации).

• Базы авиаперелётов и идентификация смартфонов (2014)
• Эволюция телефонного аппарата как персонального жучка
• Смартфоны, QR-коды и точная геолокация (2012)
• Персональные данные, которые расползаются (2011)
• Обнаружение “анонимных” мобильных телефонов (2010)
• GPS наоборот или определение координат мобильника (2009)
• Поисковая сеть из мобильных телефонов (2008)

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

Интересно, что уже формируется мода на оформление веб-страниц, рассказывающих об уязвимостях в OpenSSL – моду задала нашумевшая Heartbleed. Страница о новой уязвимости оформлена практически в том же стиле, посмотрите сами.

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

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

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

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

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

Определить посещаемость можно при помощи анализа HTTP-трафика, проводимого на сетях провайдеров доступа (либо на точках обмена трафиком, что неплохо подходит для российского сегмента Интернета). То есть, нужно использовать DPI. Наблюдая за трафиком, относительно несложно посчитать число заходов браузеров на заданный ресурс. Думаю, основная идея метода достаточно очевидна: считаются GET-запросы, содержащие заданный URL. Не обязательно даже следить за всем потоком трафика: полные данные можно вычислить по некоторой выборке.

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

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

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

На днях в издательстве “Эксмо” вышла моя новая книга о системе доменных имён (DNS). У неё простое название – “Домены”. Это, фактически, дальнейшее развитие “Доменных войн”, которые пережили два издания. Из основных дополнений – рассказ о программе New gTLD, изменения в работе ICANN, реальность внедрения DNSSEC.

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

Понятно, что подобных инструментов идентификации будет теперь появляться всё больше. Наибольший интерес представляют те из них, которые доступны для удалённого анализа. Удобно, кстати, что dxdt.ru работает уже некоторое время: можно очередной раз сослаться на старую записку – так, про идентификацию электронных устройств по отпечаткам я писал около шести лет назад. Что ж, теория потихоньку переходит в практику.

Сделал отдельный поиск по запискам, опубликованным на dxdt.ru. Это просто поиск “Яндекса” для сайта (вроде бы, пока там не показывается реклама), поэтому – отдельный поддомен и веб-сервер. Адрес: search.dxdt.ru.

Оказывается, “Компьюлента” – всё, закончилась:

“Этим материалом «Компьюлента» заканчивает свою нынешнюю историю, совершенно не ведая, что ждёт её в будущем и ждёт ли вообще. Спасибо, что были с нами. Вы были хорошие, а мы, наверное, не очень. Прощайте.”

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

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