Статистические результаты без проверки ложных срабатываний, скорее всего, неверны

Как и любая другая конфиденциальная сеть, Freenet является целью статистических атак для отслеживания активности ее пользователей.

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

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

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

Второе определение: Freenet нода - это Freenet, работающий на компьютере.

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

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

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

   6     6
6     6     6
   6     6
6     6     6
   6     6

В реальной сети на момент написания, количество соединений варьируется от 5 до 65, в зависимости от пропускной способности, доступной на нодах. Снимок распределения количества подключений можно увидеть на сайте статистики Freenet. От 10% до 80% соединений неактивны из-за перегрузки (backoff). Количество перегруженных нод увеличилось, когда группы пользователей начали исправлять свои ноды, чтобы запрашивать данные с большей скоростью, чем остальные.

Поэтому более реалистичная структура выглядит следующим образом:

       80  6   6
    70            6
  65                6
 60                  6
55                   13
50         24        13
42                   13
 39                 15
  36               18
    33           21
       30 28  24




        6   
    70      13

  55    7     20

     40   30

Отличие от идеализированной структуры, которая является наиболее важной для этой статьи, состоит в том, что почти каждая нода имеет по крайней мере одно соединение с такой нодой, у которой 8 или менее соединений. Также некоторые из этих соединений находятся в перенагруженном состоянии, таким образом, они фактически не используются, что легко уменьшает количество активных соединений до 4. Далее я буду называть такие узлы 'маленькими нодами'.

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

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

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

В качестве простого теста я скачал файл примерно 20 МБ на ноде с максимум 8 подключениями, а в среднем 6 активных соединений. Скорость загрузки была 2 MB в минуту. Увеличивая соединения, нода с 16 подключениями должна загружать около 8 МБ в минуту. Если вы наблюдаете загрузку 400 МБ, которая длится 2 часа или более, возможно, она идет от 'маленькой ноды' с примерно 11 соединениями (8-9, работающих в любое время).

Если вы видите, что 400 MB занимает всего 1 час, или 1 GB, загруженный за 2 часа, более вероятно, что источник имеет 16 или более соединений. С некоторыми хитростями, постаравшись исключить связь с 'маленькими нодами', можно увидеть загрузку 400 МБ, занимающую всего полчаса. Из-за асимметричных соединений небольшая нода обычно имеет медленную загрузку в сеть, но не медленное скачивание.

Проговорив эти основы, мы покажем все остальное с вариантами развития событий.

Предположим, что существует нода мониторинга, которая наблюдает за запросами, поступающими от узла с 50 подключениями. Размер файла составляет 400 МБ, загрузка длилась чуть более двух часов. Предположим, что вы наблюдали запросы на 4% файла от ноды с 50 подключениями.

В идеализированной единой сети без маршрутизации друг-друга (friend-of-a-friend, FOAF routing) вы можете предположить, что вы подключены к оригинальному источнику контента. Но комплексная проверка требует, чтобы вы исправили маршрутизацию FOAF и реальную неоднородную структуру и проверили наличие ложных срабатываний.

Насколько вероятно, что запросы были запущены одной из примерно 8 'маленьких нод', подключенных к обычной ноде с 50 подключениями?

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

Начнем с информации:

в промежутке от 15:50 UTC до 18:08 UTC нода Freenet запросила 383 уникальных блока. Узел Freenet сообщил в среднем о 51,3 соединениях. Для восстановления файла требуется не менее 12 723 блоков из 24 244 возможных.

• минимальное количество необходимых блоков: 12,723
• у ноды было 50 подключений
• наблюдатель увидел 383 запроса блоков, отправленных через соединение с вами

У ноды было 50 подключений.

На этот момент у около 25% нод было менее 10 соединений, 15% нод имели только от 10 до 15 соединений, остальные равномерно распределены между 16 и 70. Только около 20% нод имеют 50 и более соединений. Просмотрите ¹ сноску в конце, чтобы увидеть происхождения этих данных.

Предположения: нода была подключена к ноде с 7 соединениями, и эта нода запросила файл. У этой ноды вы были единственными с 50 или более соединениями. Потом была нода с 30 соединениями. Затем две ноды по 15 соединений в каждой и три по 7 в каждой.

• предположение: у создателя оригинального контента было 7 соединений
• предположение: распределение числа соединений было обычным

Это все еще типичная ситуация (не редкая).

Соединения создателя оригинального контента:

• нода: 50 соединений.
• A: 30 соединений.
• B: 15 соединений.
• C: 15 соединений.
• D: 7 соединений.
• E: 7 соединений.
• F: 7 соединений.

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

• предположение: у наблюдателя было 70 соединений (информация отсутствует)

Первый шаг: создатель оригинального контента запрашивает только минимально необходимые блоки файла, потому что все запросы успешны. В абсолютных цифрах: 12 723 запроса.

Они распределены по соединенным нодам. В типичной ситуации примерно одно из трех соединений отключается (backed off). Предположим, что маршрутизируемые хосты во время запроса являются нодой, A, C, D и E. B и F отключены (backed off).

Маршрутизируемые:

• нода: 50 соединений.
• A: 30 соединений.
• C: 15 соединений.
• D: 7 соединений.
• E: 7 соединений.

Теперь эти запросы распределяются через FOAF маршрутизацию не равномерно, а по количеству соединений. В сумме есть 119 соединений второй степени, таким образом, нода будет получать в среднем 50/119 * 12723 запросов, то есть 5345 запросов.

Теперь мы добрались до ноды. Давайте снова предположим типичное распределение. Поскольку она имеет много соединений, она будет придерживаться статистического числа нод из-за более сильной выборки. Она будет иметь 10 нод с 50 или более соединениями, один из которых является нодой-наблюдателем. Как обычно, 30% соединений будут отключены (backed off).

Маршрутизируемые соединения (не отключенные):

• 1 нода-наблюдатель: 70 соединений.
• 6 with 60 соединениями.
• 13 with 30 соединениями.
• 5 with 15 соединениями.
• 10 with 7 соединениями.

Отключенные соединения:

• (3 с 60 но отключенные).
• (7 с 30 но отключенные).
• (2 с 15 но отключенные).
• (3 с 7 но отключенные).

Это дает общее количество 965 подключений второго уровня через маршрутизируемые соединения, из которых наблюдатель видит 70. Таким образом, вы ожидаете, что наблюдатель увидит 5345 * 70/965 запросов: Общее количество полученных вами запросов умножается на численность подключений наблюдателя и делится на общее количество маршрутизируемых соединений второго уровня.

5345 * 70 / 965 = 387.720207253886.

Таким образом, это количество запросов подтверждается как вероятное ложное срабатывание. Это происходит в типичном сценарии, когда нода на самом деле не является тем, кто делает запрос.

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

Примечание: подобного расчета недостаточно, чтобы показать, что кто-то виноват. Это только показывает, что предоставленная информация НЕ МОЖЕТ показать вину, потому что очень вероятно, что это будет ложным срабатыванием.

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

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

minimum of 12,723 blocks of a total possible of 24,874. These 383 blocks represent 155% of the even, or expected, share of the minimum block (12,723) required to download the file and 79% of the even or expected

Те 3% файла, которые нода-наблюдатель видела, составляют 155% от того, что вы ожидали бы, если бы все соединения других нод имели одинаковое количество соединений. Но это ложное предположение, как вы уже можете видеть из примера распределения, приведенного для создателя контента. Количество запрашиваемых блоков масштабируется с учетом количества соединений каждой ноды. Таким образом, если бы у ноды-наблюдателя было 60 соединений, в то время как у обычной ноды было 20, нода-наблюдатель автоматически получала бы в 3 раза больше запросов, чем с равным разделением.

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

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

• Точное время и HTL каждого просматриваемого фрагмента, который был замечен с ноды

  • на каждый фрагмент: расположение ноды-наблюдателя в тот момент
  • на каждый фрагмент: расположение наблюдаемой ноды в тот момент
  • на каждый фрагмент: расположение всех соединений ноды-наблюдателя в тот момент
  • на каждый фрагмент: расположение всех наблюдаемой ноды в тот момент
  • на каждый фрагмент: манифест, которому он принадлежит (только размер + индекс в каком-то списке + количество фрагментов в манифесте)
  • на каждый фрагмент: маршрутизация части фрагмента ключа (расшифровка невозможна из этой информации => данные недоступны)

• Точная формула вероятности того, что наблюдаемая нода является действительной целью

• Точная формула вероятности того, что наблюдаемая нода не является ложноположительной

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

• Все фрагменты, полученные с HTL <= 16, что было бы совпадением, если HTL > 16

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

Определение: наблюдаемые фрагменты - это те, которые записаны, если получены от наблюдаемых или отправлены наблюдаемым нодам. А также те, которые будут записаны, если будут получены наблюдателем или отправлены наблюдателем.

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

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