Хабрахабр

[Из песочницы] Торфон – мобильное приложение для анонимной телефонии

image

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

  • существующие транспортные протоколы для телефонии работают поверх UDP, а Tor обеспечивает лишь TCP соединения;
  • Tor маршрутизирует пакеты через множество узлов, шифруя данные, что является причиной значительной латентности и делает дуплексную телефонную связь невозможной или крайне некомфортной.

Но так ли это на самом деле?
В далеком 2012 году я впервые задумался о принципиальной возможности реализации анонимной телефонной связи с использованием анонимизаторов Tor и i2p. Реакция сообщества была однозначно отрицательной, включая самого Филла Циммермана, автора знаменитого PGPFone, на базе которого работал первый Торфон. Но я был упрям, проверял новые идеи, тестировал и улучшал найденные трюки, в основном направленные на снижение латентности до приемлемого уровня. В данном направлении также работали и другие исследователи, и ихние публикации давали мне новые идеи и почву для дальнейшей работы. Положительными моментами было значительное ускорение глобальной сети Интернет и сети Tor в частности, а также постепенное отвыкание пользователей от PSTN в пользу GSM связи с присущей ей значительной латентностью. Наконец, подходящая концепция была выработана, и настал черед реализации задуманного.
В 2013 году Roger Dingledine в личной переписке жестко раскритиковал проект за отсутствие кроссплатформенности (на тот момент в качестве базы использовался PGPFone на Windows-платформе) и за не-модулярную архитектуру. На фоне этой критики была заложена почва для современной реализации Торфона с учетом множества проб и ошибок, а также современных тенденций в криптографии.

Это транспортный модуль, обеспечивающий работу с сокетами, модуль криптографии и звука, модуль хранилища (производит операции с приватным ключом и содержит зашифрованную адресную книгу) и модуль пользовательского интерфейса. Сегодня Торфон состоит из четырех программных модулей, взаимодействующих друг с другом с помощью 36-байтных пакетов со строго фиксированными полями. Данная архитектура позволяет разработчику определять компромисс между защищенностью и удобством реализации. Они быть запущены на одной аппаратной платформе (в одном или в различных потоках) или на нескольких изолированных платформах, использующих в качестве интерфейса стандартный последовательный протокол (аппаратный UART, USB CSD или Bluetooth SPP). Доступны варианты от автономного Windows-приложения до аппаратной реализации в виде одноплатника с Linux для Tor и транспортного модуля в связке с изолированным Cortex M4 микроконтроллером, на котором выполняется шифрование, полная обработка и проигрывание аудио, хранение приватного ключа и контактов, реализован графический интерфейс пользователя.

В промежуточный проект OnionPhone были включены 17 самых распространенных низкобитрейтных аудиокодеков. Исходный код модулей написан на C и полностью кроссплатформенен, за исключением низкоуровневой работы с аудио, вынесенной в отдельные файлы, специфичные для Windows (Wave), Linux (Alsa), Android (OpenSL) и bare metal (ADC/DAC+DMA для микроконтроллера).
При выборе аудиокодека и очереди учитывались особенности сети Tor: периодические частые спонтанные задержки, некоторое снижение латентности для пакетов в определенном диапазоне длины, возможность в процессе звонка создавать дублирующие цепочки с различными путями маршрутизации и т.п. Таким образом, с учетом естественных пауз между словами и дуплексной природы общения, итоговый средний битрейт в каждом направлении составляет около 2000-3000 bps., что дает возможность использовать GPRS даже в условиях плохого GSM — покрытия и массивных потерь GSM пакетов. После тщательного тестирования был выбран наиболее подходящий вариант: AMR с минимальным для него битрейтом 4750 bps и с быстродействующим VAD.

Алгоритм эхоподавления был выбран из проекта WebRTC как наиболее эффективный из доступных открытых решений. В качестве подавителя шума применен эффективный алгоритм NPP7, разработанный для борьбы с интенсивными аудиопомехами и входящий в составе кодека MELPe – действующего стандарта военной связи STANAG-4591.

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

Основные режимы работы:

  1. Анонимные голосовые звонки на скрытый сервис Tor (по onion-адресу). Эти звонки максимально защищены, но ощущается некоторая задержка, что может вызывать определенный дискомфорт у непривыкших пользователей.
  2. Переключение на прямое UDP соединение (с проходом NAT) после установки Tor-соединения. Сессионные ключи шифрования, согласованные внутри Tor, обеспечивают надежную конфиденциальность, но анонимность теряется (пользователи раскрывают свой IP адрес друг другу).
  3. Прямые звонки по указанному IP-адресу (или доменному имени) и номеру TCP порта. Для приема таких звонков требуется наличие «белого» (маршрутизируемого) IP адреса на устройстве (многие сотовые операторы предлагают это в качестве платной услуги) или «проброс» использующегося TCP-порта на локальном роутере (например, в домашней WiFi сети). Прямые звонки могут осуществляться в изолированной локальной сети (например, локальной WiFi сети, созданной с помощью мощной точкой доступа, установленной в центре зоны обслуживания). В этом случае Торфон не требует взаимодействия с интернет: у проекта нет своего сервера, являющегося точкой потенциального отказа, атак и сбора метаданных. Таки образом, Торфон может успешно работать даже при полной изоляции сегмента сети или всего Рунет на государственном уровне.

Сегодня достаточно часто поднимается вопрос доверия к Tor как в плане сохранения анонимности, так и в плане конфиденциальности передаваемых данных. Известный мессенджер TorChat не использовал своего шифрования и аутентификации, полностью полагаясь на сервисы, предоставляемые Tor. Лично я доверяю Tor, во всяком случае, в плане обеспечения конфиденциальности и совершенной обратной секретности. Но, к сожалению, такая позиция омрачена открытием глобальных уязвимостей SPECTRE / MELTDOWN, а также массой уязвимостей нулевого дня для всех известных операционных систем, практически используемых в качестве рабочих инструментов в арсенале любой спецслужбы. Поэтому я не смог пойти по пути TorChat и добавил в Торфон собственный слой шифрования и аутентификации, использующий самые современные протоколы и доказуемо стойкие криптографические примитивы.

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

Так, вызывающий абонент знает, кому он звонит, и должен ему сообщить свой ID (ключ). Особое внимание уделено защите идентификаторов абонентов. Мало того, если соединение будет перехвачено, в том числе активным атакующим, а позже все приватные ключи участников будут раскрыты, не существует возможности установить (или выбрать из списка известных) идентификаторы участников в каждой пробе или перехваченной сессии в прошлом. Но только ему и никому другому! Это удалось достичь, модифицировав протокол Triple-DH (тройной Диффи-Хеллман, применяемый в том числе и в Signal) добавлением параллельно выполняемого протокола SPEKE, обеспечивающего нулевое разглашение в отношении явных (explicit) аутентификаторов, которыми обмениваются стороны на этапе начального обмена ключами. Другими словами, обеспечивается защита ID вызывающего и вызываемого абонентов с совершенной обратной секретностью (PFS).

Также обеспечивается отрицаемость наперед (Forward Deniability), когда злонамеренная сторона заранее договаривается с судьей о том, что будет проводить сеанс, и после завершения сеанса пытается доказать, что он имел место. Используемый в Торфоне протокол имеет свойство отрицаемости (Deniability), когда после завершенного сеанса связи злонамеренная сторона не может убедить судью в том, что действительно контакт имел место. Исходя из практических реалий, предпочтение было в пользу KCI -устойчивости, как более практичного свойства, особенно в условиях неправовых отношений. Полная отрицаемость (Full Deniability, когда злонамеренная сторона контактирует с судьей во время сеанса связи), конкурирует с таким важным свойством, как KCI — устойчивость (невозможность представиться другим перед абонентом, приватный ключ которого известен).

Из дополнительных возможностей аутентифицировать друг друга при первом контакте (для гарантии достоверности обмена ключей) реализовано два протокола:

  • сравнение короткого отпечатка общего секрета (SAS, аналогично как в протоколе ZRTP). Для блокирования атаки подбора короткого отпечатка в процессе MitM используется коммитмент в процедуре Диффи-Хеллмана. Кроме того, отпечаток общего секрета автоматически включается в имя контакта, принятого в данной сессии. Таким образом, при обмене контактами в течение одной сессии начало имени нового контакта у обоих участников должно быть одинаковым, что можно проверить позже, например, при личной встрече. И, кстати, полученный контакт нужно обязательно переименовать для того, чтобы разрешить Торфону представлять себя (свой ID) этому контакту.
  • сравнение заранее согласованного секрета (слова, фразы). В OTR аналогичную функцию выполняет протокол Социалиста-Миллионера. В Торфоне используется аналогичный по свойствам (с нулевым разглашением) протокол SPEKE.

В случае, если у обоих участников сеанса имеются контакты (публичные ключи) друг друга, если аутентификация успешна и используется Tor (звонок на онион-адрес), то принимающая сторона осуществляет встречный звонок, используя онион-адрес вызывающей стороны из своей адресной книги. После установления соединения производится взаимная аутентификация по второму каналу, подтверждающая онион-адрес звонящего абонента. Аналогичную процедуру использует TorChat для аутентификации чатов, используя в качестве ID онион-адрес контакта.

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

К счастью, Торфон не имеет собственного сервера или облака, используя вместо него Tor. Как показывает печальная практика, сегодня весьма важно научить приложение защищаться от возможных блокировок. Но сегодня это – тоже реальность, и в подобном случае останется лишь возможность выполнения звонков непосредственно на IP — адрес и TCP порт. Поэтому блокировка Торфона возможна лишь путем блокировки Tor. Поэтому были приняты дополнительные меры для максимального сокрытия такого трафика. В самом пессимистичном сценарии большой брат будет пытаться научить системы DPI (глубокого анализа пакетов) выявлять в контролируемой сети p2p трафик между двумя Торфонами. Во вторых, абсолютно все пакеты (в том числе и звуковые) в течение сеанса связи (TCP — сессии) не имеют никаких отличительных особенностей (постоянных или инкрементируемых полей, длины и т.п.) и для внешнего наблюдателя выглядят как случайные данные случайной длины. Во первых, слушающий порт TCP может быть выбран вручную и фактически является частью адреса абонента. В третьих, для проведения активной пробы протокола требуется «подтверждение работы» (Proof of Job) в качестве защиты от массированного сканирования адресов и портов на предмет обнаружения Торфонов.

Во время первого подключения стороны обмениваются первичными сессионными ключами в виде точек на эллиптической кривой X25519, выполняя обычный протокол Диффи-Хеллмана. Фактически соединение выполняется двумя последовательными TCP — подключениями. После выведения общего секрета первая сессия разрывается, и через случайный промежуток времени (несколько секунд) устанавливается вторая сессия, все данные в которой зашифрованы ключом, выведенным из общего секрета. Так как Montgomery-формат представления точки не является случайным числом, используется представление Elligator2, дополненное случайными байтами. Из полученного секрета выводятся симметричные ключи для шифрования и расшифровки. Генерируются новые сессионные ключи, и протокол Диффи-Хеллмана выполняется еще раз, теперь уже с коммитментом. В случае отсутствия ключей в адресной книге (неизвестный контакт) или любого несоответствия все сообщения заменяются случайными байтами., т.е. Затем выполняется тройной протокол Диффи-Хеллмана параллельно с протоколом SPEKE для защиты ID вызывающего абонента и аутентификации. протокол не прерывается для предотвращения утечки информации об идентичности участников.

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

Для основного слоя симметричного шифрования используется преобразование Keccak-800 в виде функции Shake-128 и однонаправленный счетчик пакетов CTR. Для слоя обфускации был выбран симметричный алгоритм Serpent-128, работающий в режиме аутентифицированного шифрования OCB. Для шифрования адресной книги и генератора псевдослучайных чисел используется алгоритм ChaCha20. Этот же примитив используется в качестве Hash, MAC и PKDF. Накопление энтропии производится до необходимого количества, оцениваемого с помощью группового частотного теста. Ресидирование генератора производится в начале каждой сессии, для накопления энтропии в мультизадацных операционных системах используется алгоритм Havege, а в микроконтроллере – младший бит результата АЦП, измеряющего шум резистивного делителя.

Сразу скажу – эти ассемблерные коды получены от профессионалов с мировыми именами, я лишь портировал их из GNU ASM в среду Keil, более привычную для сборки встроенных проектов. Основные криптографические примитивы (элементарная математика для X25519, Keccak800, ChaCha20) используют не оптимизируемые компилятором ассемблерные реализации для микроконтроллерных платформ (Cortex M1 и M4), тщательно проверенные на постоянство времени выполнения и с минимизированными утечками по побочным каналам ЭМИ и флуктуаций тока потребления.

Ну, что в итоге?

Если так, то по запросу на почту рад предоставить тестовые сборки (статически линкованные исполняемые файлы, не требуемые установки), а также исходные коды графического интерфейса для Windows, Linux и Android в соответствующих средах разработки. Если вы дочитали до этого места и не умерли со скуки, то значит, этот проект Вам действительно может быть полезен. Там же можно найти прямые ссылки на альфа-версию Андроид-приложения и краткое руководство по его установке и использованию, что поможет всем желающим оценить латентность телефонии в сети Tor. Ядро проекта выполнено на базе кроссплатформенной библиотеки torfone, доступной поиском на github.

Тестовое приложение для всех версий Windows (начиная с древней Windows 98) выполнено в старом, но мощном Borland C++ Builder 6. Графический интерфейс реализован отдельно для каждой платформы и не является вариантом выбора (пока что это лишь альфа-тестирование). Первое должно работать как на 32- так и на 64-разрядных десктопах, второе – на недорогих одноплатных компьютерах: RPi, Orange, Nano и др. Для Linux GUI-приложение разрабатывалось с использованием забытой Wide Studio для графики X11 отдельно для i386 и ARM архитектур. 2. Для Android доступен apk-файл, собранный в Embarcadero RAD Studio 10. Также в среде Android поддерживается автоматическое резервное копирование файлов конфигурации, ключей и адресной книги (в зашифрованном виде) во внешнее хранилище и восстановление при переустановке Торфона или переносе на другое устройство. Это далеко не лучший вариант и пока что не умеет создавать Foreground service, но, тем не менее, стабильно работает в Background при отключенной оптимизации использования батареи. В качестве открытой аппаратной платформы будет использована NanoPi Neo c устанвовленным Debian server и плата Nucleo STM32F446RE, соединенные через физический UART. На момент написания статьи ведется работа над проектом в среде Keil uVision, включающим транспортный, шифровальный модули, аудио и графический интерфейс на базе Arduino — совместимого 320*240 TFT+Touch дисплея. В отдаленных планах – портирование в iOS, хотя я с трудом понимаю, как это может сочетаться с элементарными гарантиями безопасности.

И в завершение.

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

И есть много ценностей, которые не измерить деньгами. На самом деле мир не такой серый и испорченный. Ну, нельзя Торфон остановить. А ответ на первые два вопроса – никак. Нельзя заставлять обновляться. Нельзя получить от него «ключи», слить действия пользователей, даже замеченных в терроризме или педофилии, нельзя забанить неугодных. Нет в Торфоне никаких утечек, побочных соединений, кроме как предусмотренных протоколом. Нельзя управлять извне. Поэтому никто не сможет управлять пользователями Торфона. Это можно легко проверить как в коде (почти каждая строчка прокомментирована и не так уж много файлов в проекте), так и сетевыми анализаторами. Но помните: Торфон – лишь инструмент, а все ваши действия – на вашей совести, и за них отвечаете вы, а не автор проекта.

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»