Un certificat protège un fichier, pas le registre qui le contient

Quand ChronoCert certifie une photo, une vidéo ou un enregistrement audio, l'empreinte du fichier est horodatée et consignée dans un registre. Ce certificat prouve qu'un fichier précis existait, sous cette forme exacte, à un instant donné. Mais une question reste ouverte, et elle est rarement posée : qui garantit que la liste de toutes les certifications émises par la plateforme n'a pas été modifiée après coup ? Cette question devient particulièrement importante dès lors qu'un certificat doit être présenté des mois, voire des années, après son émission : le temps écoulé est justement le moment où une manipulation discrète du registre serait la plus tentante et la plus difficile à repérer sans mécanisme dédié. Un certificat individuel, aussi solide soit-il, ne répond pas à cette question. Il prouve l'existence d'un fichier à une date. Il ne dit rien sur l'intégrité du registre dans lequel cet événement a été consigné. C'est précisément le rôle du hash-chain : protéger le registre lui-même, pas le fichier.

Rappel : une empreinte numérique unique par fichier

Une fonction de hachage comme SHA-256 prend un fichier, quelle que soit sa taille, et produit une empreinte courte, de longueur fixe. Changer un seul bit du fichier d'origine (un pixel modifié, une métadonnée altérée, un octet corrompu) produit une empreinte totalement différente, sans aucun lien visible avec l'empreinte initiale. C'est ce mécanisme que ChronoCert utilise pour identifier une photo, une vidéo ou un fichier audio au moment de sa réception, avant tout horodatage. Cette empreinte devient la base du certificat : elle permettra plus tard de vérifier qu'un fichier présenté correspond bien, bit pour bit, à celui qui a été certifié à l'origine. C'est un mécanisme bien établi, simple dans son principe, et c'est le premier niveau de preuve du service. Le hash-chain, lui, s'attaque à un problème différent et complémentaire.

Le hash-chain : une chaîne d'enveloppes scellées

Imaginez une série d'enveloppes numérotées, posées les unes après les autres, chacune fermée par un sceau de cire. Rien d'inhabituel jusque-là. Mais chaque nouveau sceau ne se contente pas de fermer l'enveloppe du jour : il inclut, dans son empreinte, une trace du sceau de l'enveloppe précédente. Essayer de retirer une enveloppe au milieu de la pile, ou d'en glisser une nouvelle à une date antérieure, sans que cela se voie sur toutes les enveloppes suivantes, devient impossible à faire proprement, car la chaîne de sceaux qui suit ne correspondrait plus. C'est exactement le principe appliqué par ChronoCert à son propre journal interne de certifications. Chaque nouvelle entrée du registre intègre le hash de l'entrée précédente, combiné à ses propres données, pour calculer sa propre empreinte. Résultat : chaque entrée est liée cryptographiquement à celle qui la précède, et ainsi de suite jusqu'à la toute première entrée du registre.

Pourquoi cette distinction compte pour un service de preuve

Un certificat prouve qu'un fichier existait à une date donnée. Le hash-chain, lui, donne confiance dans le catalogue de ces certifications, le registre qui les recense toutes. La différence n'est pas théorique. Sans hash-chain, une base de données classique peut voir une de ses lignes modifiée par une simple commande UPDATE, sans laisser de trace visible pour quiconque consulte le registre depuis l'extérieur. Un administrateur du système, ou une personne ayant compromis l'accès à la base, pourrait en théorie ajouter, retirer ou modifier discrètement un événement de certification, des années plus tard, sans que rien ne le signale. Avec un hash-chain, cette même opération casse la cohérence de toutes les entrées suivantes, puisque chacune dépend mathématiquement du hash de celle qui la précède. La manipulation devient repérable au lieu de rester invisible : c'est toute la différence entre un registre qui se contente d'exister et un registre qui peut être vérifié.

Une falsification silencieuse devient détectable

Il faut être précis sur ce que cela signifie réellement, sans exagérer sa portée. Le hash-chain ne rend rien "infaillible", ni "impossible à falsifier" dans l'absolu. Ce qu'il apporte concrètement, c'est que toute tentative de modifier, d'insérer ou de supprimer discrètement une entrée passée du registre rend une falsification silencieuse détectable : les hash des entrées suivantes ne correspondent plus à ce qu'ils devraient être, et l'incohérence peut être constatée par une simple vérification de la chaîne. C'est conceptuellement proche d'une blockchain, mais plus simple, et différent sur un point essentiel : il n'y a ici ni réseau distribué, ni mécanisme de consensus entre plusieurs parties indépendantes. C'est un registre tenu par un seul opérateur de confiance, auquel s'applique cette propriété de dépendance entre entrées, dans un journal en ajout seul : on écrit, on n'efface ni ne réécrit jamais une entrée existante.

Un choix de conception délibéré, pas un argument marketing

ChronoCert applique ce hash-chain à son propre journal interne d'événements de certification depuis l'origine du service. Ce n'est pas une fonctionnalité ajoutée pour la vitrine, ni un mot posé sur une page produit pour rassurer. C'est une réponse directe à une question précise : comment permettre de vérifier que le registre des certifications n'a pas été manipulé après coup, sans demander à l'utilisateur de faire une confiance aveugle à celui qui l'héberge. Ce mécanisme ne remplace ni le sérieux d'un hébergement sécurisé, ni la vigilance nécessaire sur les accès à la base de données ; ce sont des sujets distincts, tout aussi importants. Il ajoute une couche supplémentaire et vérifiable, qui transforme une éventuelle altération du registre en quelque chose de repérable, plutôt que de la laisser indétectable. C'est une différence de nature, pas de degré.