Трафик VBR-кодека шифровать бесполезно

[waqur]

В принципе, уязвимость VBR-кодеков голоса к статистическому криптоанализу плотности трафика - вещь хорошо известная теоретически:
http://zfoneproject.com/faq.html#vbr

И все же, интересно видеть дальнейшее развитие этой темы в практическую сторону:
http://www.securityweek.com/defeating-skype-encryption-without-key

Впрочем, всё это представляет новизну только с точки зрения той информации, что есть в открытом доступе.
http://www.webplanet.ru/news/telecom/2009/09/04/fss_skype.html

UPD. Кстати, передача голоса в LTE - одном из наиболее перспективных стандартов мобильной связи 4-го поколения - тоже сделана хоть и поверх TCP/IP-сети, но на основе VBR-кодека. Ведь органы госбезопастности хотят слушать мобилки не только в своих странах, но и в чужих тоже.

Comments

[di-vizion-ary.livejournal.com]

Можно вопрос по теме шифрации. Заказчик выбирает решение по защите данных от компьютерного или физического доступа к данным. Данные хранятся в единой БД на двух сайтах (главный и резервный).
Собственно вопрос. Чтобы вы (какое средство, решение, АПК) предложили бы, чтобы надежно защитить данные заказчика.

[waqur.livejournal.com]

какая ОС? речь идёт о защите от прослушки трафика или шифровании данных на диске?

[di-vizion-ary.livejournal.com]

OS MS Win 2008 Serv. Поверх стоит MS SQL. Я пока думаю о шифрации данных БД с использованием оборудования SafeNet. Мне кажется, что от физического доступа к данным я таким образом защищаюсь.

[waqur.livejournal.com]

Речь идёт о ProtectServer HSMs?
http://www.safenet-inc.com/products/data-protection/hardware-security-modules/protectserver-hsms/

[di-vizion-ary.livejournal.com]

Вот об этом думаю. Кластеры на два сайта.

[di-vizion-ary.livejournal.com]

http://www.safenet-inc.com/products/data-protection/data-encryption-control/datasecure/

[waqur.livejournal.com]

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

Да, это будет работать. В числе возможных угроз видится только:
1. физическая кража этой железки вместе с сервером БД -- её надо спрятать подальше и охранять получше
2. вмешательство в загрузку сервера БД, захват ОС в гипервизор и отслеживание трафика с этой штукой -- а также выдача ей команд на расшифровку всей БД -- впрочем, вряд-ли ваш вероятный противник будет писать такой софт, верно?

[waqur.livejournal.com]

А может, и не нужен никакой гипервизор -- может быть, достаточно подменить библиотеку для Windows, которая связывается с этой железкой -- т.е. сделать битхак, чтобы она дампила свой расшифрованный трафик в файл. И затем дать MS SQL Server'у команду на дамп всей базы.

[di-vizion-ary.livejournal.com]

Честно говоря, я не думаю, что для заказчика кто-то будет заказывать специализированный хак. И долго, и муторно, да и риск по конфиденциальности теряется.
Предполагается защита от хакерских атак через внешнюю сеть, от действий инсайда (DBA, например), ну и от физического выноса оборудования. Железки, конечно же, будут спрятаны, т.к. не будут мозолить глаза. Как-то так.
Я так понимаю, что вы видите данный способ защиты достаточным.

[waqur.livejournal.com]

Да, если обе железки в охраняемом помещении (-ях) и круглосуточно под видеокамерой, то риском вмешательства в загрузку сервера можно пренебречь.

[di-vizion-ary.livejournal.com]

Кстати, да. Видеонаблюдение!
Надо подумать. Видеонаблюдение и мастер-ключ.

[waqur.livejournal.com]

И будет нелишним настроить аудит на этом DataSecure, чтобы если кто-то начнёт делать дамп всей базы (шифротрафик выше нормы), автоматически приходил e-mail человеку, который отвечает за безопасность.

Потому что риск подмены DLLки через Remote Desktop всё равно остаётся.

[di-vizion-ary.livejournal.com]

Аудит - конечно. Есть мысли по системе мониторинга всех подсистем ИБ, от периметра и видео, до вот таких интеллектуальных железок и антивирусных серверов.