Forensiska resultat beror på enhetens och nycklarnas verkliga tillstånd, inte bara databasens eller algoritmens namn.
Totalsträckskryptering och skydd av lokala data är två relaterade men olika frågor. Ett meddelande som skyddats under nätverksöverföringen måste bli läsbart för att visas på enheten. Resultatet av en forensisk undersökning beror på enhetens tillstånd, typen av åtkomst, system- och appversionen och nycklarnas placering; inget algoritmnamn avgör ensamt resultatet.
Därför kräver både påståendet ”med fysisk åtkomst kan allt läsas direkt” och löftet ”extraktion är aldrig möjlig” försiktighet.
Undersök fyra skyddslager var för sig
| Lager | Huvuduppgift | Viktig begränsning |
|---|---|---|
| Meddelandets E2EE | Skydda innehållet mellan deltagarnas enheter | Garanterar inte enhetens säkerhet eller lokala kopiors skydd |
| Appisolering | Begränsa vanliga appars åtkomst till varandras data | Privilegierad åtkomst eller en sårbarhet kan förändra modellen |
| Fil- eller diskkryptering | Skydda lagrade data under bestämda förutsättningar | Låsstatus och nyckelns tillgänglighet spelar roll |
| Databaskryptering i appen | En extra skyddsgräns för databasfilen | Hur nyckeln förvaras och används är avgörande |
Androids FBE-dokumentation skiljer mellan utrymme som beror på användarens inloggningsuppgifter och utrymme som är tillgängligt i Direct Boot. Enbart ”telefonen är låst” beskriver inte hela nyckeltillståndet; det kan också spela roll om den första upplåsningen efter start har skett.
Vad bevisar en SQLite-fil?
SQLite är ett lagringsformat och en lagringsmotor, inte en etikett som ensam visar om alla skydd finns eller saknas. Filen kan ligga i operativsystemets krypterade utrymme eller skyddas av en separat lösning.
Att ta bort en rad tar inte heller nödvändigtvis bort alla dess spår i alla filer. SQLite-dokumentationen beskriver inställningar för säker radering och begränsningar hos virtuella tabeller. Sidofiler och säkerhetskopior måste också ingå när datalivscykeln undersöks. Det innebär inte en garanti för att varje raderat meddelande på varje telefon går att återställa.
Kör inte underhållskommandon för databasen på verkliga data utan att känna till appen; direkt ändring av appfiler kan skada data eller förändra bevismaterial.
SQLCipher och Keystore är lösningar, inte immunitetsbevis
SQLCipher är utformat för transparent databaskryptering, men specifikationerna måste läsas versionsvis. SQLCiphers designsida beskriver AES-CBC med autentisering; introduktionen av version 5 beta i september 2026 anger en övergång till AES-GCM. Det är därför inte korrekt att tillskriva alla versioner samma krypteringsläge.
Android Keystore kan också skydda nycklar och kontrollera deras användning, men man måste fastställa vilka funktioner och vilken hårdvarunivå appen faktiskt använder. Namnet StrongBox i en artikel är inget bevis för att produkten använder det. Keystore-guiden.
Även en icke-extraherbar nyckel kan under vissa förutsättningar användas genom tillåtna operationer. ”Nyckeln kan inte kopieras” är inte samma påstående som ”angriparen kan inte dekryptera några data”.
Vilken roll har RAM och ratchet?
Att begränsa nycklars och känslig texts livslängd minskar antalet tillfällen för exponering. Att rensa en buffert bevisar däremot inte att ingen annan kopia finns kvar i ett bibliotek, en förhandsvisning eller en visningsprocess.
Ratchet-mekanismens räckvidd varierar också med typen av röjd nyckel och om angriparens åtkomst fortsätter. ”En separat nyckel per meddelande” innebär inte att en minnesdump avslöjar högst ett meddelande. Läsbar historik lagrad på enheten är en annan fråga än transportnycklar.
Vad har inte bekräftats om Livara?
Livaras hotmodell garanterar inte skydd av en infekterad eller upplåst enhet. Artikeln bekräftar inte oberoende att en viss Livara-version använder SQLCipher eller StrongBox, rensar hela RAM-minnet eller saknar lokala samtalsdata. Sådana egenskaper får inte tillskrivas produkten utan testrapporter och belägg för implementationen.
Identitetsåterställningspaketet i säkerhetsdokumentationen är inte heller detsamma som en säkerhetskopia av historiken. Kontroll av APK-hashen i Proof Lab kan visa att filen stämmer med en betrodd hash; resultatet är ingen lagringsrevision eller prövning av motstånd mot forensik.
Vilka uppgifter måste ett trovärdigt forensiskt påstående innehålla?
Begär enhetsmodell, system- och appversion, låsstatus, åtkomstmetod och åtkomstnivå, vilken typ av data som hämtades och testets begränsningar. Att ett verktyg misslyckas i ett test bevisar inte att alla metoder är omöjliga; en begränsad framgång får inte heller generaliseras till alla användare.
För vanliga användare är uppdateringar, ett starkt lås, färre extra mediekopior och omsorg om återställningsvägarna prioriterade. Vid en allvarlig incident bör du ta hjälp av en behörig expert innan du gör något som ändrar data eller bevismaterial.
