Chapitre 5 — Chaine de preuve¶

Introduction¶

La chaine de preuve constitue le socle probatoire du SAE ProbatioVault. Elle assure que chaque document archive possede une preuve d'integrite, d'anteriorite et de non-alteration verifiable de maniere autonome, sans acces privilegie au systeme.

Le mecanisme repose sur cinq maillons complementaires, chacun renforçant le precedent :

1. Empreinte documentaire SHA3-256 -- ancre cryptographique de chaque document.
2. Arbre de Merkle -- agregation par lots avec preuve d'inclusion individuelle.
3. Horodatage TSA RFC 3161 -- certification temporelle par un tiers de confiance qualifie.
4. Ancrage blockchain -- inscription publique et immuable de la racine Merkle.
5. Enveloppe probatoire PV-Envelope -- assemblage des quatre maillons en une preuve composite autonome.

Ce chapitre decrit chaque maillon, ses proprietes cryptographiques, son role dans la chaine et les modalites de verification.

5.1 Empreinte documentaire SHA3-256¶

Principe¶

Chaque document depose dans ProbatioVault est associe a une empreinte cryptographique calculee avec l'algorithme SHA3-256 (NIST FIPS 202, famille Keccak). Cette empreinte constitue l'ancre initiale de toute la chaine probatoire.

Calcul sur le document chiffre¶

Le hash est systematiquement calcule sur le document chiffre (doc.enc), jamais sur le document en clair. Ce choix fondamental repond a deux exigences simultanees :

• Zero-knowledge : le serveur ne manipule jamais le contenu en clair. L'empreinte probatoire est produite sans dechiffrement, preservant la confidentialite totale du document.
• Determinisme : pour un meme fichier chiffre, l'empreinte produite est toujours identique. La verification ulterieure consiste a recalculer le hash sur le fichier stocke et a comparer le resultat avec l'empreinte enregistree. Toute divergence signale une alteration.

Proprietes cryptographiques¶

L'algorithme SHA3-256 a ete retenu pour ses proprietes de resistance face aux attaques quantiques et son independance architecturale vis-a-vis de la famille SHA-2 (construction Merkle-Damgard). Il est conforme aux recommandations de l'ANSSI et aux exigences des normes NF Z42-013 et ISO 14641.

Flux de calcul¶

Lors du depot d'un document :

1. Le client chiffre le document cote client (AES-256-GCM avec cle derivee K_doc).
2. Le fichier chiffre est transmis au backend.
3. Le HashService calcule l'empreinte SHA3-256 du fichier chiffre.
4. L'empreinte est stockee en base de donnees (hash_doc) et associee au document.
5. L'empreinte est restituee au deposant comme accuse de reception.

Pour les fichiers volumineux (superieurs a 10 Mo), le calcul s'effectue en mode streaming par blocs successifs, sans charger l'integralite du fichier en memoire.

Verification d'integrite¶

Un verificateur — interne ou externe — peut a tout moment :

1. Recuperer le fichier chiffre depuis le stockage WORM.
2. Recalculer l'empreinte SHA3-256 sur ce fichier.
3. Comparer le resultat avec l'empreinte enregistree en base.

Si les deux valeurs coincident, l'integrite du document est confirmee. Toute difference constitue une preuve de falsification ou de corruption.

5.2 Arbre de Merkle¶

Principe du batch cryptographique¶

Les documents ne sont pas horodates individuellement. ProbatioVault regroupe les empreintes documentaires en lots (batches) et construit un arbre de Merkle dont la racine unique represente l'ensemble du lot. Cette racine est ensuite soumise a l'horodatage TSA et a l'ancrage blockchain.

Ce modele de batch cryptographique presente deux avantages majeurs :

• Efficience : une seule requete TSA et une seule transaction blockchain couvrent l'ensemble des documents du lot, reduisant les couts et la latence.
• Preuve individuelle : chaque document conserve une preuve d'inclusion dans l'arbre, permettant de demontrer son appartenance au lot sans reveler les autres documents.

Construction de l'arbre¶

L'arbre de Merkle est construit conformement aux RFC 6962 et RFC 9162 (Certificate Transparency) :

1. Tri lexicographique : les empreintes SHA3-256 des documents du lot sont triees par ordre lexicographique. Ce tri garantit le determinisme -- un meme ensemble de documents produit toujours le meme arbre.
2. Calcul des feuilles : chaque empreinte est transformee en feuille par SHA-256(0x00 || hash_document). Le prefixe 0x00 distingue les feuilles des noeuds internes.
3. Construction ascendante : les noeuds internes sont calcules par paires : SHA-256(0x01 || fils_gauche || fils_droit). Le prefixe 0x01 distingue les noeuds internes des feuilles. Si le nombre de noeuds a un niveau est impair, le dernier noeud est promu au niveau superieur.
4. Racine : le noeud final de l'arbre est la racine Merkle (Merkle root), empreinte unique et deterministe representant l'integralite du lot.

Diagramme : Structure arbre de Merkle¶

graph TB
    R["Racine Merkle<br/>SHA-256(0x01 || H_AB || H_CD)"]
    H_AB["Noeud H_AB<br/>SHA-256(0x01 || F_A || F_B)"]
    H_CD["Noeud H_CD<br/>SHA-256(0x01 || F_C || F_D)"]
    F_A["Feuille F_A<br/>SHA-256(0x00 || hash_doc1)"]
    F_B["Feuille F_B<br/>SHA-256(0x00 || hash_doc2)"]
    F_C["Feuille F_C<br/>SHA-256(0x00 || hash_doc3)"]
    F_D["Feuille F_D<br/>SHA-256(0x00 || hash_doc4)"]
    D1["Doc 1<br/>SHA3-256"]
    D2["Doc 2<br/>SHA3-256"]
    D3["Doc 3<br/>SHA3-256"]
    D4["Doc 4<br/>SHA3-256"]

    R --> H_AB
    R --> H_CD
    H_AB --> F_A
    H_AB --> F_B
    H_CD --> F_C
    H_CD --> F_D
    F_A --> D1
    F_B --> D2
    F_C --> D3
    F_D --> D4

Legende : Les documents (en bas) sont haches en SHA3-256. Chaque empreinte devient une feuille de l'arbre (prefixe 0x00). Les noeuds intermediaires sont calcules par paire (prefixe 0x01). La racine Merkle au sommet represente l'ensemble du lot de maniere deterministe.

Preuve d'inclusion¶

Pour demontrer qu'un document appartient a un lot scelle, ProbatioVault genere une preuve d'inclusion conforme a la RFC 9162. Cette preuve contient :

• L'empreinte du document (leaf hash).
• L'indice de la feuille dans l'arbre (leaf index).
• Le chemin d'authentification (Merkle path) : la sequence des noeuds freres necessaires pour recalculer la racine depuis la feuille.

La verification s'effectue en complexite logarithmique O(log n), ou n est le nombre de documents dans le lot. Le verificateur :

1. Part de l'empreinte du document.
2. Combine successivement avec chaque noeud du chemin d'authentification.
3. Compare le resultat final avec la racine Merkle publiee.

Si les deux valeurs coincident, l'appartenance du document au lot est mathematiquement prouvee.

Cycle de vie du batch¶

Un batch suit une machine a etats stricte :

• OPEN : le lot accepte de nouveaux documents.
• SEALED : le lot est clos, l'arbre de Merkle est construit, aucun ajout n'est plus possible.
• TIMESTAMPED : la racine a ete horodatee par la TSA.
• ANCHORED : la racine a ete ancree sur la blockchain.

L'arbre de Merkle, une fois construit, est serialise en format CBOR et persiste en base de donnees. Cette persistence permet de regenerer les preuves d'inclusion a tout moment.

5.3 Horodatage TSA RFC 3161¶

Principe de l'horodatage certifie¶

L'horodatage par une Autorite d'Horodatage (TSA — Time Stamping Authority) conforme a la RFC 3161 etablit une preuve d'anteriorite certifiee par un tiers de confiance independant. Ce tiers atteste que les donnees existaient a un instant donne.

ProbatioVault exige une QTSA qualifiee eIDAS (Qualified Time Stamping Authority), c'est-a-dire un prestataire de services de confiance inscrit sur une Trusted List officielle europeenne. Ce niveau de qualification confere a l'horodatage une presomption de fiabilite au sens du reglement eIDAS.

Flux d'horodatage¶

1. Cloture du batch : le lot est scelle et la racine Merkle est calculee.
2. Requete TSA : ProbatioVault soumet l'empreinte de la racine Merkle a la QTSA via le protocole RFC 3161.
3. Emission du jeton : la QTSA retourne un jeton d'horodatage signe (TST — Time Stamp Token) contenant :
4. L'empreinte soumise.
5. L'horodatage precis (horloge de reference du tiers de confiance).
6. La signature du tiers de confiance.
7. La chaine de certification.
8. L'identifiant de politique (policy OID).
9. Persistance : le jeton est stocke de maniere immuable avec le batch, creant un lien indissociable entre le lot de documents et la preuve temporelle.

Validation du jeton¶

La validation d'un jeton TSA couvre cinq verifications :

L'horloge de reference est une source de temps independante de l'horloge systeme locale, evitant toute manipulation de l'horodatage par l'operateur du systeme.

Rattachement individuel¶

Grace a l'architecture par batch, un seul jeton TSA couvre l'ensemble du lot. Le rattachement d'un document individuel a l'horodatage s'effectue via la combinaison :

• Preuve d'inclusion (section 5.2) : demontre l'appartenance du document au lot.
• Jeton TSA : certifie l'anteriorite de la racine du lot.

La preuve complete pour un document est donc : {empreinte_document, preuve_inclusion, jeton_TSA}.

5.4 Ancrage blockchain¶

Principe de l'ancrage public¶

L'ancrage blockchain consiste a inscrire la racine Merkle d'un lot dans une transaction sur une blockchain publique. Cette inscription constitue une preuve publique, immuable et verifiable par quiconque, sans cooperation de ProbatioVault.

L'ancrage renforce la chaine de preuve en ajoutant :

• Immutabilite : une fois inscrite dans un bloc confirme, la racine ne peut etre modifiee ni supprimee.
• Independance : la preuve est verifiable via n'importe quel noeud de la blockchain, sans confiance envers ProbatioVault.
• Horodatage supplementaire : le bloc porte un horodatage propre, constituant une seconde preuve temporelle independante de la TSA.

Cycle de vie de l'ancrage (protocole PV-ANCHOR)¶

L'ancrage suit un protocole formalise avec machine a etats stricte :

Les batches finalises sont proteges par un trigger PostgreSQL BEFORE UPDATE OR DELETE qui interdit toute modification. Un batch FAILED libere atomiquement ses evenements, qui redeviennent eligibles pour un nouveau cycle d'ancrage.

Periodicite et continuite¶

Le worker d'ancrage s'execute de maniere periodique (cadence cible : 10 minutes). Il collecte les evenements probatoires non encore ancres, construit le lot et publie la racine. Les fenetres temporelles successives ne laissent aucun intervalle non couvert : tout evenement probatoire est garanti d'etre ancre.

En cas d'absence d'evenements eligibles, le cycle produit une trace no-op auditee, attestant de l'execution periodique.

Verification externe¶

Un verificateur externe peut, a partir des artefacts de preuve exportes :

1. Recuperer le hash de la transaction blockchain (tx_id).
2. Consulter la blockchain publique pour obtenir la racine Merkle inscrite.
3. Verifier la preuve d'inclusion du document dans l'arbre.
4. Confirmer que la racine ancree correspond a celle du lot.

Cette verification ne necessite aucun acces privilegie a ProbatioVault. L'artefact de preuve contient toutes les informations requises : leaf hash, Merkle path, Merkle root, tx hash, block number et chain ID (conforme EIP-155).

Gestion des reorganisations¶

En cas de reorganisation de la blockchain (bloc orphelin), le batch transite de PENDING_FINALITY a FAILED. Les evenements sont liberes et re-collectes dans un nouveau cycle, garantissant qu'aucun evenement n'est perdu.

5.5 Enveloppe probatoire PV-Envelope¶

Principe de l'enveloppe probatoire¶

L'enveloppe probatoire PV-Envelope (protocole PV-PROOF) assemble les quatre maillons precedents en une preuve composite unique, autonome et verifiable offline. Elle constitue le livrable final de la chaine de preuve : un dossier complet permettant a un auditeur ou a un juge de verifier l'integrite, l'anteriorite et la non-alteration d'un document sans dependre du systeme ProbatioVault.

Structure de l'enveloppe¶

L'enveloppe PV-Envelope est composee de cinq sections d'evidence obligatoires et d'un bloc de materiel de verification :

Le materiel de verification inclus dans l'enveloppe comprend :

Chaine de preuve a quatre maillons¶

La verification de l'enveloppe s'effectue en parcourant sequentiellement les quatre maillons :

Le statut INDETERMINATE signifie que le maillon ne peut pas etre verifie a l'instant de la consultation (par exemple, blockchain temporairement inaccessible). Ce statut n'est ni un succes ni un echec.

Proprietes de surete¶

L'enveloppe probatoire garantit les proprietes suivantes, verifiees formellement (TLA+, Alloy, Z) :

• Completude : les cinq sections sont obligatoires pour la finalisation. Une section manquante interdit la generation.
• Immutabilite : une enveloppe persistee ne peut plus etre modifiee (trigger PostgreSQL).
• Absence de secrets : aucun secret cryptographique (cle privee, cle de chiffrement) ne figure dans l'enveloppe. Seuls les elements publics sont inclus.
• Autonomie de verification : le materiel de verification (cle publique, algorithmes) est integre dans l'enveloppe, permettant une verification complete sans acces a ProbatioVault.
• Tracabilite : la generation de chaque enveloppe est enregistree dans le journal d'audit append-only.

Diagramme : Flux de scellement¶

sequenceDiagram
    participant C as Client
    participant B as Backend
    participant H as HashService
    participant M as MerkleService
    participant T as QTSA RFC 3161
    participant BC as Blockchain
    participant E as PV-Envelope

    C->>B: Upload document chiffre
    B->>H: hashDocument(doc.enc)
    H-->>B: SHA3-256 (empreinte)
    B->>B: Stockage WORM + enregistrement hash
    B->>M: Ajout empreinte au batch
    Note over M: Cloture du batch
    M->>M: buildTree(empreintes triees)
    M-->>B: Racine Merkle
    B->>T: Requete RFC 3161 (racine)
    T-->>B: Jeton TSA signe
    B->>BC: anchorRoot(racine)
    BC-->>B: tx_id + block_number
    B->>E: Assemblage preuve composite
    E-->>B: PV-Envelope finalisee

Legende : Le flux complet de scellement, du depot du document chiffre jusqu'a l'assemblage de l'enveloppe probatoire. Le client transmet le document chiffre. Le backend calcule l'empreinte SHA3-256, l'integre dans un batch Merkle, soumet la racine a la TSA qualifiee, ancre la racine sur la blockchain, puis assemble l'ensemble dans une enveloppe PV-Envelope autonome et verifiable.

Synthese des garanties¶

La chaine de preuve ProbatioVault apporte les garanties suivantes pour chaque document archive :

Chaque maillon renforce les precedents : l'empreinte prouve l'integrite, l'arbre de Merkle permet la preuve par lot, la TSA certifie la date, la blockchain rend la preuve publique et immuable, et l'enveloppe probatoire assemble le tout en un dossier autosuffisant.

References¶

• NIST FIPS 202 : Standard SHA3-256 (Keccak).
• RFC 6962 / RFC 9162 : Certificate Transparency, construction d'arbres de Merkle et preuves d'inclusion.
• RFC 3161 : Time-Stamp Protocol.
• RFC 8785 : JSON Canonicalization Scheme (serialisation canonique).
• EIP-155 : Simple Replay Attack Protection (identifiant de chaine).
• RFC PV-ANCHOR-001 : Protocole d'ancrage blockchain ProbatioVault.
• RFC PV-PROOF-001 : Protocole ProofEnvelope ProbatioVault.
• NF Z42-013:2020 : Archivage electronique.
• ISO 14641:2018 : Conception et exploitation de systemes d'archivage electronique.
• Stories : PD-33, PD-34, PD-38, PD-39, PD-55, PD-81, PD-177, PD-237.