Verschlüsselter lokaler Speicher: SQLCipher und Secure Databases

1. Warum eine unverschlüsselte SQLite-Datenbank ein Risiko ist

Standard-SQLite speichert seine Datenbankdatei im Klartext-Binärformat im Dateisystem der App. Auf einem gerooteten Android-Gerät oder einem entsperrten iOS-Gerät mit Dateisystemzugriff lässt sich diese Datei direkt kopieren und mit gängigen SQLite-Tools ohne jede zusätzliche Hürde öffnen, samt sämtlicher gespeicherter Inhalte.

Für App-Einstellungen oder unkritische Cache-Daten ist das meist unproblematisch. Sobald jedoch Gesundheitsdaten, Zahlungsinformationen, private Nachrichten oder Zugangstoken lokal zwischengespeichert werden, reicht der Schutz durch die App-Sandbox allein nicht mehr aus, insbesondere bei verlorenen oder gestohlenen Geräten sowie bei Backups, die außerhalb der Kontrolle der App liegen.

2. Wie SQLCipher technisch funktioniert

SQLCipher ist eine Erweiterung von SQLite, die jede Datenbankseite transparent mit AES-256 im CBC-Modus verschlüsselt, bevor sie auf die Festplatte geschrieben wird, und beim Lesen entsprechend wieder entschlüsselt. Für den Anwendungscode ändert sich dabei nichts: Alle gewohnten SQL-Befehle funktionieren identisch, nur die zugrunde liegende Datei ist ohne den passenden Schlüssel wertloser Binärmüll.

Zusätzlich zur reinen Verschlüsselung nutzt SQLCipher HMAC-Prüfsummen pro Seite, um unbemerkte Manipulationen an der Datenbankdatei zu erkennen. Wird eine Seite ohne Kenntnis des Schlüssels verändert, schlägt die Integritätsprüfung beim nächsten Öffnen fehl, statt die manipulierten Daten stillschweigend zu akzeptieren.

3. Integration in React Native über react-native-sqlcipher-storage

In React-Native-Projekten kommt SQLCipher meist über eine Bibliothek wie react-native-sqlcipher-storage oder eine gepatchte Variante von op-sqlite zum Einsatz, die native SQLCipher-Bindings für iOS und Android bereitstellt. Die API bleibt dabei nahezu identisch zur unverschlüsselten SQLite-Variante, ergänzt lediglich um den Verschlüsselungsschlüssel beim Öffnen der Verbindung.

Wichtig ist, den Schlüssel niemals als Literal im JavaScript-Code oder in einer Konfigurationsdatei zu hinterlegen, da dieser sonst durch einfaches Dekompilieren des Bundles auslesbar wäre. Stattdessen wird der Schlüssel bei jedem App-Start aus einem sicheren nativen Speicher geladen und ausschließlich zur Laufzeit an die Datenbankverbindung übergeben.

import { openDatabase } from 'react-native-sqlcipher-storage';
import * as Keychain from 'react-native-keychain';

async function openEncryptedDatabase() {
  const credentials = await Keychain.getGenericPassword({ service: 'db-key' });
  if (!credentials) {
    throw new Error('Kein Verschlüsselungsschlüssel im sicheren Speicher gefunden');
  }
  return openDatabase({
    name: 'secure.db',
    key: credentials.password,
    location: 'default',
  });
}

4. Schlüsselverwaltung über Keychain und Android Keystore

Der Verschlüsselungsschlüssel selbst muss außerhalb der Datenbank in einem hardwaregestützten sicheren Speicher liegen, damit die Verschlüsselung überhaupt einen Sinn ergibt. Auf iOS übernimmt das die Keychain, auf Android der Android Keystore, beide isolieren den Schlüssel vom regulären App-Speicher und schützen ihn zusätzlich durch Geräte-Biometrie oder den Sperrbildschirm-Code.

Beim allerersten Start generiert die App idealerweise einen kryptographisch zufälligen Schlüssel, etwa über eine sichere Zufallszahlengenerator-Bibliothek, und legt ihn direkt im Keychain beziehungsweise Keystore ab, statt ihn selbst zu verwalten. Ein vom Nutzer gewähltes Passwort als alleinige Schlüsselquelle ist riskant, weil schwache Passwörter die gesamte Verschlüsselung effektiv wertlos machen können.

5. Performance-Overhead realistisch einordnen

Der reine Verschlüsselungs- und Entschlüsselungsvorgang mit AES-256 ist auf aktueller Mobile-Hardware dank Hardware-Beschleunigung meist kaum spürbar, typischerweise im niedrigen einstelligen Prozentbereich gegenüber unverschlüsseltem SQLite bei einzelnen Leseoperationen. Der tatsächlich spürbare Overhead entsteht seltener durch die Kryptographie selbst als durch die zusätzliche HMAC-Prüfung pro Seite bei jedem Zugriff.

Bei sehr großen Bulk-Importen oder komplexen Migrationen mit tausenden Schreiboperationen in einer Transaktion kann der kumulierte Overhead spürbar werden, meist im Bereich von 5 bis 15 Prozent längerer Laufzeit. In der Praxis lohnt sich ein konkreter Benchmark mit realistischen Datenmengen der eigenen App, statt sich auf pauschale Herstellerangaben zu verlassen. Ein solcher Benchmark sollte auf einem älteren, repräsentativen Testgerät laufen, nicht nur auf einem aktuellen Flaggschiff-Smartphone, da genau dort spürbare Unterschiede am ehesten sichtbar werden.

6. Migration bestehender unverschlüsselter Datenbanken

Für Apps, die bereits produktiv mit unverschlüsseltem SQLite laufen, bietet SQLCipher eine explizite Migrationsroutine, die eine bestehende Klartext-Datenbank in eine neue verschlüsselte Datei kopiert, ohne dass Anwendungscode oder Datenmodell angepasst werden müssen. Dieser Schritt läuft idealerweise einmalig beim ersten Start nach einem App-Update im Hintergrund ab.

Während der Migration sollte die App den Nutzer nicht blockieren, sondern einen Ladezustand anzeigen, insbesondere bei größeren Datenbanken, bei denen der Kopiervorgang mehrere Sekunden dauern kann. Nach erfolgreicher Migration muss die alte, unverschlüsselte Datei sicher gelöscht werden, da sie sonst als ungeschützte Kopie derselben sensiblen Daten auf dem Gerät verbleibt.

7. Alternative Secure-Database-Ansätze im Vergleich

Neben SQLCipher existieren weitere Ansätze für sichere lokale Speicherung: Realm bietet mit seiner integrierten Verschlüsselung eine Alternative für Apps, die bereits Realm als Objektdatenbank nutzen, während op-sqlite in neueren Versionen ebenfalls eine SQLCipher-Integration mitbringt und dabei von der neuen React-Native-Architektur mit JSI profitiert.

Für einzelne sensible Werte statt ganzer Datenbanken bleibt reiner Secure-Storage über Keychain oder Keystore, etwa über react-native-keychain, weiterhin die richtige Wahl, weil er für kleine Key-Value-Paare wie Tokens optimiert ist. SQLCipher lohnt sich dagegen erst, sobald tatsächlich strukturierte, relationale Datensätze in größerem Umfang lokal verschlüsselt vorgehalten werden müssen.

8. Häufige Implementierungsfehler bei verschlüsselten Datenbanken

Ein verbreiteter Fehler ist, den Verschlüsselungsschlüssel zwar sicher zu generieren, ihn dann aber versehentlich in Absturzberichten oder Debug-Logs auszugeben, etwa beim Protokollieren des kompletten Verbindungsobjekts während der Entwicklung. Ein einziges übersehenes Log-Statement kann die gesamte Verschlüsselung praktisch wirkungslos machen.

Ebenso riskant ist es, denselben Schlüssel unverändert über App-Neuinstallationen hinweg zu verwenden, ohne bei einer Deinstallation den zugehörigen Keychain- beziehungsweise Keystore-Eintrag zuverlässig zu entfernen. Auf iOS überlebt ein Keychain-Eintrag standardmäßig eine Deinstallation, was bei einer Neuinstallation zu einer verwaisten Datenbank mit falschem oder inkonsistentem Schlüssel führen kann.

9. Checkliste für den produktiven Einsatz von SQLCipher

Vor dem produktiven Rollout lohnt sich eine kurze, konkrete Checkliste: Schlüssel wird ausschließlich im Keychain beziehungsweise Keystore erzeugt und gespeichert, niemals im Code oder in Umgebungsvariablen. Migrationslogik für Bestandsnutzer ist getestet, inklusive sicherem Löschen der alten Klartextdatei nach erfolgreicher Migration.

Ergänzend gehören ein dokumentierter Wiederherstellungsplan für den Fall eines verlorenen Schlüssels, etwa durch eine Neuinstallation ohne Backup, sowie ein realistischer Performance-Test mit produktionsnahen Datenmengen zur Checkliste. Ohne diesen letzten Schritt bleibt unklar, ob der Verschlüsselungs-Overhead auf schwächeren Geräten im Feld tatsächlich unauffällig bleibt. Sinnvoll ist außerdem, die Checkliste als festen Bestandteil des Code-Reviews für jede Änderung an der Datenbankschicht zu verankern, damit neue Migrationen oder Schema-Änderungen nicht versehentlich an der bestehenden Verschlüsselung vorbeigeschrieben werden.

10. Zusammenfassung

11. FAQ: Verschlüsselter lokaler Speicher: Das Wichtigste auf einen Blick