Модель угроз I2P

Что мы подразумеваем под “Анонимностью”?

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

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

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

Сводка топологии сети

I2P основывается на идеях многих других систем, но при изучении соответствующей литературы следует помнить несколько ключевых моментов:

• I2P является бесплатной route mixnet — создатель сообщения явно определяет путь, по которому сообщения будут отправлены (исходящий tunnel), а получатель сообщения явно определяет путь, по которому сообщения будут получены (входящий tunnel).
• I2P не имеет официальных точек входа и выхода — все узлы полностью участвуют в микшировании, и не существует прокси на сетевом уровне для входящего или исходящего трафика (однако на прикладном уровне несколько прокси действительно существуют).
• I2P полностью распределена — нет центрального управления или властей. Можно было бы модифицировать некоторые router’ы для работы в виде каскадов микширования (создание tunnel’ей и выдача ключей, необходимых для управления пересылкой на конечной точке tunnel’а) или профилирования и выбора на основе каталогов, всё это без нарушения совместимости с остальной частью сети, но делать это, конечно, не обязательно (и может даже навредить анонимности).

У нас есть документированные планы по реализации нетривиальных задержек и стратегий группировки, о существовании которых знает только конкретный hop или tunnel gateway, который получает сообщение, что позволит в основном низколатентной mixnet обеспечивать маскирующий трафик для связи с более высокими задержками (например, электронной почты). Однако мы понимаем, что значительные задержки необходимы для обеспечения осмысленной защиты, и что реализация таких задержек будет серьёзным вызовом. На данный момент неясно, действительно ли мы будем реализовывать эти функции задержки.

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

Модель угроз

Разработка I2P началась в 2003 году, вскоре после появления Onion Routing , Freenet и Tor . Наш дизайн значительно выиграл от исследований, опубликованных в то время. I2P использует несколько техник onion routing, поэтому мы продолжаем извлекать пользу из значительного академического интереса к Tor.

Основываясь на атаках и анализе, представленных в литературе по анонимности (в основном Traffic Analysis: Protocols, Attacks, Design Issues and Open Problems ), ниже кратко описывается широкий спектр атак, а также многие средства защиты I2P. Мы обновляем этот список, включая новые атаки по мере их выявления.

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

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

Страницы сравнения сетей и терминология “garlic” также могут быть полезны для изучения.

Атаки методом перебора

Атака грубой силы может быть предпринята глобальным пассивным или активным противником, который наблюдает за всеми сообщениями, проходящими между всеми узлами, и пытается сопоставить, какое сообщение следует по какому пути. Проведение такой атаки против I2P должно быть нетривиальным, поскольку все узлы в сети часто отправляют сообщения (как конечные, так и сообщения сетевого обслуживания), плюс конечное сообщение изменяет размер и данные по своему пути. Кроме того, внешний противник также не имеет доступа к сообщениям, поскольку межмаршрутизаторная связь как зашифрована, так и передается потоком (что делает два сообщения по 1024 байта неотличимыми от одного сообщения в 2048 байт).

Однако мощный злоумышленник может использовать грубую силу для обнаружения закономерностей — если он может отправить 5ГБ на I2P назначение и отслеживать сетевое соединение каждого, он может исключить всех узлов, которые не получили 5ГБ данных. Существуют методы противодействия этой атаке, но они могут быть чрезмерно дорогостоящими (см.: имитаторы Tarzan или трафик с постоянной скоростью). Большинство пользователей не беспокоятся об этой атаке, поскольку затраты на её проведение экстремальны (и часто требуют незаконной деятельности). Однако атака всё ещё возможна, например, со стороны наблюдателя у крупного интернет-провайдера или в точке обмена интернет-трафиком. Те, кто хочет защититься от неё, захотят принять соответствующие контрмеры, такие как установка низких ограничений пропускной способности и использование неопубликованных или зашифрованных leaseSet для I2P сайтов. Другие контрмеры, такие как нетривиальные задержки и ограниченные маршруты, в настоящее время не реализованы.

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

Атаки на основе анализа времени

Сообщения I2P являются однонаправленными и не обязательно подразумевают, что будет отправлен ответ. Однако приложения поверх I2P, скорее всего, будут иметь узнаваемые паттерны в частоте своих сообщений — например, HTTP-запрос будет небольшим сообщением с большой последовательностью ответных сообщений, содержащих HTTP-ответ. Используя эти данные, а также широкое представление о топологии сети, злоумышленник может быть способен исключить некоторые связи как слишком медленные для передачи сообщения.

Этот тип атаки является мощным, но его применимость к I2P неочевидна, поскольку вариации в задержках сообщений из-за очередей, обработки сообщений и регулирования пропускной способности часто будут равняться или превышать время передачи сообщения по одной связи — даже когда атакующий знает, что ответ будет отправлен сразу же после получения сообщения. Тем не менее, существуют некоторые сценарии, которые выявляют довольно автоматические ответы — библиотека потокового вещания делает это (с SYN+ACK), как и режим сообщений гарантированной доставки (с DataMessage+DeliveryStatusMessage).

Без очистки протокола или более высокой задержки глобальные активные противники могут получить существенную информацию. Таким образом, люди, обеспокоенные такими атаками, могли бы увеличить задержку (используя нетривиальные задержки или стратегии пакетирования), включить очистку протокола или другие продвинутые методы маршрутизации tunnel, но они не реализованы в I2P.

Ссылки: Low-Resource Routing Attacks Against Anonymous Systems

Атаки пересечения

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

В заключение, если атакующий находится на обоих концах вашего tunnel одновременно, он может добиться успеха. I2P не имеет полной защиты от этого для связи с низкой задержкой. Это неотъемлемая слабость onion routing с низкой задержкой. Tor предоставляет похожее предупреждение .

Частичные защитные меры, реализованные в I2P:

• Строгое упорядочивание peers
• Профилирование peers и выбор из небольшой группы, которая медленно изменяется
• Ограничения на количество tunnel, маршрутизируемых через одного peer
• Предотвращение участия peers из одного диапазона IP /16 в качестве членов одного tunnel
• Для I2P Sites или других размещённых сервисов мы поддерживаем одновременное размещение на нескольких router или мультихоминг

Даже в совокупности эти меры защиты не являются полным решением. Также мы приняли некоторые проектные решения, которые могут значительно увеличить нашу уязвимость:

• Мы не используем “guard nodes” с низкой пропускной способностью
• Мы используем пулы tunnel, состоящие из нескольких tunnel, и трафик может переключаться с одного tunnel на другой.
• Tunnel не являются долгоживущими; новые tunnel строятся каждые 10 минут.
• Длина tunnel настраивается. Хотя 3-hop tunnel рекомендуются для полной защиты, несколько приложений и сервисов по умолчанию используют 2-hop tunnel.

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

Справка: One Cell Enough

Атаки типа “отказ в обслуживании”

Существует множество атак типа “отказ в обслуживании”, доступных против I2P, каждая из которых имеет различные затраты и последствия:

Атака жадного пользователя: Это просто люди, пытающиеся потреблять значительно больше ресурсов, чем они готовы предоставить. Защита от этого заключается в:

• Установить настройки по умолчанию так, чтобы большинство пользователей предоставляли ресурсы сети. В I2P пользователи маршрутизируют трафик по умолчанию. В отличие от других сетей , более 95% пользователей I2P ретранслируют трафик для других.
• Предоставить простые опции конфигурации, чтобы пользователи могли увеличить свой вклад (процент участия) в сеть. Отображать понятные метрики, такие как “коэффициент участия”, чтобы пользователи могли видеть, что они вносят.
• Поддерживать сильное сообщество с помощью блогов, форумов, IRC и других средств общения.

Атака истощения: Злоумышленник может попытаться навредить сети, создав значительное количество peer’ов в сети, которые не идентифицируются как находящиеся под контролем одного субъекта (как при атаке Sybil). Эти узлы затем решают не предоставлять никаких ресурсов сети, заставляя существующие peer’ы искать в более обширной базе данных сети или запрашивать больше tunnel’ов, чем должно быть необходимо. В качестве альтернативы узлы могут предоставлять прерывистый сервис, периодически отбрасывая выбранный трафик или отказывая в соединениях с определенными peer’ами. Такое поведение может быть неотличимо от поведения сильно загруженного или неисправного узла. I2P решает эти проблемы, ведя профили на peer’ы, пытаясь выявить неэффективные и просто игнорируя их или используя их редко. Мы значительно улучшили способность распознавать и избегать проблемных peer’ов; однако в этой области все еще требуются значительные усилия.

Атака флуда: Злоумышленник может попытаться затопить сеть, узел, назначение или tunnel. Флуд сети и узла возможен, и I2P никак не препятствует стандартным атакам флуда на уровне IP. Флуд назначения сообщениями путем отправки большого количества на различные шлюзы входящих tunnel возможен, но назначение узнает об этом как по содержимому сообщения, так и потому, что тесты tunnel будут проваливаться. То же самое касается флуда только одного tunnel. I2P не имеет защиты от сетевых атак флуда. При атаке флуда на назначение и tunnel цель определяет, какие tunnel не отвечают, и строит новые. Также можно написать новый код для добавления еще большего количества tunnel, если клиент хочет справиться с большей нагрузкой. С другой стороны, если нагрузка больше, чем клиент может обработать, он может указать tunnel ограничить количество сообщений или байтов, которые они должны пропускать (после реализации расширенных операций tunnel).

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

DOS-атака на floodfill: Злоумышленник может попытаться навредить сети, став floodfill router. Текущие средства защиты от ненадёжных, нестабильных или вредоносных floodfill router являются слабыми. Floodfill router может предоставлять неверные ответы на запросы или не отвечать вовсе, а также может вмешиваться в связь между floodfill узлами. Некоторые средства защиты и профилирование узлов реализованы, однако предстоит ещё много работы. Для получения дополнительной информации см. страницу базы данных сети .

Атаки с использованием меток

Атаки с метками — модификация сообщения таким образом, чтобы его можно было позже идентифицировать в дальнейшем по пути — сами по себе невозможны в I2P, поскольку сообщения, передаваемые через tunnel’ы, подписываются. Однако, если злоумышленник является одновременно входным gateway’ем tunnel’а и участником далее по этому же tunnel’у, то при сговоре они могут определить факт того, что находятся в одном tunnel’е (и до добавления уникальных hop id и других обновлений, сговорившиеся узлы в рамках одного tunnel’а могут распознать этот факт без каких-либо усилий). Злоумышленник в исходящем tunnel’е и любой части входящего tunnel’а не могут вступить в сговор, поскольку шифрование tunnel’я дополняет и модифицирует данные отдельно для входящих и исходящих tunnel’ей. Внешние злоумышленники ничего не могут сделать, поскольку соединения зашифрованы, а сообщения подписаны.

Атаки разделения

Атаки разделения — поиск способов сегрегации (технической или аналитической) узлов в сети — важно учитывать при работе с мощным противником, поскольку размер сети играет ключевую роль в определении вашей анонимности. Техническое разделение путем разрыва связей между узлами для создания фрагментированных сетей решается встроенной в I2P базой данных сети (network database), которая ведет статистику по различным узлам, чтобы позволить использовать любые существующие соединения с другими фрагментированными секциями для восстановления сети. Однако, если атакующий действительно разорвет все связи с неконтролируемыми узлами, по сути изолировав цель, никакое восстановление через network database этого не исправит. В этот момент router может лишь надеяться заметить, что значительное количество ранее надежных узлов стало недоступно, и предупредить клиента о том, что он временно отключен (этот код обнаружения в настоящий момент не реализован).

Аналитическое разделение сети путем поиска различий в поведении router’ов и назначений и их соответствующей группировки также является очень мощной атакой. Например, злоумышленник, собирающий базу данных сети, будет знать, когда у определенного назначения есть 5 входящих tunnel’ов в их leaseSet, в то время как у других есть только 2 или 3, что позволяет противнику потенциально разделить клиентов по количеству выбранных tunnel’ов. Другое разделение возможно при работе с нетривиальными задержками и стратегиями пакетирования, поскольку шлюзы tunnel’ов и конкретные переходы с ненулевыми задержками, вероятно, будут выделяться. Однако эти данные доступны только тем конкретным переходам, поэтому для эффективного разделения по этому вопросу злоумышленнику потребуется контролировать значительную часть сети (и даже тогда это будет лишь вероятностное разделение, поскольку он не будет знать, какие другие tunnel’ы или сообщения имеют эти задержки).

Также обсуждается на странице сетевой базы данных (атака начальной загрузки).

Атаки на предшественников

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

I2P избегает этого четырьмя способами: во-первых, пиры, выбранные для участия в tunnel, не отбираются случайным образом по всей сети — они получены из алгоритма выбора пиров, который разбивает их на уровни. Во-вторых, благодаря строгому упорядочиванию пиров в tunnel, тот факт, что пир появляется чаще, не означает, что он является источником. В-третьих, благодаря изменяемой длине tunnel (по умолчанию не включено) даже 0-hop tunnel могут обеспечить правдоподобное отрицание, поскольку случайные вариации шлюза будут выглядеть как обычные tunnel. В-четвертых, с ограниченными маршрутами (не реализовано) только пир с ограниченным подключением к цели когда-либо свяжется с целью, в то время как атакующие просто столкнутся с этим шлюзом.

Текущий метод построения tunnel был специально разработан для борьбы с атакой predecessor. См. также атака пересечения .

Ссылки: Wright et al. 2008 , которая является обновлением предыдущей статьи об атаке 2004 года .

Атаки сбора данных

“Сбор данных” означает составление списка пользователей, использующих I2P. Это может быть использовано для правовых атак и для содействия другим атакам путем простого запуска peer-узла, наблюдения за тем, к кому он подключается, и сбора всех ссылок на других peer-узлы, которые можно найти.

Сам I2P не разработан с эффективной защитой от этой атаки, поскольку существует распределенная сетевая база данных, содержащая именно эту информацию. Следующие факторы делают атаку несколько сложнее на практике:

• Рост сети усложнит получение заданной доли сети
• Floodfill роутеры реализуют ограничения на запросы для защиты от DOS-атак
• “Скрытый режим”, который не позволяет роутеру публиковать свою информацию в netDb (но также не позволяет ему передавать данные), сейчас не используется широко, но мог бы использоваться.

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

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

Идентификация через анализ трафика

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

• Случайный выбор порта
• Шифрование точка-точка для всего трафика
• Обмен ключами DH без протокольных байтов или других нешифрованных постоянных полей
• Одновременное использование транспортов TCP и UDP. UDP может быть значительно сложнее для отслеживания некоторым оборудованием глубокой инспекции пакетов (DPI).

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

• Добавление случайных отступов на транспортном уровне до произвольной длины, особенно во время рукопожатия соединения
• Изучение сигнатур распределения размеров пакетов и добавление дополнительных отступов при необходимости
• Разработка дополнительных транспортных методов, имитирующих SSL или другие распространенные протоколы
• Анализ стратегий добавления отступов на более высоких уровнях для понимания их влияния на размеры пакетов на транспортном уровне
• Изучение методов, реализованных различными государственными межсетевыми экранами для блокировки Tor
• Прямая работа с экспертами по DPI и обфускации

Справочный материал: Breaking and Improving Protocol Obfuscation

Атаки Сивиллы

Sybil описывает категорию атак, при которых противник создает произвольно большое количество сговаривающихся узлов и использует увеличенные числа для помощи в проведении других атак. Например, если атакующий находится в сети, где peers выбираются случайно, и он хочет получить 80% шанс быть одним из этих peers, он просто создает в пять раз больше узлов, чем есть в сети, и бросает кости. Когда идентичность бесплатна, Sybil может быть очень мощной техникой для влиятельного противника. Основная техника борьбы с этим — просто сделать идентичность ‘не бесплатной’ — Tarzan (среди прочих) использует тот факт, что IP-адреса ограничены, в то время как IIP использовал HashCash для ‘взимания платы’ за создание новой идентичности. В настоящее время мы не внедрили какую-либо конкретную технику для борьбы с Sybil, но включаем сертификаты-заглушки в структуры данных router и destination, которые могут содержать HashCash сертификат соответствующей стоимости при необходимости (или какой-либо другой сертификат, подтверждающий дефицит).

Требование сертификатов HashCash в различных местах имеет две основные проблемы:

• Поддержание обратной совместимости
• Классическая проблема HashCash — выбор значений HashCash, которые являются значимыми доказательствами работы на высокопроизводительных машинах, оставаясь при этом выполнимыми на слабых устройствах, таких как мобильные устройства.

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

Смотрите страницу базы данных сети для более подробного обсуждения Sybil-атак.

Атаки истощения партнёров

(Ссылка: In Search of an Anonymous and Secure Lookup Раздел 5.2)

Отказываясь принимать или пересылать запросы на создание tunnel, за исключением запросов к сговорившемуся узлу, router может обеспечить формирование tunnel полностью из своего набора сговорившихся router’ов. Шансы на успех увеличиваются при большом количестве сговорившихся router’ов, то есть при атаке Сибилы . Это частично смягчается нашими методами профилирования узлов, используемыми для мониторинга производительности узлов. Однако это мощная атака, когда количество router’ов приближается к f = 0.2, или 20% злонамеренных узлов, как указано в статье. Злонамеренные router’ы также могут поддерживать соединения с целевым router’ом и обеспечивать отличную пропускную способность для трафика через эти соединения, пытаясь манипулировать профилями, управляемыми целевым router’ом, и казаться привлекательными. Могут потребоваться дальнейшие исследования и защитные меры.

Криптографические атаки

Мы используем сильную криптографию с длинными ключами и полагаемся на безопасность стандартных криптографических примитивов, используемых в I2P. Функции безопасности включают мгновенное обнаружение измененных сообщений по пути, невозможность расшифровки сообщений, не адресованных вам, и защиту от атак типа “человек посередине”. Размеры ключей, выбранные в 2003 году, были весьма консервативными на то время и до сих пор длиннее тех, которые используются в других сетях анонимности . Мы не считаем, что текущая длина ключей является нашей главной слабостью, особенно для традиционных противников не государственного уровня; ошибки и малый размер сети гораздо более тревожны. Конечно, все криптографические алгоритмы в конечном итоге устаревают из-за появления более быстрых процессоров, криптографических исследований и развития методов, таких как радужные таблицы, кластеры игрового оборудования и т.д. К сожалению, I2P не был спроектирован с простыми механизмами для увеличения длины ключей или изменения значений общих секретов при сохранении обратной совместимости.

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

В будущем несколько протоколов I2P и структур данных будут поддерживать безопасное дополнение сообщений до произвольных размеров, поэтому сообщения можно будет делать постоянного размера или garlic сообщения можно будет изменять случайным образом так, чтобы некоторые части казались содержащими больше подчастей, чем на самом деле. Однако в настоящее время garlic, tunnel и end-to-end сообщения включают простое случайное дополнение.

Атаки на анонимность floodfill

Помимо DOS-атак на floodfill, описанных выше , floodfill роутеры находятся в уникальном положении для изучения участников сети из-за их роли в netDb и высокой частоты взаимодействия с этими участниками. Это несколько смягчается тем, что floodfill роутеры управляют только частью общего пространства ключей, и пространство ключей ротируется ежедневно, как объясняется на странице сетевой базы данных . Конкретные механизмы, посредством которых роутеры взаимодействуют с floodfill, были тщательно разработаны. Однако эти угрозы следует изучить более подробно. Конкретные потенциальные угрозы и соответствующие способы защиты являются темой для будущих исследований.

Другие атаки на Network Database

Злоумышленник может попытаться навредить сети, создав один или несколько floodfill роутеров и настроив их для предоставления плохих, медленных или отсутствующих ответов. Несколько сценариев обсуждаются на странице сетевой базы данных .

Атаки на центральные ресурсы

Существует несколько централизованных или ограниченных ресурсов (некоторые внутри I2P, некоторые нет), которые могут быть атакованы или использованы как вектор для атак. Отсутствие jrandom с ноября 2007 года, за которым последовала потеря хостинг-сервиса i2p.net в январе 2008 года, выявило множество централизованных ресурсов в разработке и работе сети I2P, большинство из которых теперь распределены. Атаки на внешне доступные ресурсы в основном влияют на способность новых пользователей найти нас, а не на работу самой сети.

• Веб-сайт зеркалируется и использует DNS round-robin для внешнего публичного доступа.
• Router’ы теперь поддерживают множественные внешние reseed местоположения , однако может потребоваться больше reseed хостов, и обработка ненадежных или вредоносных reseed хостов может нуждаться в улучшении.
• Router’ы теперь поддерживают множественные местоположения файлов обновлений. Вредоносный хост обновлений может передать огромный файл; необходимо ограничить размер.
• Router’ы теперь поддерживают множественных доверенных подписантов обновлений по умолчанию.
• Router’ы теперь лучше обрабатывают множественные ненадежные floodfill узлы. Вредоносные floodfill’ы нуждаются в дополнительном изучении.
• Код теперь хранится в распределенной системе контроля версий.
• Router’ы полагаются на единственный хост новостей, но есть жестко закодированный резервный URL, указывающий на другой хост. Вредоносный хост новостей может передать огромный файл; необходимо ограничить размер.
• Сервисы системы именования , включая поставщиков подписок адресных книг, сервисы добавления хостов и jump сервисы, могут быть вредоносными. Существенные защитные меры для подписок были реализованы в релизе 0.6.1.31, с дополнительными улучшениями в последующих релизах. Однако все сервисы именования требуют определенной меры доверия; подробности см. на странице именования .
• Мы остаемся зависимыми от DNS сервиса для i2p2.de; потеря этого вызвала бы существенные нарушения в нашей способности привлекать новых пользователей и сократила бы сеть (в краткосрочной и среднесрочной перспективе), точно так же, как это произошло с потерей i2p.net.

Атаки на разработку

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

Однако две техники помогают защититься от этих атак:

• Все компоненты сети должны быть с открытым исходным кодом, чтобы обеспечить возможность инспекции, верификации, модификации и улучшения. Если разработчик скомпрометирован, как только это будет замечено, сообщество должно потребовать объяснений и прекратить принимать работу этого разработчика. Все коммиты в нашу распределенную систему контроля версий криптографически подписаны, а сборщики релизов используют систему доверительного списка для ограничения модификаций теми, что были предварительно одобрены.
• Разработка через саму сеть, позволяющая разработчикам оставаться анонимными, но при этом обеспечивать безопасность процесса разработки. Вся разработка I2P может происходить через I2P — используя распределенную систему контроля версий, IRC-чат, публичные веб-серверы, форумы для обсуждений (forum.i2p) и сайты распространения программного обеспечения, все доступные внутри I2P.

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

Атаки на реализацию (ошибки)

Как бы мы ни старались, большинство нетривиальных приложений содержат ошибки в дизайне или реализации, и I2P не является исключением. Могут существовать баги, которые могут быть использованы для атак на анонимность или безопасность коммуникации, работающей поверх I2P, неожиданными способами. Чтобы помочь противостоять атакам на дизайн или используемые протоколы, мы публикуем все проекты и документацию и запрашиваем обзоры и критику в надежде, что множество глаз улучшит систему. Мы не верим в безопасность через неясность.

Кроме того, код обрабатывается таким же образом, без особого сопротивления к переработке или отбрасыванию того, что не соответствует потребностям программной системы (включая простоту модификации). Документация по проектированию и реализации сети и программных компонентов является неотъемлемой частью безопасности, поскольку без неё маловероятно, что разработчики захотят потратить время на изучение программного обеспечения в достаточной степени, чтобы выявить недостатки и ошибки.

Наше программное обеспечение, в частности, может содержать ошибки, связанные с отказом в обслуживании из-за нехватки памяти (OOM), проблемы межсайтового скриптинга (XSS) в консоли router, а также другие уязвимости к нестандартным входным данным через различные протоколы.

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

Другие средства защиты

Списки блокировки

В некоторой степени I2P можно было бы улучшить, чтобы избегать узлов, работающих по IP-адресам, указанным в списках блокировки. Несколько списков блокировки широко доступны в стандартных форматах, содержащих организации, борющиеся с P2P, потенциальных противников на государственном уровне и других.

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

Блокировочные списки являются лишь частью (возможно, небольшой частью) целого арсенала защиты от вредоносной активности. В значительной степени система профилирования хорошо справляется с измерением поведения router’ов, так что нам не нужно доверять ничему в netDb. Однако можно сделать больше. Для каждой из областей в приведенном выше списке мы можем внести улучшения в обнаружение вредоносной активности.

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

В настоящее время с нашим программным обеспечением распространяется блокировочный список по умолчанию, содержащий только IP-адреса прошлых источников DOS-атак. Механизм автоматического обновления отсутствует. Если определенный диапазон IP-адресов начнет проводить серьезные атаки на сеть I2P, нам придется просить людей обновить их блокировочный список вручную через внешние каналы связи, такие как форумы, блоги и т.д.