Защита от прослушивания разговоров — строим безопасную SIP телефонию своими руками

  • Tutorial
image
Привет, Хабр!
В этот раз хочу рассказать о технологиях шифрования VoIP звонков, о том какую защиту дают разные подходы и как организовать наиболее защищенную от прослушивания голосовую связь с технологическими гарантиями безопасности.
В статье я постараюсь доступно изложить особенности таких технологий как SIP\TLS, SRTP и ZRTP. И продемонстрирую конкретные схемы использования на примере нашего сервиса ppbbxx.com



Немного теории


Любой VoIP вызов состоит из 2-х основных составляющих: обмена сигнальной информацией и передачи между пользователями media потоков с голосом и/или видео.
На первом этапе, в процессе обмена сигнальной информацией, клиенты напрямую либо посредством сервера договариваются между собой о параметрах устанавливаемого вызова. Если связь устанавливается с помощью сервера, на основе сигнальной информации сервер авторизует клиента, устанавливает кто и кому звонит, проводит маршрутизацию и коммутацию. Благодаря данным сигнального протокола клиенты и сервер согласуют метод шифрования, используемые media кодеки, обмениваются ip адресами и номерами портов, где ожидается приём media и тд. Происходит это по таким протоколам как SIP, XMPP и прочим.
Непосредственно «разговор», то есть обмен между клиентами голосовыми данными, как правило происходит по протоколу RTP. Данные внутри передаются в том виде, о котором договорились клиенты и сервер на «сигнальном» этапе. Обмен голосом возможен как напрямую между клиентами, так и через сервер — посредник. Во втором случае сервер может помочь клиентам с прохождением NAT и в выборе кодеков.

Итак, что же собой представляет шифрованный VoIP вызов? Дальше речь пойдёт о SIP протоколе как наиболее популярном.
Как мы уже выяснили, звонок состоит из сигнальной и media частей, каждая из которых может быть зашифрована отдельно с применением специальных методов-протоколов. Для шифрования сигнальной информации применяется SIP\TLS, для шифрования «голоса» ZRTP и SRTP протоколы.

SIP\TLS — грубо говоря, аналог HTTPS для обычного SIP. Протокол позволяет клиенту убедиться, что он общается с нужным сервером при условии, что клиент доверяет предоставленному сервером сертификату. Подробнее можно прочитать на википедии

SRTP и ZRTP — это два разных способа шифровать RTP потоки. Принципиальное отличие между ними в том, что обмен ключами для SRTP происходит в сигнализации (на первой сигнальной стадии установки вызова). А для ZRTP непосредственно в начале обмена RTP пакетами (во второй, «медийной» части) по специальному протоколу, основанному на методе криптографии Диффи — Хеллмана.
Важно то, что для SRTP обязательным условием надёжности шифрования звонка является одновременное использование SIP\TLS + SRTP, иначе злоумышленнику не составит труда получить ключи (которые будут переданы по не шифрованному SIP) и прослушать разговор. В то время как для ZRTP это не важно, RTP поток будет надёжно зашифрован не зависимо от того, шифруется сигнализация или нет. Более того протокол умеет определять наличие «man in the middle» (в том числе серверов услуг!) между непосредственно говорящими клиентами. Это позволяет быть уверенным в том, что разговор невозможно прослушать, по крайней мере с точки зрения прослушивания сети/среды передачи данных.

Схема подключения SIP клиентов с различными настройками шифрования:
Схема звонков ppbbxx.com


Можно выделить следующие схемы установки шифрованного звонка:

  1. Оба пользователя используют SIP\TLS и SRTP. В этом случае обмен ключами для шифрования media происходят по защищенному сигнальному протоколу. Предполагается доверие к серверу, участвующему в установке связи. Посторонние не могут получить доступ ни к сигнальной информации, ни к голосовым данным. Недостаток в том, что пользователь не уведомлен на уровне протокола (клиента) и не убежден, что второй пользователь также использует шифрованное подключение к серверу.

  2. Оба пользователя используют ZRTP, голос при этом проходит через сервер. В этом случае сервер определяется ZRTP протоколом как Trusted MitM (man in the middle). Обмен ключами происходит по алгоритму, основанному на методе Диффи — Хеллмана (что и гарантирует невозможность прослушки) по протоколу RTP. Если при этом используется защищенный SIP\TLS — посторонние так же не могут получить доступ ни к сигнальной информации, ни к «голосу». Как и в первом варианте предполагается доверие к коммутирующему серверу, но в отличии от него для надёжного шифрования голоса не требуется обязательное использование защищенного SIP\TLS. Также, в отличии от первого варианта, каждый пользователь видит, что разговор шифруется до сервера с обоих сторон, а также то, что оба подключены к одному и тому же (доверенному) серверу.

  3. Оба пользователя используют ZRTP, но media устанавливается напрямую между клиентами. Так как обмен ключами проходит напрямую между клиентами, даже сервер, осуществивший коммутацию, не может прослушать разговор. В этом случае оба клиента отображают информацию о том, что установлен безопасный прямой сеанс связи. Убедиться в этом можно сверив SAS (короткие строки авторизации) — они будут одинаковыми. Если требуется скрыть от посторонних сигнальную информацию, следует использовать SIP\TLS. Это самый безопасный вариант, но в этом случае сервер не сможет выполнять многие функции, которые в других ситуациях выполняются на нем, к примеру запись непосредственно разговора, перекодирование голоса для клиентов с разными настройками аудиокодеков и тд.

  4. Один пользователь использует первый метод, описанный выше, а другой — второй. В этом случае так же требуется доверие к серверу. Сигнальная информация шифруется с помощью SIP\TLS. Для пользователя с ZRTP протокол сообщит, что шифрованное соединение установлено до сервера (End at MitM). Используется ли шифрование с другой стороны на уровне протокола узнать не удастся.


На этом закончим с теорией и перейдём к практике! Настроим собственный SIP сервер, создадим SIP пользователей, установим SIP клиенты и научимся совершать шифрованные звонки c помощью бесплатного сервиса облачной телефонии ppbbxx.com

Настройка сервера


настройка доменов ppbbxx.com
Для начала нужно создать собственный сервер. Для этого нужно зайти на сайт услуги ppbbxx.com, пройти простую регистрацию и войти в интерфейс настроек.

Первым делом пройдём в раздел "Internal network -> Domains" и создадим собственный домен, чтобы не быть ограниченным в выборе имён SIP пользователей. Можно припарковать свой домен либо создать личный субдомен в одной из зон сервиса.
Далее необходимо в разделе "Internal network -> Sip Users" создать SIP пользователей и настроить некоторые параметры их клиентов. Имена SIP пользователей могут быть произвольными, но так как на программных и аппаратных телефонах удобнее набирать цифры, мы будем заводить идентификаторы вида 1000@mydomain.ppbbxx.com и подобные. Я завёл 1000, 1001, 1002, 1003. После создания SIP идентификатора нужно не забыть нажать кнопку «Сохранить». Если никаких недозаполненных форм в интерфейсе настроек не осталось, система не будет ругаться и покажет лог изменений со статусом «Done».

Дальше необходимо настроить используемые кодеки и методы шифрования. Для этого нужно нажать значок с шестерёнкой слева от SIP идентификатора. Я планирую использовать SIP клиент (CSipSimple) на смартфоне и хочу использовать метод шифрования ZRTP поэтому в "basic" вкладке настроек выбираю кодеки G729 и SILK, а во вкладке "protection" ZRTP метод.

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

В целом, для настройки простейшей конфигурации этого достаточно. Можно настраивать SIP клиенты и звонить между ними, набирая их номера 1000, 1001, 1002, 1003. При желании к этому можно добавить общий SIP шлюз для звонков в телефонную сеть и настроить соответствующую маршрутизацию звонков. Но, в таком случае, это уже несколько иная схема использования услуги, которая требует скорее другого рода мер безопасности, нежели шифрование трафика до шлюза.

Перейдём к настройке SIP клиентов


Как я уже сказал, я планирую использовать CSipSimple на андроид смартфонах. Первым делом нужно установить клиент, используя стандартный Play Market, либо скачать на сайте производителя, который кстати открывает исходники своего клиента, что в отдельных случаях может иметь едва ли не сакральное значение. Установить нужно сам клиент и дополнительно кодеки. У меня установлены «CSipSimple», «Codec Pack for CSipSimple» и «G729 codec for CSipSimple». Последний платный и использовать его не обязательно, бесплатные SILK и OPUS обеспечивают достойное качество звонков по 3G сетям.

Запускаем CSipSimple и переходим в интерфейс настройки. Выбираем мастер «Вasic» и настраиваем, используя данные из веб интерфейса. Должно получиться так:
imageimage
Далее в общих настройках CSipSimple в разделе "Медиа -> Аудиокодеки" нужно выбрать предпочитаемые кодеки. Для звонков через 3G я рекомендую использовать SILK, OPUS, iLBC, G729. Поскольку настройки в интерфейсе сервера и в интерфейсе клиента должны совпадать, а на сервере я выбрал SILK и G729, то в списке аудиокодеков CSipSimple я ставлю галочки только напротив этих кодеков, а остальные снимаю.
В разделе клиента "Сеть -> Безопасный протокол" нужно выбрать желаемые параметры шифрования. Я включаю только ZRTP. Остальное оставляю выключенным. При желании можно использовать SIP\TLS — нужно учитывать что сервер ожидает TLS соединения на 443-м порту. Это сделано специально для слишком умных операторов мобильной связи, блокирующих стандартные для VoIP порты.
Так же нужно учитывать, что SRTP и ZRTP не всегда совместимы и крайне желательно выбирать в клиенте только один из них.

Совершение звонков с использованием ZRTP


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

Сразу после выполнения инструкции звонок SIP пользователя 1001 пользователю 1000 будет выглядит таким образом.
CSipSimple показывает, что в звонке участвует MitM сервер, к которому подключены оба клиента. Параметр EC25 означает, что используется протокол Диффи-Хеллмана на эллиптических кривых с параметром 256 бит. AES-256 — алгоритм симметричного шифрования, который применяется. Статус ZRTP — Verifyed означает, что контрольная строка SAS подтверждена пользователем.


Изменим режим передачи медиа в настройках ppbbxx для обоих клиентов. Установка direct media = yes позволит передавать голос напрямую. В этом случае стороны видят одинаковые строки SAS, используется алгоритм симметричного шифрования Twofish-256. Использование ZRTP в этом режиме требует от клиентов намного большей свместимости и менее надежно с точки зрения установки связи, поскольку сервер не участвует в передаче данных. Обязательно использование одинаковых аудиокодеков на всех клиентах и корректная работа NAT.


Если у SIP пользователя 1001 шифрование не установлено, тогда как 1000 использует ZRTP, то второй клиент покажет, что зашифрованная передача голоса происходит только до сервера (End at MitM).

Резюмируем


Связь полностью защищенную от прослушивания организовать можно. Это сделать не сложно. Наиболее подходящий способ для этого — использование протокола IP-телефонии SIP и метода шифрования медиа данных ZRTP. Сервис ppbbxx.com позволяет реализовать на практике различные схемы защищенной от прослушивания связи, в том числе без возможности дешифрования переговоров на коммутаторе. SIP клиент CSipSimple является открытым проектом и обладает достаточным набором функций для использования его в качестве безопасного клиента.
  • +15
  • 59,7k
  • 9
ppbbxx.com
14,46
Компания
Поделиться публикацией

Похожие публикации

Комментарии 9

    +1
    Но почему то аппаратные sip телефоны ZRTP не поддерживают. Видимо TLS+SRTP более распространенный способ.
      0
      Возможно, производители оборудования просто опасаются потерять лояльность мирового правительства, которое, разумеется, не приветствует вашу конфиденциальность ни в какой форме.
      0
      У меня все сидит мысль о включении SIP на всех устройствах и попытке перейти на него в общении с самыми частыми контактами, которые смогу пересадить. Но связь на мобильном интернете пока оставляет желать лучшего (наверное выбирал не те кодеки или в мобильных сетях часто есть совсем ужасные места). Смущает во всемэтом отсутствие втоматического выбора кодеков и шифрования под текущую связь и под друг друга (если разные клиенты с разными кодеками, то пусть находят то, что умеют оба). Если себя еще можно заставить с этим «дрючиться», то родных неайтишников уже нет. Нужен клиент, коорый бы был прост в пользовании, как скайп.

      Еще все сидит во мне идея, что установив на всех устройствах CJDNS роутер (может когда сделают удобную ноду под андроид тот же) мы даем всем устройствам белый IPv6 адрес в распределенной сети. Т.е. получаем отменный распределенный налог скайпа. Кстати, в сип сессиях в таком случае можно уже не шифроваться, т.к. CJDNS ведет END2END шифрование сам — просто пользуйся предоставленным протоколом IP. Правда скорость надо тестировтаь.

      Еще мне кажется, что со всей этой тягой к синхронной голосовой\видео связи мы себя очень жестко ограничиванием требованием к скорости соединений. Поэтому с такими вещами мы не уйдем далеко от провайдерских аплинков с чебурашкой и центральных серверов того же вайбера. Та же непопулярная голосовая почта или, в будущем, видео-почта имели бы существенно меньшие требования к пингу.
        0
        Я думаю это всё будет вполне возможно, учитывая как развиваются мобильные сети и телефоны.
        Но уже сейчас вполне можно пробовать строить для себя подобные решения.
        0
        >>«В этом случае стороны видят одинаковые строки SAS, используется алгоритм симметричного шифрования Twofish-256.»
        А можно чуть поподробнее про этот Twofish, а то я небольшой спец в вопросе. У вебманей просто есть оч удобная штука Вебмани.Войс — дополнительный виджет к андроидовскому кипер мобайлу, позволяющий совершать вызовы, шифрующиеся как раз по этому алгоритму. У меня партнер просто молится на этот сервис, дела только сквозь эту штуку обсуждает. Я сам пока со скепсисом смотрел на него. Это действительно надежно?
          0
          Twofish — это довольно надёжный метод симметричного шифрования.
          Его надёжность применительно к телефонии сводится к надёжности обмена ключами. В описанном вами случае обмен ключами проходит, судя по всему, по «сигнализации» которой в этом случае может являться https. Но это предположение.
          Фактически надёжность зависит от того как это сделано у вебмани, ну и они при желании ваши разговоры прослушать могут.
          Надёжность при нормальной реализации должна быть аналогична вариантам 1, 2 и 4 описанным в этой статье. Но врядли соответствует варианту 3.
          Но это только предположение. Я не знаю как тот сервис организован на самом деле.
            +1
            Без EC25 (или подобного), Twofish ничего не гарантирует, но даже при наличии EC25, например, для 100% гарантии вам нужно:
            а) Сверять SAS ключи каждый раз во время сеанса связи
            б) Понимать, что в клиент не встроено шпионское ПО
            0
            Обмен ключами происходит по алгоритму, основанному на методе Диффи — Хеллмана (что и гарантирует невозможность прослушки)

            Не гарантирует. Д-Х устойчив к MItM только на канале, защищенном от модификации, а тут такого канала, на сколько я понимаю, нет.
            Убедиться в отсутствии MItM-прослушки позволит, например, сверка отпечатков.

            В чистом виде алгоритм Диффи-Хеллмана уязвим для модификации данных в канале связи, в том числе для атаки «Человек посередине», поэтому схемы с его использованием применяют дополнительные методы односторонней или двусторонней аутентификации.
            © wiki
              0
              Как раз сверка отпечатков предполагается в схеме с использованием direct media. Совпадение SAS ключей и есть той самой технологической гарантией.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое