SDES
Session Description Protocol Security Descriptions (SDES) — дескриптори безпеки протоколу SDP для потокового мовлення, один з методів обміну ключів для протоколу Secure Real-time Transport SRTP. Він був стандартизований Спеціальною комісією інтернет розробок — (IETF) в липні 2006 р. як RFC 4568.
Опис ред.
Для передачі ключів використовуються вкладення протоколу 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. У такому випадку можливість «присутності» людини посередині збільшується, і про повну безпеку говорити не можна.