Forensische Ergebnisse hängen vom tatsächlichen Zustand des Geräts und der Schlüssel ab, nicht allein vom Namen einer Datenbank oder eines Algorithmus.
Ende-zu-Ende-Verschlüsselung und der Schutz lokaler Daten sind verwandte, aber unterschiedliche Fragen. Eine auf dem Netzwerkweg geschützte Nachricht muss zur Anzeige auf dem Gerät lesbar werden. Das Ergebnis einer forensischen Untersuchung hängt von Gerätezustand, Zugriffsart, System- und App-Version sowie dem Speicherort der Schlüssel ab; kein Algorithmusname entscheidet allein darüber.
Daher sind sowohl die Behauptung „Mit physischem Zugriff ist sofort alles lesbar“ als auch das Versprechen „Eine Extraktion ist niemals möglich“ mit Vorsicht zu behandeln.
Vier Schutzschichten getrennt betrachten
| Schicht | Hauptaufgabe | Wichtige Einschränkung |
|---|---|---|
| Nachrichten-E2EE | Schutz der Inhalte zwischen den Geräten der Beteiligten | Garantiert weder die Integrität des Geräts noch den Schutz lokaler Kopien |
| App-Isolation | Beschränkung des Zugriffs gewöhnlicher Apps auf die Daten anderer Apps | Höhere Zugriffsrechte oder Schwachstellen können das Modell verändern |
| Datei- oder Festplattenverschlüsselung | Schutz gespeicherter Daten unter bestimmten Bedingungen | Sperrzustand und Verfügbarkeit der Schlüssel sind entscheidend |
| Datenbankverschlüsselung in der App | Zusätzliche Schutzgrenze für die Datenbankdatei | Speicherung und Verwendung des Schlüssels sind ausschlaggebend |
Die Android-Dokumentation zu FBE unterscheidet an Benutzeranmeldedaten gebundenen Speicher von Speicher, der während Direct Boot verfügbar ist. Aus „Das Telefon ist gesperrt“ allein lässt sich nicht der Zustand sämtlicher Schlüssel ablesen; auch die erste Entsperrung nach dem Start kann eine Rolle spielen.
Was beweist eine SQLite-Datei?
SQLite ist ein Speicherformat und eine Datenbank-Engine, kein Etikett, das allein das Vorhandensein oder Fehlen sämtlicher Schutzmaßnahmen anzeigt. Die Datei kann in einem vom Betriebssystem verschlüsselten Bereich liegen oder durch eine zusätzliche Lösung geschützt sein.
Auch das Löschen einer Zeile entfernt nicht zwangsläufig alle ihre Spuren aus sämtlichen Dateien. Die SQLite-Dokumentation erläutert Einstellungen zum sicheren Löschen und Einschränkungen virtueller Tabellen. Begleitdateien und Backups müssen bei der Betrachtung des Datenlebenszyklus ebenfalls berücksichtigt werden. Das garantiert nicht, dass jede gelöschte Nachricht auf jedem Telefon wiederherstellbar ist.
Führen Sie ohne Kenntnis der App keine Datenbank-Wartungsbefehle auf echten Daten aus; direkte Änderungen an App-Dateien können Daten beschädigen oder Beweismittel verändern.
SQLCipher und Keystore sind Lösungen, keine Unverwundbarkeitsnachweise
SQLCipher wurde für transparente Datenbankverschlüsselung entwickelt, doch seine Eigenschaften müssen versionsbezogen gelesen werden. Die SQLCipher-Designseite beschreibt AES-CBC mit Authentifizierung; die Vorstellung von Version 5 Beta im September 2026 beschreibt den Wechsel zu AES-GCM. Allen Versionen denselben Verschlüsselungsmodus zuzuschreiben, ist daher ungenau.
Auch Android Keystore kann Schlüssel schützen und ihre Nutzung kontrollieren. Es muss aber geklärt werden, welche Funktionen und welches Hardware-Sicherheitsniveau die App tatsächlich verwendet. Die Erwähnung von StrongBox in einem Artikel beweist nicht dessen Nutzung im Produkt. Siehe die Keystore-Anleitung.
Auch ein nicht extrahierbarer Schlüssel kann unter bestimmten Bedingungen über erlaubte Operationen nutzbar sein. „Der Schlüssel lässt sich nicht kopieren“ ist nicht dieselbe Aussage wie „Ein Angreifer kann keinerlei Daten entschlüsseln“.
Welche Rolle spielen RAM und Ratchets?
Eine begrenzte Lebensdauer von Schlüsseln und sensiblen Klartexten verringert die Gelegenheiten zur Offenlegung. Das Löschen eines Puffers beweist jedoch nicht, dass keine andere Kopie in einer Bibliothek, einer Vorschau oder im Anzeigeprozess verbleibt.
Auch die Reichweite eines Ratchets hängt davon ab, welcher Schlüssel kompromittiert wurde und ob der Angreifer weiterhin Zugriff hat. Aus „ein eigener Schlüssel pro Nachricht“ folgt nicht, dass ein Speicherabbild höchstens eine Nachricht offenlegt. Ein lesbar gespeicherter Verlauf auf dem Gerät ist eine andere Frage als die Übertragungsschlüssel.
Was wurde über Livara nicht bestätigt?
Livaras Bedrohungsmodell garantiert keinen Schutz auf infizierten oder entsperrten Geräten. Dieser Artikel bestätigt nicht unabhängig, dass eine bestimmte Livara-Version SQLCipher oder StrongBox verwendet, den RAM vollständig bereinigt oder keine lokalen Anrufdaten speichert. Ohne Testberichte und Implementierungsnachweise dürfen diese Eigenschaften dem Produkt nicht zugeschrieben werden.
Auch das Paket zur Identitätswiederherstellung in der Sicherheitsdokumentation ist kein Verlaufsbackup. Die Prüfung eines APK-Hashes im Proof Lab kann die Übereinstimmung einer Datei mit einem vertrauenswürdigen Hash zeigen; das Ergebnis ist weder ein Speicheraudit noch ein Anti-Forensik-Test.
Welche Angaben braucht eine glaubwürdige forensische Behauptung?
Verlangen Sie Gerätemodell, System- und App-Version, Sperrzustand, Zugriffsmethode und -niveau, die Art der gewonnenen Daten und die Grenzen des Tests. Das Scheitern eines Werkzeugs in einem Versuch beweist nicht die Unmöglichkeit sämtlicher Methoden; ein begrenzter Erfolg erlaubt ebenso wenig eine Verallgemeinerung auf alle Nutzer.
Für gewöhnliche Nutzer haben Updates, eine starke Gerätesperre, weniger zusätzliche Medienkopien und der Schutz der Wiederherstellungswege Vorrang. Holen Sie bei einem ernsten Vorfall Hilfe von autorisierten Fachleuten, bevor Sie Maßnahmen ergreifen, die Daten oder Beweismittel verändern.
