Jak rozumieć szyfrowanie rozmów w Linphone
Sygnalizacja i głos płyną różnymi kanałami, więc nie chroni ich jeden magiczny przełącznik. Artykuł porządkuje warstwy i pokazuje, co należy zweryfikować przed poufną rozmową.
Linphone obsługuje kilka standardowych mechanizmów bezpieczeństwa, ale samo ich istnienie w aplikacji nie oznacza, że każde połączenie jest szyfrowane w ten sam sposób. Oficjalne FAQ wyraźnie informuje, że szyfrowanie rozmów jest opcjonalne i wymaga włączenia odpowiedniego protokołu. Dodatkowo druga strona, serwer i polityka konta muszą obsługiwać uzgodniony tryb.
Najpierw rozdziel sygnalizację SIP od mediów. SIP zestawia i kontroluje sesję, a głos oraz obraz płyną zwykle przez RTP. Ochrona jednego kanału nie musi automatycznie chronić drugiego.
Model zagrożeń przed nazwą protokołu
Zadaj trzy pytania: przed kim chronisz rozmowę, którym elementom infrastruktury ufasz i jak potwierdzasz tożsamość rozmówcy? Inne ustawienie wystarczy do ochrony sygnalizacji w lokalnej sieci, a inne jest potrzebne, gdy serwer pośredniczący nie powinien mieć dostępu do treści mediów.
Nie nazywaj rozmowy „bezpieczną” tylko na podstawie marki aplikacji. Sprawdź aktywny tryb w interfejsie, wymagania operatora, tożsamość drugiej strony i zachowanie w razie braku zgodnego szyfrowania. Polityka „preferuj” może dopuścić połączenie nieszyfrowane, podczas gdy polityka „wymagaj” powinna je odrzucić — dokładne opcje zależą od wydania i wdrożenia.
SIP przez TLS chroni sygnalizację na odcinku transportowym
TLS może zabezpieczyć połączenie aplikacji z serwerem SIP oraz pozwala zweryfikować serwer na podstawie certyfikatu X.509. Chroni dane sygnalizacyjne na danym połączeniu transportowym, takie jak zestawianie sesji i proces uwierzytelnienia. Nie szyfruje sam z siebie strumienia RTP i nie dowodzi, że każdy kolejny odcinek pomiędzy serwerami jest chroniony identycznie.
Nie ignoruj błędu nazwy lub zaufania certyfikatu. Ustawienie TLS powinno pochodzić od administratora usługi, a zegar urządzenia musi być prawidłowy, ponieważ wpływa na ocenę ważności certyfikatu. Ręczne zaakceptowanie nieprawidłowego certyfikatu odbiera część korzyści z weryfikacji serwera.
SRTP zabezpiecza strumień mediów
SRTP, opisany w RFC 3711, rozszerza RTP o poufność, uwierzytelnianie wiadomości i ochronę przed powtórzeniem pakietów. Potrzebuje jednak sposobu uzgodnienia kluczy. Nazwa „SRTP” nie mówi jeszcze, kto mógł uczestniczyć w tym uzgodnieniu i czy ochrona jest faktycznie od końca do końca w danej architekturze.
Linphone wymienia między innymi SDES, DTLS-SRTP i ZRTP jako mechanizmy związane z zabezpieczeniem mediów lub wymianą kluczy. Ich zgodność zależy od drugiego klienta i infrastruktury. Jeśli po włączeniu wymaganego trybu połączenie przestaje się zestawiać, nie obniżaj ochrony automatycznie. Najpierw ustal, czy drugi punkt obsługuje ten sam mechanizm.
Standard SRTP.
DTLS-SRTP uzgadnia klucze dla zabezpieczonych mediów
W DTLS-SRTP strony wykorzystują DTLS do uzgodnienia materiału kluczowego dla SRTP. Mechanizm jest znany także ze świata WebRTC. Nadal trzeba sprawdzić, czy oba końce rozmowy negocjują go poprawnie i jaki model uwierzytelnienia stosuje konkretne wdrożenie. Sam wybór pozycji w menu nie zastępuje kontroli statusu po zestawieniu rozmowy.
ZRTP i krótki kod SAS
ZRTP, standaryzowany w RFC 6189, uzgadnia klucze na ścieżce mediów. Short Authentication String, czyli SAS, służy rozmówcom do wykrywania ataku typu man-in-the-middle. Gdy aplikacja wyświetla krótki kod, obie strony powinny go porównać w sposób pozwalający potwierdzić, że widzą tę samą wartość. Nie klikaj potwierdzenia, jeżeli kody się różnią albo rozmówca nie został rozpoznany.
SAS nie jest kodem jednorazowym do logowania i nie należy wysyłać go przed zestawieniem rozmowy jako „hasła”. Jego znaczenie wynika z konkretnego uzgodnienia kluczy. Przy pierwszym kontakcie tożsamość rozmówcy warto potwierdzić dodatkowym, wcześniej znanym kanałem.
Standard ZRTP.
Wiadomości mają osobną politykę
Szyfrowanie rozmowy głosowej nie oznacza automatycznego szyfrowania czatu i plików. Linphone wykorzystuje LIME do szyfrowania wiadomości w obsługującej je infrastrukturze, ale oficjalne FAQ zaznacza, że rozmowę tekstową trzeba utworzyć w trybie szyfrowanym. Zewnętrzne konta SIP mogą nie mieć funkcji zależnych od Flexisip, w tym określonych mechanizmów bezpiecznego czatu.
Przed wysłaniem poufnego pliku sprawdź status konkretnej konwersacji, a nie status ostatniej rozmowy audio. Nie zakładaj też, że zwykły SIP SIMPLE zapewnia te same właściwości co szyfrowanie LIME.
Szyfrowanie transmisji nie zabezpiecza całego urządzenia
Nawet prawidłowo zaszyfrowany kanał nie ochroni rozmowy na odblokowanym lub zainfekowanym urządzeniu. Treść jest dostępna na końcach połączenia, gdzie mikrofon ją rejestruje, a głośnik odtwarza. Aktualizuj system i aplikację, używaj blokady ekranu oraz instaluj oprogramowanie tylko z zaufanego źródła. Nie przekazuj hasła SIP w komunikatorze ani razem z plikiem konfiguracyjnym.
Po utracie telefonu albo komputera usuń lub unieważnij jego dostęp zgodnie z procedurą operatora, a w razie potrzeby zmień dane uwierzytelniające. Sprawdź pozostałe urządzenia, na których konto nadal jest aktywne. Szyfrowanie mediów nie zastępuje zarządzania kontem, aktualizacji ani fizycznej poufności miejsca, w którym prowadzisz rozmowę.
Checklista przed poufną rozmową
- Potwierdź, jakie tryby szyfrowania obsługują konto, serwer i druga strona.
- Ustaw politykę zgodną z wymaganiem: preferowanie nie jest tym samym co obowiązkowe szyfrowanie.
- Sprawdź poprawność połączenia TLS i certyfikatu serwera, jeśli używasz TLS.
- Po zestawieniu odczytaj status ochrony mediów.
- Przy ZRTP porównaj kod SAS z rozmówcą. Nie potwierdzaj połączenia, jeśli kody się różnią.
- Dla wiadomości sprawdź osobno status szyfrowania konwersacji.
- Po aktualizacji lub zmianie konta wykonaj test ponownie.
Jeżeli interfejs nie pokazuje oczekiwanego statusu, zatrzymaj przekazywanie poufnych informacji i wróć do dokumentacji wdrożenia. Bezpiecznym wynikiem testu nie jest samo połączenie, lecz połączenie w wymaganym, zweryfikowanym trybie.