Włamanie na serwer komunikatora nie musi oznaczać odczytania wszystkich wiadomości. Skutek zależy od zapisanych danych, miejsca przechowywania kluczy oraz poziomu dostępu napastnika. Nawet gdy tekst rozmowy jest prawidłowo szyfrowany end-to-end, informacje o koncie, czasach, członkostwie w grupach i trasie dostarczania mogą być wrażliwe.
Oceniając incydent, najpierw zapytaj, co uzyskał napastnik: kopię bazy danych, klucze infrastruktury, aktywny serwer czy system publikowania oprogramowania? Te scenariusze nie mają takich samych konsekwencji.
Skradziona baza danych to nie to samo co przejęty serwer
Napastnik mający tylko starą kopię bazy jest ograniczony do zapisanych w niej danych. Kontrola nad działającą usługą może umożliwić rejestrowanie nowych danych, kradzież sesji, zmianę odpowiedzi lub próby podmiany klucza rozmówcy. Dostęp do łańcucha publikowania oprogramowania to inne zagrożenie: złośliwy kod na urządzeniu końcowym może widzieć tekst przed zaszyfrowaniem lub po odszyfrowaniu.
Stwierdzenie «baza danych nie zawiera klucza do tekstu wiadomości» jest więc ważne, ale nie stanowi pełnej odpowiedzi na wszystkie rodzaje włamań.
Porównanie pięciu wzorców architektury
To wzorce edukacyjne, a nie ranking pięciu produktów. Jedna usługa może stosować kilka wzorców dla różnych funkcji.
| Wzorzec | Dane dostępne z bazy | Ważna granica |
|---|---|---|
| Wiadomości i hasła w postaci jawnej | Treść i dane uwierzytelniające można odczytać bezpośrednio | Brak odpowiedniej ochrony obu rodzajów danych |
| Hasła haszowane, wiadomości jawne | Treść jest czytelna; można mieć możliwość testowania odgadniętych haseł | Jakość przechowywania haseł nie chroni tekstu czatu |
| Treść szyfrowana kluczem serwera | Szyfrogram; odczyt zależy od dostępu do klucza | Istotne jest rzeczywiste oddzielenie klucza od danych |
| Czat E2EE z kopią zapasową dostępną dla dostawcy | Bieżąca rozmowa może być chroniona, lecz kopia historii ma osobną drogę ujawnienia | Należy zbadać zasady i klucz kopii zapasowej |
| Czat E2EE z szyfrowanym odzyskiwaniem i niezależnym kluczem | Szyfrogram i dane operacyjne; ochrona treści zależy od projektu i zabezpieczenia klucza | Urządzenie, fraza odzyskiwania i uwierzytelnianie rozmówcy nadal są ważne |
Szyfrowanie dysku serwera pomaga w razie kradzieży samego dysku. Gdy napastnik dysponuje także aktywną usługą lub kluczem deszyfrującym, nie należy zakładać takiej samej ochrony. Celem E2EE jest to, aby usługa pośrednicząca nie miała klucza potrzebnego do odczytania chronionej treści.
Co ujawniają metadane?
Metadane mogą pokazywać, które konta się kontaktowały, kiedy były aktywne, do jakich grup należą i ile danych przesłano. Nie jest to tekst wiadomości, ale informacje te są cenne przy poznawaniu sieci kontaktów lub wzorców aktywności.
Strona bezpieczeństwa Livara wyraźnie opisuje przechowywanie i przetwarzanie danych operacyjnych, w tym routingu, członkostwa, czasów, rozmiaru szyfrogramu i statusu dostarczenia. Poufności prywatnej treści nie należy utożsamiać z pełną anonimowością ani brakiem jakichkolwiek danych na serwerze.
SRP nie usuwa ryzyka odgadywania hasła z danych konta
SRP to metoda udowodnienia znajomości hasła bez bezpośredniego wysyłania samego hasła. Serwer nadal przechowuje dane weryfikujące, czyli verifier. Sekcja bezpieczeństwa RFC 5054 wyjaśnia, że kradzież verifiera może umożliwić atak słownikowy w celu odgadnięcia hasła.
«Hasło nie jest przesyłane przez sieć» różni się zatem od «nie istnieją dane związane z hasłem, które można ukraść». Nadal potrzebne są silne, unikatowe hasło, ochrona urządzenia i właściwa reakcja na incydent. SRP nie zastępuje też szyfrowania treści ani ochrony sesji logowania.
Jakie granice deklaruje Livara?
Dokumentacja bezpieczeństwa Livara opisuje LVR1 dla wiadomości bezpośrednich i LGS1 dla chronionych grup. Ochrona grupy zależy od jej rzeczywistego stanu; starsza niekompatybilna grupa nie powinna otrzymywać oznaczenia E2EE. Kanały publiczne są poza tą granicą poufności.
Ten sam dokument przedstawia odzyskiwanie v7 jako zaszyfrowany pakiet tożsamości zabezpieczany przed przesłaniem. Proces ten przywraca tożsamość kryptograficzną, a nie historię czatu. Ujawnienie frazy odzyskiwania lub urządzenia zawierającego klucze to inny scenariusz niż sama kradzież bazy danych.
Są to opublikowane opisy produktu, nie wyniki niezależnego audytu przeprowadzonego na potrzeby tego artykułu. Samo wymienienie AES lub ML-KEM również nie dowodzi poprawnego zarządzania kluczami i implementacji aplikacji.
Jakie pytania zadawać po ogłoszeniu incydentu?
- Jakiego okresu i jakich systemów dotyczył incydent? Ogólnik «dane użytkowników» nie wystarcza.
- Czy dostępne były tekst jawny, pliki, klucze, verifier, sesje logowania czy tylko szyfrogramy?
- Czy napastnik mógł zmieniać usługę lub oprogramowanie dostarczane użytkownikom?
- Jakie działania trzeba wykonać oficjalną drogą: wylogować sesje, zmienić hasło, zaktualizować aplikację czy sprawdzić tożsamość rozmówcy?
- Czy zalecane odzyskiwanie może usunąć lokalną historię? Przed usunięciem aplikacji przeczytaj ograniczenia.
Nie używaj linku z anonimowej wiadomości do «pilnej weryfikacji konta». Otwórz komunikat samodzielnie pod oficjalnym adresem. Model zagrożeń Livara pomaga zrozumieć ogólne granice; zakres rzeczywistego incydentu musi wynikać z dowodów dotyczących tego konkretnego zdarzenia.
