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
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