Integralność wiadomości: czy serwer może zmienić zaszyfrowany czat?

Komunikator może umożliwiać edycję lub usuwanie wiadomości; jednak w systemie z szyfrowaniem uwierzytelnionym serwer nie powinien móc potajemnie zmienić szyfrogramu i nadal dostarczyć prawidłowej wiadomości. Integralność wiadomości w komunikatorze oznacza, że odbiorca może wykryć zmianę danych po zaszyfrowaniu; to nie to samo co zachowanie pełnej historii czy prawne udowodnienie treści rozmowy.

Najważniejsze informacje

• Szyfrowanie uwierzytelnione ujawnia manipulację szyfrogramem, ale nie musi zachowywać historii edycji i usunięć.
• Według dokumentacji technicznej Livary AES-256-GCM chroni prywatne wiadomości wraz ze znacznikiem uwierzytelniania; zmodyfikowany pakiet nie powinien zostać prawidłowo odszyfrowany.
• Dozwolona edycja powinna być nowym zdarzeniem zaszyfrowanym od końca do końca, a nie ukrytym nadpisaniem poprzedniego pakietu przez serwer.
• Numery bezpieczeństwa pomagają sprawdzić klucz rozmówcy, a nie jego uczciwość czy moc prawną zrzutu ekranu.
• Przy delikatnych sporach zachowuj oryginalny plik, czasy, status edycji i niezależne dowody także poza wątkiem rozmowy.

Czym dokładnie jest integralność wiadomości w komunikatorze?

Integralność wiadomości oznacza możliwość wykrycia przez odbiorcę nieautoryzowanej zmiany zaszyfrowanych danych. Poufność pyta: „Kto może przeczytać treść?”, a integralność: „Czy dotarły te same dane, które nadawca zaszyfrował?”. Wyjaśnienie szyfrowania end-to-end i jego granic szerzej opisuje tę różnicę.

To ilustracja koncepcyjna z przykładowymi etykietami, nie rzeczywisty interfejs Livary ani wynik testu odrzucenia zmodyfikowanej wiadomości.

Według dokumentacji technicznej Livary wiadomości bezpośrednie są szyfrowane end-to-end przy użyciu LVR1, a zgodne grupy prywatne przy użyciu LGS1. Zgodnie ze stroną bezpieczeństwa Livary stara, niezgodna grupa pozostaje jawnie poza E2EE, a nowa grupa nie jest tworzona z oznaczeniem szyfrowania, dopóki wszyscy członkowie nie są gotowi. Sprawdź stan konkretnej rozmowy. Dokumentacja mówi, że LVR1 używa ECDH P-256 i ML-KEM-768 do wyprowadzania klucza wiadomości. Standaryzacja składnika nie jest niezależnym zatwierdzeniem całego połączenia ani produktu. Następnie Livara używa AES-256-GCM do ochrony treści.

Według dokumentacji produktu ochrona obejmuje tekst, edycje i załączniki prywatnych rozmów. Kanały Livary nie są jednak szyfrowane end-to-end: serwer celowo może odczytywać ich treść, między innymi w celu usuwania nadużyć. Serwer kontroluje także członkostwo w grupach. Bezpieczeństwo połączeń i trybu nagrywania trzeba oceniać osobno od wiadomości tekstowych.

Wykrywanie manipulacji i szyfrowanie AES-256-GCM w komunikatorze

Oprócz szyfrowania treści AES-GCM tworzy znacznik uwierzytelniania. Jeśli szyfrogram lub uwierzytelniane dane się zmienią, sprawdzenie znacznika powinno zakończyć się niepowodzeniem. NIST SP 800-38D definiuje tryb GCM i ostrzega, że powtórzenie nonce z tym samym kluczem może poważnie osłabić bezpieczeństwo.

Zgodnie ze specyfikacją techniczną Livary prywatne wiadomości używają AES-256-GCM. Gdy serwer zmieni część chronionego pakietu, bez klucza wiadomości nie może utworzyć nowego znacznika uwierzytelniania; odbiorca nie powinien więc zaakceptować pakietu jako nienaruszonego. Krótka odpowiedź na pytanie „Czy serwer może zmienić wiadomość?” brzmi: serwer może usunąć, zatrzymać, zablokować lub opóźnić dane, ale nie powinien móc przedstawić zmienionej treści jako prawidłowej.

Ta gwarancja nie jest nieograniczona. Kryptografia nie neutralizuje złośliwego oprogramowania na urządzeniu, dostępu napastnika do odblokowanego ekranu ani dozwolonej edycji użytkownika. Integralność treści nie musi też ukrywać metadanych. Przewodnik po metadanych komunikatorów i ujawnianych przez nie informacjach opisuje tę granicę.

Czy serwer może zmienić wiadomość, czy edycja jest czymś innym?

Serwer nie powinien móc potajemnie nadpisać wcześniejszego zaszyfrowanego pakietu, ale może dostarczyć zdarzenie edycji utworzone przez nadawcę. Bezpieczeństwo edycji wiadomości zależy od tego, czy edycja jest uwierzytelniana i szyfrowana end-to-end tak jak oryginał, zamiast bezpośredniej zmiany zapisanego tekstu przez serwer.

Według dokumentacji Livary edycja w czacie bezpośrednim jest chroniona przez LVR1, a w zgodnej grupie prywatnej przez LGS1. Oceniając interfejs, sprawdź, czy aplikacja pokazuje status „edytowano”; sama kryptografia nie zachowuje jednak poprzedniej wersji na zawsze na wszystkich urządzeniach.

„Usuń dla wszystkich” to również prośba o odrzucenie treści, a nie dowód zniszczenia każdej kopii. Odbiorca mógł zobaczyć wiadomość, przeczytać powiadomienie, zapisać plik lub zrobić zrzut ekranu. Znikające wiadomości ograniczają trwałość, ale nie gwarantują usunięcia wszystkich kopii.

Co potwierdza uwierzytelnianie wiadomości czatu?

Uwierzytelnianie wiadomości czatu wskazuje, że wiadomość utworzono przy użyciu kluczy sesji i nie zmieniono jej po drodze. Nie dowodzi, że właściciel konta osobiście trzymał urządzenie, że treść jest prawdziwa ani że odbiorca może później jednoznacznie udowodnić ją osobie trzeciej.

Livara przedstawia w dokumentacji technicznej numery bezpieczeństwa jako sposób wykrywania zmian kluczy. Dwie osoby mogą porównać odciski kluczy niezależnym kanałem; przewodnik weryfikowania czatu numerami bezpieczeństwa opisuje praktyczne kroki. Ogranicza to ryzyko zastąpienia klucza kontaktu kluczem napastnika, ale nie zabezpiecza zainfekowanego urządzenia.

Uwierzytelnianie konta jest osobnym zagadnieniem. Żaden mechanizm logowania, niezależnie od siły, nie zastępuje integralności wiadomości, weryfikacji klucza kontaktu ani bezpieczeństwa urządzenia.

Integralność treści to nie kolejność ani świeżość wiadomości

Stary pakiet może mieć prawidłowy znacznik uwierzytelniania. Zapobieganie jego ponownemu przyjęciu wymaga odpowiedniego projektu protokołu, liczników, identyfikatora sesji i zachowania stanu odbiorcy; sam AES-GCM nie jest rejestrem kolejności całej rozmowy. To rozróżnienie ma znaczenie przy ocenie ataków replay, opóźnionych wiadomości i synchronizacji wielu urządzeń.

Trzeba też ustalić, jakie dane rzeczywiście obejmuje znacznik uwierzytelniania. Jeżeli identyfikator rozmowy lub typ zdarzenia znajduje się poza uwierzytelnianym kontekstem, sama ochrona treści nie rozwiązuje całego problemu. Przegląd kodu i testy konkretnej wersji powinny wyjaśnić to powiązanie.

Gdy treść lub status wiadomości są nieoczekiwane

Zapisz wersję aplikacji, czas obserwacji, uczestniczące urządzenia i obecność etykiety edycji. Niezależnym kanałem sprawdź u rozmówcy, czy dokonał dozwolonej edycji. Bez dowodów nie przypisuj różnic synchronizacji manipulacji serwera; nie ignoruj też bez powodu błędu uwierzytelniania lub zmiany klucza.

Do raportu technicznego użyj niewrażliwej wiadomości testowej i nie umieszczaj prywatnych danych rozmówcy w raporcie publicznym. Jeśli rozmowa ma być użyta w sprawie prawnej, sama kryptografia ani zrzut ekranu nie przesądzają o mocy prawnej; przed zmianą dowodów skorzystaj z pomocy wykwalifikowanego specjalisty.

Jak oceniać deklarację integralności komunikatora?

Nie poprzestawaj na słowie „zaszyfrowane”. Zapytaj:

• Które rozmowy i pliki są szyfrowane end-to-end?
• Jakiego algorytmu AEAD używa usługa?
• Jak rejestrowane i wyświetlane są edycje oraz usunięcia?
• Jak użytkownik wykrywa zmianę klucza kontaktu?
• Jakie metadane, treści lub członkostwa kontroluje serwer?
• Czy połączenia mają te same gwarancje co wiadomości?
• Czy protokół przeszedł niezależny audyt?

Livara publikuje specyfikacje i narzędzia pozwalające sprawdzić część deklaracji, a użytkownicy Androida mogą porównać sumę kontrolną pliku APK przy użyciu SHA-256 w Proof Lab do sprawdzania aplikacji offline. Ten artykuł nie przedstawia jednak dowodu niezależnego audytu bieżącej wersji. Publikowanie specyfikacji i wektorów testowych pomaga w badaniu, ale nie zastępuje niezależnego audytu.

Główna deklaracja Livary dla rozmów prywatnych jest ograniczona i jasna: AES-256-GCM powinien ujawniać manipulację pakietem, a edycje także powinny być szyfrowane. Nie oznacza to niezmiennego rejestru, pewnego usunięcia wszystkich kopii ani automatycznego dowodu prawnego.

Częste pytania

Czy administrator serwera może zmienić tekst zaszyfrowanej wiadomości?

W poprawnym projekcie z AES-256-GCM administrator bez klucza wiadomości nie może zmienić szyfrogramu i utworzyć prawidłowego znacznika uwierzytelniania. Nadal może usunąć, zablokować lub opóźnić pakiet. Gwarancja nie obejmuje zainfekowanego urządzenia ani dozwolonej edycji nadawcy.

Czy etykieta „edytowano” dowodzi, jaka była poprzednia wersja?

Nie. Etykieta mówi tylko, że wyświetlana treść zmieniła się po wysłaniu, chyba że aplikacja przechowuje także historię wersji. Szyfrowanie może sprawdzić autentyczność zdarzenia edycji, ale nie zachowuje automatycznie wcześniejszego tekstu.

Czy numer bezpieczeństwa gwarantuje autentyczność wszystkich wiadomości?

Nie. Numer bezpieczeństwa pomaga sprawdzić, czy klucz kryptograficzny należy do kontaktu, i wykryć jego zmianę. Nie mówi, kto trzymał urządzenie podczas wysyłania, czy wiadomość jest prawdziwa ani czy urządzenie jest wolne od złośliwego oprogramowania.

Czy usunięcie dla wszystkich usuwa wiadomość z każdego miejsca?

Nie. Funkcja może odrzucić kopię w aplikacji, ale nie cofa zapisanego pliku, powiadomienia, zrzutu ekranu ani wcześniejszego zapisu. Usuwanie dla wszystkich ogranicza trwałość; nie gwarantuje usunięcia z urządzenia odbiorcy lub innych systemów.