Tamper-evident vs tamper-proof : un registre d'audit LLM vérifiable

Deux mots qui ne sont pas synonymes

« Tamper-proof » et « tamper-evident » sont employés de façon interchangeable dans le marketing sécurité. Ils signifient l'inverse l'un de l'autre, et la différence compte quand un auditeur lit vos affirmations.

• Tamper-proof : le changement est empêché. Pour des logs logiciels, c'est essentiellement impossible — celui qui fait tourner le système peut, en principe, altérer ce qu'il a stocké. Quiconque vous dit que ses logs applicatifs sont « tamper-proof » sur-promet.
• Tamper-evident : le changement est détectable. Vous n'empêcherez pas un initié motivé de modifier un enregistrement, mais vous pouvez rendre toute modification impossible à cacher. C'est une affirmation que vous pouvez tenir — et c'est ce dont un régulateur a besoin, car un enregistrement modifiable en silence n'est pas une preuve.

La cible honnête pour un registre d'audit est donc tamper-evident. Voici comment y parvenir.

Étape 1 : chaîner les enregistrements par un hash

Donnez à chaque enregistrement un row_hash calculé sur ses champs stables plus le hash de l'enregistrement précédent :

row_hash = SHA256( prev_hash + séparateur + canonical(record) )

Comme chaque hash intègre le précédent, les enregistrements forment une chaîne. Changez un seul champ de l'enregistrement 13 — faites passer le score d'une attaque bloquée de 0.86 à 0.06 — et le hash recalculé du 13 ne correspond plus à ce qui était stocké. La rupture est localisée et évidente. Pour vérifier, vous recalculez chaque hash depuis une valeur de genèse fixe et comparez à ce qui est enregistré. Un octet changé n'importe où s'allume.

Cela achète déjà la tamper-evidence au sein de l'ensemble exporté. Mais il reste une faille.

Étape 2 : ancrer la tête à une horloge indépendante

Une chaîne de hachage que vous contrôlez prouve la cohérence interne, mais rien ne vous empêche de reconstruire toute la chaîne après coup avec un autre contenu — la nouvelle chaîne est aussi cohérente. Il faut une référence externe qui dise « cette tête de chaîne existait au plus tard à l'instant T », et vous ne devez pas tenir l'horloge.

C'est ce que fournit un horodatage RFC 3161 : vous envoyez le hash de la tête de chaîne à une autorité d'horodatage indépendante, qui renvoie un jeton signé liant ce hash à un instant. Vous ne pouvez plus antidater ou réécrire en silence l'historique antérieur à l'ancre sans produire un jeton que l'autorité n'a jamais émis. Un horodatage valide sur une chaîne rompue ne la sauve pas non plus — le verdict reste « rompu ».

En production, la bonne ancre est un horodatage qualifié eIDAS (un QTSP), qui a une valeur probante au sens du règlement eIDAS. Pour une démo publique, une autorité gratuite comme freeTSA fonctionne et utilise le mécanisme identique — elle n'est simplement pas qualifiée eIDAS. Ne laissez personne faire passer un horodatage de démo pour un horodatage qualifié eIDAS.

Étape 3 : que n'importe qui puisse vérifier, hors-ligne

Tout l'intérêt est de vous retirer de l'équation de confiance. Le vérifieur doit donc tourner sans votre base de données et sans vos serveurs : un petit programme qui prend le dossier exporté, recalcule la chaîne, vérifie le jeton d'horodatage contre le certificat public de l'autorité, et affiche un verdict. Votre auditeur le lance sur son propre portable. « Vérifier, pas croire » n'est vrai que s'il n'a pas besoin de vous appeler.

Ce que ça prouve — et ce que ça ne prouve pas

Soyez précis, car sur-promettre ici fait perdre un acheteur technique :

• Prouve : l'intégrité — les enregistrements exportés forment une chaîne continue, non réécrite en silence avant l'ancre horodatée.
• Ne prouve pas l'exhaustivité : un dossier est un instantané ; les enregistrements jamais exportés sont invisibles. La chaîne vérifie ce qui est montré.
• Ne prouve pas l'origine : que les enregistrements viennent de votre système et non d'un autre nécessite une signature, étape distincte (ultérieure).

Essayez-le

Vous pouvez le faire vous-même sur un vrai dossier Senthex (synthétique) : recalculez la chaîne dans votre navigateur, falsifiez un octet, et regardez chain_ok passer de true à false — puis relancez le vérifieur Python hors-ligne pour le verdict identique. Pour le cadrage réglementaire du pourquoi conserver cet enregistrement, voir journalisation EU AI Act articles 12 et 19. Une réserve honnête : la chaîne vérifiable de Senthex est une capacité pilote aujourd'hui, pas la version publiée.