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

Немного истории

В начале 2000-х годов существовало множество P2P-сетей, практическим применением которых был файлообмен. Копирастеры приходили в ярость, поскольку в распространении файлов принимали участие все сразу. Попытки же устроить «показательную порку» индивидуумам приводили лишь к колоссальным затратам времени и средств с нулевым конечным результатом. Для тех же, кто опасался оказаться в числе «попавших под раздачу», была предложена сеть Freenet, ключевой идеей которой был обмен зашифрованными блоками данных, при этом участник не имел представления о том, что это за данные, если они не были предназначены ему самому. Хотя сеть предоставляла и другие сервисы вроде полностью анонимных форумов, фактически все сводилось к скачиванию файлов.

Со временем весь файлообмен переместился в торренты. В результате возникла идея развития Freenet’а в направлении «невидимого интернета» — анонимной сети поверх существующего интернета. Так появился I2P. Долгое время проект был интересен лишь его создателям и некоторому числу гиков. Вскоре борьба уже стала вестись за саму информацию, поскольку, с одной стороны, интернетом стало пользоваться большинство людей, а с другой стороны, интернет оказался местом никем не контролируемого обмена информацией. Стало понятно, что так долго продолжаться не может, и поднялась новая волна интереса к подобным проектам.

I2P и Тор

«Спусковым крючком», вызвавшим массовый интерес к «невидимому интернету», стало законодательное ограничение доступа к информационным ресурсам в ряде стран, а также разоблачения Сноудена о слежке за всеми. Разумеется, многим это не понравилось: действительно, с какой стати непонятно кто станет решать за взрослого дееспособного человека, какую информацию ему следует получать, а какую нет. Что касается слежки, то она вообще никому не приятна. Осознав это, обыватель бросился искать две магические кнопки «Обойти цензуру» и «Спрятаться от слежки». И такие «кнопки» он получил в виде специальных браузеров или плагинов к браузерам для сети Tor.
Технически грамотные люди же обратили внимание на сеть I2P в качестве альтернативы Tor’у. Поскольку ты, уважаемый читатель, относишься к технически грамотным людям (иначе зачем тебе «Хакер»?), то, прочитав данную статью, поймешь, какие задачи решает сеть I2P и каким образом она это делает.
Следует обратить внимание на главное отличие I2P от Tor: основной задачей Tor’а является сокрытие истинного IP-адреса клиента, обращающегося к серверу. По большому счету серверам нет дела до того, каким образом к ним подключаются клиенты, — скорее, Тоr является для них лишней головной болью из-за хулиганов, в случае же I2P, наоборот, владельцы серверов (eepsite’ов) размещают их анонимно, а клиенты вынуждены использовать I2P, если хотят обращаться к этим серверам. Таким образом, Тоr является сетью клиентов, а I2P — серверов. Конечно, есть и onion-сайты в Тоr, и выходные узлы в I2P, однако это скорей побочные технологии.

Как участники I2P находят друг друга?

Начнем с того, что рассмотрим встроенные в I2P механизмы, которые позволяют участникам находить друг друга, и попробуем найти в них потенциальные уязвимости. Каждый узел I2P идентифицируется I2P-адресом, представляющим собой две пары открытых и закрытых ключей, генерируемых в момент создания узла случайным образом, без какой-либо корреляции с IP-адресом или местоположением. Центрального источника адресов нет, предполагается, что вероятность совпадения двух случайно сгенерированных адресов пренебрежимо мала. Одна пара ключей используется для асимметричного шифрования, а другая — для подписи. Владельцем узла является тот, у кого имеется файл с полным набором ключей длиной 660 байт. Этот файл располагается на компьютере владельца и по сети не передается. Два открытых ключа и 3-байтный сертификат (на настоящий момент всегда нулевой) образуют 387-байтный идентификатор узла, под которым узел становится известен в I2P. Поскольку полный 387-байтный идентификатор довольно неэффективен для сравнения, сортировки и передачи данных, то для обозначения узла используется 32-байтный SHA-256 хеш от идентификатора. Строковое Base32 представление этого хеша и является адресом в .b32.i2p-адресах. А что делать, если известен только хеш, а нужно знать публичные ключи, содержащиеся в идентификаторе, например для шифрования или проверки подписи? Для этого существует сетевая база данных (netDb) — не очень удачное название, правильнее было бы назвать базой данных о сети, но такова уже устоявшаяся терминология.

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

Обманываем новичков

Наличие локальной базы данных позволяет участнику выходить в сеть немедленно, не обращаясь к серверам каталогов узлов, как это делается в Тоr’е (из-за этого китайское правительство в 2010 году смогло отключить его, блокировав доступ к каталогам). Однако у такой децентрализации есть один существенный недостаток: чтобы получать информацию о новых узлах, в локальной базе данных должны уже присутствовать какие-то узлы. Значит, при первом запуске их придется откуда-то загрузить. Этот процесс называется «посевом» (reseeding) и заключается в скачивании файлов с небольшого числа жестко прописанных в коде сайтов. Достаточно заблокировать доступ к этим сайтам, и новые узлы не смогут стартовать. Правда, в этом случае для первого запуска можно просто взять список узлов у кого-то другого. Гораздо хуже, если доступ будет не заблокирован, а перенаправлен на сайты с фальшивым списком узлов, — тем самым новый узел рискует попасть в изолированную от остальной сеть, и нет простого способа распознать эту ситуацию. К чести разработчиков, они понимают масштаб проблемы и работают над тем, чтобы распространять начальный список узлов в виде подписанного их ключом архива по различным каналам.

Невидимый интернет

Сеть I2P состоит из узлов двух видов: маршрутизаторы, имеющие помимо I2P-адресов обычные IP-адреса и видимые в обычном интернете, и узлы, находящиеся позади маршрутизаторов и собственных IP-адресов не имеющие, — они и образуют тот самый «невидимый интернет». Маршрутизаторы представлены в сетевой базе данных структурой RouterInfo, помимо полного идентификатора содержащей один или несколько внешних IP-адресов и доступных протоколов, а также список возможностей данного маршрутизатора, важнейшей из которых является floodfill. Floodfill-маршрутизаторы служат своего рода «досками объявлений», куда узлы публикуют информацию о себе и куда приходят запросы клиентов. Во избежание подделки данные подписываются ключом, входящим в адрес. Поскольку информация о маршрутизаторе меняется довольно редко, то соответствующие файлы сохраняются на диске и загружаются в память при старте. У нормально функционирующего I2P-клиента таких файлов должно быть порядка нескольких тысяч.

<

«Невидимый интернет» представлен структурами данных LeaseSet, содержащих полный идентификатор, дополнительный ключ шифрования и список тоннелей, ведущих к маршрутизатору с данным узлом. Хотя входящие тоннели имеются и у самих маршрутизаторов, они никогда не формируют LeaseSet’ы: к маршрутизаторам всегда следует обращаться, устанавливая с ними прямые соединения, тоннели же используются только для получения ответов на запросы. Поскольку продолжительность жизни одного тоннеля десять минут, то LeaseSet’ы также существуют недолгое время и поэтому на диске не сохраняются, а при рестарте перезапрашиваются по новой. Тоннели и ключ шифрования из LeaseSet’а являются единственным способом обращения к «невидимому» узлу, то есть, зная адрес, следует сначала запросить его LeaseSet у ближайшего к нему floodfill’а и потом отправить сообщение в один из тоннелей. Для получения ответа требуется сформировать собственный LeaseSet, который можно отправить вместе с сообщением или же опубликовать на ближайшем floodfill’е.
Невозможность установить, на каком маршрутизаторе располагается тот или иной LeaseSet, является краеугольным камнем технологии обеспечения анонимности в сети I2P. Соответственно, большинство атак злоумышленников направлены на решение противоположной задачи. С этой целью в I2P для передачи информации используется сильная криптография, скрывающая данные от особо любопытных провайдеров разных уровней, а удачно применяемые электронные подписи делают сеть устойчивой к атакам типа man-in-the-middle.

Перехватываем тоннели

Для обеспечения анонимности внутри I2P применяются тоннели, представляющие собой цепочки маршрутизаторов, через которые передаются сообщения. Тоннели бывают исходящие и входящие. Исходящие предназначены для сокрытия местоположения отправителя, а входящие — получателя. Потому LeaseSet’ы и представляют собой список входных узлов и идентификаторов входящих тоннелей, информация об исходящих тоннелях не публикуется. Местоположение второго конца тоннеля держится в секрете. Для получения ответов клиент посылает серверу собственный LeaseSet. Каким путем проложен тоннель и, соответственно, на каком узле находится его второй конец, известно только создателю тоннеля. Все промежуточные участники тоннеля знают лишь следующий узел, которому следует передать перешифрованное сообщение. Но это в теории — на практике же промежуточные узлы также знают, откуда пришло сообщение, потому что сообщения между узлами передаются по обычному интернету и узнать IP-адрес отправителя не составляет труда. Далее, при достаточном размере базы можно найти и RouterInfo. Таким образом, если промежуточный узел тоннеля принадлежит злоумышленнику, то он немедленно узнает и двух своих соседей, что компрометирует одно- или двухшаговые тоннели, поскольку позволяет отследить всю цепочку. Теоретически можно увеличить длину тоннелей вплоть до восьми узлов, практически же каждый дополнительный узел резко замедляет скорость работы и надежность, поскольку присутствие узла онлайн на все время существования тоннеля не гарантировано. Поэтому в настоящий момент в I2P используются трехшаговые тоннели. Таким образом, для успешной деанонимизации узла злоумышленнику следует узнать маршрут любого из тоннелей в любой момент времени — для этого достаточно, чтобы два узла одного тоннеля были доступны злоумышленнику. При нынешнем размере сети в несколько тысяч узлов такой сценарий вполне по силам крупным структурам. Если в деанонимизации серверов ранее описанный перехват reseeding’а мало поможет, поскольку серверы выбирают узлы входящих тоннелей сами, то для выявления клиентов, посещающих «неблагонадежные» ресурсы, данный метод идеален: все узлы, в том числе выходные, используемые клиентом для построения его исходящих тоннелей, будут априори принадлежать злоумышленнику. Тем самым сразу станет известно, откуда пришло сообщение, предназначенное какому-нибудь входящему тоннелю сервера.

Атака методом исключения

Для тех, кто не обладает достаточными ресурсами по захвату большого числа узлов, однако располагает временем и терпением, подойдет другой способ. Цель его — резкое сужение круга «подозреваемых» маршрутизаторов (при должном везении даже до одного), на которых может располагаться искомый узел. Возможность проведения такой атаки обусловлена P2P-природой сети I2P — большинство маршрутизаторов сети не находятся онлайн 24 часа в сутки, поскольку располагаются на компьютерах ее участников. С другой стороны, эксплуатируются особенности I2P:

1. Время существования тоннеля десять минут.
2. Узел не участвует в тоннеле дважды.
3. Для построения тоннеля каждый раз выбирается новая последовательность узлов.

Перед началом атаки злоумышленник набирает достаточно обширную базу, предполагая, что в ней находится и маршрутизатор атакуемого узла. Далее он начинает постоянно обращаться к атакуемому узлу с запросом, предполагающим получение ответа. Это можно делать ненавязчиво, главное, чтобы запрос-ответ шли постоянно, тем самым злоумышленник определяет временные интервалы, когда атакуемый узел и, соответственно, его маршрутизатор находится онлайн. Одновременно с этим оставшиеся маршрутизаторы опрашиваются путем установления непосредственного соединения, отправки какого-нибудь запроса или создания тоннеля. Делается это массово в течение максимально короткого промежутка времени. Те маршрутизаторы, которые оказались неактивными в то время, как атакуемый узел показывает активность, выбрасываются из списка, и наоборот — выбрасываются активные, когда узел неактивен. Если же атакуемый узел активен все время, то в конце концов список будет состоять из постоянно активных маршрутизаторов. И он может оказаться достаточно большим. Вот тут на помощь злоумышленнику и приходят перечисленные выше особенности: входные маршрутизаторы тоннелей, входящих в LeaseSet атакуемого узла, заведомо не являются его маршрутизатором и могут быть немедленно исключены. LeaseSet обновляется не реже чем раз в десять минут и обычно содержит пять тоннелей. За час будут исключены 30 узлов, за сутки 720, таким образом, перебор списка в 5 тысяч узлов займет не более недели.

Определяем соседей по запаху чеснока

Для обеспечения анонимности с обеих сторон тоннели используются парами: исходящий тоннель отправителя и входящий тоннель получателя. Поскольку тоннели создаются независимо друг от друга, то выходной и входной маршрутизаторы в месте соединения тоннелей видят незашифрованные передаваемые данные. Поэтому поверх тоннельного используется дополнительный уровень шифрования — специальное «чесночное» сообщение, полностью зашифрованное и предназначенное для конечных узлов в цепочке. Проблема заключается в том, что расшифровкой таких сообщений занимается маршрутизатор узла, а не сам узел. Таким образом, ключ шифрования, присутствующий в полном идентификаторе, не используется, вместо этого в LeaseSet’е присутствует предназначенный для шифрования отдельный ключ, сгенерированный маршрутизатором, на котором располагается данный LeaseSet. При этом ключ должен быть одним и тем же для всех расположенных на маршрутизаторе узлов, даже если каждый LeaseSet использует свой собственный набор тоннелей. Иначе и нельзя, поскольку «чесночное» сообщение должно быть расшифровано до того, как станет понятно, кому предназначена та или иная «чесночина». В результате изначально здравая идея «чесночной» передачи данных обрела столь уродливую форму при передаче через пару тоннелей. Таким образом, ключ шифрования, публикуемый в LeaseSet’е, является уникальным идентификатором соответствующего маршрутизатора. Достаточно скомпрометировать любой из узлов, чтобы также скомпрометировать все остальные, в том числе и клиентские. Для проведения данной атаки злоумышленнику следует запустить один или несколько floodfill’ов, куда узлы будут публиковать свои LeaseSet’ы.

Выводы

Суммируя вышесказанное, приходим выводу: анонимность I2P в нынешнем состоянии носит лишь базовый характер, позволяя укрыться только от пассивного наблюдения, вроде сбора маркетологической информации. Безусловно, проведение данных типов атак требует серьезных ресурсов, вроде высокоскоростных серверов и специализированного софта, но если кому-то сильно понадобится, то он сможет раскрыть анонимность довольно быстро. Увеличение числа узлов в сети могло бы решить данную проблему, однако при нынешней организации сети это приведет к ее фактическому коллапсу. В то же самое время I2P прекрасно подходит для построения «неубиваемых» ресурсов, доступ к которым невозможно ограничить в принципе.