Voice over TOR
Предлагаю для тестирования кипто VOIP-утилиту для работы через TOR (в режимах TOR -> доменное имя и TOR->скрытый сервис). Переделал с старого PGPFone: заменил транспорт на TCP и добавил адаптивный буфер для компенсации высокого jitter в TOR-туннеле. Также добавил обмен сообщениями и файлами.
Win98-XP-7-8. Полностью портируема. Работает peer-to-peer (звонить на доменное имя или TOR-hidden service). Использует DH4096+3DES.
Приветствуются замечания и пожелания.
Сайт проекта http://torfone.org (англ./рус.), там же доступны исходники (Visual C 6).
комментариев: 9796 документов: 488 редакций: 5664
SHA-256 — это хорошо. Но в строгом смысле — оно не PRF. Изучайте, где в протоколах и почему используется HMAC вместо просто хэшей.
Я не утверждаю, что это обязательно нужно всегда. Просто ставлю обратный вопрос — достаточно ли простого хэширования вместо PRF на HMAC, чтобы не развалить протокол пусть даже на уровне теоретических уязвимостей?
Вы же спокойно ле'пите (я без негатива и критиканства, с лёгкой доброжелательной иронией только) свой протокол из обрывочных знаний, даже не задаваясь элементарными вопросами.
Глава 6.The DH Shared Secret Key
Обратите внимание на 6.1 Key Derivation Function (KDF)
См. также:
7.3 Using the Shared DH Secret Key
Вы наивно полагаете, что SHA-256 — это "suitable key derivation function"? Я знаю только то, что она ей никогда не являлась.
Думаю, что даже если осилить ВСЮ работу и массу публикаций по этой теме, это не даст гарантий от дыр. У меня впечатление, что если анализировать код такого рода проектов, (популистский шифрпансковский I2P из той же серии), то граблей там навалом.
Не падайте духом, но шифрпанки, искренне желающие написать "код без закладок", очень полезны для NSA.
Даже зачастую специально не придумать таких бэкдоров, которые может учудить оптимистичный софтописатель. Циммерман — тоже не криптограф, при всём к нему уважении, он такой же шифрпанк своего времени. Благо, его код привлёк в своё время очень большое внимание и его направлял даже Шамир.
В подавляющем большинстве случаев открытый код не из академического собщества на уязвимости анализируют такие же программеры, не криптографы. Так что вопиющие дыры в реализации собственно крипто там могут спокойно оставаться незамеченными. Годами.
OCB — похоже удачный и обоснованный выбор. Хотя и грамотно реализованный CTR с аутентификацией тоже бы подошёл.
комментариев: 1060 документов: 16 редакций: 32
Пример PRF на базе HMAC можно найти в TLS 1.2 (rfc 5246, раздел 5)
Кстати, что unknown скажет про эту PRF?
комментариев: 9796 документов: 488 редакций: 5664
Если они ссылаются на это, то ничего плохого. Только без устаревших хэшей (sha-1, md5).
Ну разве что в отдалённом будущем ожидаются универсальные PRP-PRF-примитивы и все эти нагромождения когда-нибудь устареют.
комментариев: 393 документов: 4 редакций: 0
Сегодня прикрутил AES256-OCB вместо CAST. По свободному времени займусь PRF.
ПС: я не ставлю основной целью разработать суперзащищенное приложение, просто мне интересно разобраться. Это как вязание для домохозяйки, что-ли... :)
комментариев: 9796 документов: 488 редакций: 5664
Нормальная мотивация, информацию схватываете, работаете с ней самостоятельно, может и в профессиональный навык перейдёт :)
комментариев: 393 документов: 4 редакций: 0
Покопал код PGPFone: действительно, уязвимо было...
Так, при DH из битов общего секрета (равного к-ву битов прайма) просто по очереди бралось необходимое к-во первых бит для двух ключей для двух направлений связи :(
симметричный шифр в режиме CTR вообще не имел никакой аутентификации (даже crc32 считалась от криптотекста и просто дописывалась в конец пакета :(
Изменил таким образом:
использую PKCS#5 v2.0 PBKDF2 using HMAC_SHA256, 4096 итераций;
https://polarssl.org/pbkdf2-source-code
http://tools.ietf.org/html/rfc2898#section-5.2
отдаю ей в качестве пароля все биты общего секрета DH;
получаю 512 бит кей-материала для двух ocb-AES-256 ключей;
в качестве IV для ocb использую счетчик от старого режима CTR;
128-битный таг дописываю в конец каждого пакета.
3DES и AES256 в режимах CTR без аутентификации оставил для случаев экономии трафика при работе внутри Tor, т.к. длина пакета на 16 байт меньше, а особой необходимости в шифровании и нету.
Если есть явные ляпы или предположения уязвимости, очень прошу озвучить.
комментариев: 1060 документов: 16 редакций: 32
Круто! :)
Значит в случае использования какого-нибудь adpcm можно было вообще заставить воспроизвести звуковой мусор.
Мне кажется, это даже избыточно. PBKDF2 предназначена для получения ключей из совсем небольшого исходного материала(паролей) и довольно медленная.
Про OCB не скажу ничего, не знаком пока. :(
комментариев: 393 документов: 4 редакций: 0
И не только. Многие синтезирующие кодеки, например, тот же melp, пакуют биты в кадр строго на свои места, и используют старое состояние для инициализации нового. Черт его знает, а вдруг есть возможность, последовательно манипулируя битами, установить определенный известный кадр, и затем менять его уже целенаправленно.
А касательно передачи файлов – полный п-ц: если злоумышленник точно знает, какой файл вы будете передавать, то вообще без никакой криптографии заменяет его на свой, тем самым подсовывая поддельный документ или трояна. Теперь исправил, aes256-ocb будет в следующей верии.
Я вначале хотел использовать только PRF с подходящим размером выхода (например, SHA512 на два 256 бит ключа), но попал под критику :)
Хотя до сих пор тоже не могу понять смысл использования KDF для получения 512 бит кейматериала из 4096 бит DH секрета. Понятно, что без хеширования нельзя, т.к. биты секрета неравнозначны и коррелирующие между собой, но и KDF с ее итерациями и salt, затрудняющими подбор пароля по словарю, тут как бы и ни к чему.
PS: раз уж взялся за криптографию PGPFone (хотя никогда не собирался этого делать), то хочу еще проверить реализацию DH и особенно CSPRNG и коллектор энтропии, там тоже могут быть сюрпризы. Например, nautilus предупреждает, если аудиоэнтропии недостаточно для сидирования CSPRNG (микрофон отключен). PGPFone этого не делает, что уже нехорошо.
комментариев: 9796 документов: 488 редакций: 5664
SHA-1 и SHA-2 являются не очень хорошими PRF. Для построения стойкого PRF из них используется HMAC. То, что из HMAC в свою очередь делается (для других уже целей) PBKDF2 не значит, что нужно тащить его туда весь. Достаточно правильно использовать только HMAC.
См. RFC4868 для описания PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, PRF-HMAC-SHA-512.
комментариев: 393 документов: 4 редакций: 0
Еще раз спасибо за расширение кругозора: не знаю, пригодится ли это, но за плечами не носить :)
Переделывать уже не буду: PBKDF2 взял готовую (без напрягов), кроме того, по скорости не критично.
Я, наоборот, дополнительную задержку вводил после подсчета общего секрета: это еще один прикол PGPFone, опишу для поржать.
Во многих доках, начиная с 1996, упоминалось, что PGPFone иногда виснет на этапе согласования ключей. И действительно, около 1/20 конектов зависали. Я решил попробовать разобраться. После подсчета публичного ключа, как и положено, вычислялся его хеш. После предварительного обмена хешами происходил обмен самими ключами. После получения публичного ключа подсчитывался общий секрет и создавался енкриптор, при наличии которого ВСЕ дальнейшие пакеты уходили криптованными. Так вот, если один из участников запаздывал, другой участник формировал енкриптор и отсылал публичный ключ уже в криптованном виде :) Тупейшая ситуация... Я сначала вставил костыль в виде 1 сек задержки перед формированием енкриптора, а затем изменил код, чтобы публичный ключ никогда не шифровался. Теперь не виснет :)
Мне кажется, это не последние сюрпризы...
Передача файлов практически во всех протоколах (за исключением имеющих встроенную поддержку передачи файлов на должном уровне, типа SSH и OpenVPN) не шифруется, поэтому нужно самому зашифровать файл, подписать с помощью gpg и отправить собеседнику. Подмена файла атакующим в этом случае (и только в этом) исключается. Например, так рекомендуется передавать файлы через XMPP и Skype.
комментариев: 393 документов: 4 редакций: 0
PGPFone использует нестандартный Циммерманновский протокол передачи файлов, задумывался он как надежный. Он достаточно сложный, я с ним детально не разбирался. Это как бы свой ftp-tcp поверх udp. Имя файла или папки получаем методом drag&drop, выстраиваем файлы в очередь, каждый файл инициализируем (имя, длина, SHA), передаем пакетами размером около 900 байт с указателем, подтверждаем группу байт, дублируем при потерях. Конечно, медленнее чем ftp или http, но выглядет надежно. Используется отдельный счетчик пакетов для передачи файлов. Его значение + тип пакета входят в IV.
Проблема была не в протоколе, а в режиме CTR без аутентификации: зная, какой файл будет передаваться (plaintext), ксором получаем гамму и затем формируем новый cifertext из гаммы и своего plaintext (включая пакет с именем файла, длиной, sha...), пересчитываем crc32 – и подмена готова.
При использовании OCB это исключено. Т.е. после согласования ДИффи-Хеллмана и аутентификации (голосом по списку слов или предустановленной фразой с использованием HMAC) можно быть уверенным в аутентичности файла и конфиденциальности: предварительное шифрование/подписывание PGP вроде как и не нужно. Хотя, конечно, береженого бог бережет...
комментариев: 393 документов: 4 редакций: 0
Но я веду к тому, что TORFone сейчас и без GPG обеспечивает как шифрование, так и аутентичность передаваемого файла, так что предварительное шифрование/подписывание необязательно. Скорость медленнее, чем ftp или http, но для небольшого файла не критично. Как преимущество – некоторая маскировка факта передачи файла за счет нестандартного протокола.
А вообще то это задумывалось как вспомогательная фича, а вариантов анонимного файлобмена может быть много, например GPG+стеганография и в облако, или PGP и в папку http-сервера на Tor HS.
Конечно, Вы в праве (и должны) НЕ доверять протоколу TORFone до изучения исходников, поэтому ручное предшифрование не помешает.
комментариев: 393 документов: 4 редакций: 0
Наконец нашлось время допилить Торфон до
беты 1.1. Постарался учесть все замечания и пожелания, а также реализовал две свои идеи, которые давно вынашивал. Руководство по тестированию в картинках обновлю в ближайшее время, пока можно пользоваться обновленным html-хелпом (англ., рус.) в пакете TORFona и на сайте.
AES-256-OCB (128 bit MAC).
MELPE-1200 (STANAG-4591 NATO) и CODEC2-3200 для работы через GPRS: при приемлемой задержке в 350 мс получается всего 0.3-1.0 Кбайт/сек в одном направлении.
атаки фонетической реконструкции.
алгоритм синтезирующего кодека.
дачи анонимных свидетельский показаний в судах и выглядит надежным для правдоподобного отрицания при голосовой идентификации.
исходного кода теперь достаточно установить Visual C 6.0 на Windows XP, открыть файл проекта и нажать кнопку. Больше никаких пакетов и внешних библиотек не требуется. Абсолютно все используемые библиотеки в С-исходниках и доступны для анализа.
Хочу представить Торфон как звуковой плагин для популярного Торчата: нужно лишь добавить строку в файл torrc.txt, запустить Торфон, и можно выполнять и принимать звонки. В любой момент разговора можно переключиться на прямое UDP-соединение (выполняя NAT Traversal), просто установив галочку "UDP". Затем можно выбрать HQ-кодек (например, OPUS) и наслаждаться связью. Или выбрать супер-экономный MELPE и расходовать всего 2 Мбайт GPRS (в обе стороны) за час постоянного разговора. Сравните со Skype...
Само собой, TORFone полностью портабельный, работает c трукриптовского диска, из-под виртуалки WinXP (с сетевыми и звуковыми драйверами) и из-под Wine. Я взял на себя смелость внести значимые изменения в криптографию, поэтому версия 1.1 не совместима с 0.X
Криптография:
1. Добавил
Есть смысл использовать при прямых соединениях и меньше – при работе через Tor (чем больше длина пакетов, тем больше задержка)
2. Для получения ключей с общего секрета DH использую PKDF2
3. В процедуре аутентификации по списку слов заменил SHA1 на HMAC_SHA1 для предупреждения атаки подмены выбранного откр.текста (вместе с общим секретом там хеширутся еще куча параметров, которые можно менять).
4. Проверил источники энтропии CSPRNG, там все ОК (мышь, аудио вход, таймеры производительности и системного времени), но на выходе заменил SHA1 на HMAC_SHA1 из соображений рэндомности.
5. В двухфазной аутентификации с скрытым уведомлением под прессингом использовал PKDF2 для формирования тэга из фразы и HMAC собственно для аутентификации.
Голос:
1. Использовал кодеки MELP-2400 (MIL-STD-3005) (MELP не любит встроенный высокочувствительный микрофон: намного лучше выносной в составе гарнитуры у губ говорящего с минимально необходимой чувствительностью (в т.ч. и из соображений анонимности)) и CODEC2-1400 для работы через Tor, накапливая 900 и 1600 мс голоса соответственно в одном пакете: так компенсация Jitter даже лучше, чем при пользовании дополнительного буфера.
2. Добавил кодек
3. Добавил HQ-кодеки GSM0610
(взял со SpeekFrealy )и OPUS в режиме VBR 6 Кбит/с с возможностью опции маскировки VBR для предупреждения
4. Добавил опцию подавитель шума NPP7 для подавления случайных деанонимизирующих звуков окружения.
5. Добавил опцию вокодера для деперсонализации голоса. Использовал
Можно выбрать стандартные предустановленные режимы (голос высокий, низкий, робота, шепот, интонация вверх и вниз). По данной теме очень мало материала в паблике, похоже, такой же алгоритм используется
6. Поправил режим рации (PTT) и голосового управления (VOX), теперь не теряется конец фразы. PTT может быть использован для экономии GPRS-трафика и для удобства общения в Tor (В определенных пределах наблюдается четкая корреляция между общим трафиком и латентностью Tor-канала. Кроме того, латентность существенно выше при использовании Exit-нод, но это уже другая история: кому интересно, поделюсь результатами своих исследований для Tor и I2P).
Транспорт:
1. Наконец реализовал давнюю идею, позволяющую уменьшить Tor-задержки. После установки соединения с HS адресата ему посылается инвайт с указанием своего HS. Вызываемый устанавливает встречное соединение с вызывающим (по другим цепочкам). Голосовые пакеты дублируются в оба канала, используется пакет, доставленный первым (по таймстемпу). Накапливается статистика и периодически через заданный интервал времени более медленный канал согласованно переподключается, пока второй используется. Реально уменьшает задержки в полтора раза. Если отказаться от сторожевых узлов, то возможно, и больше. Не могу сказать, как такое дублирование повлияет на эффективность атак деанонимизации, на Tor-мейл-листе не ответили...
2. Также реализовал свою вторую идею: использование Tor в качестве SIP (если анонимность не важна). Нет привязки к конкретному VOIP-серверу, регистрации и логов на нем, DH выполняется внутри p2p-Tor-шифрования к HS (MitM практически нереально), используется нестандартный UDP-протокол (определенная обфускация от DPI)), если NAT Traversal невозможен, то Tor выполняет функцию TURN.
Абонент находит другого по onion-ссылке средствами Tor-HS инфраструктуры, затем выполняется Diffie-Hellmann под прикрытием Tor и затем NAT Traversal с использованием любого заданного публичного STUN. Я не использовал техники NAT penentratin, поэтому UDP не будет установлено, если оба абонента за симметричными NAT, но это бывает не так часто. Кроме того, проблемы могут быть, если оба абонента за любыми NAT (домашними роутерами) и затем за общим NAT (в локалке провайдера). У меня не было возможности проверить на большом количестве сетей, но во всех проведенных тестах прямое UDP-соединение было установлено. Вобще, было бы очень неплохо убедить разработчиков реализовать такой без-серверный VOIP, например, в Jitsi.
Другое:
1. Добавил индикатор исходящего/входящего трафика (с учетом IP-заголовков) в кбитах/сек и общий счетчик сеансового трафика в кбайтах, а также индикатор состояния двойного Tor-соединения.
2. Для компиляции
Спасибо сообществу pgpru за помощь, буду благодарен за замечания и пожелания.