Ce que contient un certificat d'horodatage
Par BlockchainSignPublié le
Un certificat d'horodatage est un petit fichier, et chaque champ qu'il contient a une raison d'être. Comprendre le rôle de chacun transforme ce certificat d'un objet de confiance en un document vérifiable.
Les champs
Un certificat BlockchainSign est un fichier YAML comportant les champs suivants :
| Champ | Description |
|---|---|
version |
Version du format du certificat |
provider |
Émetteur du certificat |
timestamp |
Heure du bloc de la transaction — la date prouvée |
blockchain |
Chaîne sur laquelle l'enregistrement est inscrit |
algorithm |
Fonction de hachage utilisée, SHA-256 |
payload_hash |
Hash du bloc de données, tel qu'inscrit sur la chaîne |
tx_hash |
Identifiant de la transaction |
tx_url |
Lien vers cette transaction sur un explorateur de blocs public |
payload |
Trois lignes : l'email de livraison, le SHA-256 du fichier et toute métadonnée fournie |
La structure est délibérément sobre. Rien de propriétaire, rien de chiffré, et rien qui nécessite notre logiciel pour être interprété.
Pourquoi les données sont hachées séparément
C'est le point clé à comprendre, car il explique la conception.
Le bloc de données (payload) contient trois éléments : une adresse e-mail, le hash de votre fichier et des métadonnées en texte libre, comme un nom d'auteur ou une référence de projet. Il n'est pas écrit directement sur la chaîne ; c'est son propre hash SHA-256 qui y est inscrit.
Deux raisons. Premièrement, limiter les données on-chain à 64 caractères fixes rend le coût de la transaction prévisible, quel que soit le volume de métadonnées ajouté. Deuxièmement, le bloc de données contient une adresse e-mail, et il n'y a aucune raison de publier cette information de manière permanente sur un registre public.
Le résultat est une chaîne de preuves en deux étapes : le fichier génère un hash contenu dans le bloc de données, et le bloc de données génère le hash inscrit sur la chaîne. Ces deux étapes sont reproductibles par quiconque dispose du certificat.
Vérification étape par étape
Vous n'avez pas besoin de nous pour quoi que ce soit.
1. Vérifiez l'existence de la transaction. Ouvrez tx_url. Elle pointe vers une transaction réelle sur un explorateur public, avec un numéro de bloc et un horodatage.
2. Lisez ce qui est inscrit sur la chaîne. Sur la page de la transaction, trouvez les données d'entrée et sélectionnez "Afficher en UTF-8". Vous verrez le hash du bloc de données sous forme de texte lisible.
3. Comparez-le avec le certificat. Cette chaîne de caractères doit correspondre exactement à payload_hash.
4. Hachez à nouveau le bloc de données. Prenez les trois lignes du bloc de données telles qu'elles apparaissent et hachez-les avec SHA-256. Le résultat doit être égal à payload_hash. Une mise en garde : l'indentation YAML ajoute des espaces au début qui ne font pas partie du bloc de données — supprimez-les avant de hacher, sinon la valeur ne correspondra pas.
5. Hachez à nouveau votre fichier. shasum -a 256 votre_fichier.pdf sur macOS ou Linux, certutil -hashfile votre_fichier.pdf SHA256 sur Windows, ou utilisez l'outil de hachage gratuit dans votre navigateur. Comparez le résultat avec la ligne File SHA-256 dans le bloc de données.
Si ces cinq vérifications sont concluantes, vous avez établi que ce fichier exact a été engagé dans un registre public à cet instant précis, et qu'il n'a pas changé depuis.
Ce que le certificat ne vous dit pas
Être clair sur les limites est ce qui rend le reste crédible :
- Qui a créé le fichier. Le certificat enregistre que quelqu'un le détenait. Voir preuve d'existence vs preuve de paternité.
- Ce que contient le fichier. Seul son hash est enregistré. Toute personne vérifiant la couverture doit disposer du fichier lui-même, ce qui est la propriété qui rend cela utilisable pour les documents confidentiels.
- Que les métadonnées sont vraies. Le champ en texte libre indique ce que vous avez saisi. Il est figé à ce moment-là et inchangeable par la suite, ce qui est utile — mais le registre ne le vérifie pas.
- Aucun statut juridique. C'est une preuve, pas un enregistrement ou un droit.
Conservez le fichier, octet par octet
La façon la plus courante de perdre la valeur d'un certificat est de perdre le fichier exact.
Un hash couvre une séquence exacte d'octets. Réenregistrer un document, l'exporter à nouveau, ou laisser une application réécrire les métadonnées produit un fichier différent avec un hash différent — et le certificat ne correspondra plus. Archivez la version certifiée séparément et travaillez sur une copie.
Le certificat lui-même vaut aussi la peine d'être conservé, bien que moins crucialement : le hash du bloc de données est sur la chaîne, donc un certificat peut être reconstruit à partir de données publiques tant que vous savez quelle transaction il concerne.