Azərbaycanca
Беларускі
Dansk
Deutsch
Española
Français
Indonesia
Italiana
日本語
Қазақ
Lietuvos
Nederlands
Português
Русский
සිංහල
แบบไทย
Türkçe
Українська
中國人
United State
Afrikaans
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. У такому випадку можливість «присутності» людини посередині збільшується, і про повну безпеку говорити не можна.
Дивись також
Посилання
Вікіпедія, Українська, Україна, книга, книги, бібліотека, стаття, читати, завантажити, безкоштовно, безкоштовно завантажити, mp3, відео, mp4, 3gp, jpg, jpeg, gif, png, малюнок, музика, пісня, фільм, книга, гра, ігри, мобільний, телефон, android, ios, apple, мобільний телефон, samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Інтернет
Session Description Protocol Security Descriptions SDES deskriptori bezpeki protokolu SDP dlya potokovogo movlennya odin z metodiv obminu klyuchiv dlya protokolu Secure Real time Transport SRTP Vin buv standartizovanij Specialnoyu komisiyeyu internet rozrobok IETF v lipni 2006 r yak RFC 4568 OpisDlya peredachi klyuchiv vikoristovuyutsya vkladennya protokolu SDP v povidomlennya SIP Invite Ce peredbachaye konfidencijnist transportnogo kanalu SIP yakij povinen zabezpechiti nedostupnist vkladennya dlya jmovirnoyi lyudini poseredini man in the middle Ce mozhe buti zabezpecheno pri vikoristanni transportu TLS abo bud yakih inshih metodiv yak napriklad S MIME Vikoristannya TLS pripuskaye sho nastupnij lanci v lancyuzhku SIP proksi mozhna doviryati i ce zabezpechit vimogi bezpeki zapitu Invite Perevaga cogo metodu polyagaye v tomu sho ce realizuvati nadzvichajno prosto Cej metod vzhe buv realizovanij kilkoma rozrobnikami Navit pri tomu sho deyaki rozrobniki ne vikoristovuyut dosit bezpechnij mehanizm obminu klyuchiv ce realno dopomagaye vikoristovuvati cej metod v yakosti faktichnogo standartu v bilshosti dodatkiv Proilyustruyemo cej princip prikladom u yakomu telefon posilaye zapit na dzvinok SIP proksi servera Format zapitu SIP Invite pryamo vkazuye sho nastupnij dzvinok povinen buti zroblenij yak bezpechnij Klyuch shifruvannya zakodovanij standartnim kodom Base 64 yak vkladennya 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 lt sips 222 mydomain com gt tag mogkxsrhm4 To lt sips 111 mydomain com user phone gt Call ID 3c269247a122 f0ee6wcrvkcq CSCO79XX 000129287FC1 CSeq 1 INVITE Max Forwards 70 Contact lt sip 222 10 20 30 40 1055 transport tls line demoline gt 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 Telefon otrimuye vidpovid vid proksi servera i vikoristovuyuchi otrimani dani mozhe takim chinom organizuvati dvostoronnye Tx Rx zashifrovane z yednannya 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 lt sips 222 mydomain com gt tag mogkxsrhm4 To lt sips 111 mydomain com user phone gt tag 123456789 Call ID 3c269247a122 f0ee6wcrvkcq CSCO79XX 000413230A07 CSeq 1 INVITE Contact lt sip 111 10 0 0 1 5061 transport tls gt 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 sendrecvOsoblivostiZagalna problema bezpeki polyagaye v tomu sho obmin klyuchiv povinen vidbutisya do togo koli nadijde pershij media paket dlya togo shob mati mozhlivist shifruvati klyuchami ci sami media paketi Shob uniknuti nepriyemnih klacan na pochatku pershi media paketi povinni ignoruvatisya Zazvichaj ce duzhe korotkij period chasu menshe 100 milisekund tak sho ce ne buvaye problematichno Metod SDES ne zabezpechuye vid i do shifruvannya media Odnak dosit spirno naskilki realna cya vimoga Z odnogo boku zakonni pravoohoronni organi hochut mati dostup do zmistu telefonnih rozmov Z inshogo boku bezlich inshih parametriv IP adresi nomeri portiv paroli STUN mozhut zazhadati zahist vid DoS atak Krim togo dlya povnoyi bezpeki media vid i do potribno spochatku vstanoviti pryami dovireni vidnosini z inshoyu storonoyu abonentom Yaksho vi vikoristovuyete infrastrukturu obminu klyuchiv z centrom sertifikaciyi v yakosti promizhnoyi lanki to vinikaye zatrimka pri kozhnij ustanovci z yednannya pri yakomu kozhna storona povinna avtentifikuvati svij klyuch v takomu centri sho stvoryuye dodatkovi trudnoshi dlya pochatku rozmovi Yaksho vikoristovuyetsya z yednannya rivnopravnih vuzliv LVS to vinikayut trudnoshi identifikaciyi inshogo boku Napriklad operator rozvivaye arhitekturu B2BUA i abonenti zmusheni z yednuvatisya ne bezposeredno a cherez IP PBX U takomu vipadku mozhlivist prisutnosti lyudini poseredini zbilshuyetsya i pro povnu bezpeku govoriti ne mozhna Divis takozhMIKEY alternativnij metod obminu klyuchami ZRTP protokol obminu klyuchami z vikoristannyam mediakanaluPosilannyaRFC 4568