of 15 /15
ENIGMA 2004 - VIII Krajowa Konferencja Zastosowañ Kryptografii Warszawa 10-13 maja 2004 Bezpieczeństwo protokołów sygnalizacyjnych VoIP: koncepcja bezpiecznej współpracy protokołów SIP i H.323 Wojciech Mazurczyk Instytut Telekomunikacji Politechnika Warszawska E-mail: [email protected] http://security.tele.pw.edu.pl/ Streszczenie W artykule dokonano omówienia oraz analizy stanu zabezpieczeń najpopularniejszych obecnie protokołów sygnalizacyjnych dla realizacji usługi VoIP (Voice over Internet Protocol): H.323 oraz SIP (Session Initiation Protocol). Przedstawiono koncepcję bezpiecznej współpracy protokołów SIP i H.323 z wykorzystaniem funkcji IWF SIP-H.323 oraz zaprezentowano szkic wymiany uwierzytelniającej dla mechanizmów SIP Digest oraz HMAC-SHA1-96 (Procedura IA). 1. Bezpieczeństwo VoIP. Zagwarantowanie bezpiecznych połączeń dla usługi VoIP jest sprawą złożoną. Nie ogranicza się ono jedynie do zapewnienia zabezpieczonego transportu strumieni danych zawierających głos, ważniejszą sprawą jest zabezpieczenie przesyłania wiadomości protokołu sygnalizacyjnego, na którym bazuje VoIP. Problemy bezpieczeństwa dla usługi telefonii IP w świetle powyższych stwierdzeń, uwzględniając rodzaje ruchu generowanego przez systemy VoIP, można podzielić na: a. Bezpieczeństwo wiadomości sygnalizacyjnych wymienianych pomiędzy stronami komunikującymi się, b. Bezpieczeństwo pakietów przenoszących głos (pakiety RTP), c. Problemy związane z „przechodzeniem” pakietów przez Firewall’e oraz przez mechanizmy translacji adresów wewnętrznych (np. intranetowych) na zewnętrzne (np. internetowe) NAT (Network Address Translation). Niniejszy artykuł skupia się wyłącznie na tematyce zawartej w punkcie a. 2. Protokoły sygnalizacyjne dla usługi VoIP Obecnie nie ma jednego ogólnoświatowego standardu protokołu sygnalizacyjnego dla VoIP. Najbardziej znanymi protokołami, obecnie koegzystującymi, są: H.323 (stworzony przez organizację ITU-T), SIP (Session Initiation Protocol – dzieło organizacji IETF), oraz H.248/Megaco (wspólny standard ITU-T oraz IETF). Współistnienie protokołów sygnalizacyjnych (szczególnie SIP i H.323) jest zjawiskiem, które w sposób niekorzystny wpływa na popularność i rozwój VoIP. Taka sytuacja jest wynikiem wspierania tego typu rozwiązań przez różne grupy na rynku telekomunikacyjnym: producentów i sprzedawców sprzętu, środowisk akademickich i naukowych, operatorów itp. Każda ze stron oferuje określone rozwiązanie, a przez to swoją wizję i próbuje je wypromować, jako najlepsze. Przykładem może być tu spór ludzi pochodzących z dwóch różnych środowisk telekomunikacyjnych: wywodzących się z tradycyjnych sieci PSTN (Bellheads) oraz wywodzących się z sieci IP (Netheads) nad ustaleniem modelu architektury sieci telefonii IP: rozproszonego czy zcentralizowanego. Taki brak zgodności owocuje niekompatybilnością i brakiem współpracy protokołów oraz produktów, które je wykorzystują. W niniejszym artykule ograniczymy się jedynie do rozważań związanych z protokołami SIP i H.323. Na początku należy zaznaczyć, że nie są to protokoły wzajemnie równoważne. Rola protokołu SIP, w przybliżeniu, odpowiada dwóm protokołom Q.931 oraz H.225, które stanowią część protokołu H.323. To właśnie Q.931 oraz H.255 odpowiedzialne są za zestawianie połączeń oraz ich sygnalizację. W dalszej części artykułu często, dla uproszczenia, utożsamia się funkcje protokołów SIP oraz H.323, należy jednak pamiętać jednak o wyszczególnionej powyżej różnicy. Porównując protokoły SIP oraz H.323, w zakresie ich wykorzystania w telefonii IP opartej wyłącznie o sieć IP (All IP), to lepiej sprawdza się protokół SIP. H.323 posiada duży nadmiar informacji sterujących, jest zbyt złożony i gorzej skalowalny. Dla równowagi H.323 ma dla przykładu bardzo dobrze zestandaryzowaną współpracę z sieciami PSTN i możliwości zarządzania. Obecnie trudno rokować, który z wymienionych protokołów sygnalizacyjnych zdobędzie dominującą pozycję. Jednym z prognozowanych scenariuszy jest również ich powolna ewolucja w jedno uniwersalne rozwiązanie. Poniższy rysunek prezentuje stos wspomnianych powyżej protokołów dla realizacji usługi VoIP według modelu TCP/IP: Wojciech Mazurczyk

ENIGMA 2004 - Bezpieczeństwo protokołów sygnalizacyjnych

  • Author
    others

  • View
    0

  • Download
    0

Embed Size (px)

Text of ENIGMA 2004 - Bezpieczeństwo protokołów sygnalizacyjnych

6.3 Sabe punkty w architekturze bezpieczestwa SIP w zaleceniu RFC 3261ENIGMA 2004 - VIII Krajowa Konferencja Zastosowañ Kryptografii Warszawa 10-13 maja 2004
Bezpieczestwo protokoów sygnalizacyjnych VoIP: koncepcja bezpiecznej wspópracy protokoów SIP i H.323
Wojciech Mazurczyk
1. Bezpieczestwo VoIP. Zagwarantowanie bezpiecznych pocze dla usugi VoIP jest spraw zoon. Nie ogranicza si ono jedynie do
zapewnienia zabezpieczonego transportu strumieni danych zawierajcych gos, waniejsz spraw jest zabezpieczenie przesyania wiadomoci protokou sygnalizacyjnego, na którym bazuje VoIP.
Problemy bezpieczestwa dla usugi telefonii IP w wietle powyszych stwierdze, uwzgldniajc rodzaje ruchu generowanego przez systemy VoIP, mona podzieli na:
a. Bezpieczestwo wiadomoci sygnalizacyjnych wymienianych pomidzy stronami komunikujcymi si,
b. Bezpieczestwo pakietów przenoszcych gos (pakiety RTP), c. Problemy zwizane z „przechodzeniem” pakietów przez Firewall’e oraz przez mechanizmy translacji
adresów wewntrznych (np. intranetowych) na zewntrzne (np. internetowe) NAT (Network Address Translation).
Niniejszy artyku skupia si wycznie na tematyce zawartej w punkcie a. 2. Protokoy sygnalizacyjne dla usugi VoIP Obecnie nie ma jednego ogólnowiatowego standardu protokou sygnalizacyjnego dla VoIP. Najbardziej znanymi
protokoami, obecnie koegzystujcymi, s: H.323 (stworzony przez organizacj ITU-T), SIP (Session Initiation Protocol – dzieo organizacji IETF), oraz H.248/Megaco (wspólny standard ITU-T oraz IETF). Wspóistnienie protokoów sygnalizacyjnych (szczególnie SIP i H.323) jest zjawiskiem, które w sposób niekorzystny wpywa na popularno i rozwój VoIP. Taka sytuacja jest wynikiem wspierania tego typu rozwiza przez róne grupy na rynku telekomunikacyjnym: producentów i sprzedawców sprztu, rodowisk akademickich i naukowych, operatorów itp. Kada ze stron oferuje okrelone rozwizanie, a przez to swoj wizj i próbuje je wypromowa, jako najlepsze. Przykadem moe by tu spór ludzi pochodzcych z dwóch rónych rodowisk telekomunikacyjnych: wywodzcych si z tradycyjnych sieci PSTN (Bellheads) oraz wywodzcych si z sieci IP (Netheads) nad ustaleniem modelu architektury sieci telefonii IP: rozproszonego czy zcentralizowanego. Taki brak zgodnoci owocuje niekompatybilnoci i brakiem wspópracy protokoów oraz produktów, które je wykorzystuj.
W niniejszym artykule ograniczymy si jedynie do rozwaa zwizanych z protokoami SIP i H.323. Na pocztku naley zaznaczy, e nie s to protokoy wzajemnie równowane. Rola protokou SIP, w przyblieniu, odpowiada dwóm protokoom Q.931 oraz H.225, które stanowi cz protokou H.323. To wanie Q.931 oraz H.255 odpowiedzialne s za zestawianie pocze oraz ich sygnalizacj. W dalszej czci artykuu czsto, dla uproszczenia, utosamia si funkcje protokoów SIP oraz H.323, naley jednak pamita jednak o wyszczególnionej powyej rónicy.
Porównujc protokoy SIP oraz H.323, w zakresie ich wykorzystania w telefonii IP opartej wycznie o sie IP (All IP), to lepiej sprawdza si protokó SIP. H.323 posiada duy nadmiar informacji sterujcych, jest zbyt zoony i gorzej skalowalny. Dla równowagi H.323 ma dla przykadu bardzo dobrze zestandaryzowan wspóprac z sieciami PSTN i moliwoci zarzdzania. Obecnie trudno rokowa, który z wymienionych protokoów sygnalizacyjnych zdobdzie dominujc pozycj. Jednym z prognozowanych scenariuszy jest równie ich powolna ewolucja w jedno uniwersalne rozwizanie.
Poniszy rysunek prezentuje stos wspomnianych powyej protokoów dla realizacji usugi VoIP wedug modelu TCP/IP:
Wojciech Mazurczyk
ENIGMA 2004 - VIII Krajowa Konferencja Zastosowañ Kryptografii Warszawa 10-13 maja 2004
Rys. 1. Stos protokoów dla VoIP
3. Zagroenia i mechanizmy zabezpiecze protokoów sygnalizacyjnych VoIP Zagroenia powstae na wskutek celowej akcji ze strony intruza moe mie charakter pasywny (istnieje jedynie
moliwo podsuchu lub stwierdzenia faktu przepywu wiadomoci) lub aktywny (moe doj do ingerencji w przesyanie wiadomoci np. poprzez zmian jej zawartoci).
Podzia na poszczególne klasy ataków na sie oraz na komunikowanie si w niej z podziaem na pasywne i aktywne przedstawia poniszy rysunek. Klasyfikacja ta jest zmodyfikowan wersj podziau wg. Stallingsa [17] uwzgldniajc charakterystyczne cechy VoIP.
Rys. 2. Podzia ataków na sie oraz komunikacj.
Ataki na usug VoIP s realizowane z wykorzystaniem odpowiednich technik, czyli okrelonych dziaa oraz
narzdzi uytych do przeprowadzenia ataku, wród których wyrónia si przede wszystkim: podszywanie si (Spoofing), podsuchiwanie (Sniffing) oraz odmowa usugi (Denial of Service).
Zdefiniowany powyej podzia, jak i informacje tu zawarte wykorzystane zostan przy definiowaniu kryterium oceny mechanizmów zabezpiecze protokoów sygnalizacyjnych VoIP w punkcie 5.
Istnienie wymienionych powyej rodzajów technik oraz klas ataków powoduje konieczno istnienia okrelonych rodzajów mechanizmów zabezpiecze koniecznych, aby im przeciwdziaa. Dla telefonii IP, poziom zabezpiecze gwarantowany protokoom sygnalizacyjnym moe by realizowany z wykorzystaniem dwóch typów mechanizmów zabezpiecze:
o Wewntrznych wbudowanych w wykorzystywany protokó sygnalizacyjny, o Zewntrznych – pochodzcych z innych aplikacji lub zapewnianych przez mechanizmy warstw
niszych ni warstwa aplikacji modelu TCP/IP np. TLS, czy IPSec. Dodatkowo moliwe jest jednoczesne wykorzystanie obu typów tych mechanizmów.
Wojciech Mazurczyk
ENIGMA 2004 - VIII Krajowa Konferencja Zastosowañ Kryptografii Warszawa 10-13 maja 2004
Niestety obecne implementacje VoIP spychaj na drugi plan stosowanie rozwiza bezpieczestwa dla wiadomoci
sygnalizacyjnych. Gówne powodami, dla których mechanizmy zabezpiecze systemów VoIP nie s obecnie powszechnie stosowane i implementowane s nastpujce:
• Wprowadzaj one dodatkowe opónienie (negatywny wpyw na parametry QoS), • Zwiksza si obcienie urzdze sieciowych, • Zwiksza si zapotrzebowanie na wymagane pasmo, • Infrastruktura klucza publicznego nie jest dostpna globalnie, • Istniej problemy z przepywem pakietów przez Firewalle i urzdzenia wykorzystujce technik NAT.
W kolejnych czciach artykuu, przy omawianiu konkretnych mechanizmów zabezpiecze dla protokoów sygnalizacyjnych bdziemy jeszcze wracali do powyszych problemów zwizanych z VoIP.
4. Tryby pracy protokoów sygnalizacyjnych VoIP Saboci, luki czy ograniczenia bezpieczestwa mog pojawia si z rónych powodów m.in. z bdnej lub
niekompletnej implementacji okrelonych protokoów VoIP. Dodatkowo sama sie pakietowa wykorzystujca stos TCP/IP np. Internet wprowadza pewne zagroenia i ograniczenia (chodzi tu gównie problemy zwizane z wykorzystaniem Firewalli oraz techniki NAT). W zwizku z tym, aby zapewni jak najwyszy poziom zabezpiecze stworzono dwa odmienne tryby pracy mechanizmów zabezpiecze: Hop-by-Hop (HbH) oraz End-to-End (E2E).
Tryb Hop-by-Hop oznacza, i przy kadym wle sieci VoIP znajdujcym si na drodze komunikacyjnej parametry bezpieczestwa s weryfikowane oraz przeliczane od nowa tzn. usuwane s poprzednie, „stare” parametry, a na ich miejsce wprowadzane s wyliczone parametry charakterystyczne dla wza sieci VoIP, w którym si obecnie znajdujemy. Pojcie „hop” oznacza kady wze sieci VoIP znajdujcy si na drodze komunikacyjnej pomidzy stronami. Realizacj tego trybu dla usugi poufnoci dla przykadowej sieci VoIP przedstawia Rys. 3.
Rys. 3. Dziaanie trybu Hop-by-Hop dla realizacji usugi poufnoci
Odmiennie ni w Hop-by-Hop, tryb End-to-End charakteryzuje si tym, i wykonanie algorytmów
kryptograficznych odbywa si jednie w punktach: ródowym i docelowym dla danego poczenia (z pominiciem elementów porednich). Dla zobrazowania rónic pomidzy opisywanymi trybami poniej znajduje si analogiczny jak dla Hop-by-Hop rysunek:
Wojciech Mazurczyk
ENIGMA 2004 - VIII Krajowa Konferencja Zastosowañ Kryptografii Warszawa 10-13 maja 2004
Rys. 4. Dziaanie trybu End-to-End dla realizacji usugi poufnoci
Oba typy mechanizmów zabezpiecze posiadaj zarówno swoje wady i zalety. Cechy charakterystyczne, w wietle
najwaniejszych z punktu widzenia bezpieczestwa, obu trybów oraz ich zestawienie i porównanie zostay zaprezentowane w tabeli numer 1.
Kryterium Tryb Hop-by-Hop Tryb End-to-End
Transport Dostp do caoci wiadomoci sygnalizacyjnej w
kadym wle sieci VoIP na drodze
Wiadomo sygnalizacyjna oprócz okrelonych nagówków jest
niedostpna dla porednich wzów sieci VoIP.
Wzy sieci S bardziej skomplikowane w caej sieci z uwagi
czynnoci kryptograficznych w kadym wle na drodze sygnalizacyjnej (wikszy koszt).
Komplikacja i wymagania wydajnociowe jedynie dla punktów
kocowych (mniejszy koszt).
Potencjalnie zabezpieczenie sygnalizacji od punktu inicjujcego do docelowego, lecz nie wszystkie pola
Dostpno nagówków (rutowanie)
Urzdzenia poredniczce maj atwy dostp do nagówków. Nie ma problemów z rutowaniem.
Niemono zabezpieczenia caej wiadomoci w trybie E2E, gdy cz informacji niezbdna jest do rutowania
Wpyw na QoS Negatywny – wikszy ni w trybie E2E, co w konsekwencji daje wiksze opónienia
Negatywny, ale wprowadza mniejsze opónienia ni w trybie HbH
Zaufanie Wszystkie wzy na drodze sygnalizacyjnej musz by elementami zaufanymi.
Ograniczone zaufanie do wzów porednich.
Wymagania na pasmo Wiksze ni w E2E Mniejsze ni HbH
porównania
komunikacyjnej.
Tabela 1 Porównanie wasnoci trybów Hop-by-Hop i End-to-End.
Z przytoczonych powyej cech mechanizmów End-to-End i Hop-by-Hop mona wywnioskowa, i trudno jest jednoznacznie okreli, którego typu mechanizmy powinny by wykorzystywane. Zarówno jedne jak i drugie posiadaj wiele zalet, a jednoczenie powanych saboci. Oczywicie, jeli udao by si jako w satysfakcjonujcy sposób rozwiza problem QoS w sieciach IP oraz moliwe byoby zapewnienie odpowiedniej mocy obliczeniowej zarówno w urzdzeniach kocowych jak i poredniczcych (co wpywa w znaczcy sposób jednoczenie na ich cen), wtedy w idealnej sytuacji mona by korzysta zarówno z jednego, jak i drugiego typu mechanizmów jednoczenie, co pozwolio by na cho czciowe, wzajemne skompensowanie si ich saboci.
Jednak do takiej sytuacji jest obecnie daleko, dlatego te pozostaje stosowanie rozwiza, na które pozwalaj rozwizania i parametry techniczne wykorzystywanej sieci i urzdze w niej si znajdujcych. Naley jednak wykluczy sytuacj, w której nie stosowane bd adne mechanizmy zabezpiecze.
Wojciech Mazurczyk
ENIGMA 2004 - VIII Krajowa Konferencja Zastosowañ Kryptografii Warszawa 10-13 maja 2004
W dalszej czci pracy zostan scharakteryzowane dostpne mechanizmy zabezpiecze w zalenoci od wykorzystanego protokou sygnalizacyjnego dla usugi VoIP z uwzgldnieniem wanie podziau na tryby HbH oraz E2E.
5. Kryterium oceny mechanizmów zabezpiecze protokoów sygnalizacyjnych VoIP Aby usystematyzowa przegld mechanizmów zabezpiecze a nastpnie je ocenia naley ustali kryterium,
wedug którego nastpi ich analiza. Przy wyborze naley kierowa si zarówno specyfik usugi VoIP, wybranych protokoów sygnalizacyjnych (SIP, H.323) i charakterem potencjalnych zagroe, technik oraz ataków (ostatnie zagadnienia zostay scharakteryzowane w punkcie 3).
W artykule zdecydowano si na wybór rozwizania bdcego modyfikacj podziau zawartego w normie ISO 7498-2, wedug którego bezpieczestwo w systemach otwartych naley rozpatrywa w kontekcie moliwoci zapewnienia piciu podstawowych usug ochrony informacji: kontroli dostpu (Access Control), uwierzytelnienia (Authentication), integralnoci danych (Data Integrity), poufnoci danych (Confidentiality) oraz niezaprzeczalnoci (Non-repudation).
Po uwzgldnieniu zarówno specyfiki protokoów sygnalizacyjnych SIP i H.323 jak i charakteru potencjalnych na niego ataków, przyjto kryterium, zdefiniowane jako umiejtno zapewnienia dwóch gównych usug ochrony informacji oraz komunikacji w sieci tzn.:
• Poufnoci – dajcej ochron przed atakami pasywnymi oraz zabezpieczajcej wiadomoci sygnalizacyjne, wymieniane pomidzy komunikujcymi si jednostkami, przed ich nieuprawnionym uzyskaniem przez strony do tego nieupowanione;
• Uwierzytelnienia – gwarantujcego ochron przed atakami aktywnymi oraz kontrol tosamoci stron i wiadomoci sygnalizacyjnych wymienianych pomidzy nimi. Dodatkowo na potrzeby póniejszej analizy mechanizmów zabezpiecze (gównie protokou H.323) podzia tej usugi na: uwierzytelnienie pene (uwierzytelnienie + integralno) oraz niepene (tylko usuga uwierzytelnienia).
Spenienie powyszego kryterium jest wystarczajce do uznania protokou sygnalizacyjnego, na którym bazuje VoIP, za bezpieczny. Poniewa jak wykazano w punkcie 1, bezpieczne przesyanie wiadomoci sygnalizacyjnych, w znaczny sposób, rzutuje na bezpieczestwo caej usugi VoIP, dlatego te prawdziwym jest stwierdzenie, i dziki temu cay system VoIP jest bezpieczniejszy.
Kolejne punkty charakteryzuj bezpieczestwo dwóch wybranych protokoów sygnalizacyjnych dla realizacji usugi VoIP: SIP oraz H.323.
6. Bezpieczestwo SIP Wyczerpujca analiza wszystkich dostpnych mechanizmów zabezpiecze dla protokou SIP zarówno dla zalecenia
RFC 2543 (marzec 1999) oraz nowego RFC 3261 (lipiec 2002) znajduje si w [8]. Tutaj zaprezentujemy rozwizania zawarte jedynie w obowizujcym obecnie standardzie (RFC 3261).
6.1 Usuga uwierzytelnienia w SIP
Mechanizmy zastosowane dla realizacji usugi uwierzytelnienia dla SIP w wersji drugiej zostay zamieszczone na rysunku poniej:
Rys. 5. Realizacja usugi uwierzytelnienia w SIP wg RFC 3261
Do realizacji uwierzytelnienia S/MIME wykorzystuje tunelowanie oraz podpisy cyfrowe. Przebiega to nastpujco: wykonuje si pen lub czciow kopi nagówków wiadomoci SIP i umieszcza wraz z oryginalnym ciaem w jednostce MIME, która reprezentuje ciao nowej wiadomoci. Nastpnie jest ona podpisywana cyfrowo z wykorzystaniem funkcji skrótu SHA-1. Dodatkowo wykorzystuje si algorytm klucza publicznego RSA do wymiany kluczy, a w konsekwencji do bezpiecznego przesania obliczonego skrótu do waciwego odbiorcy. Po osigniciu celu
Wojciech Mazurczyk
ENIGMA 2004 - VIII Krajowa Konferencja Zastosowañ Kryptografii Warszawa 10-13 maja 2004
adresat wiadomoci weryfikuje dostarczony podpis cyfrowy. Jeli jest on prawidowy to dodatkowo dokonuje si porównania tych nagówków, które nie byy wykorzystywane przez urzdzenia znajdujce si na drodze komunikacyjnej, poniewa one mogy by modyfikowane (zapewnienie podstawowej integralnoci wiadomoci).
Jeli natomiast, jako mechanizm gwarantujcy uwierzytelnienie zosta wybrany SIPS URI to caa droga komunikacyjna powinna by zabezpieczona z wykorzystaniem protokou TLS (czyli musi on zosta zaimplementowany w caej sieci, gdy jest to warunek konieczny do prawidowego funkcjonowania SIPS URI). Jeli taki warunek nie moe zosta speniony - nie dochodzi do nawizania poczenia.
Mechanizm SIP Digest zosta opisany w punkcie 8.3.
6.2 Usuga poufnoci w SIP Jeli natomiast chodzi o realizacj drugiej usugi zdefiniowanej w wybranym przez nas kryterium to stosuje si tu
przede wszystkim mechanizm szyfrowania. Prezentuje to rysunek poniej:
Rys. 6. Realizacja usugi poufnoci w SIP wg RFC 3261
Realizacja usugi poufnoci z wykorzystaniem mechanizmu S/MIME przebiega podobnie jak w przypadku
realizacji usugi uwierzytelnienia (równie wykorzystywana jest enkapsulacja czci wiadomoci w jednostce MIME) z t rónic, e zamiast funkcji skrótu stosuje si tu szyfrowanie 3DES. 6.3 Sabe punkty w architekturze bezpieczestwa SIP w zaleceniu RFC 3261
Protokó SIP zdefiniowany w zaleceniu RFC 3261 definiuje architektur bezpieczestwa, która jest poprawna i minimalizuje prawdopodobiestwo przeprowadzenia udanego ataku na system oparty na tym protokole sygnalizacyjnym. Mimo tego, posiada ona klika saboci. Zostay one zebrane w tabeli i s one nastpujce:
Mechanizm zabezpiecze Saboci i uwagi
- wykorzystanie schematu wspódzielonego sekretu (Shared Secret)SIP Digest - brak gwarancji cakowitej integralnoci wiadomoci - zdefiniowany w SIP system wymiany kluczy jest nieodporny na atak typu Man-in-the-Middle - wykorzystanie tego mechanizmu moe owocowa duymi (w sensie objtoci) wiadomociami sygnalizacyjnymi
S/MIME - problem rzadkich serwerów sieciowych (którego prawidowe dziaanie zaley od moliwoci dostpu i modyfikowaniu ciaa wiadomoci SIP) na drodze komunikacyjnej – mechanizm ten skutecznie uniemoliwi prawidowe funkcjonowanie takiego elementu sieciowego
Tabela 2 Zestawienie saboci protokou sygnalizacyjnego SIP
Dla protokou SIP (a dalej si okae, e i dla H.323) typem ataku, przed którym nie ma cakowitej ochrony jest atak typu Odmowa Usugi (Denial of Service). Bez wzgldu na rodzaj zaimplementowanych mechanizmów zabezpiecze zawsze moliwe jest „zalanie” serwera (gównie chodzi tu w przypadku SIP o serwery proxy) poprzez wysyanie nadmiernej iloci zwykle niepoprawnych wiadomoci, w ten sposób powodujc odmow wiadczenia usug dla poprawnych wiadomoci wysanych przez uytkownika, dla których dana jednostka zostaa stworzona.
Niestety tego typu ataku nie da si wyeliminowa cakowicie, poniewa wizaoby si to z ograniczeniem podstawowych funkcji serwerów sieciowych. Jednym z rozwiza, które moe w sposób satysfakcjonujcy ograniczy prawdopodobiestwo wystpienia takiego ataku jest przeprowadzanie wzajemnego uwierzytelnienie serwerów proxy z wykorzystaniem protokou TLS.
Wojciech Mazurczyk
ENIGMA 2004 - VIII Krajowa Konferencja Zastosowañ Kryptografii Warszawa 10-13 maja 2004
7. Bezpieczestwo H.323 Mechanizmy i sposób zabezpiecze systemu VoIP bazujcego na tym protokole reguluje osobne zalecenie
organizacji ITU – H.235. Dostarcza ono rozwizania kryptograficzne niezbdne do zabezpieczenia zarówno kanaów sygnalizacyjnych (RAS, H.225.0 i H.245) jak i tych, w których przesyany jest gos.
Analiza mechanizmów zabezpiecze dla systemów H.323 zostanie zaprezentowana w podobny sposób jak to odbyo si w przypadku protokou SIP, czyli poprzez przedstawienie realizacji usug ochrony informacji i komunikacji w sieci IP, czyli uwierzytelnienia oraz poufnoci.
7.1 Usuga uwierzytelnienia w H.323
Zalecenie H.235 definiuje dwa moliwe rodzaje mechanizmów uwierzytelnienia opartych na subskrypcji. Jeden bazuje na metodzie wspódzielonego sekretu, natomiast drugi wykorzystuje infrastruktur PKI.
Mechanizmy subskrypcji wykorzystywane w H.235 mona zaklasyfikowa tak, jak na rysunku poniej:
Rys. 7. Podzia mechanizmów uwierzytelnienia w H.235
Profile bezpieczestwa w H.323 Dodatkowo w zaleceniu H.235 [3] zdefiniowano trzy profile bezpieczestwa: podstawowy (Baseline security
profile) bazujcy na hasach, wykorzystujcy podpisy cyfrowe (Signature profile) oraz hybrydowy (Hybryd profile). Wszystkie trzy wskazuj, ju bezporednio, istniejce rozwizania kryptograficzne, z których naley korzysta przy opracowywaniu architektury bezpieczestwa H.323. Podzia na profile wraz z mechanizmami zabezpiecze, które wykorzystuj przedstawiono na rysunku 8:
Rys. 8 Profile bezpieczestwa w H.235
Podstawowe cechy charakteryzujce wskazane na rysunku 7 profile opisano w tabeli 3:
Cecha: Profil podstawowy
ENIGMA 2004 - VIII Krajowa Konferencja Zastosowañ Kryptografii Warszawa 10-13 maja 2004
procedury Fast Connect
Szyfrowanie symetryczne i podpisy
Gwarantowane usugi ochrony
Uwierzytelnienie pene, niezaprzeczalno
wiadomoci Tryb
wykorzystywanych mechanizmów
Status w implementacji Opcjonalny Opcjonalny Opcjonalny
Skalowalno dla globalnych
Dodatkowe wymagania dla
niezaprzeczalnoci
Gówne wady
Wykorzystanie technik poprzednich profili -
Podsumowanie mechanizmów uwierzytelnienia Podsumowanie mechanizmów opisanych w H.235v4 [3], które maj na celu gwarantowanie usugi
uwierzytelnienia dla systemów H.323 przedstawia poniszy rysunek:
Rys.9. Realizacja usugi uwierzytelnienia w H.323
Dodatkowo naley wspomnie, i realizacja uwierzytelnienia w trybie Hop-by-hop moliwa jest w H.323 równie
poprzez wykorzystanie protokoów warstw niszych ni aplikacji modelu odniesienia TCP/IP, czyli: TLS oraz IPSec. Implementacja obu protokoów nie jest jednak obowizkowa.
7.2 Usuga poufnoci w H.323
Poniewa aden z opisanych profili bezpieczestwa nie gwarantuje usugi poufnoci dla sygnalizacji systemów H.323, dlatego te jedyn moliwoci jej zapewnienia jest zastosowanie wspomnianych niszych poprzednim punkcie rozwiza warstw niszych, co przedstawia poniszy rysunek:
Wojciech Mazurczyk
ENIGMA 2004 - VIII Krajowa Konferencja Zastosowañ Kryptografii Warszawa 10-13 maja 2004
Rys.10. Realizacja usug poufnoci w H.323
Z rysunku wida, e szyfrowanie, które umoliwia realizacj usugi poufnoci zapewniane jest jedynie przez
protokoy TLS oraz IPSec. 7.3. Sabe punkty w architekturze bezpieczestwa H.323
Trwajce cigle prace organizacji ITU-T nad rozwojem bezpieczestwa dla systemów bazujcych na protokole H.323 umoliwiaj zapewnienie poprawnej architektury bezpieczestwa. Obecna wersja protokou H.235v4 (sierpie 2003 [3]) dostarcza trzy opisane wyej profile, które mona wykorzystywa w zalenoci od warunków i wymaga stawianych sieci VoIP.
Oczywicie zarzuty, co do stosowania mechanizmów wspódzielonego sekretu pozostaj te same, co w przypadku mechanizmów zawartych w SIP – nie s to rozwizania bezpieczne, w porównaniu z algorytmami klucza publicznego. Natomiast, aby umoliwi, wymieniane w tej pracy jako jedne z kluczowych rozwiza dla bezpieczestwa systemu VoIP, wzajemne uwierzytelnienie konieczne jest wykorzystanie algorytmów klucza publicznego. Dodatkowo s praktycznie jedynym rodkiem umoliwiajcym zapewnienie usugi uwierzytelnienia dla sieci rozlegych (poprzez bezpieczn dystrybucj kluczy w niezabezpieczonej sieci). Dodatkowo mog gwarantowa równie usug niezaprzeczalnoci. Z drugiej jednak strony algorytmy klucza publicznego posiadaj wady, w kontekcie wykorzystania ich jako mechanizmów zabezpiecze dla systemów VoIP np. saby popyt na tego typu usugi oraz atwo uzyskania faszywego certyfikatu.
Podsumowujc róda problemów i luk w bezpieczestwie rozwiza VoIP bazujcych na protokole sygnalizacyjnym H.323 pozostaj podobne jak w przypadku SIP. Pomimo zdefiniowania wielu moliwych rozwiza bezpieczestwa nie s one implementowane ze wzgldu na zbyt due wprowadzane opónienia bd, dlatego, e ich stosowanie jest opcjonalne (lub wykorzystywane przez nie procedury np. Fast Connect pozostaj opcjonalne).
Innym ródem luk bezpieczestwa, jak ju wspomniano wczeniej, s bdy w implementacji samego protokou sygnalizacyjnego. Zarówno dla protokou H.323 [13], jak i wczeniej SIP [14] organizacja CERT opublikowaa wiele nieprawidowoci w komercyjnych produktach opartych na tych protokoach sygnalizacyjnych, co w konsekwencji prowadzi do istnienia dodatkowych zagroe dla rozwiza telefonii IP.
8. Wspópraca systemów VoIP opartych na rónych protokoach sygnalizacyjnych Jak opisano w punkcie 2, w najbliszej przyszoci prognozuje si jako najbardziej prawdopodobne wspóistnienie
sieci VoIP opartych na rónych protokoach sygnalizacyjnych. W zwizku z tym, rosncym problemem staje si brak moliwoci wspópracy systemów VoIP bazujcych na rónych protokoach sygnalizacyjnych. Natomiast jednym z najwaniejszych do rozwizania aspektów wspópracy systemów VoIP jest wspódziaanie protokoów sygnalizacyjnych H.323 oraz SIP. Wynika to przede wszystkim z podobiestwa funkcji, jakie peni w systemie VoIP oraz miejsca w sieci. Dodatkowo naley uwzgldni fakt mniej wicej jednakowej popularnoci obu protokoów oraz liczne prognozy raczej ich koegzystowania, ni wyparcia jednego przez drugi. Oba bd suyy zestawianiu multimedialnych konferencji i telefonicznych rozmów w sieciach IP. Dlatego dla popularyzacji i uniwersalnoci rozwiza VoIP bardzo wane jest zapewnienie wspódziaania rozwiza bazujcych na rónych protokoach sygnalizacyjnych.
Niestety obecnie spotykamy si nie tylko z brakiem kompatybilnoci pomidzy protokoami sygnalizacyjnymi, ale równie z brakiem wspódziaania pomidzy produktami w ramach jednego protokou sygnalizacyjnego, co opisane zostao dokadniej w [16]. Równie nie wida popiechu w pracach producentów sprztu do umoliwienia atwej wspópracy z rozwizaniami innych producentów. Dzieje si tak oczywicie gównie z powodów finansowych. Dlatego, aby dba o waciwy kierunek rozwoju, tak wan spraw jest standaryzacja protokoów sygnalizacyjnych VoIP. Obecnie trwaj intensywne prace nad wspóprac pomidzy SIP i H.323. Najprniej dziaa w tym kierunku organizacja IETF oraz dodatkowo inne ciaa: ETSI TIPHON oraz ITU-T.
Zapewnienie wspópracy w podstawowych aspektach pomidzy wymienionymi protokoami jest moliwe tym bardziej, e oba wykorzystuj cz tych samych protokoów m.in. IP czy RTP (Cecha I). Dodatkowo, poniewa nie istnieje potrzeba konwersji danych zawierajcych gos (Cecha II), rozwizaniem problemu wspópracy jest
Wojciech Mazurczyk
ENIGMA 2004 - VIII Krajowa Konferencja Zastosowañ Kryptografii Warszawa 10-13 maja 2004
wprowadzenie elementu, który dokonywaby translacji jedynie (a!) wiadomoci sygnalizacyjnych H.323 na SIP i odwrotnie. Proponowane jest wprowadzenie funkcji, któr za [1], [11], [15] bdziemy nazywa IWF SIP-H.323 (SIP- H.323 InterWorking Function).
Gównym zadaniem IWF SIP-H.323 jest zapewnienie translacji wiadomoci sygnalizacyjnych dla wszystkich faz poczenia. Jeli z jednej strony sieci zostanie przysana wiadomo sygnalizacyjna – zadaniem IWF jest wysanie na drug stron sieci wiadomoci ekwiwalentnej wiadomoci otrzymanej.
W cigu prac badawczych udao si opracowa wsparcie dla wielu podstawowych aspektów wspópracy protokoów SIP i H.323 m.in. mapowania poszczególnych wiadomoci sygnalizacyjnych, zestawiania poczenia, rejestracji uytkowników, translacji adresów itp. Jednak cay czas kwesti do koca nierozwizan oraz pozostawian na uboczu jest kwestia zapewnienia bezpieczestwa wiadomoci sygnalizacyjnych wymienianych pomidzy sieciami wykorzystujcymi róne protokoy sygnalizacyjne. Dzieje si tak zapewne, dlatego, i zastosowanie jakichkolwiek mechanizmów zabezpiecze wpywa negatywnie na jako przesyanego gosu w telefonii IP (parametry QoS - Quality of Service), a problem zapewnienia parametrów QoS dotychczas sieciach IP, takich jak np. Internet, mimo licznych prób, nie posiada dotychczas sprawdzonego rozwizania.
Jednak pozostawienie usugi VoIP bez zupenie adnych zabezpiecze spowoduje brak zainteresowania wykorzystaniem komercyjnym takich systemów. Bd one potencjalnie naraone na liczne ataki, co w konsekwencji moe prowadzi do zmniejszenia lub nawet zaniku zainteresowania VoIP oraz spowolnienie lub zatrzymanie prac badawczych nad telefoni IP na du skal. Mimo takiej groby nadal nie opracowano potrzebnych zaoe wspópracy dla mechanizmów zabezpiecze, cho prace nad tematem wspópracy trwaj od roku 2000. Przyjmuje si jednak jako priorytetowe umoliwienie wspópracy obu protokoów dla prostych scenariuszy i jak najprostszymi rodkami, a kolejnymi istotnymi aspektami zajmuje si dopiero na kocu. Przypomina to nieco sytuacj, w której zawodowemu bokserowi kae si wiczy jedynie zadawanie ciosów tak, aby zwikszy maksymalnie ich si, zapominajc przy tam jak wan dla tego sportu jest praca nóg.
Przestawione poniej rozwaania maj na celu uzupeni te luki i stanowi baz wyjciow dla zapewnienia wspópracy mechanizmów zabezpiecze protokoów sygnalizacyjnych SIP i H.323.
8.1.Wymagania dla sieci czonych z IWF SIP-H.323 z punktu widzenia bezpieczestwa
Opis wspópracy protokoów SIP i H.323 zosta szerzej omówiony w [11] oraz [15]. Wanie na tej bazie bdziemy si starali stworzy bezpieczny z punktu widzenia protokoów sygnalizacyjnych czony system SIP i H.323. Na potrzeby dalszych rozwaa naley, z tych dokumentów, przytoczy nastpujce cechy IWF: Zaoenie A: IWF nie powinno wykorzystywa elementów opcjonalnych architektury funkcjonalnej obu sieci, Zaoenie B: IWF moe zosta zintegrowane ze Stranikiem H.323 (Gatekeeper) lub serwerem SIP (np. proxy lub redirect), Zaoenie C: IWF nie musi dokonywa konwersji strumieni mediów (wynika to bezporednio z Cech: I oraz II), Zaoenie D: IWF powinien wspiera procedur protokou H.323 Fast Connect oraz tunelowanie H.245, Zaoenie E: IWF powinno wspiera oba protokoy warstwy transportowej modelu TCP/IP, czyli TCP oraz UDP Zaoenie F: Terminale obu sieci powinny by niewiadome istnienia i porednictwa IWF, Zaoenie G: IWF powinien obsugiwa SIP w wersji RFC3261 oraz H.323 w wersji 2 lub póniejszej, Zaoenie H: Translacja sygnalizacji nie moe wprowadza zmian ani do protokou SIP, ani do H.323.
Jeli chodzi o zaoenia bezporednio dotyczce mechanizmów zabezpiecze to dokument [11] zakada jako najwaniejsze, e: Zaoenie S1: IWF powinien wykorzystywa przypisane protokoom sygnalizacyjnym mechanizmy zabezpiecze (np. S/MIME dla SIP, czy rozwizania protokou H.235 dla H.323). Zaoenie S2: IWF musi posiada procedury uniknicia ataków typu Denial of Sernice (DoS). Zaoenie S3: IWF musi by elementem zaufanym dla obu stron sieci.
Poniej przedstawiono autorskie wymagania dla IWF SIP-H.323 z punktu widzenia bezpieczestwa dla obu stron
sieci. Wynikaj one przede wszystkim z ustosunkowania si do wymienionych powyej zaoe i czsto pozostaj z nimi w sprzecznoci. Niestety czasami cen za bezpieczestwo sygnalizacji jest utrata innych cech obu protokoów np. elastycznoci.
Wedug kryterium podanego w punkcie 5 protokó sygnalizacyjny, na którym bazuje VoIP moemy uzna za bezpieczny, jeli zapewnienia on dwie podstawowe usugi ochrony informacji i komunikacji w sieci: uwierzytelnienie oraz poufno. Poczenie dwóch sieci bazujcych na rónych protokoach sygnalizacyjnych tworzy nowy system VoIP, który chcemy, aby równie spenia to kryterium. Dlatego, aby osign nasz cel, jednostka logiczna IWF powinna spenia nastpujce wymagania: Wymaganie 1: Poniewa wszystkie profile bezpieczestwa dla protokou H.323 zakadaj wykorzystanie modelu sieci ze Stranikiem (Gatekeeper) (patrz Tabela 3), dlatego te dla bezpiecznego czonego systemu VoIP z jednostk IWF konieczne jest równie wykorzystywanie tego modelu (niezgodne z Zaoeniem A). Wymaganie 2: Z podobnych, co w Wymaganiu 1 powodów niezbdne jest wspieranie przez IWF procedur charakterystycznych dla protokou H.323 – Fast Connect oraz tunelowania H.245 (niezgodne z Zaoeniem D).
Wojciech Mazurczyk
ENIGMA 2004 - VIII Krajowa Konferencja Zastosowañ Kryptografii Warszawa 10-13 maja 2004
Wymaganie 3: Poniewa wykorzystywany bdzie model systemu H.323 ze Stranikiem (z Wymagania 1) oraz poniewa elementem obowizkowym architektury funkcjonalnej s serwery SIP (proxy lub redirect) wynika, e rozwaana bdzie nastpujca konfiguracja opisana w [15] jako scenariusz numer 4 – wykorzystujcy zarówno Stranika jak i serwer SIP (proxy lub redirect). Wymaganie 4: Skoro pojedynczo obie sieci musz by bezpieczne, wic poczenie ich z wykorzystaniem IWF musi gwarantowa kadej z sieci poziom bezpieczestwa adekwatny do tego, jaki oferuje wewntrz. Równie mechanizmy zabezpiecze wykorzystane po jednej stronie IWF powinny by adekwatne do rozwiza drugiej strony. Wymaganie 5: W przypadku, gdy nie jest zapewniony aden mechanizm gwarantujcy usug uwierzytelnienia poczenie nie moe zosta nawizane. Podobnie postpujemy w przypadku niemonoci zapewnienia usugi poufnoci. Wynika to z faktu nie wypenienia kryterium uznania protokou sygnalizacyjnego VoIP za bezpieczny – patrz punkt 5. Wymaganie 6: Istotnym aspektem dla wspópracy protokoów sygnalizacyjnych SIP i H.323 jest problem zakresu przezroczystoci IWF SIP-H.323. W tym przypadku pozostaje w mocy Zaoenie F.
Wana jest równie odpowied na pytanie, czy IWF jest elementem zaufanym sieci (Trusted Element). Za
obowizujc definicj elementu zaufanego przyjmujemy definicj zawart w zaleceniu H.235v4 [3], rezultatem zaufania okrelonej jednostce jest moliwo powierzenia mu pewnych parametrów kryptograficznych (np. klucza szyfrujcego, parametrów charakterystycznych) bez naraenia na ich pozyskanie przez stron trzeci do tego nie upowanion, czyli bez naraenia na utrat swojego bezpieczestwa. Std kolejne wymaganie postaci: Wymaganie 7: IWF musi by elementem zaufanym dla obu stron sieci (zgodne z Zaoeniem S3). W innym przypadku nie jest moliwe przeprowadzenie m.in. uwierzytelnienia pomidzy dwoma punktami kocowymi dla tych sieci, a tym samym taki system, poczonych protokoów sygnalizacyjnych, nie moe by uznany za bezpieczny (w wietle kryterium z punktu 5).
Inne zaoenia z dokumentów [11] i [15] dotyczce IWF SIP-H.323 pozostaj w mocy, jeli nie koliduj z Wymaganiami 1-7. Szczególnie dotyczy to wymaga dotyczcych bezpieczestwa.
8.2 Dekompozycja funkcjonalna IWF SIP-H.323
Zgodnie ze zdefiniowanymi w poprzednim punkcie wymaganiami dla bezpieczestwa sygnalizacji czonych sieci VoIP, w których wystpuje jednostka logiczna IWF proponuj nastpujc jej dekompozycj funkcjonaln:
Rys. 12. Dekompozycja funkcjonalna IWF SIP-H.323
Czci wystpujce na rysunku opisano poniej: GK Part – cz IWF, która widziana jest od strony czci H.323 jako Stranik, posiadajca podobne funkcje i wasnoci (szczególnie w zakresie wspierania mechanizmów zabezpiecze), SIP Server Part – cz IWF, która widziana jest od strony sieci SIP jako Serwer SIP (proxy lub redirect), posiadajca podobne funkcje i wasnoci (szczególnie w zakresie wspierania mechanizmów zabezpiecze), IWF – cz zapewniajca funkcj konwersji sygnalizacji SIP-H.323 oraz inne niezbdne do wspópracy funkcje. Ta cze nie zajmuje si wyliczaniem parametrów kryptograficznych (np. wyliczanie skrótu) – moe jedynie poredniczy w ich przekazywaniu pomidzy pozostaymi czciami. SIP UA (SIP User Agent) – Agent Uytkownika SIP, EP H.323 (End Point H.323) – punkt kocowy H.323. SIP Proxy (Redirect) – elementy architektury funkcjonalnej protokou SIP: serwery Proxy lub Redirect GateKeeper (Stranik) – element architektury funkcjonalnej protokou H.323 Taki podzia funkcji IWF jest najbardziej intuicyjny i najprostszy (abstrahujemy od aspektów finansowych
realizacji takiego urzdzenia). Gównymi zaletami takiego rozwizania s przede wszystkim: • Moliwo zapewnienia usugi uwierzytelnienia oraz poufnoci dla wiadomoci sygnalizacyjnych sieci
czonych. Dotychczas proponowane rozwizania nie speniay postawionych przez nas wymaga bezpieczestwa lub speniay tylko ich cz.
Wojciech Mazurczyk
ENIGMA 2004 - VIII Krajowa Konferencja Zastosowañ Kryptografii Warszawa 10-13 maja 2004
• Z obu stron sieci element ten jest rozpoznawany jako jeden z „normalnych” komponentów architektury funkcjonalnej: Stranik lub jeden z serwerów SIP. Takie rozwizanie nie wymaga, wic modyfikacji zarówno protokou SIP jak i H.323. W przypadku nie odnalezienia w swojej czci sieci punktu kocowego, do którego adresowana jest wiadomo SIP Serwer oraz GK wiedz, e naley si kontaktowa z czci IWF odpowiednio bdc serwerem SIP (SIP Serwer Part) lub Stranikiem (GK Part).
• Prosta wspópraca mechanizmów zabezpiecze SIP i H.323. • Gwarancja penej przezroczystoci dla komunikacji pomidzy punktami kocowymi.
8.3 Szkic uwierzytelnienia czonych systemów SIP-H.323 Jak wspomniano dla SIP obowizkowym mechanizmem zabezpiecze dla gwarancji usugi uwierzytelnienia jest
SIP Digest. Opcjonalnie dostpny jest równie protokó S/MIME. T sam usug dla H.323 realizuje si z wykorzystaniem opisanego w zaleceniu H.235v4 mechanizmu
pochodzcego z profilu podstawowego (Procedura IA) o nazwie HMAC-SHA1-96. Alternatyw dla wspomnianego rozwizania s mechanizmy zawarte w profilach: wykorzystujcym podpisy cyfrowe oraz hybrydowym.
Skoncentrujmy si na moliwoci poszukania, odpowiednika rozwizania SIP Digest, gdy jest to, jak ju wspomniaem, mechanizm, który musi by implementowany obligatoryjnie w systemie VoIP bazujcym na SIP. Sporód dostpnych rozwiza w H.323 najbardziej naturalnym, pozwalajcym zminimalizowa wprowadzane opónienie, jest mechanizm HMAC-SHA1-96 oraz Procedura IA.
Aby pokaza suszno tego wyboru naley przypomnie krótko najwaniejsze cechy oraz sposób dziaania obu rozwiza:
Mechanizm SIP Digest – wykorzystuje schemat wspódzielonego sekretu oraz metod wyzwanie/odpowied (challenge/response) wraz z funkcj skrótu. Jest to mechanizm typu End-to-End. Przebieg realizacji omawianej usugi dla mechanizmu SIP Digest zosta przedstawiony na rysunku poniej:
Rys. 13. Przebieg uwierzytelnienia SIP Digest
Dokadny opis przebiegu uwierzytelnienia dla tego mechanizmu mona znale w [8]. Mechanizm HMAC-SHA1-96 - równie wykorzystuje metod wspódzielonego sekretu oraz funkcje skrótu. Jest
to mechanizm typu Hop-by-Hop. Przebieg uwierzytelnienia przedstawia rysunek poniej:
Rys. 14. Przebieg uwierzytelnienia opartego na mechanizmie HMAC-SHA1-96 (Procedura IA)
W pierwszej fazie wymieniane s identyfikatory punktów kocowych. Kolejnym etapem jest przesanie do drugiej
strony skrótu, który zosta obliczony z parametrów zawartych w sekcji CryptoToken, czyli: znacznika czasowego (TS), identyfikatorów róda i przeznaczenia (Senders ID oraz General IDx), wspódzielonego hasa oraz wartoci losowej (Random). Uwierzytelnienie nastpuje po odebraniu skrótu, obliczeniu analogicznego po stronie odbiorczej i ich porównaniu zakoczonym sukcesem. Dokadny opis dziaania mechanizmu znajduje si w [3].
W obu algorytmach (tzn. SIP Digest oraz HMAC-SHA1-96) zaoono istnienie wzajemnie akceptowalnego odniesienia czasowego, z którego korzysta si w przypadku generowania znaczników czasowych. To, jakie odchylenia czasowe s akceptowalne, zaley ju od konkretnej implementacji. Zastosowanie znaczników czasowych moe zminimalizowa ryzyko podsuchania wiadomoci, a nastpnie wykorzystania zdobytych informacji w celu wysania faszywej wiadomoci mechanizmów z doklejonym zdobytym skrótem.
Jak wida w obu przypadkach wygenerowany zostaje pewien skrót, oba mechanizmy dziaaj na zasadzie wspódzielonego sekretu oraz w obu moliwe jest wykorzystanie tej samej funkcji skrótu SHA1.
Wojciech Mazurczyk
ENIGMA 2004 - VIII Krajowa Konferencja Zastosowañ Kryptografii Warszawa 10-13 maja 2004
W przypadku SIP skrót jest tworzony z trzech podstawowych elementów: wspódzielonego hasa, parametru nonce oraz nazwy uytkownika, czyli:
SIP Digest: H (Password, UserName, Nonce) Analogicznie w H.323 do generacji skrótu wykorzystuje si pi podstawowych elementów, a s to: wspódzielone
haso, globalny identyfikator strony wysyajcej i docelowej, znak czasowy (Timestamp) oraz liczba losowa, czyli: HMAC-SHA1-96: H (Password, SendersIDS, GIDX, TimeStamp, Random)
Przykadowy sposób wspódziaania opisanych mechanizmów, w którym uczestnicz zarówno urzdzania kocowe SIP i H.323 oraz IWF SIP-H.323 przedstawiaj dwa ponisze rysunki. Pierwszy obrazuje sytuacj, w której stron inicjujc jest terminal H.323, natomiast drugi sytuacj odwrotn.
Zakadamy, e w pierwszej fazie wymieniane s unikalne identyfikatory punktów kocowych sieci. Nastpnie punkt kocowy H.323, jako strona inicjujca, przesya wyliczony przez siebie skrót (zgodnie ze swoim mechanizmem uwierzytelnienia – Procedura IA) (1) do IWF. Po odebraniu tego skrótu IWF wysya do punktu kocowego SIP wiadomo numer 401 Authentication Required, eby wymusi wysanie skrótu SIP Digest (3). Po jego otrzymaniu IWF wylicza analogiczny skrót jak punkt kocowy SIP, a nastpnie porównuje je. Jeli oba skróty s sobie równe to IWF wysya skrót (4) do sieci H.323, aby dokoczy realizacj uwierzytelnienia. Ta ostatnia czynno implikuje fakt, i IWF musi by elementem zaufanym, poniewa znany jej bdzie wspódzielony sekret obu punktów kocowych.
Natomiast sytuacj, w której stron inicjujc jest punkt kocowy SIP przedstawia rysunek:
Wojciech Mazurczyk
ENIGMA 2004 - VIII Krajowa Konferencja Zastosowañ Kryptografii Warszawa 10-13 maja 2004
Podobnie jak w poprzednim przypadku zakadamy, i w pierwszej fazie wymieniane s unikalne identyfikatory punktów kocowych sieci. Nastpnie punkt kocowy SIP, jako inicjujca strona, da uwierzytelnienia strony H.323, dlatego te wysya danie 401 Authentication Required (1). Po odebraniu tej wiadomoci funkcja IWF przesya do punktu kocowego H.323 skrót wykorzystujce parametry charakterystyczne dla tego punktu (2). Kolejny na drodze komunikacyjnej element H.323 po otrzymaniu tego skrótu odpowiada zgodnie z dziaaniem algorytmu uwierzytelniajcego swoim skrótem (3). Ostatni rzecz jest wysanie z IWF do punktu kocowego SIP odpowiedniego skrótu (4) tak, aby po swojej stronie punkt kocowy móg dokona porównania obu skrótów i zakoczy proces uwierzytelnienia. Równie w tym przypadku funkcja IWF musi by elementem zaufanym, poniewa do przeprowadzenia wzajemnego uwierzytelnienia niezbdna jest znajomo wspódzielonego sekretu punktów kocowych.
Po stronie sieci H.323 uwierzytelnienie przebiega w trybie Hop-by-Hop, czyli przy kadej parze elementów sieciowych wartoci skrótu ulegaj ponownemu wyliczeniu. Kocowy ‘hop’ przypada wtedy, gdy urzdzeniem docelowym jest IWF. Nastpnie wysya ona (ju w trybie End-to-End) danie uwierzytelnienia do punktu kocowego SIP.
Gdy stron inicjujc jest punkt kocowy SIP moemy napotka na nastpujcy problem. IWF wysya swój skrót do pierwszego elementu sieciowego H.323. Ten odpowiada jej wyliczonym przez siebie skrótem. Daje to pewno uwierzytelnienia na pierwszym odcinku za IWF SIP-H.323. Potencjalnie moe pojawi si problem, gdy operacja uwierzytelnienia nie „dojdzie” do punktu kocowego H.323. 8.4. Poufno czonych systemów SIP-H.323
Zapewnienie usugi poufnoci wie si przede wszystkim z wykorzystaniem techniki szyfrowania. Dla obu protokoów metoda realizacji usugi poufnoci jest zapewniania poprzez wykorzystanie mechanizmów warstw niszych: TLS i IPSec. Dla SIP obowizkowe jest implementowanie algorytmu TLS, natomiast IPSec jest opcjonalne. Dla H.323 oba rozwizania s opcjonalne.
Istnieje, zatem potrzeba implementowania tego rodzaju rozwiza, szczególnie, dlatego, i w H.323 w inny sposób nie da si zagwarantowa poufnoci. W zwizku z tym, e w protokole SIP niezbdne jest wykorzystywanie mechanizmu TLS, dlatego te proponuje si, aby dla bezpiecznej wspópracy czonych systemów VoIP, stosowano w czci z H.323 równie obowizkowo ten mechanizm. A poniewa moliwe jest dodatkowo w SIP stosowanie mechanizmu SIPS URI, dlatego te niezwykle wane jest, aby mechanizmów sieci H.323 wszystkie odcinki drogi komunikacyjnej pomidzy elementami: ródowym mechanizmów docelowym byy równie zabezpieczone mechanizmów wykorzystaniem TLS.
Wojciech Mazurczyk
ENIGMA 2004 - VIII Krajowa Konferencja Zastosowañ Kryptografii Warszawa 10-13 maja 2004
Literatura [1] K. Singh, H. Schulzrinne, „Interworking Between SIP/SDP and H.323”, IPTel, Maj 2000 [2] “Packet-based multimedia communications systems” – H.323, Telecommunication Standardization Sector, ITU-T, lipiec 2003 [3] “Security and Encryption for H-Series (H.323 and other H.245-Based) multimedia terminals”s, Telecommunication Standardization Sector, ITU-T, sierpie 2003. [4] ETSI TR 101 308, “Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON); Requirements Definition Study; SIP and H.323 Interworking”, grudzie 2001 [5] Mika Marjalaakso, “Security Requirements and Constraints of VoIP”, Helsinki University of Technology Department of Electrical Engineering and Telecommunications [6] Johann Thalhammer, “Security in VoIP - Telephony Systems”, Institute for applied information processing and communications, Graz University of Technology, 2002 [7] H. Krawczyk, M. Bellare, R. Canetti, “HMAC: Keyed-Hashing for Message Authentication”, Request for Comments: 2104, luty 1997 [8] W. Mazurczyk, „Bezpieczestwo SIP jako protokou sygnalizacyjnego VoIP” – Krajowe Sympozjum Telekomunikacji (KST), wrzesie 2003, artyku recenzowany [9] F. Cuervo, N. Greene, A. Rayhan, “Megaco Protocol Version 1.0” - IETF RFC 3015 listopad 2000 [10] M. Handley, H. Schulzrinne, J. Rosenberg “SIP: Session Initiation Protocol” – IETF RFC 3261 lipiec 2002 [11] H. Schulzrinne, C. Agboh, “Session Initiation Protocol (SIP) - H.323 Interworking Requirements”, Internet Draft, luty 2004 (draft-agrawal-sip-h323-interworking-reqs-06) [12] F. Echezabal, “Voice over Internet Protocol Security”, SANS Institue, marzec 2003 [13] CERT, “Advisory CA-2004-01 Multiple H.323 Message Vulnerabilities”, stycze 2004 [14] CERT, „CA-2003-06 Multiple vulnerabilities in implementations of the SIP”, luty 2003 [15] H. Agrawal, C. Agboh, H. Schulzrinne, „SIP-H.323 Interworking”, IETF Internet Draft, lipiec 2001 [16] N. Leavitt, “Will Interoperability Problems Give IP Telephony a Busy Signal?”, Computer.org,marzec 2004 [17] W. Stallings - “Cryptography and Network Security : Principles and Practice, Second Edition”. Prentice-Hall, June 1998. Artyku recenzowany
Wojciech Mazurczyk
Do realizacji uwierzytelnienia
Tabela 2 Zestawienie saboci
Mechanizm SIP Digest – wykorzy