Recurso de criptografia de dados em repouso do DuckDB

• A partir da versão 1.4 do DuckDB, foi adicionado o recurso de criptografia de dados em repouso (Data-at-Rest Encryption), permitindo proteger todo o arquivo do banco de dados com criptografia padrão baseada em AES
• Os algoritmos compatíveis são AES-GCM-256 e AES-CTR-256; entre eles, o GCM inclui uma tag de autenticação para verificação da integridade dos dados
• A criptografia é aplicada ao arquivo do banco de dados, WAL (Write-Ahead Log) e arquivos temporários, e inclui uma estrutura de cache segura para gerenciamento de chaves e proteção da memória
• São fornecidas duas implementações, OpenSSL e Mbed TLS; ao usar OpenSSL, quase não há perda de desempenho graças à aceleração por hardware
• Arquivos DuckDB criptografados garantem ao mesmo tempo segurança e portabilidade, permitindo distribuição segura de dados mesmo em ambientes de nuvem ou CDN

---

Visão geral da criptografia

• Desde o DuckDB 1.4, é possível criptografar de forma transparente (Transparent Encryption) todo o arquivo do banco de dados
  • Ao gravar, é usada criptografia AES-GCM-256 ou AES-CTR-256
  • O AES-GCM calcula uma tag para verificação de integridade, enquanto o AES-CTR é mais rápido, mas não oferece autenticação
• O AES é um algoritmo de criptografia simétrica, no qual a criptografia e a descriptografia usam a mesma chave
• IV (Initialization Vector) e nonce são usados para garantir que o mesmo texto em claro seja convertido em textos cifrados diferentes
• Os requisitos do padrão NIST ainda não são totalmente atendidos

Estrutura de implementação interna do DuckDB

• O cabeçalho principal do arquivo do banco de dados permanece em texto claro e armazena um flag que indica se há criptografia, além de metadados de criptografia
  • Os metadados incluem identificador do banco de dados (salt), informações sobre o algoritmo de criptografia e um canary criptografado
• Por meio de uma função de derivação de chave (KDF), a chave informada pelo usuário é convertida em uma chave segura de 32 bytes
  • A chave derivada é armazenada em um cache seguro e não é transferida para swap em disco
  • A chave original é apagada imediatamente da memória
• Os blocos de dados são armazenados por padrão em unidades de 256 KB e, quando criptografados, o cabeçalho do bloco recebe nonce/IV e tag, expandindo para 40 bytes
  • O checksum é armazenado de forma criptografada

Criptografia do WAL (Write-Ahead Log)

• O WAL é um arquivo de log para recuperação de transações e, no DuckDB, a criptografia é feita por item
  • Cada item recebe nonce e tag para proteção com AES-GCM
  • Um item de WAL criptografado é composto na ordem: tamanho (texto claro) → nonce → checksum criptografado e dados → tag
• Em bancos de dados nos quais uma chave de criptografia foi definida, a criptografia do WAL é ativada automaticamente

Criptografia de arquivos temporários

• Arquivos temporários gerados em operações de grande volume, como ordenação, join e funções de janela, também são criptografados automaticamente
  • É ativada ao conectar um banco de dados criptografado ou ao definir SET temp_file_encryption = true
  • O DuckDB gera internamente uma chave temporária; em caso de colisão, a descriptografia se torna impossível
• Os arquivos temporários têm extensão .tmp ou .block, e as informações de tamanho são incluídas no cabeçalho
  • O checksum é omitido para reduzir o custo de processamento

Como usar a criptografia

• Há suporte para três formas:
  1. Criptografar um banco de dados existente
  2. Criar um novo banco de dados criptografado
  3. Recriptografar um banco de dados já criptografado
• Exemplo de comando:

  ATTACH 'encrypted.duckdb' AS encrypted (ENCRYPTION_KEY 'asdf');
  COPY FROM DATABASE unencrypted TO encrypted;
  

• É possível verificar se há criptografia com o comando FROM duckdb_databases();
• O algoritmo de criptografia padrão é AES-GCM e, se necessário, pode-se especificar AES-CTR
• Dados criptografados têm alta entropia (Entropy) e parecem dados aleatórios

Implementação e desempenho

• Para minimizar dependências externas, o DuckDB inclui duas implementações de criptografia: Mbed TLS e OpenSSL
  • O Mbed TLS tem desempenho menor por não usar aceleração por hardware e, após a descoberta de uma vulnerabilidade no gerador de números aleatórios, a função de escrita foi desativada (a partir da 1.4.1)
  • O OpenSSL usa aceleração por hardware e um gerador de números aleatórios seguro, com troca automática ao carregar a extensão httpfs
• Resultados do teste de desempenho:
  • Query SUMMARIZE sem criptografia: 5,4 segundos
  • Criptografia com Mbed TLS: 6,2 segundos
  • Criptografia com OpenSSL: 5,4 segundos (sem perda de desempenho)
• Nos testes TPC-H Power/Throughput, a diferença de desempenho ao usar criptografia foi mínima
  • Power@Size: 624,296 → 571,985
  • Throughput@Size: 450,409 → 145,353 (pequena queda quando o I/O de disco aumenta)

Conclusão

• O recurso de criptografia de dados em repouso do DuckDB permite proteger com segurança todo o arquivo do banco de dados
• Com criptografia também no WAL e nos arquivos temporários, o risco de vazamento de dados diminui até mesmo em ambientes de nuvem
• Com a implementação baseada em OpenSSL, quase não há perda de desempenho, permitindo uso eficiente também em ambientes de produção
• Arquivos DuckDB criptografados também são adequados para distribuição externa, como via CDN, mantendo funções existentes, como armazenamento de múltiplas tabelas
• A equipe do DuckDB pretende aprimorar o recurso no futuro com base no feedback dos usuários

[GN⁺]

Comentários no Hacker News

• A sensibilidade à reutilização de nonce no AES-GCM é uma parte complicada da implementação
  A documentação demonstra estar ciente disso, mas não compartilhou a forma de resolver
  O cabeçalho inclui um nonce de 16 bytes em vez de 12 bytes, e não fica claro quais bytes são aleatórios, o que causa confusão. Gostaria de saber se deixei passar algo

  • A estrutura usa uma chave estática, gera um nonce aleatório de 12 bytes e não usa uma chave por sessão para buffers temporários

• Continuo me surpreendendo com o trabalho da equipe do DuckDB
  No passado, criei uma solução simples para criptografar arquivos do DuckDB com OpenSSL, mas a primeira consulta levava o dobro do tempo de execução e também consumia muita memória
  Já o DuckDB usa criptografia por página e a aceleração AES da CPU, então o custo de leitura/escrita é praticamente nulo

  • Fico me perguntando por que simplesmente não usar LUKS
    Ele aproveita a aceleração no nível do kernel e funciona de forma transparente para as aplicações acima
    A menos que vários apps precisem usar ACLs e chaves diferentes, a criptografia no próprio banco é desnecessária
  • Sinceramente, não acho que o trabalho do DuckDB seja de um nível “surpreendente”
    Comparado com uma abordagem simples de criptografia do arquivo inteiro, claro que parece melhor, mas isso é uma implementação de nível básico
    Nós mesmos deveríamos mirar esse nível de qualidade
  • No fim, isso se deve ao pipelining
    Em comparação com a E/S de armazenamento, o custo da criptografia é quase gratuito

• Gostaria de saber se existe, além do MotherDuck, algum modelo que opere bem um DuckDB em nuvem para múltiplos usuários
  Estou procurando uma estrutura em que vários usuários possam acessar ao mesmo tempo, como em um banco comum, sem perder as vantagens do DuckDB

  • Se usar apenas DuckDB puro, dá para colocar um servidor Arrow Flight na frente ou usar a extensão httpserver
    O desempenho varia bastante dependendo de onde o arquivo .duckdb é armazenado (S3 vs EFS)
    Mas o DuckLake parece ser uma opção melhor para uso multiplayer
    Nós usamos o DuckLake no produto e, para reduzir a perda de desempenho, armazenamos as tabelas analíticas em armazenamento rápido, como o GCP Filestore
    É flexível porque permite misturar vários tipos de armazenamento dentro de um único catálogo DuckLake
  • Tenho visto muitos textos ultimamente sobre “DuckDB dentro do Postgres”, e provavelmente é esse o formato que você quer
  • O GizmoSQL também vale a pena conferir

• O DuckDB foi mais útil do que as ferramentas de IA que usei até agora
  Eu gosto de LLMs, mas, em eficiência real no trabalho, o DuckDB ajudou muito mais

• Tenho curiosidade sobre a forma de indexação das chaves
  Quero saber se, na busca, as chaves são encontradas ainda criptografadas ou se a descriptografia é feita bloco por bloco

• Falam que a “extensão de criptografia do SQLite é um add-on pago de 2 mil dólares”, mas
  o SQLiteMultipleCiphers já é oferecido gratuitamente há muito tempo
  Além disso, o Turso Database oferece suporte a criptografia por padrão

  • Na prática, tenho curiosidade sobre como usar esses SQLite modificados em Python ou Go, compilando junto com plugins
    O processo de linkedição parece complicado em cada linguagem
  • Também existe o SQLCipher
    É uma solução desenvolvida desde 2009 e que funciona de forma estável