ProbatioVault — Architecture de securite¶
Vue d'ensemble des 5 protocoles cryptographiques. Document de vulgarisation interne — onboarding, presentations, audits.
Vue d'ensemble¶
ProbatioVault est un coffre-fort numerique probatoire. Cinq protocoles cryptographiques garantissent la confidentialite, l'integrite et la valeur probante des documents conserves.
┌──────────────────────────────────────────────────────────────────────────┐
│ │
│ UTILISATEUR │
│ (mot de passe) │
│ │ │
│ ▼ │
│ ┌─────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ PV-ENVELOPE │───▶│ PV-AUDIT │───▶│ PV-ANCHOR │ │
│ │ Cles │ │ Journal │ │ Blockchain │ │
│ │ zero-knowledge│ │ immutable │ │ Polygon │ │
│ └──────┬──────┘ └──────┬───────┘ └──────┬───────┘ │
│ │ │ │ │
│ │ ▼ ▼ │
│ │ ┌──────────────┐ ┌──────────────┐ │
│ └──────────▶│ PV-PRE │ │ PV-PROOF │ │
│ │ Acces legal │ │ Preuve │ │
│ │ zero-knowledge│ │ auto-verif. │ │
│ └──────────────┘ └──────────────┘ │
│ │
└──────────────────────────────────────────────────────────────────────────┘
1. PV-ENVELOPE — Hierarchie de cles zero-knowledge¶
Le serveur ne voit JAMAIS les cles en clair.
Principe¶
L'utilisateur possede une cle maitre (K_master) generee par CSPRNG a l'inscription. Cette cle n'est jamais derivee du mot de passe — elle est enveloppee (chiffree) par une cle derivee du mot de passe.
Diagramme¶
Mot de passe
│
▼
┌────────────────────┐
│ Argon2id │ memoire=64 MiB, passes=3
│ (ralentit bruteforce)│
└─────────┬──────────┘
▼
K_enc (256 bits)
│
▼
┌────────────────────┐ ┌────────────────────┐
│ AES-256-KW │ │ BIP-39 (24 mots) │
│ (envelope MASTER) │─ ─ ─ ─│ (envelope RECOVERY) │
└─────────┬──────────┘ └────────────────────┘
│ unwrap
▼
┌──────────┐
│ K_master │ 256 bits CSPRNG, unique par utilisateur
│ (jamais │
│ en clair│
│ serveur)│
└────┬─────┘
│ HKDF-SHA256
├──────────────────▶ K_share (chiffrement partages)
├──────────────────▶ K_doc_i (1 cle unique par document)
└──────────────────▶ K_search (recherche chiffree)
Invariants cles¶
| Regle | Description |
|---|---|
| 1 seul MASTER par utilisateur | Jamais 0, jamais 2 |
| K_master = CSPRNG | Jamais derive d'un mot de passe |
| Rotation = re-enveloppe | K_master ne change pas, seul K_enc est regenere |
| Zeroisation obligatoire | K_enc efface de la memoire apres usage |
2. PV-AUDIT — Journal d'audit immutable¶
Chaque action est enregistree, signee, chainee. Rien ne peut etre supprime.
Principe¶
Tout evenement (creation, acces, modification, destruction) est enregistre dans un journal append-only. Chaque entree est : 1. Serialisee en JSON canonique (RFC 8785) 2. Hashee (SHA3-256) 3. Signee par le HSM (ECDSA P-384) 4. Chainee a l'entree precedente (hash chain)
Diagramme¶
Evenement (ex: acces document)
│
▼
┌────────────────────┐
│ JCS (RFC 8785) │ serialisation deterministe
│ canonicalisation │
└─────────┬──────────┘
▼
┌────────────────────┐
│ SHA3-256 │ + hash entree precedente (chain)
│ entry_hash │
└─────────┬──────────┘
▼
┌────────────────────┐ ┌────────────────────┐
│ HSM ECDSA P-384 │ │ TSA RFC 3161 │
│ signature │ │ horodatage │
│ (pv-master-signing)│ │ (si PROBATOIRE) │
└─────────┬──────────┘ └─────────┬──────────┘
│ │
▼ ▼
┌──────────────────────────────────────────────┐
│ PostgreSQL (vault_audit.audit_logs) │
│ TRIGGER: bloque UPDATE et DELETE │
│ REVOKE TRUNCATE │
└──────────────────────────────────────────────┘
Types d'evenements¶
| Type | Signature HSM | Horodatage TSA | Exemple |
|---|---|---|---|
| PROBATOIRE | Obligatoire | Obligatoire | Creation cle, destruction, acces legal |
| INFORMATIF | Obligatoire | Best-effort | Creation batch, echec, retry |
Invariants cles¶
| Regle | Description |
|---|---|
| Append-only | Trigger PostgreSQL bloque DELETE et UPDATE |
| Fail-closed | Si l'audit est indisponible, la destruction est bloquee |
| Chaine de hash | Chaque entree inclut le hash de la precedente |
| Retention >= 10 ans | Conforme eIDAS |
3. PV-ANCHOR — Ancrage blockchain¶
Les hash du journal sont ancres dans la blockchain Polygon, verifiables par n'importe qui.
Principe¶
Periodiquement, les hash des evenements d'audit sont regroupes en lots (batches), organises en arbre de Merkle, et la racine est inscrite dans une transaction Polygon. Un tiers peut verifier qu'un evenement fait partie du lot sans acceder au systeme ProbatioVault.
Diagramme¶
Evenements audit (hashes SHA3-256)
│
▼
┌────────────────────────────────────────┐
│ Arbre de Merkle (SHA-256, RFC 9162) │
│ │
│ merkleRoot │
│ / \ │
│ H(AB) H(CD) │
│ / \ / \ │
│ A B C D <- feuilles │
│ (hash des evenements audit) │
└─────────────────┬──────────────────────┘
│
▼
┌────────────────────────────────────────┐
│ Transaction Polygon (EIP-155) │
│ │
│ merkleRoot ──▶ tx_id + block_number │
│ │
│ Attente finalite (128 blocs Polygon) │
└─────────────────┬──────────────────────┘
│
▼
FINALIZED
(immutable, verrouille)
┌────────────────────────────────────────┐
│ Preuve d'inclusion (exportable) │
│ │
│ leaf_hash + inclusion_path + root │
│ + tx_id + block_number + chain_id │
│ │
│ → verifiable offline par un tiers │
└────────────────────────────────────────┘
Machine d'etats du batch¶
PENDING ──▶ BUILDING ──▶ SUBMITTED ──▶ PENDING_FINALITY ──▶ FINALIZED
│ │
└───────────────────┴──▶ FAILED
│
events liberes
pour retry
Invariants cles¶
| Regle | Description |
|---|---|
| FINALIZED = immutable | Trigger PostgreSQL, aucune modification possible |
| 1 event = 1 batch FINALIZED max | Pas de doublon inter-batches |
| Fenetres temporelles disjointes | Pas de chevauchement entre batches |
| Finalite = 128 blocs (Polygon) | Timeout → FAILED → retry |
4. PV-PRE — Acces legal zero-knowledge (Proxy Re-Encryption)¶
Un juge peut acceder a un document chiffre sans que ProbatioVault puisse le lire.
Principe¶
Quand un tribunal ordonne l'acces a un document chiffre, le protocole Umbral (re-chiffrement par proxy) transforme le chiffre de l'espace du proprietaire vers l'espace du destinataire legal. Le proxy (ProbatioVault) effectue la transformation sans jamais pouvoir dechiffrer le document.
Diagramme¶
Mandat judiciaire (tribunal)
│
▼
┌────────────────────────────────────────────────────┐
│ Double validation │
│ │
│ DPO (RGPD) ────┐ │
│ ├──▶ Validation conjointe │
│ Autorite legale ┘ (les 2 DOIVENT approuver) │
└──────────────────────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────────────────────┐
│ Generation KFrags (cote proprietaire) │
│ │
│ pk_owner + pk_recipient + (t, n) │
│ → n fragments de cle (KFrags), t suffisent │
│ → lies au mandat par signature HSM │
│ → chiffres au repos (AES-256-GCM, cle HSM) │
│ → TTL max 72h par defaut │
└──────────────────────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────────────────────┐
│ Re-chiffrement (proxy ProbatioVault) │
│ │
│ KFrag_i + Capsule ──▶ CFrag_i │
│ │
│ Le proxy ne peut PAS dechiffrer. │
│ Pas d'operation "decrypt" dans le modele. │
│ Nonce unique (>= 96 bits CSPRNG) anti-replay. │
└──────────────────────────┬─────────────────────────┘
│ Quand cfrags >= t : │
│ ReKey → COMPLETED │
└──────────────────────────┘
│
▼
┌────────────────────────────────────────────────────┐
│ Dechiffrement (cote destinataire legal) │
│ │
│ t CFrags + sk_recipient ──▶ document en clair │
│ (ProbatioVault n'intervient PAS) │
└────────────────────────────────────────────────────┘
Cycle de vie ReKey¶
┌── COMPLETED (cfrags >= t)
│
ACTIVE ─────────────────────┼── REVOKED (DPO ou proprietaire)
│
└── EXPIRED (TTL ecoule)
│
tous ──┴──▶ DESTROYED
(KFrags zeroises,
DB + cache purges)
Invariants cles¶
| Regle | Description |
|---|---|
| Zero-knowledge | Aucune operation decrypt dans le modele ou le code |
| Double validation obligatoire | DPO et autorite legale avant tout CFrag |
| PKI eIDAS | Chaque cle publique liee a un certificat eIDAS valide |
| TTL borne | [1h, 30j], defaut max 72h |
| Terminal = irreversible | REVOKED, EXPIRED, COMPLETED → DESTROYED |
5. PV-PROOF — Preuve composite ancree¶
Un document auto-verifiable qui prouve tout : integrite, horodatage, ancrage, signature.
Principe¶
La preuve composite reunit les 4 autres protocoles en un seul artefact exportable, verifiable offline par un tribunal ou un auditeur, sans acces au systeme ProbatioVault.
Diagramme — Chaine de verification a 4 maillons¶
┌─────────────────────────────────────────────────────────┐
│ ProofEnvelope v2.0.0 │
├─────────────────────────────────────────────────────────┤
│ │
│ Maillon 1 : INTEGRITE │
│ ──────────────────── │
│ Payload evenement ──SHA3-256──▶ eventHash │
│ Recalculable a partir du payload JCS embarque │
│ │
│ Maillon 2 : INCLUSION MERKLE │
│ ──────────────────────────── │
│ eventHash ──feuille Merkle──▶ inclusion_path │
│ ──▶ merkleRoot (recalculable depuis la preuve) │
│ │
│ Maillon 3 : HORODATAGE │
│ ────────────────────── │
│ Token TSA RFC 3161 (DER embarque) │
│ Certificat TSA + OCSP embarques │
│ genTime prouve "existait avant cette date" │
│ │
│ Maillon 4 : ANCRAGE BLOCKCHAIN │
│ ──────────────────────────── │
│ merkleRoot inscrit dans transaction Polygon │
│ tx_id + block_number + chain_id (EIP-155) │
│ Verifiable sur n'importe quel noeud Polygon │
│ │
│ SCEAU GLOBAL : HSM ECDSA P-384 │
│ ───────────────────────────── │
│ Couvre tout le contenu (JCS → SHA3-384 → HSM sign) │
│ Certificat HSM + chaine eIDAS embarques │
│ │
│ Resultat : │
│ 4 maillons OK + sceau OK → VALID │
│ >= 1 INDETERMINATE → PARTIAL │
│ >= 1 KO ou sceau KO → INVALID │
└─────────────────────────────────────────────────────────┘
Invariants cles¶
| Regle | Description |
|---|---|
| Auto-verifiable | Tout le materiel de verification est embarque dans la preuve |
| Schema versionne | schemaVersion semver obligatoire dans chaque preuve |
| Artefacts embarques | Merkle proof, TSA token DER, tx_id — pas de simples refs |
| Fail-closed | Champ manquant = preuve invalide |
Schema JSON canonique complet : voir PROOF-ENVELOPE-CANONICAL.md
Flux bout en bout — De l'upload a la preuve¶
1. UPLOAD DOCUMENT
│
├─ K_doc_i derive (PV-ENVELOPE, HKDF)
├─ Document chiffre AES-256-GCM
├─ Stocke S3 WORM (Object Lock COMPLIANCE)
└─ Evenement PROBATOIRE emis (PV-AUDIT)
│
▼
2. JOURNAL D'AUDIT
│
├─ JCS → SHA3-256 → HSM sign → TSA token
├─ Chaine de hash (previousEntryHash)
└─ Entree immutable en base
│
▼
3. ANCRAGE BLOCKCHAIN
│
├─ Batch d'events → Arbre Merkle → merkleRoot
├─ Transaction Polygon (128 blocs finalite)
└─ Preuve d'inclusion par event
│
▼
4. PREUVE COMPOSITE (sur demande)
│
├─ Assemble les 4 maillons
├─ Embarque materiel de verification (certs, OCSP)
├─ Sceau HSM global (ECDSA P-384)
└─ Export : fichier JSON auto-verifiable
────────────────────────────────────────────
5. ACCES LEGAL (si mandat judiciaire)
│
├─ Double validation DPO + autorite legale
├─ Proxy re-encryption Umbral (zero-knowledge)
├─ Destinataire dechiffre (ProbatioVault ne peut pas)
└─ Tout trace dans PV-AUDIT (PROBATOIRE)
Primitives cryptographiques partagees¶
| Primitive | Usage | Norme |
|---|---|---|
| SHA3-256 | Hash des evenements audit | FIPS 202 |
| SHA-256 | Feuilles et noeuds Merkle | FIPS 180-4 |
| SHA3-384 | Hash pour le sceau global HSM | FIPS 202 |
| ECDSA P-384 | Signature HSM (toutes les RFC) | FIPS 186-5 |
| AES-256-KW | Enveloppement K_master | RFC 3394 |
| AES-256-GCM | Chiffrement documents + KFrags | NIST SP 800-38D |
| Argon2id | Derivation cle depuis mot de passe | RFC 9106 |
| HKDF-SHA256 | Derivation cles (K_share, K_doc, K_search) | RFC 5869 |
| JCS (RFC 8785) | Serialisation canonique JSON | RFC 8785 |
| secp256k1 | Umbral PRE (interop Ethereum) | SEC 2 |
| TSA RFC 3161 | Horodatage certifie | RFC 3161 |
Toutes les cles : 256 bits minimum (NIST SP 800-131A, securite post-2030). HSM : AWS CloudHSM, cles non-extractables (
CKA_EXTRACTABLE=FALSE).