DuckDBs Verschlüsselungsfunktion für ruhende Daten

 (duckdb.org)
1 Punkte von GN⁺ 2025-11-22 | 1 Kommentare | Auf WhatsApp teilen
  • Ab DuckDB Version 1.4 wurde die Funktion Data-at-Rest Encryption hinzugefügt, mit der sich die gesamte Datenbankdatei per standardisierter AES-basierter Verschlüsselung schützen lässt
  • Unterstützte Algorithmen sind AES-GCM-256 und AES-CTR-256; GCM enthält dabei ein Authentifizierungs-Tag (tag) zur Überprüfung der Datenintegrität
  • Die Verschlüsselung gilt für Datenbankdatei, WAL (Write-Ahead Log) und temporäre Dateien und umfasst eine sichere Cache-Struktur für Schlüsselverwaltung und Speicherschutz
  • Es werden zwei Implementierungen bereitgestellt, OpenSSL und Mbed TLS; bei Verwendung von OpenSSL gibt es dank Hardwarebeschleunigung nahezu keinen Performanceverlust
  • Verschlüsselte DuckDB-Dateien bieten gleichzeitig Sicherheit und Portabilität und ermöglichen auch in Cloud- oder CDN-Umgebungen eine sichere Datenverteilung

Überblick über die Verschlüsselung

  • Seit DuckDB 1.4 kann die gesamte Datenbankdatei transparent verschlüsselt (Transparent Encryption) werden
    • Beim Speichern wird AES-GCM-256 oder AES-CTR-256 verwendet
    • AES-GCM berechnet Tags zur Integritätsprüfung, AES-CTR ist schneller, bietet aber keine Authentifizierung
  • AES ist ein symmetrischer Verschlüsselungsalgorithmus, bei dem derselbe Schlüssel für Ver- und Entschlüsselung verwendet wird
  • IV (Initialization Vector) und Nonce stellen sicher, dass derselbe Klartext in unterschiedlichen Chiffretext umgewandelt wird
  • Die Anforderungen des NIST-Standards werden noch nicht vollständig erfüllt

Interne Implementierungsstruktur in DuckDB

  • Der Haupt-Header der Datenbankdatei bleibt im Klartext und speichert ein Flag für die Verschlüsselung sowie Verschlüsselungsmetadaten
    • Zu den Metadaten gehören Datenbankkennung (salt), Informationen zum Verschlüsselungsalgorithmus und ein verschlüsselter Canary
  • Über eine Key Derivation Function (KDF) wird ein vom Nutzer eingegebener Schlüssel in einen sicheren 32-Byte-Schlüssel umgewandelt
    • Der abgeleitete Schlüssel wird in einem sicheren Cache gespeichert und nicht auf die Festplatte ausgelagert
    • Der ursprüngliche Schlüssel wird sofort aus dem Speicher entfernt
  • Datenblöcke werden standardmäßig in Einheiten von 256 KB gespeichert; bei der Verschlüsselung werden dem Block-Header Nonce/IV und Tag hinzugefügt, wodurch er sich um 40 Byte erweitert
    • Die Prüfsumme wird verschlüsselt gespeichert

Verschlüsselung des WAL (Write-Ahead Log)

  • Das WAL ist eine Logdatei für die Transaktionswiederherstellung; in DuckDB wird auf Eintragsebene verschlüsselt
    • Jedem Eintrag werden Nonce und Tag hinzugefügt und er wird per AES-GCM geschützt
    • Ein verschlüsselter WAL-Eintrag ist in der Reihenfolge Länge (Klartext) → Nonce → verschlüsselte Prüfsumme und Daten → Tag aufgebaut
  • Bei Datenbanken mit angegebenem Verschlüsselungsschlüssel wird die WAL-Verschlüsselung automatisch aktiviert

Verschlüsselung temporärer Dateien

  • Auch temporäre Dateien, die bei großen Operationen wie Sortierungen, Joins oder Window-Funktionen entstehen, werden automatisch verschlüsselt
    • Aktiviert wird dies beim Verbinden mit einer verschlüsselten Datenbank oder per Einstellung SET temp_file_encryption = true
    • DuckDB erzeugt intern einen temporären Schlüssel; bei Kollisionen ist eine Entschlüsselung nicht möglich
  • Temporäre Dateien haben die Erweiterung .tmp oder .block, Größeninformationen sind im Header enthalten
    • Auf Prüfsummen wird zur Reduzierung der Berechnungskosten verzichtet

Verwendung der Verschlüsselung

  • Es werden drei Vorgehensweisen unterstützt:
    1. Eine bestehende Datenbank verschlüsseln
    2. Eine neue verschlüsselte Datenbank erstellen
    3. Eine bestehende verschlüsselte Datenbank neu verschlüsseln
  • Beispielbefehl: 
    ATTACH 'encrypted.duckdb' AS encrypted (ENCRYPTION_KEY 'asdf');
COPY FROM DATABASE unencrypted TO encrypted;
  • Ob eine Datenbank verschlüsselt ist, lässt sich mit dem Befehl FROM duckdb_databases(); prüfen
  • Standardmäßig wird AES-GCM verwendet, bei Bedarf kann AES-CTR angegeben werden
  • Verschlüsselte Daten haben eine hohe Entropie (Entropy) und wirken wie Zufallsdaten

Implementierung und Performance

  • Um externe Abhängigkeiten gering zu halten, enthält DuckDB zwei Verschlüsselungsimplementierungen: Mbed TLS und OpenSSL
    • Mbed TLS bietet ohne Hardwarebeschleunigung eine geringere Performance; wegen einer entdeckten Schwachstelle im Zufallszahlengenerator wurde die Schreibfunktion deaktiviert (ab 1.4.1)
    • OpenSSL nutzt Hardwarebeschleunigung und einen sicheren Zufallszahlengenerator; beim Laden der Erweiterung httpfs wird automatisch darauf umgeschaltet
  • Ergebnisse von Performance-Tests:
    • Unverschlüsselte SUMMARIZE-Abfrage: 5,4 Sekunden
    • Mbed-TLS-Verschlüsselung: 6,2 Sekunden
    • OpenSSL-Verschlüsselung: 5,4 Sekunden (kein Performanceverlust)
  • Auch in TPC-H-Power/Throughput-Tests sind die Leistungsunterschiede bei aktivierter Verschlüsselung gering
    • Power@Size: 624,296 → 571,985
    • Throughput@Size: 450,409 → 145,353 (leichter Rückgang bei erhöhter Festplatten-I/O)

Fazit

  • Mit DuckDBs Data-at-Rest Encryption lässt sich die gesamte Datenbankdatei sicher schützen
  • Durch die Verschlüsselung von WAL und temporären Dateien sinkt auch in Cloud-Umgebungen das Risiko von Datenabfluss
  • Bei einer OpenSSL-basierten Implementierung entsteht nahezu kein Performanceverlust, sodass sich die Funktion auch in produktiven Umgebungen effizient nutzen lässt
  • Verschlüsselte DuckDB-Dateien eignen sich auch für die externe Verteilung über CDN & Co., während bestehende Funktionen wie das Speichern mehrerer Tabellen erhalten bleiben
  • Das DuckDB-Team will die Funktion künftig auf Basis von Nutzerfeedback weiter verbessern

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-11-22
Hacker-News-Kommentare

  • Die Empfindlichkeit von AES-GCM gegenüber Nonce-Wiederverwendung ist bei der Implementierung ein kniffliger Punkt
    In der Dokumentation wird das zwar erkannt, aber es wird keine Lösung geteilt
    Im Header ist eine 16-Byte-Nonce statt 12 Byte enthalten, und es ist nicht klar angegeben, welche Bytes zufällig sind, was verwirrend ist. Ich frage mich, ob ich etwas übersehen habe

    • Die Struktur verwendet einen statischen Schlüssel, erzeugt eine 12-Byte-Zufalls-Nonce, und für temporäre Puffer werden keine sitzungsbezogenen Schlüssel verwendet

  • Ich bin weiterhin überrascht, was das DuckDB-Team alles leistet
    Früher habe ich eine einfache Lösung gebaut, um DuckDB-Dateien mit OpenSSL zu verschlüsseln, aber bei der ersten Query dauerte die Ausführung doppelt so lange und verbrauchte auch viel Speicher
    DuckDB hingegen nutzt Verschlüsselung auf Seitenebene und die AES-Beschleunigung der CPU, sodass die Kosten für Lesen/Schreiben nahezu nicht ins Gewicht fallen

    • Ich frage mich, warum man nicht einfach LUKS verwendet
      Es nutzt Beschleunigung auf Kernel-Ebene und arbeitet für Anwendungen darüber transparent
      Wenn nicht mehrere Apps jeweils unterschiedliche ACLs und Schlüssel verwenden müssen, ist Verschlüsselung im DB-System selbst unnötig
    • Ehrlich gesagt finde ich nicht, dass die Arbeit von DuckDB auf einem „erstaunlichen“ Niveau ist
      Im Vergleich zu einfacher Voll-Datei-Verschlüsselung sieht es natürlich gut aus, aber das ist eine Implementierung auf grundlegendem Niveau
      Wir sollten selbst ebenfalls eine solche Qualitätsstufe anstreben
    • Letztlich liegt es an der Pipelining
      Im Vergleich zu Storage-I/O sind die Kosten der Verschlüsselung fast kostenlos

  • Ich frage mich, ob es außer MotherDuck ein Modell gibt, mit dem sich cloudbasiertes DuckDB für mehrere Benutzer gut betreiben lässt
    Ich suche nach einer Struktur, bei der mehrere Benutzer wie bei einer normalen DB gleichzeitig zugreifen können und dabei die Vorteile von DuckDB erhalten bleiben

    • Wenn man nur reines DuckDB verwendet, kann man einen Arrow-Flight-Server davor setzen oder die httpserver-Erweiterung verwenden
      Je nachdem, wo die .duckdb-Datei gespeichert wird (S3 vs. EFS), gibt es große Leistungsunterschiede
      DuckLake scheint aber die bessere Multiplayer-Option zu sein
      Wir verwenden DuckLake in unserem Produkt und speichern Analysetabellen auf schnellem Storage wie GCP Filestore, um Performance-Einbußen zu reduzieren
      Selbst innerhalb eines einzelnen DuckLake-Katalogs kann man mehrere Storage-Arten mischen, was flexibel ist
    • In letzter Zeit sieht man oft Beiträge über „DuckDB in Postgres“, das dürfte vermutlich die Form sein, die gesucht ist
    • GizmoSQL ist ebenfalls einen Blick wert

  • DuckDB war bisher nützlicher als die AI-Tools, die ich verwendet habe
    Ich mag LLMs, aber bei der tatsächlichen Arbeitseffizienz hat mir DuckDB viel mehr geholfen

  • Ich bin neugierig, wie Schlüssel indiziert werden
    Wird beim Suchen mit verschlüsselten Schlüsseln gesucht, oder wird pro Block entschlüsselt?

  • Es heißt zwar oft, die „SQLite-Verschlüsselungserweiterung sei ein kostenpflichtiges Add-on für 2000 Dollar“,
    aber SQLiteMultipleCiphers wird schon lange kostenlos angeboten
    Außerdem unterstützt Turso Database standardmäßig Verschlüsselung

    • Mich würde interessieren, wie man solche modifizierten SQLite-Versionen in Python oder Go zusammen mit Plugins baut und verwendet
      Der Link-Prozess scheint je nach Sprache knifflig zu sein
    • Es gibt auch SQLCipher
      Eine Lösung, die seit 2009 entwickelt wird und stabil funktioniert