Fitur enkripsi data tersimpan di DuckDB

 (duckdb.org)
1 poin oleh GN⁺ 2025-11-22 | 1 komentar | Bagikan ke WhatsApp
  • Mulai DuckDB versi 1.4, ditambahkan fitur enkripsi data tersimpan (Data-at-Rest Encryption), sehingga seluruh file database dapat dilindungi dengan enkripsi standar berbasis AES
  • Algoritme yang didukung adalah AES-GCM-256 dan AES-CTR-256; di antaranya, GCM menyertakan tag autentikasi untuk verifikasi integritas data
  • Enkripsi diterapkan pada file database, WAL (Write-Ahead Log), dan file sementara, serta mencakup struktur cache aman untuk pengelolaan kunci dan perlindungan memori
  • Tersedia dua implementasi, yaitu OpenSSL dan Mbed TLS; saat menggunakan OpenSSL, akselerasi perangkat keras membuat penurunan performa hampir tidak terasa
  • File DuckDB yang terenkripsi dapat sekaligus memastikan keamanan dan portabilitas, sehingga distribusi data tetap aman bahkan di lingkungan cloud atau CDN

Gambaran umum enkripsi

  • Sejak DuckDB 1.4, seluruh file database dapat dienkripsi secara transparan (Transparent Encryption)
    • Saat disimpan, digunakan enkripsi AES-GCM-256 atau AES-CTR-256
    • AES-GCM menghitung tag untuk verifikasi integritas, sedangkan AES-CTR lebih cepat tetapi tidak memiliki fungsi autentikasi
  • AES adalah algoritme enkripsi kunci simetris, di mana enkripsi dan dekripsi dilakukan dengan kunci yang sama
  • IV (Initialization Vector) dan nonce digunakan untuk memastikan plaintext yang sama berubah menjadi ciphertext yang berbeda
  • Persyaratan standar NIST masih belum sepenuhnya dipenuhi

Struktur implementasi internal DuckDB

  • Header utama file database tetap dalam bentuk plaintext, dan menyimpan flag yang menunjukkan apakah enkripsi digunakan serta metadata enkripsi
    • Metadata mencakup identifier database (salt), informasi algoritme enkripsi, dan canary terenkripsi
  • Melalui fungsi derivasi kunci (KDF), kunci yang dimasukkan pengguna diubah menjadi kunci aman 32 byte
    • Kunci turunan disimpan dalam cache aman sehingga tidak di-swap ke disk
    • Kunci asli langsung dihapus dari memori
    Iklan
  • Blok data disimpan dengan unit dasar 256KB; saat dienkripsi, nonce/IV dan tag ditambahkan ke header blok sehingga ukurannya bertambah 40 byte
    • Checksum disimpan dalam keadaan terenkripsi

Enkripsi WAL (Write-Ahead Log)

  • WAL adalah file log untuk pemulihan transaksi, dan di DuckDB dienkripsi per entri
    • Setiap entri ditambahkan nonce dan tag agar dilindungi dengan metode AES-GCM
    • Entri WAL terenkripsi disusun dalam urutan panjang (plaintext) → nonce → checksum dan data terenkripsi → tag
  • Pada database yang memiliki kunci enkripsi, enkripsi WAL aktif secara otomatis

Enkripsi file sementara

  • File sementara yang dibuat saat operasi besar seperti sort, join, dan window function juga dienkripsi secara otomatis
    • Aktif saat menghubungkan database terenkripsi atau ketika pengaturan SET temp_file_encryption = true digunakan
    • DuckDB secara internal membuat kunci sementara; jika terjadi benturan, dekripsi tidak dimungkinkan
    Iklan
  • File sementara memiliki ekstensi .tmp atau .block, dan informasi ukuran disertakan di header
    • Checksum dihilangkan untuk mengurangi biaya komputasi

Cara menggunakan enkripsi

  • Mendukung tiga cara:
    1. Mengenkripsi database yang sudah ada
    2. Membuat database terenkripsi baru
    3. Mengenkripsi ulang database terenkripsi yang sudah ada
  • Contoh perintah: 
    ATTACH 'encrypted.duckdb' AS encrypted (ENCRYPTION_KEY 'asdf');
COPY FROM DATABASE unencrypted TO encrypted;
  • Status enkripsi dapat diperiksa dengan perintah FROM duckdb_databases();
  • Algoritme enkripsi default adalah AES-GCM, dan bila perlu dapat ditentukan sebagai AES-CTR
  • Data terenkripsi memiliki entropi (Entropy) tinggi sehingga tampak seperti data acak
Iklan

Implementasi dan performa

  • Untuk meminimalkan dependensi eksternal, DuckDB menyertakan dua implementasi enkripsi: Mbed TLS dan OpenSSL
    • Mbed TLS memiliki performa lebih rendah karena akselerasi perangkat keras tidak aktif, dan karena ditemukannya kerentanan pada generator angka acak, fitur tulis dinonaktifkan (sejak 1.4.1)
    • OpenSSL menggunakan akselerasi perangkat keras dan generator angka acak yang aman, dan akan beralih otomatis saat ekstensi httpfs dimuat
  • Hasil uji performa:
    • Kueri SUMMARIZE tanpa enkripsi: 5,4 detik
    • Enkripsi Mbed TLS: 6,2 detik
    • Enkripsi OpenSSL: 5,4 detik (tanpa penurunan performa)
  • Pada pengujian TPC-H Power/Throughput juga, perbedaan performa sangat kecil saat enkripsi digunakan
    • Power@Size: 624,296 → 571,985
    • Throughput@Size: 450,409 → 145,353 (sedikit menurun saat I/O disk meningkat)

Kesimpulan

  • Dengan fitur enkripsi data tersimpan DuckDB, seluruh file database dapat dilindungi secara aman
  • Karena WAL dan file sementara juga dienkripsi, risiko kebocoran data di lingkungan cloud ikut berkurang
  • Dengan implementasi berbasis OpenSSL, hampir tidak ada kehilangan performa, sehingga tetap efisien digunakan di lingkungan produksi
  • File DuckDB terenkripsi juga cocok untuk distribusi eksternal seperti CDN, sambil tetap mempertahankan fitur yang ada seperti penyimpanan multi-tabel
  • Tim DuckDB berencana terus meningkatkan fitur ini berdasarkan umpan balik pengguna

Bacaan terkait

1 komentar

 
GN⁺ 2025-11-22
Komentar Hacker News

  • Sensitivitas terhadap reuse nonce pada AES-GCM adalah bagian yang rumit saat implementasi
    Dokumentasinya menyadari hal ini, tetapi tidak membagikan cara mengatasinya
    Header berisi nonce 16 byte, bukan 12 byte, dan tidak jelas byte mana yang acak, sehingga membingungkan. Saya penasaran apakah ada bagian yang saya lewatkan

    • Strukturnya menggunakan kunci statis, menghasilkan nonce acak 12 byte, dan tidak menggunakan kunci per sesi untuk buffer sementara

  • Saya terus terkesan dengan capaian tim DuckDB
    Dulu saya membuat solusi sederhana untuk mengenkripsi file DuckDB dengan OpenSSL, tetapi saat kueri pertama waktu eksekusinya 2x lebih lama dan penggunaan memorinya juga besar
    Sebaliknya, DuckDB menggunakan enkripsi per halaman dan akselerasi AES dari CPU sehingga biaya baca/tulis hampir nyaris tidak ada

    • Saya penasaran kenapa tidak pakai LUKS saja
      Di level kernel, ia memanfaatkan akselerasi dan bekerja transparan bagi aplikasi di atasnya
      Kecuali jika beberapa aplikasi harus memakai ACL dan kunci yang berbeda-beda, enkripsi di level DB sebenarnya tidak diperlukan
    • Sejujurnya, saya tidak merasa pekerjaan DuckDB sampai level “menakjubkan”
      Dibandingkan metode enkripsi satu file penuh yang sederhana, hasilnya tentu terlihat lebih baik, tetapi ini adalah implementasi tingkat dasar
      Kita sendiri juga seharusnya menargetkan kualitas pada level seperti ini
    • Pada akhirnya ini berkat pipelining
      Dibandingkan I/O penyimpanan, biaya enkripsi nyaris gratis

  • Saya penasaran apakah ada model lain selain MotherDuck yang menjalankan DuckDB berbasis cloud untuk banyak pengguna dengan baik
    Saya sedang mencari arsitektur yang memungkinkan banyak pengguna mengaksesnya secara bersamaan seperti DB biasa sambil tetap memanfaatkan keunggulan DuckDB

    • Jika hanya memakai DuckDB murni, Anda bisa menaruh server Arrow Flight di depan atau memakai ekstensi httpserver
      Performa sangat berbeda tergantung di mana file .duckdb disimpan (S3 vs EFS)
      Namun DuckLake tampaknya opsi multipemain yang lebih baik
      Kami menggunakan DuckLake di produk kami, dan untuk mengurangi penurunan performa, tabel analitik disimpan di storage cepat seperti GCP Filestore
      Bahkan dalam satu katalog DuckLake, beberapa metode penyimpanan bisa dicampur sehingga fleksibel
    • Belakangan saya sering melihat tulisan tentang “DuckDB di dalam Postgres”, mungkin itu bentuk yang Anda cari
    • GizmoSQL juga layak dilihat

  • DuckDB sejauh ini lebih berguna daripada alat AI yang pernah saya pakai
    Saya suka LLM, tetapi untuk efisiensi kerja nyata, DuckDB jauh lebih membantu

  • Saya penasaran dengan cara pemrosesan indeks untuk kunci
    Saya ingin tahu apakah saat pencarian kunci dicari dalam keadaan terenkripsi, atau apakah dekripsi dilakukan per blok

  • Ada yang bilang “ekstensi enkripsi SQLite adalah add-on berbayar seharga 2000 dolar”,
    tetapi SQLiteMultipleCiphers sudah lama tersedia gratis
    Selain itu, Turso Database juga mendukung enkripsi secara bawaan

    • Saya penasaran bagaimana cara build varian SQLite seperti ini di Python atau Go bersama plugin
      Proses linking-nya tampak rumit untuk tiap bahasa
    • Ada juga SQLCipher
      Ini adalah solusi yang sudah dikembangkan sejak 2009 dan bekerja stabil