SDES ( Session Description Protocol Security Descriptions ) для потоков мультимедиа — это способ согласования ключа для протокола Secure Real-time Transport Protocol . Он был предложен для стандартизации в IETF в июле 2006 года (см. RFC 4568.)
Ключи передаются во вложении SDP сообщения SIP . Это означает, что транспортный уровень SIP должен убедиться, что никто другой не может увидеть вложение. Это можно сделать с помощью транспортного уровня TLS или других методов, таких как S/MIME. Использование TLS предполагает, что следующему узлу в цепочке прокси-серверов SIP можно доверять, и он позаботится о требованиях безопасности запроса.
Главное преимущество этого метода в том, что он чрезвычайно прост. Метод обмена ключами уже подхватили несколько поставщиков, хотя некоторые поставщики не используют безопасный механизм для транспортировки ключа. Это помогает получить критическую массу внедрения, чтобы сделать этот метод фактическим стандартом.
Чтобы проиллюстрировать этот принцип на примере, телефон отправляет вызов на прокси-сервер. Используя схему sips, он указывает, что вызов должен быть защищен. Ключ закодирован в base-64 во вложении SDP.
ПРИГЛАСИТЬ sips:*[email protected];user=phone SIP/2.0Через: SIP/2.0/TLS 172.20.25.100:2049;branch=z9hG4bK-s5kcqq8jqjv3;rportОт: "123" <sips:[email protected]>;tag=mogkxsrhm4Кому: <sips:*[email protected];user=phone>Идентификатор вызова: 3c269247a122-f0ee6wcrvkcq@snom360-000413230A07CSeq: 1 ПРИГЛАСИТЬМакс. количество нападающих: 70Контакты: <sip:[email protected]:2049;transport=tls;line=gyhiepdm>;reg-id=1Пользовательский агент: snom360/6.2.2Принять: приложение/sdpРазрешить: ПРИГЛАСИТЬ, ПОДТВЕРДИТЬ, ОТМЕНИТЬ, ПОКА, ОТПРАВИТЬ, ПАРАМЕТРЫ, УВЕДОМИТЬ, ПОДПИСАТЬСЯ, ПРАКТИКОВАТЬ, СООБЩЕНИЕ, ИНФОРМАЦИЯРазрешить события: разговор, удержание, ссылкаПоддерживается: таймер, 100rel, replaces, calleridИстекает сеанс: 3600;refresher=uasМин-SE: 90Тип содержимого: application/sdpДлина контента: 477в=0o=корень 2071608643 2071608643 В IP4 172.20.25.100с=вызовс=IN IP4 172.20.25.100т=0 0m=аудио 57676 RTP/SAVP 0 8 9 2 3 18 4 101a=crypto:1 AES_CM_128_HMAC_SHA1_32 встроенный:WbTBosdVUZqEb6Htqhn+m3z7wUh4RJVR8nE15GbNа=rtpmap:0 pcmu/8000а=rtpmap:8 pcma/8000а=rtpmap:9 g722/8000а=rtpmap:2 g726-32/8000а=rtpmap:3 гсм/8000а=rtpmap:18 g729/8000а=rtpmap:4 g723/8000a=rtpmap:101 телефон-событие/8000а=фмтп:101 0-16а=pвремя:20a=шифрование:необязательноа=отправитьприем
Телефон получает ответ от прокси-сервера, и теперь возможен двусторонний защищенный звонок:
SIP/2.0 200 ОКЧерез: SIP/2.0/TLS 172.20.25.100:2049;branch=z9hG4bK-s5kcqq8jqjv3;rport=62401;received=66.31.106.96От: "123" <sips:[email protected]>;tag=mogkxsrhm4Кому: <sips:*[email protected];user=phone>;tag=237592673Идентификатор вызова: 3c269247a122-f0ee6wcrvkcq@snom360-000413230A07CSeq: 1 ПРИГЛАСИТЬКонтакты: <sip:*[email protected]:5061;transport=tls>Поддерживается: 100rel, заменяетРазрешить события: см.Разрешить: ПРИГЛАСИТЬ, ПОДТВЕРДИТЬ, ОТМЕНИТЬ, ПОКА, ОТПРАВИТЬ, ОПЦИИ, ПРАКТИКУЙТЕ, ИНФОРМАЦИЯПринять: приложение/sdpПользовательский агент: pbxnsip-PBX/1.5.1Тип содержимого: application/sdpДлина контента: 298в=0о=- 1996782469 1996782469 В IP4 203.43.12.32с=-с=IN IP4 203.43.12.32т=0 0m=аудио 57076 RTP/SAVP 0 101а=rtpmap:0 pcmu/8000a=rtpmap:101 телефон-событие/8000а=фмтп:101 0-11a=crypto:1 AES_CM_128_HMAC_SHA1_32 встроенный:bmt4MzIzMmYxdnFyaWM3d282dGR5Z3g0c2k5M3Yxа=pвремя:20а=отправитьприем
Распространенной проблемой с защищенными носителями является то, что обмен ключами может не быть завершен, когда прибывает первый пакет носителя. Чтобы избежать начальных щелчков, эти пакеты должны быть отброшены. Обычно это лишь короткий промежуток времени (менее 100 мс), так что это не является серьезной проблемой.
Метод SDES не решает проблему «сквозного» шифрования медиа. Например, если пользователь A общается с пользователем B через прокси-сервер P, SDES позволяет согласовывать ключи между A и P или между B и P, но не между A и B. Для сквозной защиты медиа вы должны сначала установить доверительные отношения с другой стороной. Если вы используете для этого доверенного посредника, задержка установления вызова значительно увеличится, что затрудняет такие приложения, как push-to-talk. Если вы делаете это в одноранговой сети, вам может быть сложно идентифицировать другую сторону. Например, ваш оператор может реализовать архитектуру B2BUA и играть роль другой стороны, так что у вас все равно не будет сквозной защиты. Более новые современные протоколы, такие как ZRTP , предлагают сквозное шифрование для вызовов SIP/RTP.