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. У такому випадку можливість «присутності» людини посередині збільшується, і про повну безпеку говорити не можна.

Дивись також

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

Посилання

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.