Сегодня я хотел бы рассказать о результатах моих семилетних исследований в области передачи голоса через сеть 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 микроконтроллером, на котором выполняется шифрование, полная обработка и проигрывание аудио, хранение приватного ключа и контактов, реализован графический интерфейс пользователя.
Исходный код модулей написан на C и полностью кроссплатформенен, за исключением низкоуровневой работы с аудио, вынесенной в отдельные файлы, специфичные для Windows (Wave), Linux (Alsa), Android (OpenSL) и bare metal (ADC/DAC+DMA для микроконтроллера).
При выборе аудиокодека и очереди учитывались особенности сети Tor: периодические частые спонтанные задержки, некоторое снижение латентности для пакетов в определенном диапазоне длины, возможность в процессе звонка создавать дублирующие цепочки с различными путями маршрутизации и т.п. В промежуточный проект OnionPhone были включены 17 самых распространенных низкобитрейтных аудиокодеков. После тщательного тестирования был выбран наиболее подходящий вариант: AMR с минимальным для него битрейтом 4750 bps и с быстродействующим VAD. Таким образом, с учетом естественных пауз между словами и дуплексной природы общения, итоговый средний битрейт в каждом направлении составляет около 2000-3000 bps., что дает возможность использовать GPRS даже в условиях плохого GSM — покрытия и массивных потерь GSM пакетов.
В качестве подавителя шума применен эффективный алгоритм NPP7, разработанный для борьбы с интенсивными аудиопомехами и входящий в составе кодека MELPe – действующего стандарта военной связи STANAG-4591. Алгоритм эхоподавления был выбран из проекта WebRTC как наиболее эффективный из доступных открытых решений.
Общий функционал Торфона разрабатывался с учетом возможных вариантов использования и существующих моделей угроз, уже применявшихся против популярных мессенджеров.
Основные режимы работы:
- Анонимные голосовые звонки на скрытый сервис Tor (по onion-адресу). Эти звонки максимально защищены, но ощущается некоторая задержка, что может вызывать определенный дискомфорт у непривыкших пользователей.
- Переключение на прямое UDP соединение (с проходом NAT) после установки Tor-соединения. Сессионные ключи шифрования, согласованные внутри Tor, обеспечивают надежную конфиденциальность, но анонимность теряется (пользователи раскрывают свой IP адрес друг другу).
- Прямые звонки по указанному IP-адресу (или доменному имени) и номеру TCP порта. Для приема таких звонков требуется наличие «белого» (маршрутизируемого) IP адреса на устройстве (многие сотовые операторы предлагают это в качестве платной услуги) или «проброс» использующегося TCP-порта на локальном роутере (например, в домашней WiFi сети). Прямые звонки могут осуществляться в изолированной локальной сети (например, локальной WiFi сети, созданной с помощью мощной точкой доступа, установленной в центре зоны обслуживания). В этом случае Торфон не требует взаимодействия с интернет: у проекта нет своего сервера, являющегося точкой потенциального отказа, атак и сбора метаданных. Таки образом, Торфон может успешно работать даже при полной изоляции сегмента сети или всего Рунет на государственном уровне.
Сегодня достаточно часто поднимается вопрос доверия к Tor как в плане сохранения анонимности, так и в плане конфиденциальности передаваемых данных. Известный мессенджер TorChat не использовал своего шифрования и аутентификации, полностью полагаясь на сервисы, предоставляемые Tor. Лично я доверяю Tor, во всяком случае, в плане обеспечения конфиденциальности и совершенной обратной секретности. Но, к сожалению, такая позиция омрачена открытием глобальных уязвимостей SPECTRE / MELTDOWN, а также массой уязвимостей нулевого дня для всех известных операционных систем, практически используемых в качестве рабочих инструментов в арсенале любой спецслужбы. Поэтому я не смог пойти по пути TorChat и добавил в Торфон собственный слой шифрования и аутентификации, использующий самые современные протоколы и доказуемо стойкие криптографические примитивы.
В основе концепции лежит возможность осуществлять звонки между незнакомыми абонентами, а затем автоматически обмениваться своими публичными ключами для взаимной аутентификации в последующих сеансах связи. Данный подход обеспечивает определенную отрицаемость в вопросе наличия компрометирующего ключа в списке ваших контактов: любой абонент, зная ваш онион-адрес, может осуществить анонимный звонок и тут же переслать вам любой контакт из своей записной книги. Этот контакт будет автоматически добавлен в вашу адресную книгу. Впрочем, эту возможность можно отключить в настройках, но кто знает, была ли она у вас включена раньше?
Особое внимание уделено защите идентификаторов абонентов. Так, вызывающий абонент знает, кому он звонит, и должен ему сообщить свой ID (ключ). Но только ему и никому другому! Мало того, если соединение будет перехвачено, в том числе активным атакующим, а позже все приватные ключи участников будут раскрыты, не существует возможности установить (или выбрать из списка известных) идентификаторы участников в каждой пробе или перехваченной сессии в прошлом. Другими словами, обеспечивается защита ID вызывающего и вызываемого абонентов с совершенной обратной секретностью (PFS). Это удалось достичь, модифицировав протокол Triple-DH (тройной Диффи-Хеллман, применяемый в том числе и в Signal) добавлением параллельно выполняемого протокола SPEKE, обеспечивающего нулевое разглашение в отношении явных (explicit) аутентификаторов, которыми обмениваются стороны на этапе начального обмена ключами.
Используемый в Торфоне протокол имеет свойство отрицаемости (Deniability), когда после завершенного сеанса связи злонамеренная сторона не может убедить судью в том, что действительно контакт имел место. Также обеспечивается отрицаемость наперед (Forward Deniability), когда злонамеренная сторона заранее договаривается с судьей о том, что будет проводить сеанс, и после завершения сеанса пытается доказать, что он имел место. Полная отрицаемость (Full Deniability, когда злонамеренная сторона контактирует с судьей во время сеанса связи), конкурирует с таким важным свойством, как KCI — устойчивость (невозможность представиться другим перед абонентом, приватный ключ которого известен). Исходя из практических реалий, предпочтение было в пользу KCI -устойчивости, как более практичного свойства, особенно в условиях неправовых отношений.
Из дополнительных возможностей аутентифицировать друг друга при первом контакте (для гарантии достоверности обмена ключей) реализовано два протокола:
- сравнение короткого отпечатка общего секрета (SAS, аналогично как в протоколе ZRTP). Для блокирования атаки подбора короткого отпечатка в процессе MitM используется коммитмент в процедуре Диффи-Хеллмана. Кроме того, отпечаток общего секрета автоматически включается в имя контакта, принятого в данной сессии. Таким образом, при обмене контактами в течение одной сессии начало имени нового контакта у обоих участников должно быть одинаковым, что можно проверить позже, например, при личной встрече. И, кстати, полученный контакт нужно обязательно переименовать для того, чтобы разрешить Торфону представлять себя (свой ID) этому контакту.
- сравнение заранее согласованного секрета (слова, фразы). В OTR аналогичную функцию выполняет протокол Социалиста-Миллионера. В Торфоне используется аналогичный по свойствам (с нулевым разглашением) протокол SPEKE.
В случае, если у обоих участников сеанса имеются контакты (публичные ключи) друг друга, если аутентификация успешна и используется Tor (звонок на онион-адрес), то принимающая сторона осуществляет встречный звонок, используя онион-адрес вызывающей стороны из своей адресной книги. После установления соединения производится взаимная аутентификация по второму каналу, подтверждающая онион-адрес звонящего абонента. Аналогичную процедуру использует TorChat для аутентификации чатов, используя в качестве ID онион-адрес контакта.
Параллельное Tor-соединение состоит из иных цепочек, что выгодно используется для компенсации спонтанных задержек: речевые пакеты отправляются сразу в оба канала, используется пакет, пришедший ранее. Кроме того, ведется статистика задержек в обоих каналах, и, если один из каналов значительно медленнее, то он периодически переподключается в процессе разговора. Это снижает общую латентность аутентифицированного звонка в сравнении со звонком от неизвестного абонента.
Как показывает печальная практика, сегодня весьма важно научить приложение защищаться от возможных блокировок. К счастью, Торфон не имеет собственного сервера или облака, используя вместо него Tor. Поэтому блокировка Торфона возможна лишь путем блокировки Tor. Но сегодня это – тоже реальность, и в подобном случае останется лишь возможность выполнения звонков непосредственно на IP — адрес и TCP порт. В самом пессимистичном сценарии большой брат будет пытаться научить системы DPI (глубокого анализа пакетов) выявлять в контролируемой сети p2p трафик между двумя Торфонами. Поэтому были приняты дополнительные меры для максимального сокрытия такого трафика. Во первых, слушающий порт TCP может быть выбран вручную и фактически является частью адреса абонента. Во вторых, абсолютно все пакеты (в том числе и звуковые) в течение сеанса связи (TCP — сессии) не имеют никаких отличительных особенностей (постоянных или инкрементируемых полей, длины и т.п.) и для внешнего наблюдателя выглядят как случайные данные случайной длины. В третьих, для проведения активной пробы протокола требуется «подтверждение работы» (Proof of Job) в качестве защиты от массированного сканирования адресов и портов на предмет обнаружения Торфонов.
Фактически соединение выполняется двумя последовательными TCP — подключениями. Во время первого подключения стороны обмениваются первичными сессионными ключами в виде точек на эллиптической кривой X25519, выполняя обычный протокол Диффи-Хеллмана. Так как Montgomery-формат представления точки не является случайным числом, используется представление Elligator2, дополненное случайными байтами. После выведения общего секрета первая сессия разрывается, и через случайный промежуток времени (несколько секунд) устанавливается вторая сессия, все данные в которой зашифрованы ключом, выведенным из общего секрета. Генерируются новые сессионные ключи, и протокол Диффи-Хеллмана выполняется еще раз, теперь уже с коммитментом. Из полученного секрета выводятся симметричные ключи для шифрования и расшифровки. Затем выполняется тройной протокол Диффи-Хеллмана параллельно с протоколом SPEKE для защиты ID вызывающего абонента и аутентификации. В случае отсутствия ключей в адресной книге (неизвестный контакт) или любого несоответствия все сообщения заменяются случайными байтами., т.е. протокол не прерывается для предотвращения утечки информации об идентичности участников.
Для реализации указанных протоколов используются тщательно перепроверенные исходные С-коды криптографических примитивов, взятые из известных криптографических библиотек. Для верификации на этапе разработки использовались известные тестовые векторы, а после каждого запуска приложения производится дополнительная верификация конкретной реализации исполняемого кода (результата компиляции).
Для слоя обфускации был выбран симметричный алгоритм Serpent-128, работающий в режиме аутентифицированного шифрования OCB. Для основного слоя симметричного шифрования используется преобразование Keccak-800 в виде функции Shake-128 и однонаправленный счетчик пакетов CTR. Этот же примитив используется в качестве Hash, MAC и PKDF. Для шифрования адресной книги и генератора псевдослучайных чисел используется алгоритм ChaCha20. Ресидирование генератора производится в начале каждой сессии, для накопления энтропии в мультизадацных операционных системах используется алгоритм Havege, а в микроконтроллере – младший бит результата АЦП, измеряющего шум резистивного делителя. Накопление энтропии производится до необходимого количества, оцениваемого с помощью группового частотного теста.
Основные криптографические примитивы (элементарная математика для X25519, Keccak800, ChaCha20) используют не оптимизируемые компилятором ассемблерные реализации для микроконтроллерных платформ (Cortex M1 и M4), тщательно проверенные на постоянство времени выполнения и с минимизированными утечками по побочным каналам ЭМИ и флуктуаций тока потребления. Сразу скажу – эти ассемблерные коды получены от профессионалов с мировыми именами, я лишь портировал их из GNU ASM в среду Keil, более привычную для сборки встроенных проектов.
Ну, что в итоге?
Если вы дочитали до этого места и не умерли со скуки, то значит, этот проект Вам действительно может быть полезен. Если так, то по запросу на почту рад предоставить тестовые сборки (статически линкованные исполняемые файлы, не требуемые установки), а также исходные коды графического интерфейса для Windows, Linux и Android в соответствующих средах разработки. Ядро проекта выполнено на базе кроссплатформенной библиотеки torfone, доступной поиском на github. Там же можно найти прямые ссылки на альфа-версию Андроид-приложения и краткое руководство по его установке и использованию, что поможет всем желающим оценить латентность телефонии в сети Tor.
Графический интерфейс реализован отдельно для каждой платформы и не является вариантом выбора (пока что это лишь альфа-тестирование). Тестовое приложение для всех версий Windows (начиная с древней Windows 98) выполнено в старом, но мощном Borland C++ Builder 6. Для Linux GUI-приложение разрабатывалось с использованием забытой Wide Studio для графики X11 отдельно для i386 и ARM архитектур. Первое должно работать как на 32- так и на 64-разрядных десктопах, второе – на недорогих одноплатных компьютерах: RPi, Orange, Nano и др. Для Android доступен apk-файл, собранный в Embarcadero RAD Studio 10.2. Это далеко не лучший вариант и пока что не умеет создавать Foreground service, но, тем не менее, стабильно работает в Background при отключенной оптимизации использования батареи. Также в среде Android поддерживается автоматическое резервное копирование файлов конфигурации, ключей и адресной книги (в зашифрованном виде) во внешнее хранилище и восстановление при переустановке Торфона или переносе на другое устройство. На момент написания статьи ведется работа над проектом в среде Keil uVision, включающим транспортный, шифровальный модули, аудио и графический интерфейс на базе Arduino — совместимого 320*240 TFT+Touch дисплея. В качестве открытой аппаратной платформы будет использована NanoPi Neo c устанвовленным Debian server и плата Nucleo STM32F446RE, соединенные через физический UART. В отдаленных планах – портирование в iOS, хотя я с трудом понимаю, как это может сочетаться с элементарными гарантиями безопасности.
И в завершение.
Мне часто задают одни и те же вопросы: как можно управлять пользователями без центрального сервера? Как забрасывать обновления, рекламу? И, главное, зачем это все мне нужно, если в этом нет коммерческой ценности?
На самом деле мир не такой серый и испорченный. И есть много ценностей, которые не измерить деньгами. А ответ на первые два вопроса – никак. Ну, нельзя Торфон остановить. Нельзя получить от него «ключи», слить действия пользователей, даже замеченных в терроризме или педофилии, нельзя забанить неугодных. Нельзя заставлять обновляться. Нельзя управлять извне. Нет в Торфоне никаких утечек, побочных соединений, кроме как предусмотренных протоколом. Это можно легко проверить как в коде (почти каждая строчка прокомментирована и не так уж много файлов в проекте), так и сетевыми анализаторами. Поэтому никто не сможет управлять пользователями Торфона. Но помните: Торфон – лишь инструмент, а все ваши действия – на вашей совести, и за них отвечаете вы, а не автор проекта.
Автор: gegel
