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

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

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

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

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

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

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

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

Пользователь “вычислен персонально”.

Более того, можно составить чёткие критерии, когда программа “извлечения данных” определила пользователя точно, а когда – нет: просто учитывается число оставшихся возможных вариантов.

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

Главное тут вот что: в приведённом решении хитрой задачи достигается “полная анонимность”, “полное обезличивание” на этапе сбора исходных данных; а позже, совсем другими серверами, из этих “обезличенных данных” восстанавливаются вполне точные персональные данные. Такая вот реконструкция алгоритмами data mining.

Кому интересно, вот ссылка на работу с исследованием этой темы: On the Anonymity of Home/Work Location Pairs. Также, около года назад, я писал про очень логически близкие к только что описанной технологии построения поведенческих профилей посетителей веб-сайтов.

Для тех, кто предпочитает сразу тему развивать: подумайте, что, в теории, аналогичная схема сработает и при анализе пользовательского интернет-трафика.



Комментарии (9) »

Credit: Eric Shmiedl Кстати, про DNSSEC – технологию, которую сейчас будут бурно обсуждать. Для чего DNSSEC? Для того, чтобы ввести в интернетовский обиход механизм, позволяющий всем участникам обмена адресной информацией осуществлять более надёжное управление доверием. Доверие – это самое важное в DNSSEC. Тем не менее, сейчас про DNSSEC напридумывали много всякого, неверного.

Чтобы проще было разбираться, на всякий случай напомню, что же такое DNS. DNS – это такой сервис в Интернете, позволяющий преобразовывать символьные имена узлов в числовые IP-адреса, по которым и производится реальная адресация. (Ну и, вообще говоря, с помощью сервиса DNS специальным образом возможно осуществить и обратное преобразование: IP-адрес – в символьное имя.) Главный философский момент тут такой: DNS – именно сервис, работающий с помощью большого количества серверов, разбросанных по глобальному Интернету; напрямую к маршрутизации пакетов DNS не привязана – пакеты между узлами вполне ходят без всякой DNS, которую придумали-то для людей.

Вот.

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

2. DNSSEC позволяет победить такие вполне себе фундаментальные уязвимости в DNS, как, например, отравление кеша. Эти уязвимости позволяют нехорошим злоумышленникам перенаправлять пользователей Интернета на свои серверы, подменяя соответствие имён доменов и IP-адресов. Набрал мойбанк.ru, а браузер попал вовсе не на сервер банка. Кому-то может показаться, что более старые, чем Веб, уязвимости вовсе не так уж и опасны, они протухли. Но вот, скажем, если недавно продемонстрированную на практике возможность создания поддельного SSL-сертификата, вообще не отличимого от настоящего, прикрепить к отравлению кеша, то получится, что достаточно продвинутые злоумышленники могут клонировать сайт банка, снабдив его, в том числе, и валидным SSL-сертификатом. Даже крайне недоверчивый пользователь будет введён в заблуждение. Хорошо построенная атака может дать массовый эффект: пользователи крупного провайдера все как один пойдут вместо реального сервера банка на подставной, при этом в адресной строке браузера будет значиться правильный адрес, и SSL-сертификат не вызовет в браузере окон с предупреждениями.

3. В DNSSEC используются криптографические методы. Это так. Но нужно понимать, что передаваемая информация при этом не скрывается. То есть цель протоколов DNSSEC не в том, чтобы сделать данные об адресации “нечитабельными”, а в том, чтобы обеспечить целостность данных и аутентификацию источника. Но для этого используются криптографические алгоритмы, привлекающие, в том числе, и секретные ключи, необходимые для генерации подписей.

4. Вот с ключами как раз и возникают основные хитрости. Как известно, для проверки подписи нужен открытый ключ, принадлежащий тому, кто подписывал. В случае DNS – тому лицу, которое сгенерировало данные об адресации в доменной зоне. Можно рассматривать всякие технические особенности и хитрости криптосистем RSA (и если это интересно, то можно написать серию заметок по теме), но самый важный вопрос всё равно более системный: как узнать, что претендующее на владение той или иной доменной зоной лицо, размахивающее через DNS-запрос открытым ключом и соответствующей подписью, действительно владеет этой зоной и уполномочено ей управлять? И вправду, может, это самозванец? То есть, опять вопрос сводится к такому: можно ли конкретной подписи доверять, если раньше этой подписи не попадалось и о её владельце особой информации нет? Это общий вопрос для систем аутентификации. В офлайне он издревле решается так: приглашают третью сторону, которой доверяют оба “участника сделки”. Если решение обобщить, то возникает некая структура доверия, которая может быть “плоской” (как, например, в системах PGP), но чаще бывает иерархической, сходящейся к некоторому корневому центру, который, в итоге, удостоверяет подписи всех остальных “участников соглашения”.

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

Вот.

Вообще, несколько подробнее про DNSSEC в популярном изложении можно прочитать в недавнем выпуске журнала “Доменные имена”, который в электронном виде можно взять на сайте RU-CENTER. На 69-й странице там начинается моя статья про DNSSEC.

(Если есть какие-то вопросы – прошу в комментарии, я, возможно, сделаю отдельный раздел про DNSSEC.)

***

Дополнения (2012):

О DNSSEC, в течение нескольких лет, я написал много других публикаций и реализовал несколько технологических демонстраций, например, такой демонстрацией является первый подписанный домен в зоне .su – nox.su.

Корневую зону глобальной DNS (общепринятой) подписали в ночь с 15 на 16 июля 2010 года. Связанные с этой процедурой домыслы прессы, падкой на криптосенсации, привели к возникновению забавного “мема” о “шестёрке программистов, которых уполномочили перезагрузить Интернет, если он сломается”. Естественно, в реальности всё обстоит сильно иначе.

DNSSEC, как и ожидалось, постепенно проникает на клиентские машины (обычно, в виде браузерных расширений); это – важный аспект внедрения данной технологии, который, кстати, является маркером изменения основных принципов использования DNS.



Комментарии (2) »

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

Например, Штаты опасаются небольших, недорогих, но выполненных на современном уровне подводных лодок, которые могли бы оказаться у тех же самых “вероятных противников” из числа неразвитых в военно-техническом отношении стран.

(Германская подводная лодка времён Второй Мировой)

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

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

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

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

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

При этом со стороны противника требуется лишь поддержание боеспособности небольшого флота подводных лодок, которые уже конструктивно выполнены так, чтобы требовать минимума внимания и минимума технического оснащения и грамотности.

Продолжение – в третьей части.

(Часть 1)



Комментарии (8) »
Навигация по запискам: