SRTP

WebRTC использует DTLS-SRTP для шифрования, аутентификации и целостности сообщений, а также для защиты от атак повторного воспроизведения. Это дает конфиденциальность за счет шифрования RTP-нагрузки и проверки подлинности. SRTP это один из компонентов для безопасности, он очень удобен для разработчиков, которые ищут надежное и безопасное API.

Использование 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 обеспечивает конфиденциальность за счет шифрования RTP-нагрузки, не включая заголовки RTP. Также поддерживается проверка подлинности, которая широко используется как защитный механизм в RTP. В то время как SRTP можно использовать во всей его полноте, также возможно отключать/включать определенные функции. Главный затык в SRTP – это управление ключами, так как вариантов много: DTLS-SRTP, MIKEY в SIP, SDES (Security Description) в SDP, ZRTP и пр.

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

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

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

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

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