La fonctionnalité de chiffrement des données au repos de DuckDB

 (duckdb.org)
1 points par GN⁺ 2025-11-22 | 1 commentaires | Partager sur WhatsApp
  • Depuis la version 1.4 de DuckDB, une fonctionnalité de chiffrement des données au repos (Data-at-Rest Encryption) a été ajoutée, permettant de protéger l’intégralité du fichier de base de données avec un chiffrement standard basé sur AES
  • Les algorithmes pris en charge sont AES-GCM-256 et AES-CTR-256 ; parmi eux, GCM inclut un tag d’authentification pour la vérification de l’intégrité des données
  • Le chiffrement s’applique au fichier de base de données, au WAL (Write-Ahead Log) et aux fichiers temporaires, et inclut une structure de cache sécurisé pour la gestion des clés et la protection en mémoire
  • Deux implémentations sont proposées, OpenSSL et Mbed TLS ; avec OpenSSL, grâce à l’accélération matérielle, la baisse de performances est quasiment nulle
  • Les fichiers DuckDB chiffrés assurent à la fois sécurité et portabilité, ce qui permet une distribution sûre des données dans le cloud ou via un CDN

Aperçu du chiffrement

  • À partir de DuckDB 1.4, il est possible de chiffrer de manière transparente (Transparent Encryption) l’intégralité du fichier de base de données
    • Le chiffrement lors de l’écriture utilise AES-GCM-256 ou AES-CTR-256
    • AES-GCM calcule un tag pour la vérification de l’intégrité, tandis qu’AES-CTR est plus rapide mais ne fournit pas d’authentification
  • AES est un algorithme de chiffrement symétrique, qui utilise la même clé pour le chiffrement et le déchiffrement
  • L’utilisation d’un IV (Initialization Vector) et d’un nonce garantit qu’un même texte en clair est transformé en des textes chiffrés différents
  • Les exigences du standard NIST ne sont pas encore entièrement satisfaites

Structure de l’implémentation interne de DuckDB

  • L’en-tête principal du fichier de base de données reste en clair et stocke un indicateur signalant si le chiffrement est activé ainsi que les métadonnées de chiffrement
    • Ces métadonnées incluent l’identifiant de la base de données (salt), les informations sur l’algorithme de chiffrement et un canary chiffré
  • Une fonction de dérivation de clé (KDF) transforme la clé fournie par l’utilisateur en une clé sécurisée de 32 octets
    • La clé dérivée est stockée dans un cache sécurisé et n’est pas échangée sur disque
    • La clé d’origine est immédiatement effacée de la mémoire
  • Les blocs de données sont stockés par défaut en unités de 256 KB et, lors du chiffrement, un nonce/IV et un tag sont ajoutés à l’en-tête du bloc, ce qui l’étend à 40 octets
    • La somme de contrôle est stockée sous forme chiffrée

Chiffrement du WAL (Write-Ahead Log)

  • Le WAL est un fichier journal utilisé pour la récupération des transactions ; dans DuckDB, le chiffrement est effectué entrée par entrée
    • Chaque entrée reçoit un nonce et un tag pour être protégée en AES-GCM
    • Une entrée WAL chiffrée est structurée dans l’ordre suivant : longueur (texte en clair) → nonce → somme de contrôle chiffrée et données → tag
  • Dans une base de données pour laquelle une clé de chiffrement est définie, le chiffrement du WAL est activé automatiquement

Chiffrement des fichiers temporaires

  • Les fichiers temporaires créés lors d’opérations volumineuses comme les tris, les jointures ou les fonctions de fenêtre sont eux aussi chiffrés automatiquement
    • Cette fonction s’active lorsqu’on connecte une base de données chiffrée ou via le paramètre SET temp_file_encryption = true
    • DuckDB génère en interne une clé temporaire ; en cas de conflit, le déchiffrement devient impossible
  • Les fichiers temporaires portent l’extension .tmp ou .block, et les informations de taille sont incluses dans l’en-tête
    • La somme de contrôle est omise pour réduire le coût de calcul

Utilisation du chiffrement

  • Trois modes sont pris en charge :
    1. chiffrer une base de données existante
    2. créer une nouvelle base de données chiffrée
    3. rechiffrer une base de données déjà chiffrée
  • Exemple de commande : 
    ATTACH 'encrypted.duckdb' AS encrypted (ENCRYPTION_KEY 'asdf');
COPY FROM DATABASE unencrypted TO encrypted;
  • Il est possible de vérifier si le chiffrement est activé avec la commande FROM duckdb_databases();
  • L’algorithme de chiffrement par défaut est AES-GCM, avec possibilité de choisir AES-CTR si nécessaire
  • Les données chiffrées présentent une entropie élevée et ressemblent à des données aléatoires

Implémentation et performances

  • Afin de minimiser les dépendances externes, DuckDB inclut deux implémentations du chiffrement : Mbed TLS et OpenSSL
    • Mbed TLS offre des performances plus faibles faute d’accélération matérielle et, à la suite de la découverte d’une vulnérabilité dans le générateur de nombres aléatoires, la fonction d’écriture a été désactivée (à partir de la 1.4.1)
    • OpenSSL utilise l’accélération matérielle et un générateur de nombres aléatoires sûr, et la bascule s’effectue automatiquement lors du chargement de l’extension httpfs
  • Résultats des tests de performance :
    • Requête SUMMARIZE non chiffrée : 5,4 secondes
    • Chiffrement Mbed TLS : 6,2 secondes
    • Chiffrement OpenSSL : 5,4 secondes (aucune perte de performances)
  • Dans les tests TPC-H Power/Throughput également, l’impact du chiffrement sur les performances reste minime
    • Power@Size : 624,296 → 571,985
    • Throughput@Size : 450,409 → 145,353 (légère baisse lorsque les E/S disque augmentent)

Conclusion

  • La fonction de chiffrement des données au repos de DuckDB permet de protéger en toute sécurité l’intégralité du fichier de base de données
  • Le WAL et les fichiers temporaires sont eux aussi chiffrés, ce qui réduit le risque de fuite de données même dans le cloud
  • Avec l’implémentation basée sur OpenSSL, la perte de performances est presque nulle, ce qui permet une utilisation efficace en environnement réel
  • Les fichiers DuckDB chiffrés se prêtent aussi à une distribution externe, notamment via un CDN, tout en conservant les fonctionnalités existantes comme le stockage multi-tables
  • L’équipe DuckDB prévoit d’améliorer la fonctionnalité à l’avenir en s’appuyant sur les retours des utilisateurs

À lire aussi

1 commentaires

 
GN⁺ 2025-11-22
Avis Hacker News

  • La sensibilité à la réutilisation de nonce d’AES-GCM est un point délicat en implémentation
    La documentation en est consciente, mais ne partage pas la solution retenue
    L’en-tête contient un nonce de 16 octets au lieu de 12, et il n’est pas précisé quels octets sont aléatoires, ce qui prête à confusion. Je me demande si j’ai raté quelque chose

    • La structure utilise une clé statique, génère un nonce aléatoire de 12 octets et n’emploie pas de clé par session pour les tampons temporaires

  • Je continue d’être impressionné par ce que réalise l’équipe DuckDB
    J’avais auparavant créé une solution simple pour chiffrer des fichiers DuckDB avec OpenSSL, mais la première requête prenait 2 fois plus de temps et consommait beaucoup de mémoire
    DuckDB, à l’inverse, exploite le chiffrement par page et l’accélération AES du CPU, au point que le coût en lecture/écriture est presque nul

    • Je me demande pourquoi ne pas simplement utiliser LUKS
      Il exploite l’accélération au niveau du noyau et fonctionne de façon transparente pour les applications au-dessus
      Sauf si plusieurs applications doivent chacune utiliser des ACL et des clés différentes, le chiffrement intégré à la base semble inutile
    • Honnêtement, je ne dirais pas que le travail de DuckDB est “impressionnant”
      Comparé à une simple approche de chiffrement du fichier entier, cela paraît forcément meilleur, mais cela reste une implémentation de base
      Nous devrions nous-mêmes viser ce niveau de qualité comme standard minimal
    • Au final, c’est surtout grâce au pipelining
      Comparé aux entrées/sorties du stockage, le coût du chiffrement est quasiment gratuit

  • Je me demande s’il existe, en dehors de MotherDuck, un bon modèle de DuckDB cloud multi-utilisateur
    Je cherche une architecture où plusieurs utilisateurs peuvent accéder en même temps, comme avec une base classique, tout en conservant les avantages de DuckDB

    • Avec DuckDB seul, on peut mettre un serveur Arrow Flight devant, ou utiliser l’extension httpserver
      Les performances varient beaucoup selon l’endroit où le fichier .duckdb est stocké (S3 vs EFS)
      Mais DuckLake semble être une meilleure option multijoueur
      Nous utilisons DuckLake dans notre produit, et pour limiter la baisse de performances, nous stockons les tables analytiques sur un stockage rapide comme GCP Filestore
      On peut aussi mélanger plusieurs types de stockage dans un même catalogue DuckLake, ce qui apporte de la flexibilité
    • On voit souvent passer en ce moment des articles sur “DuckDB dans Postgres”, et c’est probablement ce que vous cherchez
    • GizmoSQL mérite aussi un coup d’œil

  • DuckDB m’a été plus utile que tous les outils d’IA que j’ai utilisés jusqu’ici
    J’aime les LLM, mais en efficacité réelle au travail, DuckDB m’a beaucoup plus aidé

  • Je me demande comment est gérée l’indexation des clés
    Je voudrais savoir si la recherche se fait sur les clés chiffrées, ou s’il faut déchiffrer bloc par bloc

  • On entend dire que “l’extension de chiffrement de SQLite est un add-on payant à 2000 dollars”, mais
    SQLiteMultipleCiphers est proposé gratuitement depuis longtemps
    De plus, Turso Database prend en charge le chiffrement par défaut

    • En pratique, je me demande comment utiliser ces variantes de SQLite compilées avec des plugins en Python ou en Go
      Le processus de linkage semble délicat selon le langage
    • Il y a aussi SQLCipher
      C’est une solution développée depuis 2009 qui fonctionne de manière stable