Kopia dysku, bieżąca kontrola serwera i dostęp do telefonu to trzy różne scenariusze; jedna ogólna gwarancja nie wystarcza dla wszystkich.
Jeśli serwer komunikatora zostanie przejęty, dokładna odpowiedź na pytanie „co zostanie ujawnione?” zależy od przechowywanych danych, lokalizacji kluczy i rodzaju dostępu napastnika. Zdobycie kopii dysku to nie to samo co bieżąca kontrola usługi i kanału dystrybucji aplikacji.
Ten artykuł analizuje hipotetyczny scenariusz na podstawie publicznej dokumentacji Livara. Nie zawiera twierdzeń o lokalizacji centrów danych Livara, faktycznym zajęciu serwera ani gwarancji działania usługi podczas przerwy w dostępie do internetu. Szyfrowanie treści, dostępność sieci i bezpieczeństwo infrastruktury to osobne zagadnienia.
Najpierw określmy rodzaj dostępu
Przechowywana kopia serwera: napastnik uzyskuje dostęp do plików, bazy danych lub kopii zapasowych znajdujących się w tej kopii. Jeśli prywatna treść została prawidłowo zaszyfrowana na urządzeniu, a serwer nie dysponuje kluczem do jej odszyfrowania, samo posiadanie kopii nie ujawnia tekstu rozmowy.
Aktywna kontrola usługi: oprócz odczytywania istniejących danych napastnik może blokować pewne żądania, zwracać stare dane lub zmieniać zachowanie kontrolowanych elementów. W tym scenariuszu większe znaczenie mają weryfikacja tożsamości rozmówcy, kontrola wersji i integralność klienta.
Równoczesny dostęp do urządzenia: odblokowany telefon, złośliwe oprogramowanie lub czytelna kopia u uczestnika rozmowy mogą ujawnić treść zupełnie inną drogą. Także model zagrożeń Livara nie gwarantuje ochrony odblokowanego lub zainfekowanego urządzenia.
Jakie dane według dokumentacji Livara są widoczne na serwerze?
Strona bezpieczeństwa Livara, oznaczona wersją 0.1.68, oddziela treść rozmów bezpośrednich w LVR1 i zgodnych grup prywatnych w LGS1 od informacji operacyjnych. Ta sama strona wyraźnie stwierdza, że stare, niezgodne grupy pozostają poza E2EE; trzeba zatem sprawdzić stan konkretnej rozmowy.
| Kategoria danych | Udokumentowana granica i możliwy skutek |
|---|---|
| Tekst i załączniki chronionej rozmowy | Serwer przechowuje zaszyfrowaną kopię; odczyt wymaga odpowiedniego klucza |
| Metadane komunikacji | Usługa ma dostęp do informacji takich jak strony rozmowy, czas, rozmiar i status dostarczenia |
| Członkostwo w grupie | Jest częścią informacji i uprawnień operacyjnych serwera |
| Kanał publiczny | Treść jest publiczna i czytelna dla serwera |
| Pakiet odzyskiwania tożsamości v7 | Jest szyfrowany przed przesłaniem i wymaga osobnego sekretu odzyskiwania |
| Opcjonalny tryb nagrywania na serwerze | Oznaczenie REC odróżnia go od E2EE; nie należy zakładać w nim prywatności end-to-end |
Dokumentacja wymienia kod LSS1 służący ochronie metadanych, ale nie jest on połączony ze zwykłym wysyłaniem wiadomości. Obecność nazwy protokołu w projekcie nie dowodzi, że działa on we wszystkich połączeniach.
Tabela opisuje deklaracje produktu, a nie wyniki testu rzeczywistego zajęcia serwera czy niezależnego audytu wszystkich kopii bazy danych.
Jak ważne mogą być metadane?
Informacje o kontaktach między ludźmi, czasie i członkostwie w grupach mogą być wrażliwe nawet bez tekstu wiadomości. Jednak stwierdzenie „cały graf komunikacji zostanie ujawniony na zawsze” jest nieprecyzyjne bez znajomości okresu przechowywania, zakresu logów i uzyskanej kopii danych.
Rzetelna ocena wymaga pytań o to, jakie pola zbierano, jak długo je przechowywano i jakie kopie zapasowe są dostępne. Samo szyfrowanie treści nie określa polityki przechowywania danych. Nie można też na podstawie architektury jednego komunikatora wnioskować, że wszystkie komunikatory muszą przechowywać te same metadane.
Jakie zagrożenie dla przyszłych wiadomości stwarza kontrola serwera?
W badaniu bezpieczeństwa należy osobno testować manipulowanie listą członków, podawanie innego klucza tożsamości, blokowanie aktualizacji i dostarczanie złośliwego klienta. Skutek każdego działania zależy od walidacji po stronie klienta, prezentowania zmian i weryfikacji tożsamości.
Bez testów implementacji nie można twierdzić, że każdy przejęty serwer na pewno może dodać ukrytego członka; tak samo nie można twierdzić, że aktywna kontrola serwera nie ma żadnych skutków. W poufnych rozmowach trzeba sprawdzać nieoczekiwane zmiany tożsamości lub składu grupy. Porównanie odcisku klucza z rozmówcą niezależnym, zaufanym kanałem daje więcej informacji niż samo zaufanie do wyświetlanej nazwy.
Jeśli napastnik zmieni kod wykonywany na urządzeniu, może zobaczyć tekst przed zaszyfrowaniem. Dlatego bezpieczeństwo dystrybucji i aktualizacji aplikacji jest częścią tego scenariusza, a nie zagadnieniem poza kryptografią.
Co daje postkwantowość?
Standard NIST FIPS 203 dla ML-KEM pomaga ustanawiać wspólny sekret. Prawidłowe wykorzystanie go w konstrukcji hybrydowej może ograniczyć ryzyko niektórych przyszłych ataków na wymianę kluczy. Nie zastępuje to bezpieczeństwa urządzenia, ograniczonego przechowywania metadanych ani kontroli dostępu do serwera.
Również Proof Lab prezentuje tylko niektóre lokalne operacje P-256, HKDF i AES-GCM i wyłącza pełną konstrukcję LVR1/LGS1 z tego testu. Pomyślny wynik nie gwarantuje odporności całego produktu na przejęcie infrastruktury.
Co robić podczas oceny lub rzeczywistego incydentu?
- Zapisz rodzaj dostępu i potwierdzone informacje; nie utożsamiaj pogłoski o awarii z pewnym incydentem bezpieczeństwa.
- Sprawdź wersję aplikacji i stan szyfrowania konkretnej rozmowy.
- Sprawdź oficjalną drogą zmiany tożsamości, członków grupy i nieznane sesje.
- Nie przekazuj nieznajomym sekretu odzyskiwania, hasła ani prywatnej treści w celu „kontroli bezpieczeństwa”.
- Przy poważnym zagrożeniu lub kwestiach prawnych skorzystaj z pomocy odpowiedniego specjalisty i nie podejmuj nieodwracalnych działań na podstawie jednego artykułu.
Wiarygodny wniosek musi wskazywać, jakie dane, w jakiej wersji i przed jakim dostępem są chronione. Zdanie „nawet po zajęciu serwera nic się nie stanie” nie zastępuje takiej odpowiedzi.
