Oceniając bezpieczeństwo rozmowy, pytaj nie tylko „czy jest szyfrowana?”, ale też gdzie szyfrowanie się kończy i co zmienia nagrywanie.
Samo szyfrowanie czatu nie dowodzi, że dźwięk, obraz, udostępnianie ekranu lub nagranie rozmowy są chronione w ten sam sposób. Oceniając bezpieczeństwo rozmowy, trzeba zapytać, do którego miejsca media pozostają zaszyfrowane, kto ma klucz i co zmienia włączenie takich funkcji jak nagrywanie.
Ten przewodnik dzieli twierdzenia dotyczące bezpieczeństwa na warstwy, które można sprawdzić; nazwa protokołu ani ikona kłódki nie zastępują odpowiedzi na te pytania.
Trzy różne ścieżki w jednej aplikacji
| Ścieżka | Przykładowe dane | Pytanie o bezpieczeństwo |
|---|---|---|
| Wiadomości przechowywane | Tekst, zdjęcia, pliki i wiadomości głosowe | Kto może odczytać kopie na urządzeniu, serwerze i w kopii zapasowej? |
| Media na żywo | Dźwięk z mikrofonu, wideo i udostępnianie ekranu | Czy szyfrowanie kończy się na urządzeniu rozmówcy, czy na serwerze pośredniczącym? |
| Sygnalizacja | Zaproszenie do rozmowy, odpowiedź i informacje służące uzgodnieniu połączenia | Kto może zmienić komunikaty sterujące lub tożsamość odbiorcy? |
Wiadomość głosowa wysłana na czacie jest plikiem; rozmowa głosowa to strumień na żywo. Produkt może używać dla nich różnych kluczy i mechanizmów. Dobra jakość dźwięku ani niedostarczenie wiadomości tekstowej również same w sobie niczego nie mówią o bezpieczeństwie drugiej ścieżki.
Co potwierdza DTLS-SRTP?
W WebRTC protokół SRTP chroni strumień mediów, a DTLS-SRTP jest sposobem uzgadniania potrzebnego materiału kluczowego. RFC 5764 opisuje mechanizm DTLS-SRTP, a RFC 3711 — ochronę pakietów mediów.
Jednak samo stwierdzenie „używamy WebRTC” nie odpowiada na pytanie, czy serwer konferencyjny odszyfrowuje media. Muszą być określone punkty końcowe szyfrowania i sposób ich uwierzytelniania. Połączenie między użytkownikiem a serwerem może być szyfrowane, a mimo to serwer może mieć dostęp do odszyfrowanej treści na potrzeby przetwarzania lub nagrywania. Nie jest to to samo co E2EE między uczestnikami.
Architektura bezpieczeństwa WebRTC opisana w RFC 8827 pokazuje też, że oprócz ochrony mediów znaczenie mają zaufanie do aplikacji internetowej, ścieżka sygnalizacji i tożsamość rozmówcy. Szyfrowanie pakietów nie oznacza, że wszystkie elementy produktu są godne zaufania.
Dlaczego sygnalizację trzeba oceniać osobno?
Sygnalizacja koordynuje to, kto z kim rozmawia i jak powstaje połączenie. Jeśli aplikacja chroni komunikaty sterujące, nadal trzeba sprawdzić, w jaki sposób ta ochrona jest powiązana z rzeczywistą tożsamością uczestników i kluczami mediów.
Do czytania dokumentacji wystarczą trzy pytania:
- Czy zaproszenie, odpowiedź i informacje o kluczach są chronione przed modyfikacją?
- Skąd użytkownik wie, że klucz należy do właściwego rozmówcy?
- Jakie ostrzeżenie pojawia się po zmianie klucza lub urządzenia?
Informacje o trasowaniu, czasie i uczestnikach rozmowy mogą być znane usłudze nawet w przypadku rozmowy E2EE. Omówienie metadanych komunikatora wyjaśnia tę różnicę.
Nagrywanie rozmowy tworzy nową granicę bezpieczeństwa
Określenie „szyfrowana rozmowa” nie daje pełnej odpowiedzi w odniesieniu do nagrania. Uczestnik może zarejestrować dźwięk lub obraz za pomocą własnego urządzenia. Nagrywanie po stronie serwera również wymaga osobnej dokumentacji: czy w celu nagrywania serwer uzyskuje dostęp do mediów w postaci jawnej? Kto przechowuje plik? Kiedy jest on usuwany?
Jeżeli włączenie nagrywania zmienia tryb bezpieczeństwa, uczestnicy powinni wyraźnie widzieć tę zmianę. Przed rozmową na wrażliwy temat sprawdź stan nagrywania i zgodę uczestników; wyłączony wbudowany wskaźnik nagrywania nie gwarantuje, że nikt nie nagrywa za pomocą innego urządzenia.
Jak czytać aktualną dokumentację Livara?
Strona bezpieczeństwa Livara opisuje rozmowy bezpośrednie i grupowe jako E2EE, ale wskazuje opcjonalne nagrywanie po stronie serwera jako wyjątek: w widocznym trybie REC ochrona rozmowy zmienia się na szyfrowanie transportowe. To twierdzenie zawarte w dokumentacji produktu, a nie wynik niezależnego testu lub audytu przeprowadzonego w ramach tego artykułu.
Ograniczenie wszystkich rozmów grupowych do „2–6 osób na Androidzie” w starym tekście jest niezgodne z aktualną dokumentacją i nie stanowi podstawy tego przewodnika. Dla danej liczby uczestników, platformy i wersji należy sprawdzić bieżącą instrukcję oraz rzeczywiste działanie aplikacji; ten artykuł nie przedstawia testu obsługiwanej liczby uczestników.
Również sama nazwa algorytmów czatu, takich jak ML-KEM, nie dowodzi, że ten sam algorytm jest stosowany do mediów w rozmowach. Twierdzenie o postkwantowej ochronie rozmów wymaga dowodów dotyczących konkretnie ścieżki mediów i uwierzytelniania. Czytaj model zagrożeń Livara razem ze stroną funkcji, a nie zamiast niezależnego testu.
Krótka lista kontrolna przed porównaniem dwóch usług
Przy każdej odpowiedzi „tak” zanotuj również wersję i źródło:
- Czy rozmowy dwuosobowe, grupowe i udostępnianie ekranu zostały opisane osobno?
- Czy wiadomo, czy serwer tylko przekazuje pakiety, czy może też odszyfrować media?
- Czy można zweryfikować tożsamość i klucz uczestnika?
- Czy zmiana urządzenia, dodanie uczestnika i włączenie nagrywania są widoczne?
- Czy ścieżka rozmowy w wersji internetowej i w aplikacji jest taka sama, czy się różni?
- Czy wyjaśniono zasady przechowywania nagrań i metadanych?
- Czy dowody z testów lub audytów dotyczą tej samej wersji i funkcji?
Jeśli w dokumentacji nie ma odpowiedzi, zapisz „nie wiadomo”; brak odpowiedzi nie dowodzi ani bezpieczeństwa, ani podsłuchiwania.
Najczęściej zadawane pytania
Czy rozmowa E2EE uniemożliwia rozmówcy nagrywanie?
Nie. Uprawniony odbiorca ma dostęp do treści w postaci jawnej i może ją nagrać za pomocą oprogramowania lub innego urządzenia.
Czy szyfrowanie transportowe jest złe?
Szyfrowanie transportowe zapewnia ważną ochronę przed podsłuchem na trasie przesyłania danych. Różnica polega na tym, że usługa będąca punktem końcowym może mieć dostęp do odszyfrowanej treści; nie należy tego nazywać E2EE między użytkownikami.
Czy użycie szyfrowania postkwantowego w czacie zapewnia również postkwantową ochronę rozmów?
Nie. Twierdzenie musi dotyczyć tej samej warstwy, algorytmów i wersji implementacji. Oceniaj czat i rozmowy osobno.
