SDES

В статье не хватает ссылок на источники (см. рекомендации по поиску). Информация должна быть проверяема, иначе она может быть удалена. Вы можете отредактировать статью, добавив ссылки на авторитетные источники в виде сносок. (22 апреля 2015)

SDES — акроним Session Description Protocol Security Descriptions, что можно перевести как Дескрипторы безопасности протокола SDP для потокового вещания, один из методов обмена ключей для протокола Secure Real-time Transport SRTP. Он был стандартизирован Специальной комиссией интернет разработок — (IETF) в июле 2006 г. как RFC 4568 ^[1].

Для передачи ключей используются вложения протокола SDP в сообщения SIP — Invite. Это предполагает конфиденциальность транспортного канала SIP, который должен обеспечить недоступность вложения для вероятного человека посередине (man in the middle). Это может быть обеспечено при использовании транспорта TLS, или каких-либо других методов, как например S/MIME. Использование TLS предполагает, что следующему звену в цепочке SIP-прокси можно доверять, и это обеспечит требования безопасности запроса Invite. Преимущество этого метода состоит в том, что это реализовать чрезвычайно просто. Этот метод уже был реализован несколькими разработчиками. Даже при том, что некоторые разработчики не используют достаточно безопасный механизм обмена ключей, это реально помогает использовать этот метод в качестве фактического стандарта в большинстве приложений.

Проиллюстрируем этот принцип примером, в котором телефон посылает запрос на звонок SIP прокси-серверу. Формат запроса SIP Invite прямо указывает, что последующий звонок должен быть сделан как безопасный. Ключ шифрования закодирован стандартным кодом Base-64 как вложение SDP:

INVITE sips:111@mydomain.com;user=phone SIP/2.0 Via: SIP/2.0/TLS 10.20.30.40:1055;branch=z9hG4bK-s5kcqq8jqjv3;rport From: "222" <sips:222@mydomain.com>;tag=mogkxsrhm4 To: <sips:111@mydomain.com;user=phone> Call-ID: 3c269247a122-f0ee6wcrvkcq@CSCO79XX-000129287FC1 CSeq: 1 INVITE Max-Forwards: 70 Contact: <sip:222@10.20.30.40:1055;transport=tls;line=demoline>;reg-id=1 User-Agent: CSCO79XX/8.3.2 Accept: application/sdp Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO Allow-Events: talk, hold, refer Supported: timer, 100rel, replaces, callerid Session-Expires: 3600;refresher=uas Min-SE: 90 Content-Type: application/sdp Content-Length: 477 

v=0 o=root 2071608643 2071608643 IN IP4 10.20.30.40 s=call c=IN IP4 10.20.30.40 t=0 0 m=audio 42501 RTP/AVP 0 8 9 18 4 101 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:WbTBosdVUZqEb6Htqhn+m3z7wUh4RJVR8nE15GbN a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:9 g722/8000 a=rtpmap:18 g729/8000 a=rtpmap:4 g723/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=encryption:optional a=sendrecv 

Телефон получает ответ от прокси-сервера, и, используя полученные данные, может таким образом организовать двунаправленное (Tx/Rx) зашифрованное соединение:

SIP/2.0 200 Ok Via: SIP/2.0/TLS 10.20.30.40:1055;branch=z9hG4bK-s5kcqq8jqjv3;rport=62401;received=66.31.106.96 From: "222" <sips:222@mydomain.com>;tag=mogkxsrhm4 To: <sips:111@mydomain.com;user=phone>;tag=123456789 Call-ID: 3c269247a122-f0ee6wcrvkcq@CSCO79XX-000413230A07 CSeq: 1 INVITE Contact: <sip:111@10.0.0.1:5061;transport=tls> Supported: 100rel, replaces Allow-Events: refer Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, PRACK, INFO Accept: application/sdp User-Agent: Asterisk/1.4.21-1 Content-Type: application/sdp Content-Length: 298 

v=0 o=- 349587934875 349587934875 IN IP4 10.0.0.1 s=- c=IN IP4 10.0.0.1 t=0 0 m=audio 57076 RTP/AVP 0 101 a=rtpmap:0 pcmu/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:bmt4MzIzMmYxdnFyaWM3d282dGR5Z3g0c2k5M3Yx a=ptime:20 a=sendrecv 

Общая проблема безопасности состоит в том, что обмен ключей должен произойти до того, когда поступит первый медиа пакет, для того, чтобы иметь возможность шифровать ключами эти самые медиа пакеты. Чтобы избежать неприятных щелчков в начале, первые медиа пакеты должны игнорироваться. Обычно это очень короткий период времени (менее 100 миллисекунд), так что это не бывает проблематично.

Метод SDES не обеспечивает «от-и-до» шифрования медиа. Однако, достаточно спорно, насколько реально это требование. С одной стороны, законные правоохранительные органы хотят иметь доступ к содержанию телефонных разговоров. С другой стороны, множество других параметров — IP адреса, номера портов, пароли STUN могут потребовать защиту от DoS-атак.

Кроме того, для полной безопасности медиа «от-и-до» нужно сначала установить прямые доверенные отношения с другой стороной (абонентом). Если вы используете инфраструктуру обмена ключей с центром сертификации в качестве промежуточного звена, то возникает задержка при каждой установке соединения, при котором каждая сторона должна аутентифицировать свой ключ в таком центре, что создаёт дополнительные трудности для начала разговора. Если используется соединение равноправных узлов ЛВС, то возникают трудности идентификации другой стороны. Например, оператор развивает архитектуру B2BUA и абоненты вынуждены соединяться не напрямую, а через IP-PBX. В таком случае возможность «присутствия» Человека_посередине увеличивается, и о полной безопасности говорить нельзя.

• MIKEY альтернативный метод обмена ключей
• ZRTP протокол обмена ключами с использованием медиаканала

• RFC 4568 Архивная копия от 24 января 2009 на Wayback Machine