РегистрацияАнонс идеи аппаратного скремблера
Параллельно работе над Linux OnionPhone по просьбе трудящихся хочу взяться за разработку аппаратного решения для шифрованной телефонии через обычные акустические каналы со стандартной полосой 300-3000Гц (наземные телефоны, УКВ и КВ, в т.ч. SSB радиоканалы и, возможно, GSM/CDMA). Идея заключается в портировании открытого софта в подходящий DSP: низкобитрейтный кодек, софтверный модем и криптографию. Аппаратно потребуются: DSP (микроконтроллер) с АЦП/ЦАП (ШИМ) стандартной разрядности, производительностью не ниже 50 MIPS и со значительным объемом ПЗУ для кодовой книги аудиокодека, монохромный графический дисплей, подключаемый по трехпроводному SPI-интерфейсу (например, от Nokia 3310) для отображения результатов аутентификации, микроSD для хранения адресной книги (публичных ключей контактов), смарт-карта стандарта ISO7816 (например, GoldWaffer на PIC16F84+24LC16, ранее популярная для клонов сим-карт и карт платного спутникового телевидения) для хранения приватного ключа и возведения в его степень по модулю, и, возможно, внешнее ОЗУ.
В качестве голосового кодека думаю использовать или свободный Codec2, или лицензированный MELPe (стандарт NATO STANAG-4591) на битрейте 1200bps с подавителем шума NPP7, специально адаптированным для условий боя. В качестве модема – FDMDV из проекта Codec2, обеспечивающий битрейт 1450bps, быструю синхронизацию и восстановления после ошибок, устойчивый к частотным и временным сдвигам.
Хочу более подробно озвучить свои соображения по поводу криптографии: не с целью получить експертную оценку и потом ссылаться на форум, но чтобы как минимум исключить явные ляпы и, возможно, услышать конкретные советы по улучшению. Я старался не использовать совсем уж Bleeding edge, хотя все же предпочел Modern. Естественно, данный проект является исключительно образовательным (например, как основа для дипломной работы), так как шифрование гражданской радиосвязи в большинстве стран запрещено.
Задача.
В групповом попарном радиочате выполнять отбор сообщений для себя и их потоковое дешифрование с быстрой синхронизацией после потерь неизвестного количества байт. Индивидуальная аутентификация контаков друг перед другом должна выполняться с помощью уже имеющихся PGP-ключей, обеспечивать PFS и полную отрицаемость в отношении этих ключей, содержимого энергонезависимой памяти (в случае захвата устройства), а также между сеансами связи.
На первом этапе хочу сделать софтварную реализацию под Linux для i386 без использования FPU, приведенное описание протокола сделано под нее.
Планирую использовать ECDH на Бернштейновкой кривой 25519, хеширование Keccak, потоковое шифрование и PRNG с использованием Keccak Duplexing Sponge, для сидирования PRNG использовать HAVEGE (а в аппаратной реализации – RNG на шуме перехода стабилитрона).
Общее описание протокола.
При первичном включении генерируется индивидуальная долговременная ECDH-ключевая пара Aa, приватный ключ a сохраняется на диске (предполагается, что программа будет запускаться с TrueCrypt-контейнера). Публичный ECDH-ключ A (256 бит) дополняется пользовательской информацией I (256 бит) и подписывается с помощью PGP. В качестве публичного ключа используется:
PubKeyA = A | I | PGPSig{A | I}
Для идентификации используется отпечаток ключа в виде его 128-битного хеша:
IDA=H(PubKeyA)
Включение подписи в хеш блокирует UKS, характерную, например, для ранних версий OTR.
При появлении на радиоканале абоненты периодически, используя промежутки радиообмена, публикуют свои ключи, сопровождая их флагом ключа и CRC32. Последняя необходима только для исключения непреднамеренных ошибок передачи и не используется в протоколе. При размере ключа в 150-200 байт публикация займет около секунды. При получении валидного ключа он автоматически добавляется в адресную книгу. Позже в ручном режиме можно просмотреть полученные ключи, удалить лишние, проверить PGP-подпись, используя PGP PKI и пометить ключи как доверенные.
Публикация ключа полностью отрицаемая, т.к. ключ может быть переопубликован кем угодно на любом канале. Наличие ключа в адресной книге также отрицаемо, т.к. ключи принимаются и сохраняются автоматически. Например, приняв ключ на канале террористов, и затем опубликовав его на канале гомосексуалистов, можно всегда утверждать, что приняли его именно там, а ЗАС пользуетесь, т.к. стесняетесь ориентации.
Установка связи.
Для установки связи между A и B необходимо, чтобы оба участника уже имели ключи друг друга. Процедура установки связи сводится к обмену всего двумя посылками: А (инициатор) посылает запрос, а B (вызываемый) отвечает подтверждением. После этого между данными абонентами устанавливается приватный сеанс, и они могут общаться друг с другом без дополнительных согласований в пределах этого сеанса (но без PFS). Для обеспечения PFS абоненты просто переустанавливают сеанс, снова обмениваясь запросом и подтверждением.
A выполняет запрос для B:
– генерирует две DH-пары: аутентификационную и ключевую (Xx и X'x' соответственно);
– подсчитывает префикс:
P AB = H( IDA | Bx),
где IDA-собственный отпечаток, B – публичный DH-ключ получателя. Префикс усекается до 32 бит из соображений снижения битрейта. Он является только идентификатором, и даже если будет совпадение (2-32), то соединение не будет установлено из-за несовпадения ключей. Префикс полностью отрицаемый, т.к. любой может сгенерировать его, используя публичные отпечаток и DH-ключ участников.
– фиксирует таймстемп T, ограничивающий время для подбора злоумышленником и предотвращающий Replay-атаку.
– транслирует запрос в виде: P AB, T, X, X'
– добавляет в список ожидающих соединение запись IDB, T, x, x'
– удаляет слишком старые безответные записи из списка по таймстемпу.
B получает запрос от A и отвечает:
B cлушает канал и, приняв посылку с флагом запроса, сверяет таймстемп, затем "примеряет" ее к каждому контакту из адресной книги:
– однократно подсчитывает Xb, где b – собственный приватный ключ.
– для каждого абонента их адресной книги
извлекает IDn и подсчитывает Pn=H(IDn | Xb)
– при совпадении с префиксом считает, что получил запрос именно для себя предположительно от абонета n, иначе запрос адресован кому-то другому.
– аналогично генерирует две DH-пары (Yy и Y'y') и подсчитывает ответный префикс:
P BA=H( IDB | Ay),
где IDB-собственный отпечаток, A – публичный DH-ключ предполагаемого отправителя.
– транслирует ответ в виде: P BA, Y, Y'
– подсчитывает мастер-ключ данного соединения:
K=X'y'
Мастер-ключ выводится с использованием исключительно DH и не содержит материала долговременных ключей и ключей аутентификации. Это необходимое условие полной отрицаемости, в отличие от "разумной" отрицаемости, которую обеспечивают протоколы с неявной аутентификацией (например, FHMQV).
– подсчитывает аутентификаторы:
M A=H( Xb | Ay | X | Y | X' | Y' )
M B=H( Xb | Ay | X | Y | Y' | X' )
Учитывая идеальность хеширования Keccak, фактически DH-параметры мастер-ключа (X' и Y') подписываются (с перестановкой местами) общим ключом аутентификации. Это в точности соответствует протоколу SKEME, но в нем ключ аутентификации выводится с использованием протокола Abadi (обмен случайными значениями, зашифрованными публичными ключами участников), а в данном случае – с использованием протокла KEA+ (по смыслу то же, но с использованием DH-публичных ключей). SKEME обеспечивает полную отрицаемость и является доказуемо стойкой (по Кравчику). KEA+ также удовлетворяет требованиям отрицаемости, т.к. не использует непосредственой комбинации ключей A и B вне хеширования.
– инициализируется 32-битный счетчик-вектор для шифрования: С=0
– добавляет запись в список открытых соединений: IDA, T, С, K, M A, M B
A получает подтверждение от B:
А слушает канал, и приняв посылку с флагом ответа, аналогично "примеряет" ее к каждому контакту из адресной книги:
– однократно подсчитывает Ya, где a – собственный приватный ключ.
– для каждого абонента их адресной клиги извлекает IDn и подсчитывает
Pn=H(IDn | Ya)
– при совпадении с префиксом считает, что получил ответ именно для себя предположительно от абонета n, иначе ответ адресован кому-то другому.
– находит соответствующую запись в списке ожидающих соединение контактов и сверяет таймстемп получения ответа с таймстемпом отправки запроса, игнорируя ответ при слишком длинном интервале.
– подсчитывает мастер-ключ данного соединения:
K=Y'x'
– подсчитывает аутентификаторы:
M A=H( Xb | Ay | X | Y | X' | Y' )
M B=H( Xb | Ay | X | Y | Y' | X' )
– инициализируется 32-битный счетчик-вектор для шифрования С=0
– добавляет запись в список открытых соединений: IDA, T, C, K, M A, M B
– удаляет запись из списка ожидающих соединение
На данном этапе ни А, ни B пока не могут быть уверены ни в идентичности друг друга, ни в отсутствии MitM, т.к. они еще не обменялись аутентификаторами. Тем не менее они имеют общий мастер-ключ и могут начинать общение. Это исключает прерывание протокола при неудачной аутентификации, что необходимо для полной отрицаемости. Уведомление об аутентичности контакта будет скрытно выдано абоненту при приеме первой же голосовой посылки (любая передача теперь будет начинаться с аутентификатора). Также контролируется интервал времени по таймстемпу от начала протокола до получения первого аутентификатора, в случае слишком длинного интервала достоверность аутентификации снижается (т.к. злоумышленник имел время для вычислений).
Аутентификаторы также усекаются до 26 байт (этого требует низкий битрейт канала). Я старался внимательно проанализировать возможность использования коротких аутентификаторов и прише к выводу, что это допустимо в данной приложении, хотя буду рад услышать другие обоснованные мнения на этот счет и идеи.
При приеме данных с флагом голосового сообщения получатель ищет подходящий аутентификатор в списке открытых соединений. Если он там отсутствует, получатель считает, что сообщение адресовано не ему. Если аутентификатор обнаружен, и он не соответствует последнему контакту, то выводится сообщение о новом контакте в виде контактной информации из публичного ключа контакта и степени доверия, установленной ранее вручную в результате проверки PGP-подписи.
Вместе с аутентификатором в начале каждой передачи, а также с полусекундным интервалом на протяжении передачи, транслируется счетчик С (его младшие 26 бит). При приеме счетчика С его значение восстанавливается до полных 32 бит (только вперед!) и последовательность T | C | K используется для инициализации Keccak Duplexing Sponge. При получении последующих данных выжимается гамма, использующаяся для расшифровки потока. Т.к. транспорт не обеспечивает коррекцию ошибок по соображениям снижения битрейта и минимизации задержки, то регулярная реинициализация с полусекундным интервалом позволяет восстанавливать корректность расшифровки при потерях данных в случае длительной непрерывной передачи.
Также из соображений снижения битрейта и устойчивости связи аутентификация принятых данных не производится. Шнаер допускает такой подход при передаче голоса, т.к. голос сам по себе является достаточным аутентификатором. Такой же подход используется и в PGPFone Циммерманна. Голосовой кодек MELPe является военным стандартом и его рефференс-код тщательно проверен на предмет выполнения произвольного кода при подаче на вход фатальных битовых последовательностей. Любая манипуляция входными битами без знания ключа шифрования может вызвать лишь искажение голоса вплоть до получения шума, но не нарушение криптографии в целом. Преимущество данного подхода очевидно: спонтанное искажение единичных битов приведет лишь к искажению голоса, но не к полному выпадению неаутентифицированных блоков.
комментариев: 9796 документов: 488 редакций: 5664
Для КВ есть программа Pathsim. Только под винду. И возможно, какие-то аналоги. CoCoaPath — под MAC. Под Linux ничего нет.
Rowetel уже читал.
Готовых тестов для режимов данных на КВ
тоже хватает.
Может прямо внутрь FMDV вставлять данные запросов в режиме 4QAM, а сам FMDV считать оптимально проходящим через все каналы?
комментариев: 393 документов: 4 редакций: 0
Такая идея возникала, но это, наверное, еще больший геморрой в реализации, чем просто добавить FEC к FMDV или же даже чем чередовать FMDV и 4QAM (в последнем случае можно одновременно декодить и то, и другое, и далее методом исключения: если устойчивый 4QAM валидет, то, понятно, не голос в FMDV.
Ваша ссылка на GSM-modem просто супер, я давно думал над этим, и где-то так и предполагал решение. Дело в том, что скорее всего, FMDV через GSM не пройдет: GSM-кодеки (06.10-full rate, 06.20-half rate и 06.60 enhanced full rate) все же LPC, они ищет описатели именно голоса в специальных статичтически наработанных кодовых таблицах с учетом особенностей голосового тракта именно человек. В своей Linux-версии SpeakFrealy, которую я выкладывал пару месяцев назад, сигнал вызова (трель звонка) проигрывается не получателем, а отправляется отправителем, сжимаясь текущим кодеком. После декодирования даже на слух – не узнать, хотя речь разборчива.
Я по свободному времени попробую пропустить FMDV через все GSM-кодеки (все это уже есть в исходниках OnoinPhone и отлажено), но, боюсь, результат будет плачевный.
Решение, предложенное по ссылке (слайд 47), очевидно: подстроить модем под кодек, использовать его же таблицы так, чтобы модем генерировал для кодека понятные ему и обрабатываемые звуки (псевдо-речь).
Это новое решение, и, боюсь, кроме слайдов, в паблике не удастся найти даже спецификаций, не говоря об рабочем прототипе и исходниках – уж слишком это в пику большому брату. Разработать такое самому вряд ли под силу, во всяком случае у меня нет такого опыта и достаточно хорошего понимания LPC и особенностей его реализации в отдельных кодеках.
комментариев: 9796 документов: 488 редакций: 5664
Именно. Где-то даже упоминалось, что MELPe даёт плохую разборчивость с низким битрейтом когда речь не на английском. Т.е., отличие уже даже на уровне распознавания типичного произношения.
Кстати, видео к слайдам.
комментариев: 393 документов: 4 редакций: 0
Мало того, когда слушаю себя loopback-ом в своем Торфоне, радуюсь: MELPe-1200 такой милый английский акцент добавляет, как у настоящего американца, пытающегося общаться на русском :)
комментариев: 9796 документов: 488 редакций: 5664
Вот похожая работа ещё от других авторов:
комментариев: 9796 документов: 488 редакций: 5664
В смысле, всегда без проблем вычисляется:
Bx = Xb
Ay = Ya
комментариев: 393 документов: 4 редакций: 0
Да, конечно. Ограничения касаются лишь приватного ключа: он получается с 256 бит рандома сбросом младших трех бит и установкой 4-ого бита и старшего, если не ошибаюсь. Я это все лично тестировал, для проверки использовал тестовый код из Tor, отдельно
Берштейновские векторы и отдельно сотню DH-согласований c рандомными ключами. Все пробовал с различными компиляторами как под Linux, так и под Win32, и с разными оптимизациями. Никаких проблем ни разу не возникло.
Так это они есть, из Суррея. По первой ссылке просто использован их модем, их имена – на слайде 47. Жаль, работа не особо свежая, пробовать написать им уже нет смысла, наверное.
Если случайно наткнетесь на другие ссылки, буду безмерно благодарен – интерес к p2p поверх GSM огромен.
Я уже несколько лет дружу с китайской Quectel, производящей дешевые ($15) GSM-модули M12 и M85 на чипсете MT6252, базирующимся на ARM7 с возможности разработки встраиваемого прямо в модуль кода для пользовательский задач и имеющего все неообходимые HW-интерфейсы (SIM, аудио, клавиатура, дисплей, SD-карта, RS232). IMEI тоже может меняться налету изнутри. Конечно, он MELPe внутри не потянет, но можно добавить внешний STM процессор для кодека и модема. Т.о. можно сделать простой криптофон.
комментариев: 9796 документов: 488 редакций: 5664
Ссылки по Data/Encrypted Voice over GSM попадались ещё от индусов каких-то. Но малоинформативно. Такой же квадратик в схеме: а вот тут у нас псевдоречевой кодировщик. В принципе, можно попробовать совсем методом тыка: порезать речь на очень мелкие фрагменты, придумать между ними функцию сглаживающего перехода, посмотреть статистически — какие фрагменты лучше сохраняются в канале, выбрать их, назначить им комбинации битов и оптимизировать это всё по устойчивости-скорости, многократно прогоняя поиск с самого начала.
комментариев: 9796 документов: 488 редакций: 5664
Code Review lulzlabs Radio AirChat. Это просто обвязка к fldigi, которая стандартно в Linux дистрах есть. Если эта обвязка настолько кривая, как описано в обзоре, то она просто не нужна, как и попытка использовать её реализацию криптографии.
Для связи можно использовать лазеры. Или нелазерные фотодиоды, как в RONJA. Бывает ещё оптика с отражением от облаков, рассеивающийся и переотражающийся в воздухе через препятствия ультрафиолет (UV NLOS), связь через пространственное разделение светосигналов (по типу считывания картинок видеокамерой с экранов), ультразвуковые сигналы под водой, подземные токи и подземное радио… Потоки нейтрино ещё :) Много интересных каналов.
Оказывается, всё есть. Linsim, например.
комментариев: 393 документов: 4 редакций: 0
Я не пожалел времени – активно погуглил. Индус – это тот же N.N. Katugampala, просто публикуется в Англии. Но удалось найти гораздо более подробные работы:
По второй ссылке расписаны подробности реализации Katugampala.
Третья на турецком, но, похоже, в тему.
В принципе, если напрячься, то можно попробовать. Но не факт, что у меня хватит опыта – тема весьма специфическая, может занять массу времени, к чему я не готов.
Но если они просто желающие, как все? Тогда эти аппаратные решения достанутся еденицам (десяткам, сотням), а остальные миллионы юзеров слюну глотать.
Гораздо полезнее было бы сделать программный – разошелся бы по всему миру!
Заодно и имя бы свое обессмертили, как Циммерман :-)
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 393 документов: 4 редакций: 0
Из первого поста:
И то, и другое планируется. Но многие, далекие от теории, предпочтут доверяемое железо, и готовы за это заплатить. Сотф все равно open source: закрытое аппаратное коммерческое решение бесперспективно – доверия никакого. В других своих поделках я использовал хитрые способы доставки софта производителю с его активацией под ИД железа: производитель заливал загрузчик, устанавливая защиту от чтения, код загрузчика генерировал уникальный ИД, привязанный к ИД железа, на данный ИД я давал активационный ключ, в котором передавался мастер-ключ. При активации мастер-ключ помещался в устройство (под защитой от чтения), и с его помощью загрузчик расшифровывал публичную прошивку и писал ее в устройство. Т.о. после однократной активации можно было обновлять версии. Также были варианты активации на время, если в устройстве была возможность синхронизации часов (например, GSM или GPS).
PS:
4QAM тоже проходит. Так что есть перспектива решить проблему малой кровью.
Ну это не совсем скремблер, а полноценный криптованный голосовой мессенджер, включающий и скремблер.
А отдельный программный скремблер, как я понимаю, это универсальный модуль с открытым интерфейсом, который можно подключить, например, к Skype (если позволяет его API) и тем самым послать любопытных товарищей майоров из M$ и АНБ лесом.
http://www.vesti.ru/doc.html?id=1742120
Как ваш скремблер – получчше будет меркелевского? ;-)