Forensische resultaten hangen af van de werkelijke toestand van het apparaat en de sleutels, niet alleen van de naam van een database of algoritme.
End-to-end-versleuteling en de bescherming van lokale gegevens zijn verwante maar verschillende vraagstukken. Een bericht dat onderweg over het netwerk is beschermd, moet leesbaar worden om op een apparaat te kunnen verschijnen. Het resultaat van forensisch onderzoek hangt af van de apparaatstatus, het soort toegang, de systeem- en appversies en de locatie van sleutels; geen enkele algoritmenaam bepaalt op zichzelf de uitkomst.
Zowel de bewering ‘met fysieke toegang is alles meteen leesbaar’ als de belofte ‘extractie is nooit mogelijk’ vraagt daarom om voorzichtigheid.
Onderzoek vier beschermingslagen afzonderlijk
| Laag | Hoofdfunctie | Belangrijke beperking |
|---|---|---|
| Bericht-E2EE | Inhoud beschermen tussen de apparaten van deelnemers | Garandeert niet de integriteit van het apparaat of bescherming van lokale kopieën |
| App-isolatie | Toegang van gewone apps tot elkaars gegevens beperken | Verhoogde toegangsrechten of een kwetsbaarheid kunnen het model veranderen |
| Bestands- of schijfversleuteling | Opgeslagen gegevens onder bepaalde voorwaarden beschermen | Vergrendeling en beschikbaarheid van sleutels zijn belangrijk |
| Databaseversleuteling in de app | Een extra beschermingsgrens rond het databasebestand | De opslag en het gebruik van de sleutel zijn doorslaggevend |
Androids FBE-documentatie maakt onderscheid tussen opslag die afhankelijk is van gebruikersreferenties en opslag die tijdens Direct Boot beschikbaar is. ‘De telefoon is vergrendeld’ zegt op zichzelf niet alles over de status van sleutels; ook de vraag of de eerste ontgrendeling na het opstarten al heeft plaatsgevonden kan van belang zijn.
Wat bewijst een SQLite-bestand?
SQLite is een opslagformaat en database-engine, geen label dat op zichzelf aangeeft of alle beschermingsmaatregelen aanwezig of afwezig zijn. Een bestand kan in door het besturingssysteem versleutelde opslag staan of met een aparte oplossing worden beschermd.
Het verwijderen van een rij wist ook niet noodzakelijk alle sporen daarvan uit alle bestanden. De SQLite-documentatie bespreekt instellingen voor veilig verwijderen en beperkingen van virtuele tabellen. Ook hulpbestanden en back-ups moeten worden meegenomen bij het onderzoeken van de gegevenslevenscyclus. Dit garandeert niet dat elk verwijderd bericht op iedere telefoon kan worden hersteld.
Voer zonder kennis van de app geen databaseonderhoudscommando’s uit op echte gegevens; directe wijzigingen aan appbestanden kunnen gegevens beschadigen of bewijsmateriaal veranderen.
SQLCipher en Keystore zijn oplossingen, geen bewijzen van onkwetsbaarheid
SQLCipher is ontworpen voor transparante databaseversleuteling, maar de specificaties moeten per versie worden gelezen. De SQLCipher-ontwerppagina beschrijft een AES-CBC-structuur met authenticatie; de introductie van versie 5 bèta in september 2026 beschrijft de overstap naar AES-GCM. Eén versleutelingsmodus aan alle versies toeschrijven is daarom onjuist.
Android Keystore kan eveneens sleutels beschermen en het gebruik ervan beheersen, maar er moet worden vastgesteld welke functies en welk hardwarebeveiligingsniveau de app daadwerkelijk gebruikt. StrongBox noemen in een artikel bewijst niet dat een product het gebruikt. Zie de Keystore-handleiding.
Ook een niet-extraheerbare sleutel kan onder bepaalde omstandigheden via toegestane bewerkingen bruikbaar zijn. ‘De sleutel kan niet worden gekopieerd’ is niet dezelfde bewering als ‘een aanvaller kan geen enkele gegevens ontsleutelen’.
Welke rol spelen RAM en ratcheting?
De levensduur van sleutels en gevoelige leesbare tekst beperken verkleint de kansen op blootstelling. Maar één buffer wissen bewijst niet dat er geen andere kopie achterblijft in een bibliotheek, voorvertoning of weergaveproces.
Ook de reikwijdte van ratcheting hangt af van het soort gecompromitteerde sleutel en de vraag of de aanvaller toegang houdt. ‘Een afzonderlijke sleutel per bericht’ betekent niet dat een geheugenopname hoogstens één bericht blootlegt. Een leesbare geschiedenis op het apparaat bewaren staat los van transportsleutels.
Wat is niet geverifieerd over Livara?
Livara’s dreigingsmodel garandeert geen bescherming van een besmet of ontgrendeld apparaat. Dit artikel verifieert niet onafhankelijk dat een bepaalde Livara-versie SQLCipher of StrongBox gebruikt, het RAM volledig wist of geen lokale oproepgegevens bewaart. Zonder testrapporten en implementatiebewijs mogen deze eigenschappen niet aan het product worden toegeschreven.
Het pakket voor identiteitsherstel in de beveiligingsdocumentatie is bovendien geen back-up van de geschiedenis. Een APK-hash controleren in Proof Lab kan aantonen dat een bestand overeenkomt met een vertrouwde hash; dat resultaat is geen opslagcontrole of antiforensische test.
Welke informatie moet een geloofwaardige forensische claim bevatten?
Vraag naar apparaatmodel, systeem- en appversies, vergrendelingsstatus, toegangsmethode en -niveau, het soort verkregen gegevens en de beperkingen van de test. Het falen van één hulpmiddel in één experiment bewijst niet dat alle methoden onmogelijk zijn; beperkt succes rechtvaardigt evenmin een generalisatie naar alle gebruikers.
Voor gewone gebruikers hebben updates, een sterke vergrendeling, minder extra mediakopieën en bescherming van herstelmethoden prioriteit. Vraag bij een ernstig incident hulp aan een bevoegde specialist voordat je handelingen uitvoert die gegevens of bewijsmateriaal veranderen.
