Secure Real-time Transport Protocol — Безопасный Протокол Передачи Данных В реальном времени (или SRTP) определяет профиль RTP (Транспортный Протокол В реальном времени) и предназначен для шифрования, установления подлинности сообщения, целостности, защиту от замены данных RTP в однонаправленных и multicast передачах медиа и приложениях. Он был разработан небольшой командой криптоэкспертов IP протоколов компаний Cisco и Ericsson в составе David Oran, David McGrew, Mark Baugher, Mats Naslund, Elisabetta Carrara, Karl Norman, и Rolf Blom. Был впервые опубликован в IETF в марте 2004 как RFC 3711.
Так как 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 в потоковый шифр:
Помимо шифра 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.
Данная страница на сайте WikiSort.ru содержит текст со страницы сайта "Википедия".
Если Вы хотите её отредактировать, то можете сделать это на странице редактирования в Википедии.
Если сделанные Вами правки не будут кем-нибудь удалены, то через несколько дней они появятся на сайте WikiSort.ru .