Parte V · 2 — Dados e chaves

draft

Proteger o que se move é metade do problema; proteger o que repousa — e as chaves que o protegem — é a outra. O elo mais fraco da criptografia aplicada é quase sempre a gestão de chaves, não o algoritmo.


2.1 Cifra de arquivos: kzip

O kzip (engines/sdk/kzip) é a cifra de arquivos da Stack. Usa AEAD (Parte II) — confidencialidade e integridade juntas — e está ganhando modo destinatário: cifrar para a chave pública de alguém (encapsulamento assimétrico, Parte II), para que só o dono da chave privada abra. É o padrão híbrido em miniatura: assimétrica encapsula a chave, simétrica cifra o conteúdo.


2.2 O ciclo de vida das chaves

Uma chave nasce, vive, gira e morre. A Stack trata cada fase:

O ciclo de vida de uma chave: gerar, guardar, derivar, rotacionar, fazer backup

  • Geração — sempre do CSPRNG do sistema (Parte II);

    nunca de um RNG comum (há guard anti-padrão no SDK).

  • Armazenamento — chaves-mestras em HSM (PKCS#11) quando possível; na

    ausência, cifradas em disco com passphrase em chave de hardware (YubiKey) + backup em papel no cofre.

  • Derivação — chaves por-deployment vêm de HKDF sobre a master — uma raiz,

    muitas subchaves, sem reusar segredo.

  • Rotação — cadência por tipo: certificado TLS a cada 90 dias, JWT do Koder ID

    a cada 6 meses (com 30 dias de sobreposição), LUKS a cada 5 anos. A raiz do HSM nunca gira (comprometer = reprovisionar tudo).

  • Backup — chaves de banco divididas por Shamir 3-de-5 entre custódios:

    preciso de 3 dos 5 para reconstruir, nenhum sozinho basta.

O Shamir secret sharing é a ideia elegante aqui: um segredo vira n partes tais que k delas o reconstroem e k–1 não revelam nada. Resiliência sem ponto único de confiança.


2.3 Aleatoriedade: a base silenciosa

Quase toda primitiva depende de aleatoriedade imprevisível — chaves, nonces, salts, IVs. Um RNG fraco quebra tudo silenciosamente (o ciphertext parece seguro). Por isso a regra é absoluta: só o CSPRNG do sistema (getrandom`dev/urandom), nunca rand()` ou variantes previsíveis. O SDK expõe só o wrapper correto e barra o resto.


2.4 Multi-tenant: isolar por design

Por policies/multi-tenant-by-default.kmd, todo dado carrega koder_user_id desde o primeiro commit, com isolamento por RLS (row-level security) ou prefixo de chave. No plano criptográfico, isso significa que material de chave e trilhas de auditoria são escopados por tenant — o vazamento de um não compromete os outros. Backups também são cifrados (AEAD) antes de sair para armazenamento frio.


Referência densa: HSM/PKCS#11, cadência de rotação completa, Shamir e backup em 14-koder-aplicada. A seguir: Disciplina e postura — o que mantém tudo isto correto ao longo do tempo, e o fecho do compêndio.