SRTP

Так как RTP тесно связан с RTCP (Real-Time Control Protocol), который может использоваться, чтобы управлять сессией RTP, у SRTP также есть родственный протокол, названный Secure RTCP (или SRTCP). SRTCP обеспечивает те же самые функции, связанные с безопасностью в RTCP, для той же функциональности SRTP в RTP.

Использование SRTP или SRTCP является необязательным при использовании RTP или RTCP, но даже если SRTP/SRTCP используются, все дополнительные возможности (такие как шифрование и установление подлинности) опциональны и могут быть включены или выключены. Единственное исключение — функция аутентификации сообщений, которая обязательна при использовании SRTCP.

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

• Сегментированный целочисленный счётчик — типичный режим, который осуществляет произвольный доступ к любым блокам, что является существенным для трафика RTP, передающегося в публичных сетях с непредсказуемым уровнем надежности и возможной потерей пакетов. В общем случае почти любая функция может использоваться в роли «счётчика», предполагая, что эта функция не повторяется для большого числа итераций. Но стандарт для шифрования данных RTP — только обычное целочисленное значение счётчика. AES, работающий в этом режиме, является алгоритмом шифрования по умолчанию, с длиной шифровального ключа по умолчанию в 128 бит и ключом сессии длиной в 112 бит.

• f8-режим — вариант режима способа обратной связи, расширенного, чтобы быть доступным с изменённой функцией инициализации. Значения по умолчанию для шифровального ключа и ключа сессии — то же, что и в AES в режиме, описаном выше. (AES, работающий в этом режиме, был выбран для использования в мобильных сетях 3G UMTS.)

Помимо шифра AES, SRTP позволяет прямое шифрование, используя так называемый «пустой шифр», который может быть принят как второй поддерживаемый шифр (или третий режим шифрования в дополнение к описаным двум выше). Фактически, пустой шифр не выполняет шифрования (то есть функции алгоритма шифрования, как если бы ключевой поток содержал только нули, и копирует входной поток в выходной без изменений). Это обязательно для этого способа шифрования, который должен быть обеспечен в любой SRTP-совместимой системе. Также это может использоваться, когда конфиденциальность, которую гарантирует SRTP, не требуется, однако другие возможности SRTP — аутентификация и целостность сообщения — могут использоваться.

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

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

Чтобы подтвердить подлинность сообщения и защитить его целостность, алгоритм хеширования HMAC-SHA1, определенный в RFC 2104, используется для получения 160-битового хэша, который затем урезается до 80 или до 32 битов, чтобы стать опознавательным признаком, включаемым в пакет. HMAC вычисляется по типу payload пакета и данных в заголовке пакета, включая номер последовательности пакета. Чтобы защитить против встраивания сообщений Человека_посередине, приёмник поддерживает индексы ранее полученных пакетов, сравнивает их с индексом каждого нового полученного пакета и пропускает новый пакет, только если он не проигрался (то есть был послан), прежде. Такой подход в большой степени полагается на полную защиту целостности (чтобы лишить возможности изменить индексы последовательности пакетов для обмана).

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

Периодическое изменение самой функции генерации ключей ведет к дополнительным мерам по усилению безопасности. Как правило это препятствует тому, чтобы Человек_посередине собрал большое количество зашифрованного материала, зашифрованного с одним единственным сеансовым ключом. Некоторые взломы легче выполнить, когда имеется большое количество зашифрованного материала. Кроме того, многократное изменение функции генерации ключей обеспечивает прямую и обратную безопасность в том смысле, что расшифрованный сеансовый ключ не ставит под угрозу другие сеансовые ключи, полученные из того же самого главного ключа. Это означает, что, даже если взломщику удалось получить определенный сеансовый ключ, он не в состоянии расшифровать сообщения, обеспеченные с предыдущими и более поздними сеансовыми ключами, полученными из того же самого главного ключа. (Хотя, конечно, полученный главный ключ даст все сеансовые ключи, полученные из него.)

SRTP полагается на внешний протокол обмена ключами, чтобы установить главный начальный ключ. Разработаны два специальных протокола для использования с SRTP — ZRTP и MIKEY.

Есть и другие методы, чтобы договориться о ключах SRTP. Несколько различных производителей предлагают продукты, которые используют метод обмена ключей SDES.

• RTP/RTCP
• ZRTP

• RFC 3711
• RFC 4771
• RFC 3551
• RFC 3550
• RFC 2104