Комментарии 12
Статья интересная, но вот с уровнем сложности вы излишне оптимистичны.
Многобуков. Просто ответь, от частотного анализа и других бигдата-приёмов защита уже есть, или можно ещё подремать?
Вроде как есть
Как отправитель А узнает, что воспользовался общедоступным ключом получателя C, а не некоторого злоумышленника X, который выдаёт себя за C? Вопрос простой. Хотелось бы получить столь же простой ответ. Короткий и ясный.
Краткий ответ - используя сторонние линии связи.
В более общем ответе, инструкция от меня может быть уже такой:
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 не будут знать кому отправляют и от кого получают ключи.
Пользователь C отправляет открытый ключ PubT на несколько централизованных сервисов прямо несвязанных между собой…
Так активный злоумышленник X перехватит этот ключ и пошлёт свой вместо него.
Вы пишете очень длинно и, к сожалению, не предлагаете решения. А когда предлагаете что-то, то потом начинаете оправдываться, мол, всё плохо и не работает. Как к этому всему следует относиться? Это исследования такие?
Я предполагаю в качестве активного злоумышленника X конкретно сервисы связи, а не какого-то локального злоумышленника, который просто подключается к одному из узлов. С последним проблем вообще нет, потому что связь между клиентом и централизованными сервисами уже безопасна, исходя из существования центров сертификации.
Далее, если мы отправляем нескольким несвязанным сервисам связи X1, X2, X3, ... один и тот же ключ PubT, то вероятность того, что все ключи или большая их часть будет подменена - стремится к нулю при увеличении количества участвующих сервисов.
Перечитайте пожалуйста ещё раз всё, что я описал выше. Такое ощущение, что вы даже не хотите видеть написанное и цепляетесь вне контекста к любой непонравившейся вам фразе.
Тяжело вникать в текст полный не знакомой терминологии. По этому, если автору не сложно, прошу прокомментировать следующие утверждения и вопросы на примере пресловутых TOR и I2P:
1. что если искомый наблюдатель обладает не одним, а несколькими узлами сети с одинаковым публичным ключом (так можно делать в TOR, вероятно, и в I2P, но я не пробовал). Вроде как это даже использовали для распределения нагрузки и для защиты серверов от обнаружения.
2. что если и получатель и источник выстраивают по нескольку разных маршрутов до «точек рандеву в терминологии TOR» (основная идея I2P) и при разрыве любого количества, кроме всех, связь сохраняется. Как их отключать тогда? (можно свет погасить в отдельно взятой стране, потом в городе и т. д. но предыдущий пункт!)
3. Что если узлы обмениваются мусорным трафиком, скрывая таким образом факт передачи настоящего сообщения (есть точно в i2p)?
4. Что если, маршруты могут вести к «мусорным узлам», которые периодически отправляют, принимают трафик и отвечают на ping? Просто ping‑ом не обойтись (это тоже в i2p).
5. А более высокоуровневый «ping» в виде письма в котором заинтересован хозяин публичного ключа, может встретить противодействие в виде случайного времени ответа. Вы не будете знать получил ли хозяин ключа ваше сообщение, пока не пройдёт слишком много времени (кстати, freenet)
Разве это всё, а в особенности пункт 1 не увеличивает драматически сложность обнаружения? Я имею в виду, что сложность не будет снижаться из-за атак. Вы же не знаете заранее сколько всего в сети таких узлов. Как я понял, все атаки сводятся к возможности отключить целого пользователя. Но на практике это не возможно, т.к. пользователь может поднять несколько одинаковых узлов.
Хорошие вопросы. В первую очередь я отвечу, что все вышеописанные пункты действительно в той или иной мере повышают качество анонимности узлов сети, но определённые из них содержат своё но.
Пункт 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) чтобы не отклоняться от периода генераций сообщений.
Поэтому да, задержки они часто помогают в анонимизации трафика, но часто идут в совокупности с чем-то. И конечно же естественным минусом таковых задержек является медленная передача данных.
-----
Вроде бы ответил на все вопросы. Сами ответы получились достаточно обширными. Если что-то непонятно или что-то нужно будет более детально пояснить, то можно продолжить здесь или в чате ВК, если будет проще.
Большое спасибо за столь обстоятельный ответ. Для меня много стало очевидно.
Я ещё прошу прокомментировать подход bitmessage. Узлы подписываю данные своим закрытым ключом и шифруют на открытый ключ получателя и посылают данные в блокчейн. Все узлы поддерживают синхронную реплику всего блокчейна и проверяют все появляющиеся там блоки, пытаясь их расшифровать своим закрытым ключом (я оставляю за скобками соль, искажение размера данных и другие стандартные приёмы) Таким образом и внутренний и глобальный наблюдатель, насколько я понимаю, видят одинаковые картины: все узлы посылают блоки в блокчейн и не понятно кто именно их читает. ping-овать владельца ключа бессмысленно, т.к. он просто не будет отвечать тем, с кем он не заинтересован во взаимодействии.
Конечно сеть чрезвычайно ресурсозатратна и не подразумевает p2p-трафика с низкой латентностью. С другой стороны, задачу обмена сигналами, она может решать эффективно, особенно если учитывать, что прогресс технологий блокчейна не стоит на месте: например, блокчейн может делиться на миниблокчейны, которые растут параллельно, тем самым ускоряя транзакции. Можно договорится о правилах выбора ветвей заранее или на основе алгоритма, которые поставит выбор ветки в зависимость от, например открытого ключа и тем самым, можно уменьшить количество загружаемых данных, но и сузить круг, среди которого идёт поиск взаимодействующих нод.
Мне кажется, эта идея в чем-то похожа на накопление энтропии.
А ещё есть не прозрачные блокчейны, в механику работых которых я не вникал, но вот например XMR (Monero) утверждают что проследить их транзакции можно только в редких случаях.
Я ещё прошу прокомментировать подход 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 ещё существуют колцьевые подписи, но на сколько знаю, они защищают не от просмотра трафика, тобишь не от внешнего/глобального наблюдателя, а конкретно от узлов-майнеров - внутренних атакующих, которые должны каким-то образом вычислить кто и кому отправляет ту или иную транзакцию.
Примерно как-то так.
Анонимная сеть с теоретически доказуемой моделью на базе увеличения энтропии