11.06 // Простой способ создания неотслеживаемых коммуникаций
Многие пользователи интернета думали о том, как организовать для себя неотслеживаемый канал связи. При этом приходит в голову два решения: стеганография и сети анонимной связи.
У обоих решений есть свои недостатки. Стеганографический канал обладает малой пропускной способностью, а регулярно подбирать контент сообщений так, чтобы он не вызывал подозрение у наблюдателя — сложно. Канал анонимной связи требует от пользователей поиска и/или установки и поддержки собственных сервисов (например скрытых сервисов в сети Tor) и согласования параметров — по каким адресам искать друг друга.
Однако, многим приходило в голову как-то пытаться сочетать оба подхода, чтобы компенсировать их недостатки: по одному каналу в интернете договариваться о связи, а по другому — осуществлять передачу данных.
Исследователи Филип Беато (Кафедра электротехники, исследовательская группа по компьютерной безопасности и промышленной криптографии, кафедра перспектив здравоохранения iMind католического университета Лёвен, Бельгия), Эмилиано де Кристофаро (Университетский колледж Лондона, кафедра компьютерных наук) и Каспер Рассмусен (Оксфордский Университет, кафедра компьютерных наук) также не остались в стороне от этой темы, опубликовав работу "Undetectable Communication: The Online Social Networks Case".
Вместо использования полновесной стеганографии, они предложили и формально описали концепции низкоэнтропийной стеганографии, целью которой является передача не закодированного осмысленного сообщения, а небольшого количества энтропии через обычный текст с целью вычисления сеансовых ключей и вычисления адресов для секретной связи по другим каналам. А уже по этим адресам можно получить сколь-угодно большие сообщения, используя сети анонимной связи. При этом противник не может догадаться ни о наличии таких каналов, ни о связи с ними отправителей согласующих сообщений.
К достоинствам метода относится то, что сторонам достаточно иметь лишь совместный долговременный симметричный ключ k. Больше никаких параметров в быстроменяющемся мире интернета им согласовывать не потребуется. Сообщения для согласования связи могут иметь произвольную форму: это может быть любая фраза, из которой достаточно получить уникальный хэш.
Итак, Алиса и Боб знают k. Алиса вычисляет из него ключ шифрования kENC = H (k ║ 0) путём хэширования с нулём и ключ аутентификации kMAC = H (k ║ 1) путём хэширования с единицей. В дальнейшем, для простоты оба ключа будут обозначаться как k и различаться в формулах по смыслу операций: аутентификации или шифрования.
Алиса публикует на открытом ресурсе (например, на странице своей социальной сети) произвольное сообщение tA, скорее всего представляющее собой короткий текст. Никакой специальной формы сообщению при этом придавать не обязательно. Алиса вычисляет index = MACk (tA) — псевдослучайный адрес связи. Этот адрес связи она может использовать для создания логина на файлообменном сервисе или скрытом сервисе Tor. А для сопоставления этого адреса какому-либо реальному адресу, она анонимно (через Tor) размещает ссылку на него в сервисе отображения адресов (таком как tinyurl). Затем Алиса шифрует секретное сообщение SA посредством EK (SA) и размещает его на ранее вычисленном адресе.
Только Боб, зная ключ k может проделать такие же вычисления, как и Алиса, найти адрес размещения её скрытого сообщения и расшифровать его.
Используя такой простой протокол можно даже из одного сеанса связи вычислить массу производных ключей, которые использовать для согласования адресов, логинов, паролей для входа в сервисы и расшифровки данных. Если пользователи создают эти адреса через анонимные сети, то между ними и создаваемыми адресами не существует никакой легкообнаружимой связи. А если адреса находятся на подконтрольном им скрытом сервисе Tor, то после использования они могут уничтожать эти адреса, не оставляя следов обмена информацией даже если сам факт этого будет заподозрен или раскрыты секретные параметры связи.
Исследователи создали тестовую реализацию простейшей версии такого протокола, способного работать в виде JavaScript-плагина к браузеру для сетей Facebook, Twitter и Google+.
Данная публикация будет представлена на 12-ой международной конференции по приватности, безопасности и доверию PST2014 в Торонто, Канада, 23-24 июля 2014 года на базе кафедры компьютерных наук университета Райерсона при технической поддержке компьютерного сообщества Института инженеров электротехники и электроники.
Источник: Университетский колледж Лондона, кафедра компьютерных наук, группа информационной безопасности
комментариев: 9796 документов: 488 редакций: 5664
Если у двух сторон есть общий ключ k, то всем понятно, что из любого совместно доступного источника случайности и этого ключа они могут выводить сколько угодно псевдослучайных чисел и как-угодно их совместно использовать. Так можно договориться и заголовки новостных сайтов с ключом хэшировать.
Но что обращает внимание, так это использование. Если есть публичные файлообменники и сайты, где можно размещать ссылки, и всё это без регистрации, то при использовании анонимных сетей почта, да ещё привязанная к одному псевдониму, не нужна.
Если tinyurl перестанет работать, то Алиса может взять пару «вычисленный хэш от текста — url» и инструкции по вычислению логина и пароля, а затем анонимно выложить на любой сайт, наподобие pastebin. Поскольку большинство поисковиков индексируют то, что выглядит как md5-суммы, то Боб может анонимно через поиск найти ресурс, где лежат указания для связи.
комментариев: 9796 документов: 488 редакций: 5664
Алиса и Боб договариваются о ключе из секретной фразы по безопасному каналу:
Из этого ключа вычисляется ключ шифрования:
и ключ вычисления индекса:
Алиса публикует безобидное сообщение и вычисляет его индекс:
Затем Алиса идёт на https://tinyurl.com и создаёт ссылку на свой адрес ymnhndy1yjbjzjy5.onion c алиасом 5bb1d24d22edbb894e94708dc006b812
На onion-адрес Алиса кладёт файл, зашифрованный ключом d3207bc818ea66dec5c012a84514b735.
Боб, увидев сообщение Алисы, проводит вычисления аналогичным образом и идёт по ссылке: http://preview.tinyurl.com/5bb.....edbb894e94708dc006b8
Оттуда он узнаёт адрес для скачивания файла http://ymnhndy1yjbjzjy5.onion
Алиса может составить и более сложную ссылку, в которой указать, как Бобу расшифровать адреса скрытой аутентификации Tor. Например, в конфиге своего скрытого сервиса она может разместить опцию HiddenServiceAuthorizeClient stealth Bob. Тогда для Боба на сервере Алисы автоматически создасться cookie-файл вида YmNhNDY1YjBjZjY5ZTZkMm. Алиса не должна публиковать его в ссылке открыто, а зашифровать:
После расшифрования Боб должен будет поместить в свой тор-конфиг опцию
Тогда никто, кроме Боба не сможет соединиться со скрытым сервисом и скачать файл, пусть даже и в зашифрованном виде.
Ещё более надёжным является постинг всех url в tinyurl также в шифрованном виде. Чтобы владельцы сервера tinyurl не знали, какие адреса для связи они размещают. А если Алиса поднимет свой скрытый сервис или какой-то другой адрес, то он не будет засвечен специфическими ссылками в tinyurl или в каких-то других сервисах в вебе. Это ещё больше затруднит отслеживание противником связей Алисы и Боба.
После того как Боб аналогичным образом подтвердит скачивание, расшифровку и прочтение файла от Алисы, она может уничтожить свой одноразовый скрытый сервис.
комментариев: 9796 документов: 488 редакций: 5664
Чтобы не расстраивать в следующий раз буду писать в примерах http://0123456789abcdef.onion/
По идее, как я уже упомянул, сами ссылки и короткие инструкции тоже лучше шифровать, представляя их в форме ссылок вида: http://www.existingfakesite.co.....7hBHXI6WD3.index.htm
Тогда, даже если станет известно, что кто-то размещал ссылки по такой схеме, то их нельзя будет вытянуть поиском. Так, если есть подозрение, что сервер http://0123456789abcdef.onion/ принадлежит Алисе, нельзя будет сказать, что она выкладывала на него ссылки на tinyurl — ведь ссылки зашифрованы неизвестным противнику ключом.
Если действовать осторожно, то вариаций схемы можно придумать множество. Например, два человека встречаются и пишут фразу на бумаге, разучивают, бумагу уничтожают. Затем по первому хэшу (с нулём) от этой фразы находят поиском узел для связи (адрес в твиттере), с твиттера — вычисляя HMAC от сообщения первой ссылкой получают шифрованные инструкции, далее разворачивают скрытые каналы связи.
Весь смысл в том, чтобы из одного общего секрета создать скрытые устойчивые к меняющейся обстановке каналы связи.
А разгадка проста:
Грибы — они такие, да.
Приумножение сущностей без необходимости. С учётом того, что аккаунты в указанных сетях делать анонимно становится всё труднее (требуют авторизацию по телефону, блокируют Tor и т.д.), не вижу смысл завязываться на них; если же такой аккаунт заведён неанонимно на реальное имя, то первый же Боб сможет сделать полный деанон, слив все ключи, кому надо, и тем самым доказав вовлечённость человека в определённые виды коммуникаций.
Есть публичные PGP-ключи на серверах ключей. На них есть uid'ы, где можно прописать любую контактную информацию. Чем это хуже? Если боитесь, что противник заподозрит ключ и начнёт его блокировать, то, с тем же успехом, он может заблокировать и аккаунт в твиттере или ещё где. Наконец, самое главное — как стороны будут искать друг друга, если противник уничтожит все их связные данные? Сервера ключей пока не заподозрены в цензуре, но если считать, что противник может уничтожить всё, то и сервера ключей могут быть отцензурированы или закрыты.
комментариев: 9796 документов: 488 редакций: 5664
Если на один и тот же ключ вешать некую случайную строку-уведомление, из которого стороны могут вывести, что появилось новое сообщение по такому-то адресу, то такие часто обновляемые ключи с понавешанными уидами будут выглядеть подозрительно. Да и все уведомления будут связаны с ключом-псевдонимом. Можно даже смотреть корреляцию между такими ключами: какой псевдоним предположительно какому отвечает. Это проще, чем блоги и форумы перелопачивать, пытаясь установить закономерность появления сообщений.
У авторов этого нет, но исходя из общей идеи протокол можно легко дополнить и до таких случаев.
У сторон есть общий симметричный пароль-ключ k. Если контакт пропадает (у Алисы закрыли бложик), то сторона A может выложить в интернет хэш вида H (k ║ 1 ║ "Alice call Bob trying count 0001").
Когда Боб видит, что с Алисой нет контакта, он ищет в поисковиках этот спасательный хэш. И находит его на какой-нибудь очередной файлопомойке, где рядом лежит шифрованное сообщение от Алисы с инструкциями для связи и адресом нового бложика.
Если и с новым блогом не выйдет, то тогда Боб будет пробовать искать H (k ║ 1 ║ "Alice call Bob trying count 0002") и т.д.
Непонятно только как шифровать сами ссылки (неизвестным противнику ключом).
комментариев: 9796 документов: 488 редакций: 5664
Из общего секрета можно выводить сколько угодно симметричных ключей, хоть для аутентификации (и поиска по отпечатку), хоть для симметричного шифрования.
Выше приводился код для постинга шифрованного файла-инструкции, но его же можно использовать и для ссылки:
Тогда на адресе, вычисленном в предыдущем примере:
Можно разместить ссылку вида:
Мысль понятна, остаётся лишь вопрос практичности. Всегда ли легко найти нужную случайную строку, не привязанную ни к чему? Хорошо ли поисковик будет такое индексировать? Я часто сталкиваюсь с тем, что даже зная, что я примерно писал, где писал, зная ключевые слова... я, тем не менее, не могу найти соответствующий пост. ☹
комментариев: 9796 документов: 488 редакций: 5664
MD5-суммы все поисковики собирают специально настроенными ботами и похожие на них последовательности индексируются поисковиками автоматически. Так что при условии их заведомой уникальности, найти их не составит труда. D.J. Бернштейн уже давно метит так все свои работы и они отлично ищутся.
Он пользуется BSD? Первый раз слышу. Честно говоря, раньше я почему-то всегда думал, что этот ID — md5-хэш от файла, и публикуется он для того, чтобы иметь возможнсть сразу детектировать, битый файл скачался или цельный.
комментариев: 9796 документов: 488 редакций: 5664
Это задача по криптографии «со звёздочкой».Я ранее не знал, что этот хэш ещё и где-то внутри записан. :) Строго говоря, в некоторых случаях это якобы решается, если запись идёт в самый конец файла (зная хэш строки, можно вычислить хэш от "строка+ещё_одна_строка", так сказать, «досчитать хэш»).P.S. Напомнило классическую задачу «напишите программу, которая распечатывает свой исходник на экран».