[Coffre Secrets] Phase 1a — Chiffrement par enveloppe et store (KEK/DEK, AES-GCM) #17

Open
opened 2026-10-27 21:36:18 -04:00 by bruno · 0 comments
Owner

Contexte : spec « Coffre de secrets ObsiGate » (16 p., ancrage Secrets sous home-). Aujourd'hui, data/api_keys.json est en clair et il n'existe aucune voûte de secrets.

Périmètre :

  • Nouveau module de chiffrement (dépendance cryptography à ajouter) : AES-256-GCM, KEK 256 bits (env OBSIGATE_KEK ou fichier 0600 OBSIGATE_KEK_FILE, hors dépôt, hors arborescence des vaults), DEK aléatoire par coffre stockée uniquement chiffrée par la KEK.
  • Store dédié sur le patron de backend/tools/secrets.py : JSON dans data/ (coffres.json : métadonnées + DEK chiffrées ; coffres_valeurs.json : versions chiffrées), permissions 0600, écriture atomique tmp+rename, verrou RLock.
  • Une version de secret = ciphertext + nonce unique + tag GCM. Tag invalide = refus, jamais de valeur fausse.
  • Rotations indépendantes : secret (nouvelle version), DEK (re-chiffrement du coffre), KEK (re-chiffrement des DEK seulement).
  • Mode dégradé sans KEK : métadonnées lisibles, distributions refusées (503 kek_absente), bandeau UI, aucun repli en clair, aucune régénération silencieuse de KEK.
  • Initialisation guidée : génération KEK, consigne de sauvegarde externe, confirmation explicite avant la première création.
  • La KEK ne doit jamais être dérivée du secret d'application (limite actuelle de Flowdeck, à ne pas reproduire), jamais journalisée, jamais renvoyée par API.

Hors périmètre : routes API (issue Phase 1b), UI (issue Phase 1c), migration api_keys.json (issue Phase 2).

Critères d'acceptation :

  • Chiffrement/déchiffrement aller-retour, tag invalide refusé, rotations KEK puis DEK puis secret vérifiées, mode dégradé sans KEK vérifié.
  • Aucune valeur en clair dans data/, les logs ou l'audit ; grep sur une valeur de test dans les fichiers et journaux = vide.
  • Tests unitaires dédiés.
Contexte : spec « Coffre de secrets ObsiGate » (16 p., ancrage Secrets sous home-<username>). Aujourd'hui, data/api_keys.json est en clair et il n'existe aucune voûte de secrets. Périmètre : - Nouveau module de chiffrement (dépendance `cryptography` à ajouter) : AES-256-GCM, KEK 256 bits (env OBSIGATE_KEK ou fichier 0600 OBSIGATE_KEK_FILE, hors dépôt, hors arborescence des vaults), DEK aléatoire par coffre stockée uniquement chiffrée par la KEK. - Store dédié sur le patron de backend/tools/secrets.py : JSON dans data/ (coffres.json : métadonnées + DEK chiffrées ; coffres_valeurs.json : versions chiffrées), permissions 0600, écriture atomique tmp+rename, verrou RLock. - Une version de secret = ciphertext + nonce unique + tag GCM. Tag invalide = refus, jamais de valeur fausse. - Rotations indépendantes : secret (nouvelle version), DEK (re-chiffrement du coffre), KEK (re-chiffrement des DEK seulement). - Mode dégradé sans KEK : métadonnées lisibles, distributions refusées (503 kek_absente), bandeau UI, aucun repli en clair, aucune régénération silencieuse de KEK. - Initialisation guidée : génération KEK, consigne de sauvegarde externe, confirmation explicite avant la première création. - La KEK ne doit jamais être dérivée du secret d'application (limite actuelle de Flowdeck, à ne pas reproduire), jamais journalisée, jamais renvoyée par API. Hors périmètre : routes API (issue Phase 1b), UI (issue Phase 1c), migration api_keys.json (issue Phase 2). Critères d'acceptation : - Chiffrement/déchiffrement aller-retour, tag invalide refusé, rotations KEK puis DEK puis secret vérifiées, mode dégradé sans KEK vérifié. - Aucune valeur en clair dans data/, les logs ou l'audit ; grep sur une valeur de test dans les fichiers et journaux = vide. - Tests unitaires dédiés.
bruno added the kanban:todo label 2026-10-27 21:36:18 -04:00
bruno added kanban:review and removed kanban:todo labels 2026-10-27 21:55:02 -04:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Projets/ObsiGate#17