SQLite3 Multiple Ciphers Logo

SQLite3 Multiple Ciphers

Das Projekt SQLite3MultipleCiphers implementiert eine Verschlüsselungserweiterung für SQLite mit Unterstützung für mehrere Verschlüsselungsalgorithmen.

license

Aktuelle SQLite3 Multiple Ciphers Version ist die aktuelle Version. Die API-Dokumentation kann online eingesehen werden. Die Komponente selbst ist in GitHub verfügbar:

SQLite3 encryption extension with support for multiple ciphers

C 582 97

Beschreibung

SQLite3 Multiple Ciphers ist eine Erweiterung der Public-Domain-Version von SQLite, die es Anwendungen ermöglicht, verschlüsselte Datenbankdateien zu lesen und zu schreiben. Derzeit werden 7 verschiedene Verschlüsselungsschemata unterstützt:

  • wxSQLite3: AES 128 Bit CBC - Kein HMAC
  • wxSQLite3: AES 256 Bit CBC - Kein HMAC
  • sqleet: ChaCha20 - Poly1305 HMAC (Standard-Verschlüsselungsschema)
  • SQLCipher: AES 256 Bit CBC - SHA1/SHA256/SHA512 HMAC
  • System.Data.SQLite: RC4
  • Ascon: Ascon-128 v1.2
  • AEGIS: AEGIS Familie authentifizierter Verschlüsselungsalgorithmen

In der Vergangenheit war die Verschlüsselungserweiterung SQLite im Projekt wxSQLite3 enthalten, das einen schlanken SQLite3-Datenbank-Wrapper für wxWidgets-basierte Anwendungen bereitstellt.

Im Laufe der Zeit hatten mehrere Entwickler um eine eigenständige Version der Verschlüsselungserweiterung wxSQLite3 gebeten. Ursprünglich war geplant, den Trennungsprozess bereits 2019 durchzuführen, aber aufgrund persönlicher Umstände musste er um mehrere Monate verschoben werden. Vielleicht war das aber gar nicht so schlecht, denn am 7. Februar 2020 gab es Änderungen am öffentlichen SQLite-Code: „Vereinfachung des Codes durch Entfernen der nicht unterstützten und undokumentierten Kompilierungsoption SQLITE_HAS_CODEC“. Diese Änderungen traten mit der Veröffentlichung der SQLite-Version 3.32.0 am 22. Mai 2020 in Kraft. Infolgedessen werden alle vorhandenen SQLite-Verschlüsselungserweiterungen die SQLite-Version 3.32.0 und spätere Versionen nicht ohne Weiteres unterstützen können.

Ende Februar 2020 wurde mit der Arbeit an einer neuen Implementierung einer SQLite-Verschlüsselungserweiterung begonnen, die SQLite 3.32.0 und höher unterstützt. Der neue Ansatz basiert auf der VFS-Funktion von SQLite. Dieser Ansatz hat Vor- und Nachteile. Einerseits ist der Code weniger eng mit SQLite selbst gekoppelt, andererseits ist der Zugriff auf die internen Datenstrukturen von SQLite komplexer.

Technische Details

SQLite3 Multiple Ciphers verschlüsselt die gesamte Datenbankdatei, sodass eine verschlüsselte SQLite-Datenbankdatei für einen Außenstehenden wie weißes Rauschen aussieht. Nicht nur die Datenbankdateien selbst, sondern auch die Journal-Dateien werden verschlüsselt.

Notiz

SQLite3 Multiple Ciphers hat mehr oder weniger die gleichen Einschränkungen wie die offizielle SQLite Encryption Extension (SEE):

  1. TEMP-Tabellen werden nicht verschlüsselt.
  2. In-Memory-Datenbanken (:memory:) werden nicht verschlüsselt.
  3. Die Bytes 16 bis 23 der Datenbankdatei enthalten Header-Informationen, die in der Regel nicht verschlüsselt werden.

Um die Sicherheit nicht durch das Speichern temporärer Daten auf der Festplatte zu gefährden, ist es sehr wichtig, alle temporären Daten im Speicher zu behalten. Daher wird dringend empfohlen, die Kompilierungsoption SQLITE_TEMP_STORE=2 (die in den aktuellen Build-Dateien standardmäßig verwendet wird) (oder sogar SQLITE_TEMP_STORE=3, wodurch temporäre Daten bedingungslos in den Speicher verschoben werden) zu verwenden. PRAGMA temp_store=MEMORY; sollte für verschlüsselte Datenbanken verwendet werden, wenn die Kompilierungsoption SQLITE_TEMP_STORE nicht auf den Wert 2 oder 3 gesetzt wurde.

Zusätzlich zum Lesen und Schreiben verschlüsselter Datenbankdateien kann SQLite3 Multiple Ciphers auch normale Datenbankdateien lesen und schreiben, die mit einer Public-Domain-Version von SQLite erstellt wurden. Anwendungen können die Anweisung ATTACH von SQLite verwenden, um gleichzeitig eine Verbindung zu zwei oder mehr verschlüsselten und/oder unverschlüsselten Datenbankdateien herzustellen. Für jede Datenbankdatei kann ein anderes Verschlüsselungsschema verwendet werden.

Historie

Eine detaillierte Versionshistorie findet sich im Änderungs-Log.

0%