id: Гость   вход   регистрация
текущее время 15:46 24/11/2017
Автор темы: 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 След.
Комментарии
— SATtva (25/06/2014 09:30)   профиль/связь   <#>
комментариев: 11514   документов: 1035   редакций: 4046
фиксирует таймстемп T, ограничивающий время для подбора злоумышленником и предотвращающий Replay-атаку.

B cлушает канал и, приняв посылку с флагом запроса, сверяет таймстемп

То есть предполагаются синхронные часы? Не слишком ли непрактичное требование?
— gegel (25/06/2014 10:21)   профиль/связь   <#>
комментариев: 389   документов: 4   редакций: 0
Не особо синхронные – предполагался допуск минутной погрешности.
Хотя, конечно, в аппаратной реализации это не совсем практично, да.
Собственно, таймстемп нужен исключительно для ограничения времени выполнения протокола для усеченных айтентификаторов. Но, как мне намекнули, это неэффективный костыль: хотя-бы в начале надо передать полный (128 бит) аутентификатор. В таком случае синхронизированный таймстемп можно смело выбрасывать, а для удаления зависших в ожидании соединений использовать счетчик тактов с момента включения устройства.
— unknown (25/06/2014 10:35, исправлен 25/06/2014 11:03)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

А, так вы всё-таки прослушиваете мои интернет-коммуникации! Буквально вчера искал документы такого плана.


Начал интересоваться возможностью создания скрытых каналов в WiFi. По типу стего поверх обычного WiFi-соединения между двумя подставными узлами (чтобы кто-то в стороне получал сообщение путём пассивного перехвата этого канала) или коротких импульсных односторонних связей.


Сначала нашёл fileэто и fileэто. Но показалось слишком примитивно.


Затем наткнулся на fileULTRA WIDEBAND DATA CHANNELS FOR SPECIAL OPERATIONS FORCES. Откуда вышел на fileMillimeter-Wave Soldier-to-Soldier Communications for Covert Battlefield Operations.


И дошёл до: fileRadio Communications in the digital Age, откуда заинтересовался STANAG и низкобитрейтным MELPe. Там, ближе к концу, после разъяснения азов, интересная информация


Начал думать, как это всё можно скомпоновать вместе и понавесить крипто. А тут вы со своей темой :)

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

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


Использование таймштампа T вполне оправданно, чтобы действительно не отвечать на слишком старые вызовы. Но тогда, почему бы его не включить и снаружи в чистом виде, и внутри хэша запроса?


Т.е., вместо PAB = H(IDA ║ Bx) считать PAB = H(IDA ║ T ║ Bx) и передавать запрос внешне по старому PAB, T, X, X', но с учётом зависимости PAB от T. И в других шагах протокола по аналогии.


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



Скрытно, это как?



Это если абоненты знают друг друга не только по ключам, но и по голосу. А если абонент B, скажет: «по этому вопросу свяжись с C, он больше владеет информацией». А с C до этого A никогда не разговаривал(а)?

— Гость (25/06/2014 21:19)   <#>
Уважаемый Gegel!

Аппаратный скремблер, это, конечно, хорошо, но каковы перспективы дальнейшего развития вашего Torfone – вот что заботит большинство пользователей!
Особенно с учетом непопулярных действий MS по Skype.
Вы посмотрите, какой переполох начался по этому поводу – https://www.linux.org.ru/news/internet/10606010, и это только на ЛОРе.
А у простого люда до сих пор нет надежного качественного открытого шифрующего Voice-мессенджера, которым можно заменить Skype.
Хотя количество их разработок достигает десятков, но все они в абсолютном своем большинстве – у.г.
Вот на что следует обратить ваше бесценное внимание и усилия!
— gegel (25/06/2014 21:33, исправлен 25/06/2014 21:42)   профиль/связь   <#>
комментариев: 389   документов: 4   редакций: 0
А, так вы всё-таки прослушиваете мои интернет-коммуникации!

СОРМ+. Добавлен астральный модуль.
СОРМ+Pro. Активный режим: участники pgpru дружно роют в направлении, заданном тов.майором :)
А если серьезно, то тенденция к смене модели со шпионской на военную тревожная.


Использование таймштампа T вполне оправданно

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


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


Скрытно, это как?

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

Это если абоненты знают друг друга не только по ключам, но и по голосу.

Я понял Шнаера немного по другому: человек четко отличает голос от не-голоса. Это и есть фактор аутентификации. Т.е. вероятность, не зная ключа, изменить данные так, чтобы после дешифровки и декодирования получить голос, а не шум, причем с другой голосовой информацией, пренебрежимо мала.
Хотя, конечно, если, рассматривать вариант с фразой "Казнить нельзя помиловать", то можно внести искажения и изменить двоякий смысл. Но на практике, учитывая наличие естественных искажений телефонии, обычно критические места уточняют.


PS: если можно, поменяйте в моем первом посте в двух местах SIGMA на SKEME: думал об одном, а писал другое...


каковы перспективы дальнейшего развития вашего Torfone

Доделываю консольный под Linux (но несовместим со старым по протоколу и криптографии – все оптимизировал). И сразу будет под Windows. Значительно улучшил обработку голоса (новые кодеки) и криптографию (ECDH, Keccak).

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

Поменял. Возможно, кое-какие вопросы и размышления сформулирую чуть позже.
— Гость (25/06/2014 23:35)   <#>


Можно попробовать текущую бетку? Или она сильно сыра?
— gegel (26/06/2014 02:53)   профиль/связь   <#>
комментариев: 389   документов: 4   редакций: 0
Можно попробовать текущую бетку? Или она сильно сыра?

Пока сырая. Я заморочился аудиокодеками (добавил практически все, что нашел), они жутко конфликтовали – потерял много времени. Вроде все наладил. Сейчас только взялся за криптографию. Постараюсь не затягивать.

To unknown: похоже, это те же ребята, что и по первой вашей ссылке: https://github.com/lulzlabs/AirChat
— unknown (26/06/2014 12:19, исправлен 26/06/2014 12:34)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Т.е. уже после согласования при установлении связи по шифрованному каналу передаётся от A к B значение MA, а от B к A значение MB?


Да и ещё в DH там предусмотрены проверки на навязывание плохих значений?


Ещё интересно: голос не аутентифицируется и не кодируется кодами упреждающей коррекции ошибок (FEC), это понятно. А данные запросов каким кодированием передаются в однонаправленном канале с помехами? В КВ (HF/SSB) и GSM особенно, где могут быть сильные шумы, задержки, пропуски, эхо и искажения. Или FDMDV это всё обеспечивает для данных?

— gegel (26/06/2014 23:50, исправлен 27/06/2014 00:37)   профиль/связь   <#>
комментариев: 389   документов: 4   редакций: 0
Т.е. уже после согласования при установлении связи по шифрованному каналу передаётся от A к B значение MA, а от B к A значение MB?

После DH-согласования мастер-ключа абоненты могут обмениваться голосовыми посылками. В начале каждой посылки в открытом виде передаются MA (MB) и CTR. Аутентификаторы служат одновременно и идентификаторами отправителей: получатель просматривает список открытых соединений и, найдя аутентификатор, идентифицирует отправителя и одновременно его подлинность. Прятать аутентификаторы под шифр нет смысла, т.к. тогда понадобятся отдельные идентификаторы отправителя. Кроме того, в этом случаем мы уходим от fileSKEME, что, скорее всего, повлияет на fileее доказуемо полную отрицаемость.


Тут хочу уточнить один момент: аутентификатор усекать нельзя: хотя бы однократно каждый абонет должен получить 128-битный аутентификатор другого (иначе Боб может MitM-мить, подобрав подходящий X' – Боб ведь может влиять на мастер-ключ). После обмена полными аутентификаторами можно перейти на усеченные (используя их только в качестве идентификатора отправителя). Думаю, есть смысл передать длинные аутентификаторы однократно в первых голосовых посылках. Если будет сбой передачи полного аутентификатора, соединение для кого-то из участников будет выглядеть неаутентифицированным, и он инициирует его переустановку.


CTR содержит младшие биты счетчика пакетов. Счетчики должны быть синхронизированы у абонентов, т.к. они используются в качестве IV. Счетчики передаются периодически на протяжении длинных голосовых посылок, чтобы корректировать возможную рассинхронизацию при потерях и уменьшить выпадание голосовых блоков. Счетчики корректируются только вперед, аналогичный механизм используется в Циммермановском PGPFone. Важно: CTR может быть коротким (в данном случае 8 бит), но дублироваться (в данном случае 3x), иначе помеха может сбить счетчик вперед, и тогда придется ждать, пока счетчик отправителя дойдет до установившегося значения, или переоткрывать соединение.


Вообще я опишу побитную структуру фреймов чуть позже, исходя из требований кодека и возможностей FDMDV-модема, прикидка уже есть. Модем обеспечивает передачу фрейма в 28 бит за 20 mS. Его достоинство (в сравнении с STANAG) – в начале посылки нет тренинг-сигнала, и плюс моментальное восстановление. 20mS звуковой фрейм содержит одну центральную несущую (для синхро) и по 7 боковых с каждой стороны, т.о. параллельно передаются 28 бит+1 синхро (фазовыми сдвигами). Один бит уходит на тип, остальные: или данные, или подтип+control. Я, гуляючи, придумал устойчивый транспортный протокол для проекта, но надо по свободному времени потестировать, хотя бы через микрофон между двумя ноутами для начала.


Да и ещё в DH там предусмотрены проверки на навязывание плохих значений?

Я не готов ответить, на сколько это актуально для EC25519. Для обычной DH публичный ключ проверяют на 0 и ±1 (в PGPFone это реализовано). Что касается ECDH, то планируется использовать C-реализацию. fileБернштейн пишет, что валидны любый публичные ключи (пункт Free Key Validation на стр.2). Или Вы не то имели в виду?

А данные запросов каким кодированием передаются в однонаправленном канале с помехами?

Это вопрос меня тоже волновал. Наверное, есть смысл использовать обычную CRC32, просто игнорируя ошибочные. Не знаю, какой процент ошибок (BER) реально получим в канале, но, думаю, 40 байт все же удастся передать без коррекции, если не с первого раза, то повторами (это полсекунды эфирного времени). А что касается ключа, то он тоже не такой уж длинный (скажем, те же 40 байт + PGP-сигнатура), и содержит урезанный отпечаток к качестве идентификатора, который есть хеш. Так что даже CRC32 не нужна. Публикуем периодически, рано или поздно выловится.

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

Всё строится на том, что под хэш запроса попадают случайные параметры DH. Поэтому посторонняя сторона (Ева), даже зная открытые ключи, по записи данных не может определить, кто с кем связывается — если речь речь идёт про радио (некоммутируемую среду распространения сигнала). И это хорошо :)


Но допустим, она определила это по косвенным признакам (пеленговала, номера GSM прослушивала). Затем, Ева от своего имени связывается с Бобом и прерывает сеанс после прохождения всех шагов («извините, не на тот номер попала»).


Также она может соединиться и с Алисой.


Затем, она знает, что настоящий Боб по каким-то причинам ответить не может. И знает, что в данный момент его вызывает Алиса. Сможет ли Ева выдать себя за Боба, подсунув Xb и Ay, записанные от предыдущих сеансов связи с настоящими Алисой и Бобом? Или хотя бы навязать известный ей K, пусть даже не пройдя аутентификацию? Или как-то вклиниться посредине? Хотя, вроде нет — аутентификаторы M не совпадут.



В то время как всё прогрессивное человечество использует MFSK для данных.


А совсем прогрессивное — 4QAM как раз под вашу задачу.


fileData transmission over voice dedicated channels using digital modulations:


Abstract. The mobile phone networks use medium rate voice coders. These coders use a destructive compression based on speech specific characteristics. Therefore, any other signal than voice could be highly damaged. In this paper we discuss the technical reasons of this degradation by exposing the principle algorithms used in speech coders, and the features and the effect of Voice Activity Detectors (VAD). We propose a flexible approach allowing data transmission up to 3 kbps with a binary error rate (BER) lower than 3.10-3. Such a bit rate makes it possible to transmit ciphered speech. This approach is based on using digital modulation and optimizing their parameters, in order to obtain a modulated signal that shows the better resistance to the speech coder and robustness to the VAD. The considered modulations are QAM and FSK. We evaluate and compare their performances for transmission through a medium rate speech coder.

Digital modulations can handle data transmission through an EFR speech coder at considerable binary rates. With 4QAM, we can reach 3 kbps while maintaining a BER lower than 3.10-3. The advantage of using digital modulations is the simplicity of the demodulation, which doesn’t require complex computations as in [3, 4]. Thus, it remains to add some error correcting code, and a channel equalizer in order to improve the BER and increase the achievable bit rate. The performances offer the possibility of tunneling real time speech conversations through speech-dedicated channels, like GSM voice channel, in order to establish a secure communication. In this case, the tunneled speech is coded at low bit rates, typically by a MELP 2.4 kbps. Then the binary coded parameters are modulated, and the modulated signal is transmitted through the channel, across one or more speech coders.

Т.е., можно упаковать всё в 4QAM и слать и свои данные, и кодированно-шифрованную речь по узким каналам с помехами и внешними кодеками, хоть по GSM, хоть по КВ/УКВ.

— gegel (27/06/2014 12:15, исправлен 27/06/2014 12:18)   профиль/связь   <#>
комментариев: 389   документов: 4   редакций: 0
И знает, что в данный момент его вызывает Алиса. Сможет ли Ева выдать себя за Боба

По описанию – классическая попытка MitM. Предлагаемый протокол – не мой велосипед, все же это доказанный fileSKEME. Как я уже писал, в классической SKEME общий ключ, которым стороны подписывают параметры (с перестановкой) выводится с помощью протокола fileAbadi, у меня – с помощью fileKEA+ (исключительно для удобства работы с ECDH вместо, скажем RSA). Правда, для KEA+ fileпоказана wPFS-атака в eCK-модели, но, мне кажется, в данном приложении это не суть важно, т.к. выводимый с помощью KEA+ ключ используется лишь для подписи других DH-параметров, и "мастер-ключевая" чистая DH сама по себе уже обеспечивает PFS. Даже утечка общего ключа подписывания после завершения протокола ничего не даст злоумышленнику, т.к. в любой новой сесии (в т.ч. параллельной) честной стороной всегда будут использованы новые DH-параметры.
Но это мы опять вступаем в высокие сферы доказательств, я зимними вечерами их столько перелопатил, что уже аллергия – проще использовать общеизвестные доказанные протоколы, что я и пытался сделать в проекте.


В то время как всё прогрессивное человечество использует MFSK.

Как раз вчера тоже был по этой ссылке :) Еще подробнее тут.
Программа open-source, можно даже скачать и потестировать все варианты. Большинство работает ниже уровня шума (маскировка!). Есть прикольные решения, например Hellschreiber, передающий в чат вместо кодов символов их графические сканы (человек сам корректирует искажения графического образа). Но они все слишком низкобитрейтные (для чата), для голоса не подходят. Да и исходный код MELPe-600 жутко проприетарный, мне так и не удалось достать. С больши трудом нашел MELPe-1200 (для Торфона), так что от этого и исходим. Как вариант, можно использовать для голоса FDMDV, а для чувствительных данных – MFSK, но это будет еще тот гемморой: определять еще и тип модуляции на фоне шумов. Как ни крути, а проще короткие, но важные данные защищать контрольной суммой и дублировать в случае ошибки, чем городить для них отдельную низкобитрейтную, но надежную инфраструктуру с FEC.
Другое дело, если дополнительно планируется обмен пользовательскими данными (например, картинками или документами). Мой проект этого не предполагает, и это значительно упрощает ситуацию. Но если это для Вас важно, то посмотрите проект Анонимусов по моей ссылке в посте выше – там используется как раз FLDIGI со всеми ее модемами. В их демо-видеоролике, ближе к концу, при демонстрации поиска в Твиттере ищут по ключевому слову Ukraine, прикольно.


PS:

А совсем прогрессивное — www4QAM как раз под вашу задачу.

Сейчас гляну.

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

Гляньте ещё на fileEnd-to-End Voice Encryption over GSM – Defcon.


Я так понимаю, что в голосовых цифровых сетях с вредными кодеками (GSM) данные лучше передавать в 4QAM (туда же и паковать шифрованный кодек для голоса), а небольшие объёмы данных на (ультра)коротких волнах — в MFSK-посылках. И посылка вызова будет слышна на слух.


Совсем извратный вариант: для КВ — в FMDV-модем положить данные в 4QAM в перерыве между голосом; а для GSM — обернуть всё в 4QAM.

— gegel (27/06/2014 14:49)   профиль/связь   <#>
комментариев: 389   документов: 4   редакций: 0
Дело в том, что каждый из вариантов (КВ, УКВ, GSM, WiFi-вставики) имеют свои особенности, поэтому пытаться делать универсальное решение только хуже. Например, в КВ это замирания, доплер при движении отражающего слоя в ионосфере, эхо от многократных отражений и даже повторы после втогого огибания земли. Плюс неточная настройка SSB (неизвестный частотный сдвиг). Где-то в этом блоге я встречал ссылку на документ с рекомендациями по эмуляции различных каналов, сейчас не найду.
Но в любом случае – это целые исследования, которые, к тому же активно продолжаются. Я не рискну взяться за разработку собственных решений в этой области, нет достаточного опыта. Пока поиграюсь с FMDV, а там посмотрим по результатам.
Кстати, тут блог по тестированию FMDV радиолюбителями на КВ, а тут – их проект в железе (аналогично, но без криптографии, конечно).
На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3