Помним, что мы строим сеть в которой есть дядя, который может принудить делать все УЦ всё что угодно.
Пропустил это. Да, если сами центры сертификации начнут подменять все запросы, то данный метод становится бессильным. Но, по моиму субъективному мнению, такая кооперация и ЦС, и сервисов связи является достаточно сложной, потому как требуется не только подменить сертификат на стороне ЦС, но и перенаправлять все запросы на внешне похожие сервисы связи, или на оригинальные сервисы, с учётом того, если они смогут корректно воспринимать подменённый сертификат от самого ЦС.
Откуда им взяться в сети с глобальным наблюдателем?
Глобальный наблюдатель здесь и не фигурирует. Суть заключается в том, что идентификация любого рода, будь то знание публичного ключа или знание сетевого адреса не приведёт к деанонимизации самих действий в анонимной сети. Будет ровно такая же сложность обнаружения действий пользователя.
Причём забавно, что чем больше мы этих сервисов добавляем, тем сложнее становится алгоритм консенсуса "а кому из них мы можем доверять". Любой скомпроментированный УЦ автоматически ложит нам вообще всю сеть. Ну такое.
Алгоритм можно изменить на доверие к N-ому количеству сервисов из множества представленных. Сам алгоритм является вероятностным в любом случае, поэтому здесь оперируем лишь количественными характеристиками.
> Причем интересно то, что пользователям предлагается обменяться публичными ключами самостоятельно, что на самом эквивалентно обмену симметричными ключами и сводит весь смысл использования ассиметрии к нулю.
>> Не сводит. Как минимум асимметричная криптография защищает от пассивных атак злоумышленника, что нельзя сказать о симметричной криптографии.
Почему нельзя сказазать этого о симметричной? Откуда такой вывод 0_o?
Я говорил в контексте обмена ключами асимметричной и симметричной криптографий. При симметричной криптографии обмен ключами легко может привести к пассивным атакам на обычный их перехват, что нельзя сказать об асимметричной криптографии, где действуют лишь активные атаки на перехват ключей.
В принципе, как и симметричные, только в отличии от ассиметрии вообще не проблема обменяться энтропией при встрече хоть до конца жизни. В принципе, как и публичных ключей можно выдать хоть 100500 штук сразу, что опять же вызывает вопросы: нафига нам ассиметрия?
Как минимум простота обмена ключами: N(N-1)/2, вместо 2N, и существование идентификатора со связью 1 (публичный ключ) ко многим абонентам, а не 1 (сеансовый ключ) к одному абоненту.
Да - это сузит область прослушивания для глобального наблюдателя, но это не решит его проблему - он всё также не сможет определить кто из этих 100 получателей мой целевой.
Совершенно верно. Подобного же принципа придерживается сеть Herbivore, разделяющая участников сети по группам. Тем не менее у такого принципа есть нюанс в плане того, что децентрализованные сети сами по себе являются динамичными структурами. Если будут существовать в сети статичные узлы, то вероятность того, что пользователь общается именно с ними будет стремиться к нулю. Если общение двух абонентов частое, то из всего множества N=100 можно со временем по крупицам убирать узлы, которых ранее не существовало и оставлять только тех, которые до сих пор активно работают. В таком случае, будет существовать вероятность, при которой N будет стремиться к единице за счёт продолжительной связи между двумя абонентами. Когда же мы в качестве N берём все узлы в системе, такого уже не будет возникать.
Ассиметричная криптография сама по себе подтверждена MITM атакам и требует наличия полноценной инфраструктуры PKI (УЦ, CRL и вот это всё). При наличии глобального наблюдателя - анонимность слили в мусор. Наличие УЦ - это точки доверия, а значит анонимность в мусор.
В статье об этом говорится и о решении тоже:
Необходимо, чтобы все пользователи обменялись своими публичными ключами. Данное обстоятельство также может быть проблемой, потому как публичный ключ может быть подменён извне. Из-за децентрализованного характера сети, не допускается использование центров сертификации (ЦС). Тем не менее, можно воспользоваться N-ым количеством централизованных сервисов явно не связанных между собой для безопасной передачи публичных ключей.
---
Есть всего два вменяемыхсценария распределения ключей - это квантовое распределение ключей (менее надёжно)
Как вы защититесь от централизованных сервисов, которые и являются фактическими конечными получателями всех сообщений? Квантовые технологии лишь укрепят безопасность связи клиент-сервер, но не клиент-клиент.
Причем интересно то, что пользователям предлагается обменяться публичными ключами самостоятельно, что на самом эквивалентно обмену симметричными ключами и сводит весь смысл использования ассиметрии к нулю.
Не сводит. Как минимум асимметричная криптография защищает от пассивных атак злоумышленника, что нельзя сказать о симметричной криптографии. Данное свойство как раз и позволяет использовать множество централизованных сервисов для обмена публичными ключами. Если бы мы передавали симметричные ключи, то их можно было бы напрямую использовать без явной подмены.
Также надо помнить, что существует такая вещь, как "нагрузка на ключ", т.е. мы не можем передавать на одном ключе слишком много информации, т.к. каждый отправленный бит увеличивает вероятность раскрытия информации. А значит ещё нужно предусмотреть возможность обновления этих ключей...
Факт, только в какой пропорции происходит увеличение вероятности раскрытия информации, сколько потребуется памяти для её осуществления? На сколько знаю такие атаки также являются достаточно трудоёмкими и требуют огромного количества открытых и закрытых текстов для их осуществления. Асимметричные ключи могут жить фактически годами, но да, это не отменяет необходимости их смены/замены.
Если честно, не до конца понял, зачем нам полная связность между узлами. При условии посылки сообщений каждый период T подойдёт в принципе любая топология, вопрос только в скорости передачи.
Совершенно верно. Полная связность необходима лишь для упрощения самого механизма работы, т.к. это исключает маршрутизацию и, как следствие, дополнительный код. Целью статьи являлось, в первую очередь, создание минимальной анонимной сети. Все дальнейшие совершенствования лишь увеличили бы её количество кода. Так например, в основной моей анонимной сети, которую я пишу в свободное время, как раз неважна топология. Но в любом случае, какую бы мы топологию не выбрали, нагрузка на сеть будет всегда линейна. Если бы мы выбрали топологию "Звезда", то от одной точки к любой другой также бы сообщение доходило и также бы обрабатывалось.
И вот тут мы плавно переходим к третьей проблеме: стабильности работы сети. При наличии одного глобального периода Т возникает проблема доверенного источника времени.
Возможно тут я неправильно донёс мысль. В задаче на базе очередей период T выставляется локально и независимо для каждого узла в сети. Иными словами, они не кооперируют с тем, чтобы каждый подстраивался под конкретное время начала генерации. Асинхронность, либо даже изменение выставленного периода T, в сравнении со всеми другими узлами сети, не влияет на качество анонимизации трафика. Тем не менее, период T равный одному и тому же значению для всех узлов в сети как минимум способен приводить к отсутствию чётко заданных групп, которые можно было бы выделять по времени генерации. Поэтому я в описании задачи на базе очередей указывал именно константную T.
Примерно как-то так, надеюсь ответил на все вопросы и замечания.
Сколько не пытался исследовать способы снижения/предотвращения линейной нагрузки на сеть, с учётом задачи на базе очередей, всегда упирался в дальнейшие проблемы возможной деанонимизации. Скорее всего линейная нагрузка не может быть обойдена без сопутствующего снижения качества анонимности.
Как по мне - это сомнительный проект, не в плане его безопасности, а в плане рациональности отсутствия идентификаторов. Отсутствие идентификаторов никак не коррелирует с отсутствием метаданных. На это они собственно и метаданные, несвязанные напрямую с основной информацией, к коей относятся публичные ключи или их хеши.
Метаданные подобия отправления/получения сообщений, маршрутизации сообщений проект SimpleX Chat никак не скрывает, тобишь не обеспечивает сетевую анонимность вовсе. При этом, идентификация в лице публичных ключей могла бы обеспечить анонимность пользователей.
Плюс к этому, SimpleX Chat вместо проблемы обмена публичными ключами, приводит к проблеме обмена симметричными/сеансовыми ключами. В отличие от первых, которые хотя бы защищены от пассивных наблюдателей - вторые никак от этого не защищают. Следовательно встаёт вопрос обмена ключами связи, ведь теперь мы даже не можем использовать централизованные инфраструктуры, как это можно было делать с публичными ключами.
Если не учитывать первый пункт, с отсутствием сетевой анонимности, и второй пункт, с проблемой передачи сеансовых ключей, то проект кажется (т.к. не углублялся в его детали реализации, в его программную реализацию) вполне безопасным.
Да, шифр Хилла я просто привёл для примера, в отрыве от телеги. Что касается телеги, так просто сам факт проверки безопасности, основывающийся исключительно на атаке по шифртексту, является мягко говоря странным.
Как пример, шифр Хилла, где при матрице большого размера атака по шифртексту становится неэффективной, что нельзя сказать об атаке по открытому тексту, которая становится для самого шифра губительной вследствие большой линейности между открытым и закрытым текстами.
Почему так? Если есть только одна реализация, и в ней присутствует уязвимость, то она наследуется всеми клиентами.
Действительно, она будет наследоваться. Вопрос здесь находится в другом: Если приложение X пишется, то чисто количественно (с большей долей вероятности) в нём будет меньше уязвимостей, чем количественно в нескольких приложениях A, B, C, ... реализующих этот же самый фунционал иными методами, технологиями. Меньшее количество уязвимостей позволяет более быстро/оперативно/монолитно их исправить.
Это можно гипотетически сравнить на примере ядра Linux, которое разрабатывается монолитно и где существовали бы другие ядра Linux1, Linux2, Linux3, ..., которые бы обладали точно таким же функционалом и подходили бы точно также под любой дистрибутив, но просто были бы написаны например на других языках программирования.
Как это сочетается с тем, что писалось ранее:
Я говорю о чрезмерном внимании/апеллировании на общеизвеизвестных криптографических алгоритмах/протоколах, не углубляясь в детали собственной реализации приложения. Например, часто такие "безопасные" приложения могут говорить о том, что раз они используют протокол Диффи-Хеллмана, то никто кроме отправителя/получателя их информацию не может прочитать (ведь DH защищает от прослушивания). Или AES является стандартом шифрования мирового уровня, вся переписка безопасно передаётся по линиям связи (ведь никто ещё не взломал его). Иными словами, часто происходит апеллирование криптографической терминологией как магическими словами, образно придающими их приложениям безопасность.
Whats up. Повторяют чуть ли не на каждом слайде про end-to-end шифрование
Telegram. Часто вообще не волнует какая используется длина ключа (главное правило - чтобы оно было не малое), но во всех подобных мессенджерах это пишут как чуть ли не обязательную характеристику, для более весомого словца
Здесь я не осуждаю тот факт, что они используют AES, DH или что-то подобное, а осуждаю тот факт, что существует ещё масса других проблем, которая как раз возложена на плечи разработчиков подобных продуктов. Тут будет лучше процитировать Шнайера:
Читатели поверили, что криптография – род некоей магической пыли, которая покроет их программное обеспечение и сделает его неуязвимым. И они произносили магические заклинания вроде «128-битовый ключ» или «инфраструктура открытого ключа».
(Хоть он и говорил о своей книге, тем не менее схожая тенденция жива и по сей день)
Поэтому да, с криптографией, как консервативной наукой тут противоречий нет.
Я не говорил, что в телеграме отсутствует реклама. Пункт "Информационная гигиена" рассматривает мессенджеры в общем, в отрыве от одного лишь Телеграма.
Вот вы утверждаете, что если продукт бесплатный, то продукт это пользователь. Но в телеграме есть реклама в каналах, а также предложения оплатить премиум.
Телеграму ничего не мешает делать и то, и другое одновременно - собирать конфиденциальную информацию и выводить рекламу, скорее это даже будет очень хорошо сочетаться. Технически Телеграм способен собирать конфиденциальную информацию и ничего ему не мешает этого делать, кроме джентельменского слова. Но таковое слово не будет платить зарплаты, не будет поддерживать сервисы, не будет обновлять ПО и железо.
Так же как и другие догадки из статьи вроде "больше количество обновлений - больше шансов разработчикам добавить бекдор"
То есть не существует инцидентом связанных с тем, что в открытое программное обеспечение намеренно вставляют бэкдоры? Это достаточно классическая проблема информационной безопасности, когда мы не можем точно доверять буквально многим программам, как на уровне обычных багов, уязвимостей, так и на уровне намеренных бэкдоров не проанализировав код. Но если код изменяется часто, то и человеку становится легче пропустить саму уязвимость. Бэкдоры не всегда ясны и могут быть достаточно изощрёнными, например как был этот.
и "если государство не смогло полностью заблокировать мессенджер - оно тем самым специально загоняет туда людей".
Сотрудничество государства с телеграмом является гипотизой и я лишь даю оценку, что более вероятным событием является их сотрудничество на основании всех тех событий выдачи ключей, блокировок, пакета Яровой, более успешных блокировок Tor'a (гибридной сети, в отличие от централизованной) и тем, что в конечном счёте государство при всей своей первичной напышности и злости в один момент перестало обращать внимание на телеграм. Узнать на 100% существует сотрудничество или нет можно лишь будучи сторонами этого сотрудничества/несотрудничества.
что если продукт бесплатный, то продукт это пользователь
Удалил этот график с таблицей, вызывают больше споров из-за неграмотного их составления. Заменил на статистику из другого источника. Данные всё также более-менее совпадают.
Удалил этот график с таблицей, вызывают больше споров из-за неграмотного их составления. Заменил на статистику из другого источника. Данные всё также более-менее совпадают.
Я ещё прошу прокомментировать подход bitmessage. Узлы подписываю данные своим закрытым ключом и шифруют на открытый ключ получателя и посылают данные в блокчейн.
Bitmessage действительно производит операции с асимметричными ключами, но получившийся результат или производные от него данные в блокчейн bitmessage не посылает. У Bitmessage с криптовалютами, типа Bitcoin, схожесть заключается лишь в алгоритме PoW (proof-of-work). Но в отличие от криптовалют, где таковой алгоритм служит для выстраивания консенсуса, в Bitmessage PoW играет роль в борьбе со спамом. То есть, чтобы отправить сообщение в сеть Bitmessage - надо будет выполнить работу, затратив N-ое количество времени за которое машина будет пытаться решать сложную математическую задачу - нахождение правильного хеша.
Все узлы поддерживают синхронную реплику всего блокчейна и проверяют все появляющиеся там блоки, пытаясь их расшифровать своим закрытым ключом (я оставляю за скобками соль, искажение размера данных и другие стандартные приёмы)
Нет, узлы в Bitmessage просто содержат все полученные сообщение из сети в своём хранилище буквально пару дней, после чего эти сообщения удаляются. Здесь нет смысла в БЧ, потому как не существует связей между разными сообщениями. Например, в Bitcoin необходим блокчейн для сохранения последовательности транзаций и блоков. В Bitmessage такой задачи не требуется. За счёт этого и синхронизации узлов не требуется, достаточно лишь подключиться к нескольким узлам и запросить у них все имеющиеся сообщения. Т.к. в Bitmessage используется заливочная маршрутизация, то велика вероятность, что нужные сообщения будут иметься на тех узлах к которым клиент подключится.
Таким образом и внутренний и глобальный наблюдатель, насколько я понимаю, видят одинаковые картины
Совершенно верно.
ping-овать владельца ключа бессмысленно, т.к. он просто не будет отвечать тем, с кем он не заинтересован во взаимодействии.
Да, т.к. у Bitmessage архитектура построена не на принципе запрос-ответ, а на принципе пушей сообщений без дальнейших ответов, то собственно узнать истинного получателя становится проблемным событием (что нельзя сказать об отправителе данных). Тем не менее, такой подход урезает количество возможных применений, в которых нельзя создавать автоматические ответы. Даже если пользователь самостоятельно напишет программу для автоматических ответов, то вся фича Bitmessage начнёт испоряться, потому что ответ будет генерироваться каждый раз под новый запрос.
За счёт вышеописанного, Bitmessage сложно будет назвать полноценно анонимной сетью. Всё сводится к тому, что анонимная сеть - это в первую очередь механизм маршрутизации от отправителя к любому возможному сервису, будь то к внутреннему, как в I2P, или к возможному внешнему, как в Tor, и обратно к клиенту. В любом случае сервис связи генерирует самостоятельно ответ, а анонимная сеть, в свою очередь, является лишь способом доставки запросов и ответов между абонентами связи, не представляя дополнительной логики обработки/сохранения этих данных.
Если же рассматривать Bitmessage как связь "анонимная сеть+сервис связи", то мы придём к некоторому противоречию: в Bitmessage не существует множества сервисов связи, существует только один монолитный сервис - сама система, как раз и отвечающая на успешность/безуспешность пуша информации. Если появляется самостоятельный сервис-узел поверх сервиса-системы, то связь автоматически становится неанонимной для сервиса-узла, потому как он становится отправителем информации. Цепочка запрос-ответ будет рассматриваться глобальным наблюдателем как постоянное отправление данных с двух точек, что и выдаёт абонентов информации. В такой концепции Bitmessage более похож на безопасное хранилище данных, где существуют производители (producers) и потребители (consumers) данных. Таким образом, Bitmessage лишь обеспечивает анонимность получателей на половине передачи информации, что не скажешь об анонимных сетях, отвечающих за весь цикл передачи.
Мне кажется, эта идея в чем-то похожа на накопление энтропии.
Да, даже более, идея EIN и QBN была взята первично с Bitmessage. EIN и QBN используют один и тот же криптографический протокол, который основан на протоколе Bitmessage. Более подробно об этом протоколе можно почитать тут.
Но у EIN и QBN существуют отличия в сравнении с Bitmessage:
EIN и QBN являются анонимными сетями, в то время как Bitmessage - клиент-безопасным приложением. Из этого нельзя сказать, что какая-то сеть лучше или нет - потому что, они предназначены для разных целей. Невозможность сравнения связано с противоречием анонимности к безопасности. При развитии безопасных и анонимных сетевых коммуникаций всегда существует противоречие, которое гласит, что если сеть становится более анонимной - она становится менее безопасной и наоборот. Данное противоречие я хорошо показал в своей основной статье. Примером тому масса: 1) первая и первая^, а также пятая и пятая^ стадии анонимности противоположны друг другу как раз по безопасности и анонимности, 2) как только сеть, при своём развитии, повышает стадию анонимности с пятой до шестой, то она становится анонимной сетью, теряя элемент безопасности связи, 3) как только первичная децентрализация переходит в форму централизации, она теряет свою безопасность, но повышает качество анонимности. О данных стадиях достаточно много рассказывать, тут думаю легче будет обратиться к "Теории строения скрытых систем".
EIN использует более модифицированную версию протокола Bitmessage, чем тот же QBN, за счёт множественного шифрования, которого не существует в Bitmessage. Можно было бы сказать, что множественное шифрование определяет является ли сеть анонимной или нет, но это неверно. QBN не имеет множественного шифрования, но является анонимной сетью. Суть здесь заключается как раз в запутывающей маршрутизации. Для EIN - это механизм увеличения энтропии, для QBN - это очереди с периодами. У Bitmessage подобных механизмов не существует, а сама по себе слепая маршрутизация не представляет анонимность, она является лишь одним из возможных конструктов анонимности (но достаточно хорошим, поэтому часто Bitmessage и причисляют к анонимным сетям). О конструктах анонимности можно почитать тут.
А ещё есть не прозрачные блокчейны, в механику работых которых я не вникал, но вот например XMR (Monero) утверждают что проследить их транзакции можно только в редких случаях.
Если не ошибаюсь, принцип работы Monero, со стороны сетевых коммуникаций, напоминает работу анонимной сети Mixminion, когда транзакции перемешиваются между собой, переходя от одного маршрутизатора к другому. На выходе становится проблемным определить какая транзакция кому назначалась. В любом случае, Mixminion не является теоретически доказуемой анонимной сетью и если будет существовать глобальный наблюдатель, то с течением времени он может ограничивать круг возможных лиц участвующих в транзакциях.
Примерно это же пишут в википедии:
Анонимность транзакций Monero не является абсолютной. Если атакующий контролирует значительную часть сети, то при определённом стечении обстоятельств он сможет деанонимизировать часть транзакций
У Monero ещё существуют колцьевые подписи, но на сколько знаю, они защищают не от просмотра трафика, тобишь не от внешнего/глобального наблюдателя, а конкретно от узлов-майнеров - внутренних атакующих, которые должны каким-то образом вычислить кто и кому отправляет ту или иную транзакцию.
Хорошие вопросы. В первую очередь я отвечу, что все вышеописанные пункты действительно в той или иной мере повышают качество анонимности узлов сети, но определённые из них содержат своё но.
Пункт 1
что если искомый наблюдатель обладает не одним, а несколькими узлами сети с одинаковым публичным ключом (так можно делать в TOR, вероятно, и в I2P, но я не пробовал). Вроде как это даже использовали для распределения нагрузки и для защиты серверов от обнаружения.
Сначала проанализирую такое действие со стороны Tor и I2P. Если один пользователь обладает несколькими узлами в сети, то они также должны, в лучшем случае, располагаться географически удалённо друг от друга, чтобы нельзя было выявить человека по его расположению, методом уменьшения "радиуса" подконтрольных ему узлов. Но в таком случае, человек должен как-то удалённо связывать один узел с другим узлом для синхронизации хранимых данных. А это приведёт к тому, что такой способ автоматически создаст зависимые связи, которые статистически можно будет выявить глобальному наблюдателю. Допустим, какой-либо клиент отправит запрос узлу1, узел1 сохранит в БД1 действие от запроса, отправит ответ клиенту, а далее, для синхронизации, узел1 должен будет также отправить узлу2 сохранённый результат, для такого же сохранения в БД2. Либо для синхронизации может использоваться сервер, но сути дело это не меняет. Подобное действие может приводить к более пристальному анализу узла1 и узла2 (либо сервера), т.к. они связаны между собой не только клиентскими запросами, но и постоянной кооперацией между собой. Для подобного вида атаки достаточным является существование глобального наблюдателя и N-ое количество времени.
Теперь проанилизируем такое действие со стороны описанной мной сети. В отличие от Tor и I2P у которых существует направленная маршрутизация (будь то луковая или чесночная), в описанной мной сети (назовём её далее EIN - entropy increase network) маршрутизация является заливочной (слепой). Последняя отличается отсутствием понимания где находится получатель, и отправленный пакет, можно сказать, сам ищет своего получателя блуждая по всей сети. В таком случае, если будут существовать два узла с одним и тем же публичным ключом, то оба этих узла будут генерировать ответ, потому как запрос дойдёт до каждого (в отличие от Tor и I2P, которые выберут только один узел). К чему это приведёт? Т.к. EIN является теоретически доказуемой сетью, то такое поведение никак не приведёт к деанонимизации субъектов со стороны пассивного глобального наблюдателя. Тем не менее, если злоумышленник является внутренним активным атакующим и самостоятельно способен отправлять запросы, то это даст ему дополнительную информацию о том, что существует целых два узла обладающих одним и тем же публичным ключом. Как следствие, это упростит деанонимизацию при условии, что существует кооперация внутреннего активного активного атакующего с активным глобальным наблюдателем, потому как упрощается задача блокировки участников с целью выявления кому принадлежит публичный ключ - если на очередной запрос злоумышленник получит уже не два, а только один ответ, то последний заблокированный пользователь будет относиться к проверяемому ключу. Таким образом, для сети EIN такое действие будет являться скорее негативным, чем позитивным, что нельзя однозначно сказать о Tor и I2P, потому как с одной стороны такое действие может приводить к неоднозначности используемого маршрута, но с другой стороны создаёт дополнительные связи между конечными узлами.
Пункт 2
что если и получатель и источник выстраивают по нескольку разных маршрутов до «точек рандеву в терминологии TOR» (основная идея I2P) и при разрыве любого количества, кроме всех, связь сохраняется. Как их отключать тогда? (можно свет погасить в отдельно взятой стране, потом в городе и т. д. но предыдущий пункт!)
Если рассматривать данный случай со стороны Tor и I2P, то такой подход особо не улучшает качество анонимности при условии существования глобального наблюдателя, потому как для глобального наблюдателя остаются постоянными точки "взаимодействия", узлы, которые всегда остаются статичными и никогда не изменяются, сколько бы итераций изменения маршрутов не происходило. Таким образом, разрыв связи может происходить за счёт удаления одного из абонента, будь то отправителя или получателя. Такое возможно, когда сам же провайдер связи (или множество провайдеров связи) является активным глобальным наблюдателем. В таком случае, провайдер может просто запретить любые запросы-ответы направленные на или полученные от конкретного узла. Таким образом и может быть осуществлено отключение узла от сети. Существование нескольких узлов с одним и тем же публичным ключом усложняет однозначность блокирования, но тут нужно учитывать ещё несколько факторов: 1) глобальный наблюдатель может учитывать сколько раз один и тот же узел участвовал в маршрутизации. За счёт этого глобальный наблюдатель может разграничить узлы, которые применялись в маршрутах, и узлы которые являлись непосредственно абонентами за счёт неравных пропорций; 2) внутренний активный атакующий может учитывать разницу времени доставки пакета при большом количестве отправляемых данных на большом промежутке времени при очередном блокировании узла. Но такая атака наиболее эффективна, когда существует разделение между маршрутизирующими узлами и получателями, как в сети Tor.
В EIN не существует маршрутов подобных Tor и I2P. В отличие от последних, в которых существует точно заданные маршруты, в EIN пакет пробегается по всем узлам от одного к другому, до тех пор пока не найдёт своего получателя, или пока не пробежит всю сеть и не будет ею забыт. В следствие этого, можно утверждать, что в EIN уже существует много разных маршрутов до точки назначения. Поэтому атаки, направленные на разрыв связей между узлами, в EIN не особо эффективны. Тем не менее, эффективны атаки направленные на отключение самих узлов от сети с целью их дальнейшей деанонимизации (посредством активным атак). Также, как было описано в пункте 1, существование нескольких узлов с одним публичным ключом не повысит анонимность, а скорее наоборот её понизит для EIN.
Пункт 3 и Пункт 4
Что если узлы обмениваются мусорным трафиком, скрывая таким образом факт передачи настоящего сообщения (есть точно в i2p)?
Что если, маршруты могут вести к «мусорным узлам», которые периодически отправляют, принимают трафик и отвечают на ping? Просто ping‑ом не обойтись (это тоже в i2p).
В таком случае качество анонимности действительно повысится. Но вопрос здесь скорее находится в плоскости - как этот мусорный трафик распределяется? От ответа на этот вопрос и будет зависеть на сколько качественней будет анонимность.
Так например, если мусорный трафик будет появляться от каждого узла в сети и создаваться в случайные периоды времени со случайными маршрутами, то при более длительном анализе (со стороны конечно же глобального наблюдателя) можно будет выявлять корреляцию между шумом (мусорным трафиком) и истинным трафиком. Такое может быть осуществленно, если между абонентами связь держится продолжительное время, допустим при передаче большого количества данных. В таком случае, глобальный наблюдатель, хоть и в менее явном виде, но будет замечать более статичный трафик.
В случае же с EIN мусорный трафик генерируется исключительно на базе механизма вероятностной маршрутизации, не для того, чтобы скрыть истинность связи, а для того, чтобы продлить итерацию увеличения энтропии. В таком случае, сколько бы истинного трафика не генерировалось, энтропия будет его поглощать.
Приведу также ещё один пример с мусорным трафиком. В моих статьях я очень часто рассказывал об анонимной сети на базе очередей (назовём её QBN - queue based network). Интересной её особенностью является то, что мусорный трафик генерируется исключительно в определённое время со всем истинным трафиком. Так например, если узел собирается что-то отправлять, то он генерирует запрос или ответ, в ином случае он генерирует ложный пакет. В отличие от I2P и EIN, в которых мусорный трафик накладывается в той или иной мере на истинный, в QBN мусорный трафик чередуется с истинным.
Пункт 5
А более высокоуровневый «ping» в виде письма в котором заинтересован хозяин публичного ключа, может встретить противодействие в виде случайного времени ответа. Вы не будете знать получил ли хозяин ключа ваше сообщение, пока не пройдёт слишком много времени (кстати, freenet)
Это также может повысить уровень анонимности. Например, в EIN такой механизм применяется для успешности накапливания энтропии. Подход аккумулирования сообщений, применяемый в Mixminion сетях, также приводит к задержкам в соединениях. В QBN сами задержки являются основой функционирования сети. Но во всех этих случаях, задержки применяются с разной целью: 1) чтобы накопить энтропию для отправления сообщения, 2) чтобы накопить количество сообщения для дальнейшей маршрутизации, 3) чтобы не отклоняться от периода генераций сообщений.
Поэтому да, задержки они часто помогают в анонимизации трафика, но часто идут в совокупности с чем-то. И конечно же естественным минусом таковых задержек является медленная передача данных.
-----
Вроде бы ответил на все вопросы. Сами ответы получились достаточно обширными. Если что-то непонятно или что-то нужно будет более детально пояснить, то можно продолжить здесь или в чате ВК, если будет проще.
Я предполагаю в качестве активного злоумышленника X конкретно сервисы связи, а не какого-то локального злоумышленника, который просто подключается к одному из узлов. С последним проблем вообще нет, потому что связь между клиентом и централизованными сервисами уже безопасна, исходя из существования центров сертификации. Далее, если мы отправляем нескольким несвязанным сервисам связи X1, X2, X3, ... один и тот же ключ PubT, то вероятность того, что все ключи или большая их часть будет подменена - стремится к нулю при увеличении количества участвующих сервисов. Перечитайте пожалуйста ещё раз всё, что я описал выше. Такое ощущение, что вы даже не хотите видеть написанное и цепляетесь вне контекста к любой непонравившейся вам фразе.
В более общем ответе, инструкция от меня может быть уже такой: 1. Предполагается, что у A и C есть своя пара открытый/закрытый ключ. Для A - это (PubA/PrivA), для C- это (PubC/PrivC), 2. Пользователь C генерирует временную пару открытый/закрытый ключ - (PubT/PrivT), 3. Пользователь C отправляет открытый ключ PubT на несколько централизованных сервисов прямо несвязанных между собой, допустим на 5 разных сервисов. Под несвязанностью понимается отсутствие общих директоров, инфраструктуры и прочего, допустим ВК и Mail.ru - будут считаться за связанные сервисы, 4. Пользователь A получает открытые ключи PubT1, PubT2, PubT3, PubT4, PubT5 с централизованных сервисов соответственно 1, 2, 3, 4, 5, 5. Пользователь A просматривает открытые ключи и сравнивает все ли они одинаковые, 6. Если больше половины ключей расходится (допустим 3/2) - пользователи A и C выбирают совершенно новые 5 централизованных сервисов и начинают процедуру заново, 7. Если меньше половины ключей расходится (допустим 4/1) - пользователи A и C выбирают под несогласованный публичный ключ новый сервис связи и повторяют процедуру конкретно с ним, 8. В конечном итоге, пользователь A получит от C временный публичный ключ PubT. 9. Далее пользователь A зашифровывает открытым ключом PubT свой открытый ключ PubA и отправит полученный результат также на эти 5 сервисов, CPubA = E(PubT, PubA); 10. Пользователь C просматривает корректность получения CPubA. Если шифрованные ключи расходятся, то применяются процедуры 6/7 направленные на уже шифрованную версию ключей, 11. При успешном получении шифрованного публичного ключа CPubA, пользователь C применяет временный закрытый ключ PrivT и расшифровывает CPubA, получая тем самым публичный ключ PubA, PubA = D(PrivT, CPubA); 12. Далее, пользователь C подписывает свой публичный ключ PubC временным закрытым ключои PrivT, и шифрует результат ранее полученным публичным ключом PubA. Результат подписания и шифрования пользователь C отправляет пользователю A. Пользователь C может использовать любой сервис связи, т.к. в данном случае уже нельзя будет корректно подменить информацию за счёт необходимости нарушения подписи для PrivT, SPubC =S(PrivT, PubC); CSPubC = E(PubA, SPubC); 13. Пользователь A принимает CSPubC, расшифровывает его своим публичным ключом PubA, получая тем самым SPubC. Далее пользователь A проверяет подпись, используя временный публичный ключ PubT, получая тем самым истинность публичного ключа PubC.
Таким образом, пользователи A и C обменялись своими публичными ключами, воспользовавшись сторонними централизованными сервисами связи. При этом, в вышеописанном протоколе централизованные сервисы так и не узнали истинные публичные ключи, которые будут применяться в качестве дальнейших идентификаторов ID в анонимной сети, а потому и не смогут их использовать для связывания с сетевым адресом IP. У централизованных сервисов в полномочии остались только PubT, CPubA, CSPubC. Этапы 6/7 защищают от активных атак за счёт однотипных действий на несвязанных сервисах.
В данном протоколе присутствуют следующие проблемы: 1. Протокол является вероятностным. Существует вероятность, что централизованные сервисы смогут связаться и успешно подменять публичные ключи хотя бы для 4/1 сервисов, что будет достаточно, т.к. последний сервис будет считаться уже некорректным. 2. Если A или C является злоумышленником, то он легко найдёт идентификатор ID своего абонента. При сотрудничестве с сервисами связи, он сможет легко узнать и IP абонента. Таким образом, легко свяжет полученный публичный ключ с сетевым адресом. 3. Предполагается, что пользователи A и C уже друг друга идентифицируют на выбираемых ими централизованных сервисах. В противном случае, пользователи A и C не будут знать кому отправляют и от кого получают ключи.
Государство - это лишь один из возможных потребителей конфиденциальной информации. Наиболее же важным потребителем становятся рекламные сервисы, собственно которые и выдают на выходе таргетированную рекламу. Такие сервисы становятся очень выгодны с экономической точки зрения социальным сетям, мессенджерам, форумам и т.п. централизованным сервисам. Можно сказать, что государства в такой иерархии играют скорее второстепенную роль.
То есть, отпечаток пальца или скан лица не переводятся в цифровой вид и их нельзя будет скопировать? Магия будущего?
И как понимаю опечатка в "парольные".
Пропустил это. Да, если сами центры сертификации начнут подменять все запросы, то данный метод становится бессильным. Но, по моиму субъективному мнению, такая кооперация и ЦС, и сервисов связи является достаточно сложной, потому как требуется не только подменить сертификат на стороне ЦС, но и перенаправлять все запросы на внешне похожие сервисы связи, или на оригинальные сервисы, с учётом того, если они смогут корректно воспринимать подменённый сертификат от самого ЦС.
Глобальный наблюдатель здесь и не фигурирует. Суть заключается в том, что идентификация любого рода, будь то знание публичного ключа или знание сетевого адреса не приведёт к деанонимизации самих действий в анонимной сети. Будет ровно такая же сложность обнаружения действий пользователя.
Алгоритм можно изменить на доверие к N-ому количеству сервисов из множества представленных. Сам алгоритм является вероятностным в любом случае, поэтому здесь оперируем лишь количественными характеристиками.
Я говорил в контексте обмена ключами асимметричной и симметричной криптографий. При симметричной криптографии обмен ключами легко может привести к пассивным атакам на обычный их перехват, что нельзя сказать об асимметричной криптографии, где действуют лишь активные атаки на перехват ключей.
Как минимум простота обмена ключами: N(N-1)/2, вместо 2N, и существование идентификатора со связью 1 (публичный ключ) ко многим абонентам, а не 1 (сеансовый ключ) к одному абоненту.
Совершенно верно. Подобного же принципа придерживается сеть Herbivore, разделяющая участников сети по группам. Тем не менее у такого принципа есть нюанс в плане того, что децентрализованные сети сами по себе являются динамичными структурами. Если будут существовать в сети статичные узлы, то вероятность того, что пользователь общается именно с ними будет стремиться к нулю. Если общение двух абонентов частое, то из всего множества N=100 можно со временем по крупицам убирать узлы, которых ранее не существовало и оставлять только тех, которые до сих пор активно работают. В таком случае, будет существовать вероятность, при которой N будет стремиться к единице за счёт продолжительной связи между двумя абонентами. Когда же мы в качестве N берём все узлы в системе, такого уже не будет возникать.
В статье об этом говорится и о решении тоже:
---
Как вы защититесь от централизованных сервисов, которые и являются фактическими конечными получателями всех сообщений? Квантовые технологии лишь укрепят безопасность связи клиент-сервер, но не клиент-клиент.
Не сводит. Как минимум асимметричная криптография защищает от пассивных атак злоумышленника, что нельзя сказать о симметричной криптографии. Данное свойство как раз и позволяет использовать множество централизованных сервисов для обмена публичными ключами. Если бы мы передавали симметричные ключи, то их можно было бы напрямую использовать без явной подмены.
Факт, только в какой пропорции происходит увеличение вероятности раскрытия информации, сколько потребуется памяти для её осуществления? На сколько знаю такие атаки также являются достаточно трудоёмкими и требуют огромного количества открытых и закрытых текстов для их осуществления. Асимметричные ключи могут жить фактически годами, но да, это не отменяет необходимости их смены/замены.
Совершенно верно. Полная связность необходима лишь для упрощения самого механизма работы, т.к. это исключает маршрутизацию и, как следствие, дополнительный код. Целью статьи являлось, в первую очередь, создание минимальной анонимной сети. Все дальнейшие совершенствования лишь увеличили бы её количество кода. Так например, в основной моей анонимной сети, которую я пишу в свободное время, как раз неважна топология. Но в любом случае, какую бы мы топологию не выбрали, нагрузка на сеть будет всегда линейна. Если бы мы выбрали топологию "Звезда", то от одной точки к любой другой также бы сообщение доходило и также бы обрабатывалось.
Возможно тут я неправильно донёс мысль. В задаче на базе очередей период T выставляется локально и независимо для каждого узла в сети. Иными словами, они не кооперируют с тем, чтобы каждый подстраивался под конкретное время начала генерации. Асинхронность, либо даже изменение выставленного периода T, в сравнении со всеми другими узлами сети, не влияет на качество анонимизации трафика. Тем не менее, период T равный одному и тому же значению для всех узлов в сети как минимум способен приводить к отсутствию чётко заданных групп, которые можно было бы выделять по времени генерации. Поэтому я в описании задачи на базе очередей указывал именно константную T.
Примерно как-то так, надеюсь ответил на все вопросы и замечания.
Сколько не пытался исследовать способы снижения/предотвращения линейной нагрузки на сеть, с учётом задачи на базе очередей, всегда упирался в дальнейшие проблемы возможной деанонимизации. Скорее всего линейная нагрузка не может быть обойдена без сопутствующего снижения качества анонимности.
Как по мне - это сомнительный проект, не в плане его безопасности, а в плане рациональности отсутствия идентификаторов. Отсутствие идентификаторов никак не коррелирует с отсутствием метаданных. На это они собственно и метаданные, несвязанные напрямую с основной информацией, к коей относятся публичные ключи или их хеши.
Метаданные подобия отправления/получения сообщений, маршрутизации сообщений проект SimpleX Chat никак не скрывает, тобишь не обеспечивает сетевую анонимность вовсе. При этом, идентификация в лице публичных ключей могла бы обеспечить анонимность пользователей.
Плюс к этому, SimpleX Chat вместо проблемы обмена публичными ключами, приводит к проблеме обмена симметричными/сеансовыми ключами. В отличие от первых, которые хотя бы защищены от пассивных наблюдателей - вторые никак от этого не защищают. Следовательно встаёт вопрос обмена ключами связи, ведь теперь мы даже не можем использовать централизованные инфраструктуры, как это можно было делать с публичными ключами.
Если не учитывать первый пункт, с отсутствием сетевой анонимности, и второй пункт, с проблемой передачи сеансовых ключей, то проект кажется (т.к. не углублялся в его детали реализации, в его программную реализацию) вполне безопасным.
Да, шифр Хилла я просто привёл для примера, в отрыве от телеги. Что касается телеги, так просто сам факт проверки безопасности, основывающийся исключительно на атаке по шифртексту, является мягко говоря странным.
Как пример, шифр Хилла, где при матрице большого размера атака по шифртексту становится неэффективной, что нельзя сказать об атаке по открытому тексту, которая становится для самого шифра губительной вследствие большой линейности между открытым и закрытым текстами.
Действительно, она будет наследоваться. Вопрос здесь находится в другом:
Если приложение X пишется, то чисто количественно (с большей долей вероятности) в нём будет меньше уязвимостей, чем количественно в нескольких приложениях A, B, C, ... реализующих этот же самый фунционал иными методами, технологиями. Меньшее количество уязвимостей позволяет более быстро/оперативно/монолитно их исправить.
Это можно гипотетически сравнить на примере ядра Linux, которое разрабатывается монолитно и где существовали бы другие ядра Linux1, Linux2, Linux3, ..., которые бы обладали точно таким же функционалом и подходили бы точно также под любой дистрибутив, но просто были бы написаны например на других языках программирования.
Я говорю о чрезмерном внимании/апеллировании на общеизвеизвестных криптографических алгоритмах/протоколах, не углубляясь в детали собственной реализации приложения. Например, часто такие "безопасные" приложения могут говорить о том, что раз они используют протокол Диффи-Хеллмана, то никто кроме отправителя/получателя их информацию не может прочитать (ведь DH защищает от прослушивания). Или AES является стандартом шифрования мирового уровня, вся переписка безопасно передаётся по линиям связи (ведь никто ещё не взломал его). Иными словами, часто происходит апеллирование криптографической терминологией как магическими словами, образно придающими их приложениям безопасность.
Здесь я не осуждаю тот факт, что они используют AES, DH или что-то подобное, а осуждаю тот факт, что существует ещё масса других проблем, которая как раз возложена на плечи разработчиков подобных продуктов. Тут будет лучше процитировать Шнайера:
Поэтому да, с криптографией, как консервативной наукой тут противоречий нет.
Я не говорил, что в телеграме отсутствует реклама. Пункт "Информационная гигиена" рассматривает мессенджеры в общем, в отрыве от одного лишь Телеграма.
Телеграму ничего не мешает делать и то, и другое одновременно - собирать конфиденциальную информацию и выводить рекламу, скорее это даже будет очень хорошо сочетаться. Технически Телеграм способен собирать конфиденциальную информацию и ничего ему не мешает этого делать, кроме джентельменского слова. Но таковое слово не будет платить зарплаты, не будет поддерживать сервисы, не будет обновлять ПО и железо.
То есть не существует инцидентом связанных с тем, что в открытое программное обеспечение намеренно вставляют бэкдоры? Это достаточно классическая проблема информационной безопасности, когда мы не можем точно доверять буквально многим программам, как на уровне обычных багов, уязвимостей, так и на уровне намеренных бэкдоров не проанализировав код. Но если код изменяется часто, то и человеку становится легче пропустить саму уязвимость. Бэкдоры не всегда ясны и могут быть достаточно изощрёнными, например как был этот.
Сотрудничество государства с телеграмом является гипотизой и я лишь даю оценку, что более вероятным событием является их сотрудничество на основании всех тех событий выдачи ключей, блокировок, пакета Яровой, более успешных блокировок Tor'a (гибридной сети, в отличие от централизованной) и тем, что в конечном счёте государство при всей своей первичной напышности и злости в один момент перестало обращать внимание на телеграм. Узнать на 100% существует сотрудничество или нет можно лишь будучи сторонами этого сотрудничества/несотрудничества.
Также разрешу себе подушнить, товар != продукт.
Удалил этот график с таблицей, вызывают больше споров из-за неграмотного их составления. Заменил на статистику из другого источника. Данные всё также более-менее совпадают.
Удалил этот график с таблицей, вызывают больше споров из-за неграмотного их составления. Заменил на статистику из другого источника. Данные всё также более-менее совпадают.
Статистику брал от сюда: https://inclient.ru/telegram-stats/ (Сколько каналов и чатов в Telegram)
Как я понял, под этими цифрами понимается не аудитория, а активность аудитории.
Бесспорно
Bitmessage действительно производит операции с асимметричными ключами, но получившийся результат или производные от него данные в блокчейн bitmessage не посылает. У Bitmessage с криптовалютами, типа Bitcoin, схожесть заключается лишь в алгоритме PoW (proof-of-work). Но в отличие от криптовалют, где таковой алгоритм служит для выстраивания консенсуса, в Bitmessage PoW играет роль в борьбе со спамом. То есть, чтобы отправить сообщение в сеть Bitmessage - надо будет выполнить работу, затратив N-ое количество времени за которое машина будет пытаться решать сложную математическую задачу - нахождение правильного хеша.
Нет, узлы в Bitmessage просто содержат все полученные сообщение из сети в своём хранилище буквально пару дней, после чего эти сообщения удаляются. Здесь нет смысла в БЧ, потому как не существует связей между разными сообщениями. Например, в Bitcoin необходим блокчейн для сохранения последовательности транзаций и блоков. В Bitmessage такой задачи не требуется. За счёт этого и синхронизации узлов не требуется, достаточно лишь подключиться к нескольким узлам и запросить у них все имеющиеся сообщения. Т.к. в Bitmessage используется заливочная маршрутизация, то велика вероятность, что нужные сообщения будут иметься на тех узлах к которым клиент подключится.
Совершенно верно.
Да, т.к. у Bitmessage архитектура построена не на принципе запрос-ответ, а на принципе пушей сообщений без дальнейших ответов, то собственно узнать истинного получателя становится проблемным событием (что нельзя сказать об отправителе данных). Тем не менее, такой подход урезает количество возможных применений, в которых нельзя создавать автоматические ответы. Даже если пользователь самостоятельно напишет программу для автоматических ответов, то вся фича Bitmessage начнёт испоряться, потому что ответ будет генерироваться каждый раз под новый запрос.
За счёт вышеописанного, Bitmessage сложно будет назвать полноценно анонимной сетью. Всё сводится к тому, что анонимная сеть - это в первую очередь механизм маршрутизации от отправителя к любому возможному сервису, будь то к внутреннему, как в I2P, или к возможному внешнему, как в Tor, и обратно к клиенту. В любом случае сервис связи генерирует самостоятельно ответ, а анонимная сеть, в свою очередь, является лишь способом доставки запросов и ответов между абонентами связи, не представляя дополнительной логики обработки/сохранения этих данных.
Если же рассматривать Bitmessage как связь "анонимная сеть+сервис связи", то мы придём к некоторому противоречию: в Bitmessage не существует множества сервисов связи, существует только один монолитный сервис - сама система, как раз и отвечающая на успешность/безуспешность пуша информации. Если появляется самостоятельный сервис-узел поверх сервиса-системы, то связь автоматически становится неанонимной для сервиса-узла, потому как он становится отправителем информации. Цепочка запрос-ответ будет рассматриваться глобальным наблюдателем как постоянное отправление данных с двух точек, что и выдаёт абонентов информации. В такой концепции Bitmessage более похож на безопасное хранилище данных, где существуют производители (producers) и потребители (consumers) данных. Таким образом, Bitmessage лишь обеспечивает анонимность получателей на половине передачи информации, что не скажешь об анонимных сетях, отвечающих за весь цикл передачи.
Да, даже более, идея EIN и QBN была взята первично с Bitmessage. EIN и QBN используют один и тот же криптографический протокол, который основан на протоколе Bitmessage. Более подробно об этом протоколе можно почитать тут.
Но у EIN и QBN существуют отличия в сравнении с Bitmessage:
EIN и QBN являются анонимными сетями, в то время как Bitmessage - клиент-безопасным приложением. Из этого нельзя сказать, что какая-то сеть лучше или нет - потому что, они предназначены для разных целей. Невозможность сравнения связано с противоречием анонимности к безопасности. При развитии безопасных и анонимных сетевых коммуникаций всегда существует противоречие, которое гласит, что если сеть становится более анонимной - она становится менее безопасной и наоборот. Данное противоречие я хорошо показал в своей основной статье. Примером тому масса: 1) первая и первая^, а также пятая и пятая^ стадии анонимности противоположны друг другу как раз по безопасности и анонимности, 2) как только сеть, при своём развитии, повышает стадию анонимности с пятой до шестой, то она становится анонимной сетью, теряя элемент безопасности связи, 3) как только первичная децентрализация переходит в форму централизации, она теряет свою безопасность, но повышает качество анонимности. О данных стадиях достаточно много рассказывать, тут думаю легче будет обратиться к "Теории строения скрытых систем".
EIN использует более модифицированную версию протокола Bitmessage, чем тот же QBN, за счёт множественного шифрования, которого не существует в Bitmessage. Можно было бы сказать, что множественное шифрование определяет является ли сеть анонимной или нет, но это неверно. QBN не имеет множественного шифрования, но является анонимной сетью. Суть здесь заключается как раз в запутывающей маршрутизации. Для EIN - это механизм увеличения энтропии, для QBN - это очереди с периодами. У Bitmessage подобных механизмов не существует, а сама по себе слепая маршрутизация не представляет анонимность, она является лишь одним из возможных конструктов анонимности (но достаточно хорошим, поэтому часто Bitmessage и причисляют к анонимным сетям). О конструктах анонимности можно почитать тут.
Если не ошибаюсь, принцип работы Monero, со стороны сетевых коммуникаций, напоминает работу анонимной сети Mixminion, когда транзакции перемешиваются между собой, переходя от одного маршрутизатора к другому. На выходе становится проблемным определить какая транзакция кому назначалась. В любом случае, Mixminion не является теоретически доказуемой анонимной сетью и если будет существовать глобальный наблюдатель, то с течением времени он может ограничивать круг возможных лиц участвующих в транзакциях.
Примерно это же пишут в википедии:
У Monero ещё существуют колцьевые подписи, но на сколько знаю, они защищают не от просмотра трафика, тобишь не от внешнего/глобального наблюдателя, а конкретно от узлов-майнеров - внутренних атакующих, которые должны каким-то образом вычислить кто и кому отправляет ту или иную транзакцию.
Примерно как-то так.
Хорошие вопросы. В первую очередь я отвечу, что все вышеописанные пункты действительно в той или иной мере повышают качество анонимности узлов сети, но определённые из них содержат своё но.
Пункт 1
Сначала проанализирую такое действие со стороны Tor и I2P.
Если один пользователь обладает несколькими узлами в сети, то они также должны, в лучшем случае, располагаться географически удалённо друг от друга, чтобы нельзя было выявить человека по его расположению, методом уменьшения "радиуса" подконтрольных ему узлов. Но в таком случае, человек должен как-то удалённо связывать один узел с другим узлом для синхронизации хранимых данных. А это приведёт к тому, что такой способ автоматически создаст зависимые связи, которые статистически можно будет выявить глобальному наблюдателю. Допустим, какой-либо клиент отправит запрос узлу1, узел1 сохранит в БД1 действие от запроса, отправит ответ клиенту, а далее, для синхронизации, узел1 должен будет также отправить узлу2 сохранённый результат, для такого же сохранения в БД2. Либо для синхронизации может использоваться сервер, но сути дело это не меняет. Подобное действие может приводить к более пристальному анализу узла1 и узла2 (либо сервера), т.к. они связаны между собой не только клиентскими запросами, но и постоянной кооперацией между собой. Для подобного вида атаки достаточным является существование глобального наблюдателя и N-ое количество времени.
Теперь проанилизируем такое действие со стороны описанной мной сети.
В отличие от Tor и I2P у которых существует направленная маршрутизация (будь то луковая или чесночная), в описанной мной сети (назовём её далее EIN - entropy increase network) маршрутизация является заливочной (слепой). Последняя отличается отсутствием понимания где находится получатель, и отправленный пакет, можно сказать, сам ищет своего получателя блуждая по всей сети. В таком случае, если будут существовать два узла с одним и тем же публичным ключом, то оба этих узла будут генерировать ответ, потому как запрос дойдёт до каждого (в отличие от Tor и I2P, которые выберут только один узел). К чему это приведёт? Т.к. EIN является теоретически доказуемой сетью, то такое поведение никак не приведёт к деанонимизации субъектов со стороны пассивного глобального наблюдателя. Тем не менее, если злоумышленник является внутренним активным атакующим и самостоятельно способен отправлять запросы, то это даст ему дополнительную информацию о том, что существует целых два узла обладающих одним и тем же публичным ключом. Как следствие, это упростит деанонимизацию при условии, что существует кооперация внутреннего активного активного атакующего с активным глобальным наблюдателем, потому как упрощается задача блокировки участников с целью выявления кому принадлежит публичный ключ - если на очередной запрос злоумышленник получит уже не два, а только один ответ, то последний заблокированный пользователь будет относиться к проверяемому ключу.
Таким образом, для сети EIN такое действие будет являться скорее негативным, чем позитивным, что нельзя однозначно сказать о Tor и I2P, потому как с одной стороны такое действие может приводить к неоднозначности используемого маршрута, но с другой стороны создаёт дополнительные связи между конечными узлами.
Пункт 2
Если рассматривать данный случай со стороны Tor и I2P, то такой подход особо не улучшает качество анонимности при условии существования глобального наблюдателя, потому как для глобального наблюдателя остаются постоянными точки "взаимодействия", узлы, которые всегда остаются статичными и никогда не изменяются, сколько бы итераций изменения маршрутов не происходило. Таким образом, разрыв связи может происходить за счёт удаления одного из абонента, будь то отправителя или получателя. Такое возможно, когда сам же провайдер связи (или множество провайдеров связи) является активным глобальным наблюдателем. В таком случае, провайдер может просто запретить любые запросы-ответы направленные на или полученные от конкретного узла. Таким образом и может быть осуществлено отключение узла от сети. Существование нескольких узлов с одним и тем же публичным ключом усложняет однозначность блокирования, но тут нужно учитывать ещё несколько факторов: 1) глобальный наблюдатель может учитывать сколько раз один и тот же узел участвовал в маршрутизации. За счёт этого глобальный наблюдатель может разграничить узлы, которые применялись в маршрутах, и узлы которые являлись непосредственно абонентами за счёт неравных пропорций; 2) внутренний активный атакующий может учитывать разницу времени доставки пакета при большом количестве отправляемых данных на большом промежутке времени при очередном блокировании узла. Но такая атака наиболее эффективна, когда существует разделение между маршрутизирующими узлами и получателями, как в сети Tor.
В EIN не существует маршрутов подобных Tor и I2P. В отличие от последних, в которых существует точно заданные маршруты, в EIN пакет пробегается по всем узлам от одного к другому, до тех пор пока не найдёт своего получателя, или пока не пробежит всю сеть и не будет ею забыт. В следствие этого, можно утверждать, что в EIN уже существует много разных маршрутов до точки назначения. Поэтому атаки, направленные на разрыв связей между узлами, в EIN не особо эффективны. Тем не менее, эффективны атаки направленные на отключение самих узлов от сети с целью их дальнейшей деанонимизации (посредством активным атак). Также, как было описано в пункте 1, существование нескольких узлов с одним публичным ключом не повысит анонимность, а скорее наоборот её понизит для EIN.
Пункт 3 и Пункт 4
В таком случае качество анонимности действительно повысится. Но вопрос здесь скорее находится в плоскости - как этот мусорный трафик распределяется? От ответа на этот вопрос и будет зависеть на сколько качественней будет анонимность.
Так например, если мусорный трафик будет появляться от каждого узла в сети и создаваться в случайные периоды времени со случайными маршрутами, то при более длительном анализе (со стороны конечно же глобального наблюдателя) можно будет выявлять корреляцию между шумом (мусорным трафиком) и истинным трафиком. Такое может быть осуществленно, если между абонентами связь держится продолжительное время, допустим при передаче большого количества данных. В таком случае, глобальный наблюдатель, хоть и в менее явном виде, но будет замечать более статичный трафик.
В случае же с EIN мусорный трафик генерируется исключительно на базе механизма вероятностной маршрутизации, не для того, чтобы скрыть истинность связи, а для того, чтобы продлить итерацию увеличения энтропии. В таком случае, сколько бы истинного трафика не генерировалось, энтропия будет его поглощать.
Приведу также ещё один пример с мусорным трафиком. В моих статьях я очень часто рассказывал об анонимной сети на базе очередей (назовём её QBN - queue based network). Интересной её особенностью является то, что мусорный трафик генерируется исключительно в определённое время со всем истинным трафиком. Так например, если узел собирается что-то отправлять, то он генерирует запрос или ответ, в ином случае он генерирует ложный пакет. В отличие от I2P и EIN, в которых мусорный трафик накладывается в той или иной мере на истинный, в QBN мусорный трафик чередуется с истинным.
Пункт 5
Это также может повысить уровень анонимности. Например, в EIN такой механизм применяется для успешности накапливания энтропии. Подход аккумулирования сообщений, применяемый в Mixminion сетях, также приводит к задержкам в соединениях. В QBN сами задержки являются основой функционирования сети. Но во всех этих случаях, задержки применяются с разной целью: 1) чтобы накопить энтропию для отправления сообщения, 2) чтобы накопить количество сообщения для дальнейшей маршрутизации, 3) чтобы не отклоняться от периода генераций сообщений.
Поэтому да, задержки они часто помогают в анонимизации трафика, но часто идут в совокупности с чем-то. И конечно же естественным минусом таковых задержек является медленная передача данных.
-----
Вроде бы ответил на все вопросы. Сами ответы получились достаточно обширными. Если что-то непонятно или что-то нужно будет более детально пояснить, то можно продолжить здесь или в чате ВК, если будет проще.
Я предполагаю в качестве активного злоумышленника X конкретно сервисы связи, а не какого-то локального злоумышленника, который просто подключается к одному из узлов. С последним проблем вообще нет, потому что связь между клиентом и централизованными сервисами уже безопасна, исходя из существования центров сертификации.
Далее, если мы отправляем нескольким несвязанным сервисам связи X1, X2, X3, ... один и тот же ключ PubT, то вероятность того, что все ключи или большая их часть будет подменена - стремится к нулю при увеличении количества участвующих сервисов.
Перечитайте пожалуйста ещё раз всё, что я описал выше. Такое ощущение, что вы даже не хотите видеть написанное и цепляетесь вне контекста к любой непонравившейся вам фразе.
Краткий ответ - используя сторонние линии связи.
В более общем ответе, инструкция от меня может быть уже такой:
1. Предполагается, что у A и C есть своя пара открытый/закрытый ключ. Для A - это (PubA/PrivA), для C- это (PubC/PrivC),
2. Пользователь C генерирует временную пару открытый/закрытый ключ - (PubT/PrivT),
3. Пользователь C отправляет открытый ключ PubT на несколько централизованных сервисов прямо несвязанных между собой, допустим на 5 разных сервисов. Под несвязанностью понимается отсутствие общих директоров, инфраструктуры и прочего, допустим ВК и Mail.ru - будут считаться за связанные сервисы,
4. Пользователь A получает открытые ключи PubT1, PubT2, PubT3, PubT4, PubT5 с централизованных сервисов соответственно 1, 2, 3, 4, 5,
5. Пользователь A просматривает открытые ключи и сравнивает все ли они одинаковые,
6. Если больше половины ключей расходится (допустим 3/2) - пользователи A и C выбирают совершенно новые 5 централизованных сервисов и начинают процедуру заново,
7. Если меньше половины ключей расходится (допустим 4/1) - пользователи A и C выбирают под несогласованный публичный ключ новый сервис связи и повторяют процедуру конкретно с ним,
8. В конечном итоге, пользователь A получит от C временный публичный ключ PubT.
9. Далее пользователь A зашифровывает открытым ключом PubT свой открытый ключ PubA и отправит полученный результат также на эти 5 сервисов,
CPubA = E(PubT, PubA);
10. Пользователь C просматривает корректность получения CPubA. Если шифрованные ключи расходятся, то применяются процедуры 6/7 направленные на уже шифрованную версию ключей,
11. При успешном получении шифрованного публичного ключа CPubA, пользователь C применяет временный закрытый ключ PrivT и расшифровывает CPubA, получая тем самым публичный ключ PubA,
PubA = D(PrivT, CPubA);
12. Далее, пользователь C подписывает свой публичный ключ PubC временным закрытым ключои PrivT, и шифрует результат ранее полученным публичным ключом PubA. Результат подписания и шифрования пользователь C отправляет пользователю A. Пользователь C может использовать любой сервис связи, т.к. в данном случае уже нельзя будет корректно подменить информацию за счёт необходимости нарушения подписи для PrivT,
SPubC = S(PrivT, PubC);
CSPubC = E(PubA, SPubC);
13. Пользователь A принимает CSPubC, расшифровывает его своим публичным ключом PubA, получая тем самым SPubC. Далее пользователь A проверяет подпись, используя временный публичный ключ PubT, получая тем самым истинность публичного ключа PubC.
Таким образом, пользователи A и C обменялись своими публичными ключами, воспользовавшись сторонними централизованными сервисами связи. При этом, в вышеописанном протоколе централизованные сервисы так и не узнали истинные публичные ключи, которые будут применяться в качестве дальнейших идентификаторов ID в анонимной сети, а потому и не смогут их использовать для связывания с сетевым адресом IP. У централизованных сервисов в полномочии остались только PubT, CPubA, CSPubC. Этапы 6/7 защищают от активных атак за счёт однотипных действий на несвязанных сервисах.
В данном протоколе присутствуют следующие проблемы:
1. Протокол является вероятностным. Существует вероятность, что централизованные сервисы смогут связаться и успешно подменять публичные ключи хотя бы для 4/1 сервисов, что будет достаточно, т.к. последний сервис будет считаться уже некорректным.
2. Если A или C является злоумышленником, то он легко найдёт идентификатор ID своего абонента. При сотрудничестве с сервисами связи, он сможет легко узнать и IP абонента. Таким образом, легко свяжет полученный публичный ключ с сетевым адресом.
3. Предполагается, что пользователи A и C уже друг друга идентифицируют на выбираемых ими централизованных сервисах. В противном случае, пользователи A и C не будут знать кому отправляют и от кого получают ключи.
Да, думаю вы правы. Сложность изменил
Государство - это лишь один из возможных потребителей конфиденциальной информации. Наиболее же важным потребителем становятся рекламные сервисы, собственно которые и выдают на выходе таргетированную рекламу. Такие сервисы становятся очень выгодны с экономической точки зрения социальным сетям, мессенджерам, форумам и т.п. централизованным сервисам. Можно сказать, что государства в такой иерархии играют скорее второстепенную роль.