Обзор и особенности протоколов передачи данных RTP/SRTP/ZRTP

RTP — (Realtime Transport Protocol) — является протоколом передачи мультимедийной информации в режиме реального времени прикладного уровня модели OSI. Данный протокол используется в системах связи, таких как телефония, видеоконференциях, IPTV и т.п.

RTP использует в качестве транспорта протокол UDP, а для мониторинга статистики передачи и обеспечения качества обслуживания RTCP. Протокол RTP является одним из технических основ в VoIP-телефонии, обеспечивая передачу голоса в таких протоколах, как SIP и IAX/IAX2.

Впервые спецификация протокола RTP была опубликована RFC  в 1996 году, а в 2003 была опубликована версия спецификации, используемая по сей день.

Обзор протокола RTP

RTP изначально разрабатывался для передачи мультимедиа, поэтому он имеет следующие особенности:

• Информация передаваемая по данному протоколу, содержит временные метки для синхронизации;
• Пакеты нумеруются для избежания потерь либо неправильного порядка доставки;
• Указывается формат передаваемых данных для контроля полезной нагрузки на канал.

К возможностям RTP стоит отнести такие функции, как компенсация джиттера, предоставление средств для отслеживания потерь среди пакетов и их неправильной доставки, контроля времени задержки. Также данный протокол позволяет проводить многоадресную доставку информации. Перечисленные элементы управления RTP, как правило выделяют в отдельный протокол RTCP (Real Time Control Protocol). Основной задачей RTCP является исправление ошибок и потерь при работе RTP, а также обеспечение обратной связи по качеству обслуживания при доставке данных.

Сеансы с использованием протокола RTP, как правило инициализируются между устройствами с помощью таких управляющих протоколов как SIP, IAX/IAX2, H.323. Они используются для создания и управления сеансом, в то время как RTP используется для передачи информации.

Взаимодействие RTP и RTCP

Взаимодействие механизмов работы RTP и RTCP происходит в режиме сессии. Для передачи видео либо аудио потока устанавливается отдельная сессия. В заголовке каждого пакета указывается тип полезной нагрузки, которая в него заключена. Работа протоколов RTP и RTCP происходит по двум разным портам (могут использоваться различные варианты портов), как правило для RTP назначается порт с четным номером, а на RTCP следующий порт с нечетным номером. В соответствии со спецификациями, нет четко определенных портов для данного взаимодействия.

Безопасность при передаче мультимедиа данных

Существуют две реализации шифрования медиаданных при их передаче. Обе эти реализации основаны на протоколе RTP, отличает их способ передачи ключа. SRTP передает ключ на этапе установления сессии, а ZRTP —  уже после, перед началом передачи данных. Для работы SRTP в качестве протокола установления сессии может быть использован только SIP\TLS для защиты от того, что передаваемый ключ попадет в руки злоумышленников.

Протокол SRTP

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

Шифрование информации выполняется методом AES, что положительно отражается на криптозащите информации и скорости работы протокола.Возможности по конфигурированию шифрования в SRTP весьма широки вплоть до использования любого, описанного в RFC стандарта шифрования (с четко описанным алгоритмом) или отключения шифрования вовсе (используя NULL-шифр). Отключение шифрования может быть полезно для экономии аппаратных ресурсов в том случае, если для вас важно обеспечение целостности и правильного порядка доставки данных, но не требуется шифрование. При этом сохраняется защита от playback-атак, так как блоки передаваемой информации нумеруются и исключена возможность повторной передачи уже ранее принятого сообщения. Методы шифрования SRTP обеспечивают не только безопасную передачу, но так же и безопасное воспроизведение мультимедиа, т.е. злоумышленник не только не сможет расшифровать данные, но и также не сможет их подменить либо воспроизвести. Для аутентификации сообщений и защите его целостности используется алгоритм HMAC-SHA1, в качестве аргумента функция хеширования получает данные из заголовка пакета о полезной нагрузке им переносимой, т.е. обеспечивается высокий уровень криптозащиты. Слабым звеном в данной схеме является то, что заголовки пакетов SRTP не шифруются и по данным о передаваемой информации, злоумышленник может сделать косвенное предположение что происходит обмен мультимедиа и каким-то образом помешать передаче.
Еще одним механизмом обеспечения безопасности данных в протоколе SRTP является обновление ключей идентификации. На основе главного ключа генерируются дополнительные идентификационные ключи для каждой отдельной сессии. Таким образом, даже если  злоумышленник получит ключ, передаваемый в сессии, то он не поможет ему для расшифровки других сессий, и объем полученных им данных не будет сколь-либо значительным.

Протокол ZRTP

ZRTP это основанный на RTP протокол, который предоставляет методы безопасности посредством шифрования данных. ZRTP основан на механизме симметричного шифрования без использования защищенного канала для передачи ключа. Говоря другими словами, ключи передаются между абонентами в режиме передачи мультимедиа, а не в режиме установления сессии и не видны каким-либо другим устройствам, принимающим участие в передаче данных. Ключ при установлении сеанса связи ZRTP создается уникальный для каждого отдельного звонка, его генерация основывается на публичных идентификаторах вызова. Ключи являются временными, после окончания звонка весь криптографический контекст уничтожается.
Удобство протокола ZRTP в том, что нет необходимости хранения заранее сгенерированных ключей и поддержания инфраструктуры их доставки, либо центров сертификации. Так же для ZRTP в теории не имеет значения, какой протокол используется для установления сеанса связи, т.к. обмен ключами происходит на уровне RTP.

Основываясь на методах симметричного шифрования, ZRTP не исключает возможность перехвата трафика, но позволяет быстро и безболезненно обнаруживать его. У злоумышленника, выполнившего перехват трафика есть всего лишь одна возможность скомпрометировать идентификационную строку (SAS). Плюсом к этому, генерируемые ключи для абонентов, уже устанавливавших ранее вызов, генерируются на основе хешей уже ранее созданных ключей. Т.е. если злоумышленник не получил доступ при первом звонке, то не сможет и при дальнейших.
           

ZRTP и Asterisk

Программная АТС Asterisk изначально не поддерживает ZRTP, так как логика работы Asterisk подразумевает что между абонентами всегда находится связующее звено в виде АТС. Логика же работы ZRTP принципиально отличается и старается исключить любую возможность промежуточных передач трафика во избежание его компрометации. Тем не менее существует набор патчей к Asterisk, разработанных в рамках проекта Zfone и описанных в библиотеке libzrtp, обеспечивающих поддержку данного протокола сервером Asterisk. Особенностью данной реализации является то, что она позволяет клиентским терминалам обмениваться RTP-трафиком непосредственно между друг другом, при этом параллельно терминалы обмениваются с АТС Asterisk SIP-трафиком. Шифруется только полезная нагрузка RTP/RTCP, заголовки пакетов передаются в незашифрованном виде.

Существует два основных режима работы реализации ZRTP в Asterisk: Passthrough и MiTM. В режиме сквозной передачи (Passthrough) АТС просто передает данные мультимедиа и сообщения ZRTP без изменений. Для поддержки данного режима, нужно внести только одно изменение — заставить Asterisk принимать и передавать сообщения протокола ZRTP. В режиме MiTM Asterisk действует как промежуточная точка и запускает протокол ZRTP для настройки безопасного соединения ZRTP между двумя конечными точками поочередно.

Процесс работы механизма реализации ZRTP для Asterisk сопровождается вызовами zrtp_event_callback () с соответствующими значениями событий. После запуска сеанса ZRTP существует три возможных стабильных состояния каждого потока: “Безопасный”, “Очистить” и “Ошибка”. Когда каждое состояние потока назначается, оно идентифицируется соответствующим обратным вызовом:

• Состояние ошибки. Это состояние указывает на программные или аппаратные ошибки в протоколе ZRTP. Это состояние не обрабатывается в текущей реализации Asterisk ZRTP.
• Состояние очистки. Поток может войти в это состояние, если на клиентском терминале включена опция «Перейти к воспроизведению RTP» или когда в Asterisk ZRTP включена опция allowclear. Во время вызова Asterisk обе опции отключены, поэтому поток не может войти в это состояние.
• Безопасное состояние. В режиме ZRTP Asterisk существуют разные способы входа в безопасное состояние. В зависимости от поддержки терминалами различных протоколов могут быть использованы режимы этого состояния: ENDPOINT (nonSIP/nonZRTP — SIP/ZRTP, MiTM (SIP/nonZRTP — SIP/ZRTP) или ENROLLMENТ (SIP/ZRTP — SIP/ZRTP).