Wynik analizy śledczej zależy od rzeczywistego stanu urządzenia i kluczy, a nie tylko nazwy bazy danych lub algorytmu.
Szyfrowanie end-to-end i ochrona danych lokalnych to dwa powiązane, ale różne zagadnienia. Wiadomość chroniona w sieci musi stać się czytelna, aby można ją było wyświetlić na urządzeniu. Wynik analizy śledczej zależy od stanu urządzenia, rodzaju dostępu, wersji systemu i aplikacji oraz miejsca przechowywania kluczy; sama nazwa algorytmu nie przesądza wyniku.
Dlatego zarówno twierdzenie „przy fizycznym dostępie wszystko można od razu odczytać”, jak i obietnica „ekstrakcja nigdy nie jest możliwa” wymagają ostrożności.
Zbadaj osobno cztery warstwy ochrony
| Warstwa | Główna funkcja | Ważne ograniczenie |
|---|---|---|
| E2EE wiadomości | Ochrona treści między urządzeniami uczestników | Nie gwarantuje bezpieczeństwa urządzenia ani lokalnych kopii |
| Izolacja aplikacji | Ograniczanie dostępu zwykłych aplikacji do danych innych aplikacji | Dostęp uprzywilejowany lub luka może zmienić model |
| Szyfrowanie plików lub dysku | Ochrona zapisanych danych w określonych warunkach | Liczy się stan blokady i dostępność klucza |
| Szyfrowanie bazy w aplikacji | Dodatkowa granica ochrony pliku bazy danych | Decyduje sposób przechowywania i używania klucza |
Dokumentacja Android FBE rozróżnia przestrzeń zależną od poświadczeń użytkownika i przestrzeń dostępną w Direct Boot. Samo stwierdzenie „telefon jest zablokowany” nie opisuje całego stanu kluczy; znaczenie może mieć również to, czy nastąpiło już pierwsze odblokowanie po uruchomieniu.
Co dowodzi plik SQLite?
SQLite jest formatem i silnikiem przechowywania, a nie etykietą, która sama wskazuje obecność lub brak wszystkich zabezpieczeń. Plik może znajdować się w zaszyfrowanej przestrzeni systemu operacyjnego albo być chroniony osobnym rozwiązaniem.
Ponadto usunięcie wiersza nie musi usuwać wszystkich jego śladów we wszystkich plikach. Dokumentacja SQLite opisuje ustawienia bezpiecznego usuwania i ograniczenia tabel wirtualnych. Analiza cyklu życia danych musi też uwzględniać pliki pomocnicze i kopie zapasowe. Nie oznacza to gwarancji odzyskania każdej usuniętej wiadomości z każdego telefonu.
Nie uruchamiaj poleceń konserwacji bazy na rzeczywistych danych bez znajomości aplikacji; bezpośrednie zmienianie jej plików może uszkodzić dane lub zmienić materiał dowodowy.
SQLCipher i Keystore to rozwiązania, nie certyfikaty nietykalności
SQLCipher zaprojektowano do przezroczystego szyfrowania baz danych, ale specyfikację należy czytać w kontekście wersji. Strona projektu SQLCipher opisuje konstrukcję AES-CBC z uwierzytelnianiem; zapowiedź wersji 5 beta z września 2026 r. mówi o przejściu na AES-GCM. Przypisywanie jednego trybu szyfrowania wszystkim wersjom jest więc nieprecyzyjne.
Android Keystore również może chronić klucze i kontrolować ich użycie, ale trzeba ustalić, z jakich funkcji i jakiego poziomu sprzętowego aplikacja rzeczywiście korzysta. Nazwa StrongBox w artykule nie dowodzi używania go przez produkt. Przewodnik Keystore.
Nawet klucz, którego nie można wyeksportować, w pewnych warunkach może być używany przez dozwolone operacje. „Nie można skopiować klucza” nie jest tym samym twierdzeniem co „napastnik nie może odszyfrować żadnych danych”.
Jaką rolę odgrywają RAM i ratchet?
Ograniczanie czasu życia kluczy i wrażliwego tekstu zmniejsza liczbę okazji do ujawnienia. Wyczyszczenie jednego bufora nie dowodzi jednak, że żadna inna kopia nie pozostała w bibliotece, podglądzie lub procesie wyświetlania.
Zakres ochrony mechanizmu ratchet także zależy od rodzaju ujawnionego klucza i tego, czy napastnik nadal ma dostęp. Z „osobnego klucza dla każdej wiadomości” nie wynika, że jeden zrzut pamięci ujawni najwyżej jedną wiadomość. Przechowywanie czytelnej historii na urządzeniu jest zagadnieniem odrębnym od kluczy transmisji.
Czego nie potwierdzono w przypadku Livara?
Model zagrożeń Livara nie gwarantuje ochrony zainfekowanego ani odblokowanego urządzenia. Ten artykuł nie potwierdza niezależnie, że konkretna wersja Livara używa SQLCipher lub StrongBox, całkowicie czyści RAM albo nie przechowuje lokalnych danych połączeń. Bez raportów z testów i dowodów implementacji nie należy przypisywać produktowi tych właściwości.
Również pakiet odzyskiwania tożsamości w dokumentacji bezpieczeństwa nie jest tym samym co kopia historii. Sprawdzanie skrótu APK w Proof Lab może wykazać zgodność pliku z zaufanym skrótem; wynik nie jest audytem przechowywania ani testem odporności na analizę śledczą.
Jakie informacje musi zawierać wiarygodne twierdzenie śledcze?
Poproś o model urządzenia, wersję systemu i aplikacji, stan blokady, metodę i poziom dostępu, rodzaj uzyskanych danych oraz ograniczenia testu. Niepowodzenie jednego narzędzia w jednym badaniu nie dowodzi niemożliwości wszystkich metod; ograniczony sukces również nie pozwala uogólniać wyniku na wszystkich użytkowników.
Dla zwykłego użytkownika priorytetem są aktualizacje, silna blokada, ograniczanie dodatkowych kopii multimediów i dbałość o metody odzyskiwania. Przy poważnym incydencie zasięgnij pomocy uprawnionego specjalisty, zanim podejmiesz działania zmieniające dane lub dowody.
