id: Гость   вход   регистрация
текущее время 13:32 28/03/2024
Автор темы: gegel, тема открыта 24/06/2014 23:21 Печать
Категории: криптография, инфобезопасность, протоколы, защита телефонной связи
https://www.pgpru.com/Форум/ПрактическаяБезопасность/АнонсИдеиАппаратногоСкремблера
создать
просмотр
ссылки

Анонс идеи аппаратного скремблера

Параллельно работе над 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 является военным стандартом и его рефференс-код тщательно проверен на предмет выполнения произвольного кода при подаче на вход фатальных битовых последовательностей. Любая манипуляция входными битами без знания ключа шифрования может вызвать лишь искажение голоса вплоть до получения шума, но не нарушение криптографии в целом. Преимущество данного подхода очевидно: спонтанное искажение единичных битов приведет лишь к искажению голоса, но не к полному выпадению неаутентифицированных блоков.



 
На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.
Комментарии
— Гость (30/06/2014 03:05)   <#>

GSM — это не радиосвязь. Кстати, по ссылке как раз обсуждались альтернативные каналы связи.


Судя по картинкам по ссылке, «невидимость» луча просто феноменальная. Я думаю, если такое в городе запустить, незванные гости на пороге будут уже через 5 минут.
— SATtva (30/06/2014 09:58)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Заметно, что фотки сняты с очень высокой экспозицией. Но учитывая, какая сейчас истерия в связи с идиотами, светящими лазерами в самолёты (может, это на самом деле просто лазерные каналы связи?), гостей действительно можно будет ждать.
— unknown (30/06/2014 10:04, исправлен 30/06/2014 10:31)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Для связи с шифрованием точка-точка должен быть крайне простой аппарат, самосборный мобильник с неизбежной закрытой неподконтрольной частью только в виде GSM-модуля, а не переделанный смартфон. И у другого абонента должен быть такой же.



Можно использовать инфракрасный лазер, который невооружённым глазом невиден. Правда, ближний ИК виден на обычных фотоаппаратах и массово засветится на уличных камерах, видеорегистраторах, фотках и видеороликах со смартфонов.



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


При этом связь по рации, связь по GSM и связь через интернет — принципиально разные каналы, которые требуют разных скрэмблеров на этапе кодирования в цифру, но не шифрования. А вот криптографическая часть вполне может быть везде такой, как предложено.

— unknown (17/10/2014 10:26, исправлен 17/10/2014 11:54)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Описание некоего проекта, похожего на идею топика, на кикстартере (сумму собрали в сентябре), сайт http://www.jackpair.com, довольно кстати неудобный и малоинформативный, даже по сравнению с кикстартеровской страницей (лучше сначала прочитать/посмотреть её).


Авторы создали прототип аппаратного скрэмблера с кодеком, пробивающим GSM (имитирует речь) и с шифрованием DH/Salsa. Размером с флэшку или стандартную карманную зажигалку для сигарет. Подключается в разъём аудиогарнитуры к мобилке — шифруется только аналоговое аудио и нет контакта с аппаратной/программной частью мобилки (выломать встроенный микрофон в мобилке когда-то в форуме уже советовали). В принципе, наверное может работать и для VoIP (например, Скайп), и других аудиоканалов.


Нужно только нажать кнопку и посмотреть на экранчике высвечиваемый код, который и сверить по шифрованному каналу. Т.е., подключить в аудиоразъём, нажать кнопку, прочитать код с экрана при соединении. Любая бабулька справится.


Насчёт доверия к проекту — вопрос открытый. Много презентационных материалов, но мало описания технической части. Интересно как демонстрация возможности. Непонятно, что они уже реально сделали, а на что только заказы принимают. Если опубликуют все открытые спеки, то можно перевоспроизвести самому, хотя бы их прототип на raspberry pi.


P.S. Собственно, слово «скрэмблер» — устаревшее понятие из аналоговой техники, а термин «цифровой скрэмблер» — не совсем удачная попытка его осовременить.

— SATtva (17/10/2014 12:05)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Некоторое время назад даже Шнайер эту штуку попиарил.
— unknown (06/11/2014 00:06, исправлен 06/11/2014 00:11)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Всё-таки, проект модема на речеподобном сигнале, способном проходить внутри GSM-канала, не давал мне покоя. Изначально он упоминался в /comment80945, /comment80950, /comment80964, /comment80975. Затем вот проект Jackpair /comment84026.


Нигде не опубликовано ни подробное описание, ни даже намёки на то, как устроен собственно речеподобный модем. Сначала мне казалось, что это как-то очень сложно. Например, один раз обрабатывается много речевых записей, из них генерируется некая таблица фонем, которые лучшим образом проходят через GSM, это сопоставляется каким-то битовым последовательностям. Но проект JackPair косвенно указывает, что всё должно быть проще. Их девайс не тянет даже AES, они использовали бернштейновский симметричный шифр, чтобы сэкономить производительность, значит и речеподобный модем должен быть сравнительно просто устроен в плане генерации самих звуков.


Скорее всего, проект JackPair хочет выжать прибыль по максимуму, пока никто не разгадал их ноу-хау по речеподобному модему, а возможно они держат и патент наготове. Но идея носится в воздухе и по обрывкам информации мне пришла в голову её возможная реализация.


Итак, оцифрованный голос они кодируют в codec2, шифруют, а вот чем создают сигналы речеподобного модема? Скорее всего, самим codec2!


Представить, как звучит этот сигнал, вероятнее всего, можно нижеследующим способом.


Узнаем, какая звуковуха в ALSA-системе нам подходит коммандой aplay -L. Допустим это будет default:CARD=SB. Тогда, скачаем и скомпилим утилиты для codec2 и наслаждаемся звучанием посредством команды:


Скорость 2400 — оптимальная, звук очень похож на речь, покодированную чем-то вроде старого аналогового скрэмблера. Если взять 3200 — то слишком быстро и много высоких тонов, какое-то птичье чирикание. А на меньших скоростях псевдоречь очень медленная, много больших пауз. И скорее всего, раскодировка псевдослучайных бит через codec2 и есть тот речеподобный сигнал, который гарантированно проходит через GSM и другое внешнее речевое кодирование.


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


Если эта догадка верна, то вторая часть ноу-хау скрывается в системе кодирования (не путать с шифрованием): биты на входе возможно как-то дополняются, чтобы давать наиболее различимые фонемы. Ну и с однозначным раскодированием тоже не всё понятно: непонятен пока ни сам принцип однозначного обратного преобразования, ни система синхронизации, ни система коррекции ошибок. В GSM, когда каналы забиты и абонентам режут битрейт, очень часто пропадают куски (звуковые фреймы), возникают дребезжания (многократные повторы очень коротких фрагментов), задержки и пр. Кодирование и синхронизация должны уметь с этим эффективно бороться. Возможно и тут всё сравнительно просто, например всё бьётся на очень большие куски, к которым применяется FEC (Forward Error Correction).


Может, местный и потусторонний прочий коллективный разум что-то раскрутит по этой теме с пользой для открытого сообщества? Передать, если не голос в реальном времени, но хотя бы оффлайновый шифрованный файл через GSM было бы интересно. В Linux есть аудиоредактор Audacity, в котором есть плагин, правдободобно эмулирующий искажения GSM-канала, с регулировкой их уровня. Прохождение сигналов через GSM-канал можно сначала проверять в нём.

— Гость (06/11/2014 14:04)   <#>
Не знаток в области голосовой связи, но всё-же выскажу мысль. Самое простое это наверное выделить звуковые образцы, которые можно распознать после GSM-кодирования. Например если образцы А и Б после прохождения
через GSM-канал распознаются опять как А и Б, то получается однобитное кодирование: А=0, Б=1. Подобрать два образца можно и на слух без всякой теории. Например использовать два гласных – А и О, которые отличаются частотой и могут легко идентифицироваться при декодировании. Принципиально это решает задачу, но для повышения плотности кодирования необходимо увеличение количества образцов. Чтобы решить задачу по распознаванию образцов после прохода через GSM, нужно определить набор параметров, которыми описывается каждый образец, и критерии для их различия между. Получается чисто математическая задача – для заданных допусках по искажению при GSM-преобразовании и величине шума найти все образцы, которые могут быть различимы. Чем качественней канал, тем меньше допуски и тем больше можно использовать образцов. Чтобы контролировать ошибки, ввести CRC для кусков кодированной информации. В зависимости от качества канала и процента ошибок автоматически регулировать количество звуковых образцов, т.е. битность кодирования. Если ошибок много, то это количество/битность уменьшается, если мало – увеличивается.
— gegel (06/11/2014 20:40, исправлен 06/11/2014 21:23)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0

Я эту тему не забыл, но полностью переключился на ониофон, так что отложил до лучших времен. Но в начале лета провел несколько экспериментов по проходу GSM различными модуляциями. В частности, я поднял рефференс-код кодеков GSM-FR (классический, поддерживается всеми телефона), GSM-HR (половина битрейта, отключаемый), GSM-EFR (улучшенный на полном битрейте), а также семейство AMR. Все эти кодеки сейчас входят в проект ониофона, и можно включить онионфон в режим теста и использовать как платформу для тестирования, пропуская через нее модулированный сигнал (единственно что, работает автоподстройка битрейта, но только в случае нехватки быстродействия, и, кроме того, отключен DTX/VAD на GSM-HR, но если у кого-то возникнет желание тестировать, я сделаю кастомизированную сборку).
Для теста использовал две FreeDV, запущенные на двух компьютерах, итого понадобилось 3 компьютера, пара звуковых шнурков, микрофон и наушники.
FreeDV использует FDMDV-модуляцию в трех разных режимах: 14 полос без FEC, 16 полос с FEC, и 16 полос с бОльшим разносом между ними (Wide). Единственный кодек, через который удалось пропустить сигнал, был GSM-EFR, с ошибками меньше десятой процента, и без срабатывания VAD (по моему, в wide он все же срабатывал – кодек считал, что это не речь). Т.о. вопрос по крайней мере частично был решен, и можно было делать реализацию, в т.ч. и аппаратную.


Что касается теории, то ссылки в теме выше, наверное, исчерпывающие. Вкратце так.
В fileтеоретической работе (кстати, один из авторов – русский) подробно расписан алгоритм выбора псевдоречевых символов и формирования таблиц. Много математики, unknown должно понравиться. И, кстати. это похоже на предложенный Вами метод. Но есть один минус – не учитываются внутренние алгоритмы кодирования в GSM. Хотя, может, оно и лучше, т.к. дает статистически наработанную универсальность.
fileВ дипломной работе швед на гораздо более простом языке подробно излагает классический Суррейский путь (см. 3.1.1., я уже было подумал, что их алгоритм нон-паблик), а также предлагает его улучшение, и, самое главное, расширение на стандартный GSM-FR (остальные кодеки в любом телефоне можно принудительно отключить). Он использует синтетическую кодовую таблицу, наработанную не статистически, а выведенную исходя их особенностей кодового алгоритма (см. 5.3.7). Вобще. рекомендую прочитать – очень познавательно.
И, наконец, fileфранцузская статья, где показано, как просто и сердито решается проблема с помощью выше рекомендованной unknown модуляции 4QAM. Наверное, я мог бы выполнить подобную работу, протестировав FDMDV в различных вариантах и выбрав оптимум, но это позже, сначала закончу онионфон.


В итоге, наиболее простым вариантом видится использование FDMDV или 4QAM с настраиваемыми (возможно, даже, адаптируемыми к текущему каналу) параметрами, а наиболее перспективным – использование кодовой таблицы, рекомендованной шведом для GSM-FR. Кодер там тривиальный (в зависимости от слова данных выбираем из таблицы и шлем на звуковую карту нужный символ), декодер можно сделать минимальной переделкой стандартного GSM-декодера (заменить имеющуюся таблицу на свою).
Что касается статистической наработки, то тут будет напряг с ее синтезом на базе рандома и больших речевых фрагментов в матлаб. Я к этому не готов, если кто-то возьмется – респект.
Ну, и, наверное, вместо codec2 я бы использовал melpe (но лицензия!), и на выбор варианты на низком битрейте, но без FEC, и на более высоком, но с FEC.


ПС: это видится одним из тех немногих криптографических проектов, которые, несмотря на открытый код, в аппаратном исполнении будут иметь коммерческую ценность.

— unknown (06/11/2014 22:44)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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


Хотелось бы даже в двустороннем канале иметь одностороннюю связь (как UDP вместо TCP), полностью опирающуюся на FEC вместо CRC и не использующую какие-либо автоматические ответы для переотправок или подстройки канала — это ещё и для радио может пригодиться. Для голоса стопроцентная коррекция не нужна. Именно на этом принципе работает codec2 и его аналоги: если какие-то биты приняты неправильно, то кодек выдаст случайный речеподобный звук или искажение уже существующего. Если битовых ошибок мало, то человеческое ухо само всё поправит. Поэтому, если стоит задача передавать именно шифрованный голос, то можно использовать шифрование счётчиком без аутентификации и слабое FEC, больше для синхронизации, чем для исправления ошибок.


Я бы исходил из ситуации, в которой каналы связи труднодоступны (например, в районах стихийных бедствий или боевых действий), сигнал от сотовой вышки слабый, каналы перегружены, голос постоянно рвётся, качество связи ужасное, всем режут битрейт. Кроме того, может таким способом пытаться прокинуть канал внутри спутникового телефона (чисто голосовые звонки там гораздо дешевле, чем зверские тарифы на интернет) или недоверяемого VoIP (Skype и др.), возможно способ будет универсальным и для раций (а там некоторые современные модели в некоторых диапазонах голос уже тоже передают цифрой или имеют перескок частоты, но это всё закрытое и недоверяемое, хорошо бы иметь внутри этого свой канал). Т.е., заранее неизвестно, какой кодек будет в канале оператора и насколько плохое качество связи. Чем создавать коррекцию связи, абонентам проще голосом в открытую корректировать: «твой сигнал плохо схватывается, голос в шифре совсем не разобрать, попробуем переключиться на битрейт пониже, 1600 вместо 2400».


Есть что объединить по смыслу и почитать.


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


Вот когда-то ширпанку Циммерману было не до лицензий, после чего был такой бардак с алгоритмами в PGP: RSA пришлось выкидывать, а когда патент на RSA истёк — возвращать, но в другом формате; IDEA тоже выковыривали, так что те, кто к ней привык, долго использовали сторонние патчи, но сидели на несовместимых по свойствам ключах и т.д.
— gegel (19/11/2014 22:04, исправлен 19/11/2014 22:12)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0

Воодушевленный китайцами, провел эксперименты и сделал модем для GSM-FR по рекомендациям в шведской дипломной работе + некоторые расширения + синхронизация. Действительно, получился очень низкий BER через GSM-HR и чуть хуже через GSM-EFR на битрейте 1600, чего достаточно для кодека на 1200 + FEC 2/3.
Но GSM-HR был не проходим.


Очень внимательно изучил демку JackPair с ютуба, прогнав аудио через массу возможных анализаторов. Со слов китайцев, их модем прекрасно проходит fileGSM-HR и fileAMR-4750. Очень похоже по звуку, что в качестве модема они использовали готовый GSM-HR декодер, использующий кодовую таблицу CELP. Тщательно разобрал документацию ETSI на данные кодеки, чтобы использовать их в качестве модема.


В качестве модулятора можно использовать декодер GSM-HR (fig.5).
Четыре псевдоречевые символы длительностью по 5 мс выбираются из таблицы (512 шт) 9-ю битами каждый (CODE_1 – CODE_4), расположенными в фиксированных позициях сжатого фрейма (блока) кодированного голоса. Остальные биты надо оставлять постоянными, причем LPC-паремтры подобрать по равномерному спектру (китайцы, походе, их меняют каждые 40-60 мс для предотвращения сработки детектора не-голоса, отсюда специфическое улюлюканье), а GSP-параметрами задать максимальное усиление для статической таблицы и минимальное – для адаптивной. Блок с 4 псевдоречевыми сиволами (4*9 полезных бит) подаем на декодер и получаем фрейм псевдоречи (20 мс, 160 сэмплов), которую и передаем через аудиоканал.


В качестве демодулятора можно использовать GSM-HR-кодер (fig.2), подавая на него псевдоречь и извлекая 4*9 бит из кодированного фрейма. Сдвиг по времени (лаг) компенсируется самим кодеком по максимуму вероятности совпадения с стандартными табличными символами, так что остается лишь синхронизировать бит-поток, разбив его на блоки. В итоге получаем те же 1600bps чистые и 1200bps после FEC.
По идее, стандартная кодовая таблица CELP уже наработана с учетом реальной речи, поэтому такой вариант должен быть проходим через большинство кодеков.


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


Попробую еще так, результат отпишу.

— unknown (20/11/2014 09:37, исправлен 20/11/2014 09:38)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

А можете прокоментировать в шведской диссертации рис. "Figure 4.4. Framework voice channel" (стр. 46 в pdf или page 30 во внутренней нумерации документа)?


Насколько я понимаю, в реальном канале возможно двойное перекодирование всеми сочетаниями кодеков, например AMR Narrow → TETRA (если передаётся в транк). И идея в том, чтобы сигнал гарантировано проходил через все такие возможные сочетания.



Разговаривать на 1200bps в codec2 — это жесть! Это как голоса в голове слушать :)

— gegel (20/11/2014 12:40, исправлен 20/11/2014 12:46)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
в реальном канале возможно двойное перекодирование всеми сочетаниями кодеков, например AMR Narrow → TETRA

На сколько я понимаю, Figure 4.4 возможно в случае соединения между различными операторами, особенно различных систем связи. Например, один абонент использует GSM и старую трубу (в ней только GSM-FR) и звонит UMTS-абоненту (там только AMR). Тогда система должна преобразовать одно сжатие в другое через несжатый голос. Поэтому швед в своем фреймворке использовал два последовательных преобразования (но одним кодеком). Хотя мне кажется, что при использовании одинаковых кодеков в одной сети двойного преобразования не выполняется в целях экономии ресурса системы (и звонки с своей сети поэтому дешевле). Но принудительно выбираются (переключаются) кодеки абонентов из их набора возможных.
Я вчера почитал доки к GSM-модулям Quectel, которые я использую в других разработках. В инженерном меню есть команды выбора предпочитаемого кодека, а также есть возможность уведомления о используемом кодеке, а также каждый раз в случае его изменения. Попробую использовать две отладочные платы с модулями в одной и в разных сетях, проверю, что там реально происходит. А также попробую сделать реальный аналоговый аудиолинк через модули и проверю поведение модемов с ним.


Разговаривать на 1200bps в codec2 — это жесть!

Согласен. Меня и MELPE напрягает. Но это все для полувоенных задач, шептаться с девушкой так врядли кто будет.
А вот поврех Skype/Jitsi, возможно, придется искать более скоростные модемы. Например, скайповский Silk оказался весьма проходим.
Сделать шифровальщик там вобще можно без труда: в виндоус установить пару виртуальных аудио-кабелей (каждый создает в системе устройства ввода и вывода так, что все аудио, поданное на вывод, может быть считано с ввода). Кодировщик представляет два аудиоинтерфейса: один настраиваем на штаную звуковую карту, второй на шнурки. Скайп настраиваем на другие концы шнурков.
В линукс мне посоветовали в качестве аналога alsa loop, но я пока с ним не разбирался.

— unknown (20/11/2014 13:06)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Я бы на это особенно не наделся. Мало ли что учудит провайдер при падениях и перегрузке линии.


Это интересно в любом случае.


На 3200/2600 можно хотя бы узнавать голос и различать интонации. На более низком битрейте даже односложные команды можно перепутать. Т.е., для разговора нужна тренировка ушей. Понятно, что сквозь аудио-тракт GSM вытянуть гарантированные 1200 — уже успех.


Эту задачу решает такая надстройка на ALSA как Jack, но его используют только в профессиональной работе с сигналами вообще и со звуком в частности. Обычный пользователь его не поставит и не настроит. Хуже того, обычным пользователям удобнее PulseAudio, которое несовместимо (плохо совместимо) с Jack.
— gegel (20/11/2014 13:18, исправлен 20/11/2014 13:40)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0

Посмотрите варианты, которые мне посоветовали. Вы скорее в этом разберетесь.


http://www.alsa-project.org/ma...../Matrix:Module-aloop


http://www.vsound.org/


PS: этот пример показался мне более информативным:
http://unix.stackexchange.com/.....ing-alsa-loop-device

— unknown (20/11/2014 14:55, исправлен 20/11/2014 15:13)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Там всё закончилось предсказуемым срачем ALSA vs. PulseAudio.
И предсказуемым же призывом использовать ALSA+Jack. Чтобы стало вот так:


Option 1: don't use PulseAudio with JACK
The most experienced and demanding users of JACK do not attempt to link PulseAudio and JACK. Many of them will not run PulseAudio at all, having either never installed it, removed it from their systems, or disabled it. They will generally route audio from other apps to JACK without using PulseAudio

Option 2: use two different soundcards

И другие решения. Принцип в том, чтобы были рады или хомячки (PulseAudio), или продвинутые пользователи (ALSA+Jack). Или-или, а другая половина чтобы страдала. Похоже на проблему TBB у торпроджекта (выбор между системным тором и TBB).


Вот напишете вы свой аудиопроект под PulseAudio, >90% будут рады, а часть ни за что его не поставит, чтобы не связываться с PulseAudio также как с Java, Flash, Mono etc.


Виновник и первоисточник несовместимого аудиозоопарка печально известен, вот fileслайды, где он оправдывает свою позицию.

На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3