SDES — акроним Session Description Protocol Security Descriptions, что можно перевести как Дескрипторы безопасности протокола RFC 4568.

Описание

Для передачи ключей используются вложения протокола SDP в сообщения SIP — Invite. Это предполагает конфиденциальность транспортного канала SIP, который должен обеспечить недоступность вложения для вероятного Человека_посередине. Это может быть обеспечено при использовании транспорта 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