Bitcoin, le grand testament du Temps qui passe – OpenTimestamps, l’horodatage par excellence
Ce qu’il faut savoir sur OTS – S’il y a bien un vieux mythe persistant autour du bitcoin, c’est bien de le décrire comme utilisant la technologie blockchain. Ceci ne manque pas de piment puisque, comme nous l’avions vu dans un précédent article, notre bon vieux Bitcoin utilise un serveur de temps partagé et structuré autour d’une chaîne preuve de travail. C’est bien Satoshi qui l’explique le mieux dans ses différents échanges dans la mailing list.
Sans surprise, nous savons que ce serveur de temps permet d’enregistrer les transactions de nos précieux bitcoins. Cependant, savez-vous qu’il est possible d’enregistrer d’autres informations ?
Plus précisément, une transaction bitcoin est munie d’un jeu d’instructions permettant le plus souvent de bloquer des fonds sur une adresse bitcoin. L’envoi d’une transaction correspondant au déverrouillage des fonds via la résolution d’un script. Sans forcément aller dans les détails, il existe une instruction permettant d’embarquer un peu de données.
“OP_RETURN” est une instruction (ou OP_CODE pour les puristes) intégrée spécifiquement pour ajouter quelques données. Elle a la caractéristique de rendre la transaction non dépensable. Vous l’aurez compris, l’utiliser, c’est brûler ses bitcoins.
Bien évidemment, cela ne viendrait à l’esprit de personne d’utiliser cette instruction pour y sauvegarder ses photos de vacances. Cependant et à bien y réfléchir, il est possible d’y inscrire des méta données comme l’empreinte d’un fichier. De cette manière, il devient possible de faire de la preuve d’existence et d’antériorité.
Suivez-moi dans la découverte d’OpenTimestamps. Nous verrons ensemble son cas d’usage, son fonctionnement et nous irons même jusqu’à prouver manuellement la validité d’une preuve d’existence.
Tous mes remerciements à Gilles Cadignan et Vincent Barat de la société Woleet ainsi qu’à Peter Todd le développeur de OpenTimestamps pour m’avoir aidé à écrire cette analyse.
La preuve d’existence
OpenTimestamps est une solution opensource permettant d’horodater des données et ainsi de prouver que ces dernières ont existé avant une date donnée. Sa particularité vient de sa capacité à ancrer des fichiers sur le serveur d’horodatage le plus fiable et le plus résistant à la modification du monde. Ce serveur, vous le connaissez tous puisqu’il s’agit de Bitcoin.
Je ne peux m’empêcher de faire un clin d’oeil à Satoshi Nakamoto qui a été le premier à utiliser cette caractéristique de bitcoin dès le premier bloc. Notez cependant qu’à l’époque, ni OpenTimestamps ni l’opération “OP_RETURN” n’existait encore.
Le texte “The 03/01/2009 Chancellor on brink of second bailout for bank” faisait référence à la première page de l’édition du trois janvier 2009 du journal The Times.
De cette manière, Satoshi Nakamoto prouvait que Bitcoin démarrait bien après la publication de cette édition. Cependant, OpenTimestamps facilite considérablement cette opération car après tout, n’est pas Satoshi qui veut.
Cas pratique
Pour que cela soit plus concret, je vais vous montrer en image le procédé d’ancrage.
OpenTimestamps se décline de plusieurs manières avec notamment un logiciel développé en python et une librairie Javascript. Le site OpenTimestamps.org fournit un démonstrateur utilisant cette librairie. Il vous permettra gratuitement (et sans pub) d’ancrer vos documents sur Bitcoin.
Pour l’exemple, j’ai repris l’image représentant l’édition du Times afin de créer une preuve à l’aide du site https://OpenTimestamps.org/.
Il vous suffira de déplacer le fichier en question dans la zone suivante. Magie de la technologie, votre fichier n’est nullement envoyé sur le serveur du site puisque c’est la librairie Javascript dans votre navigateur qui se charge de l’ensemble des opérations.
Votre navigateur calcule et envoie l’empreinte numérique du fichier (SHA256) aux serveurs de calendrier. Ces serveurs sont l’interface entre vous et Bitcoin, Ils ont pour rôle d’ancrer les empreintes dans des transactions Bitcoin. Par ailleurs, pour éviter de faire une transaction par demande et d’encombrer le réseau, ces serveurs agrègent également les demandes. Ceci permet de maintenir la gratuité à l’aide des donations des utilisateurs.
Après avoir déposé votre fichier, vous récupérez un fichier de preuve temporaire que nous décortiquerons un peu plus bas. Conservez là bien chaudement, car elle sera indispensable pour obtenir la preuve finale. Elle sera disponible dès lors que la transaction aura été intégrée dans un bloc. Il vous faudra donc vous armer de patience.
Le fichier de preuve est indispensable pour permettre de prouver l’ancrage du fichier et sa perte est irréversible. Comme nous le verrons par la suite, il est assez trivial de vérifier manuellement cet ancrage à partir du fichier de preuve à l’aide d’OpenTimestamps et d’un explorateur de blocs Bitcoin. Si vous avez l’âme d’un cypher punk, il est même possible de faire ces opérations à partir de son propre full node.
A quoi ça (ne) sert (pas)
L’ancrage d’un fichier au sein de Bitcoin est un outil particulièrement puissant. Cependant, comme le décrit si bien son créateur Peter Todd, il comporte de nombreuses limitations.
Si OpenTimestamps peut prouver l’existence d’un fichier avant une date, il ne dit rien sur la qualité ni sur l’intégrité de cette dernière.
Une personne malveillante peut très bien réaliser une imitation à la même date et la substituer à la donnée d’origine. OpenTimestamps ne certifie pas les données.
Reprenons l’exemple de notre couverture du Times. Qu’est-ce qui vous dit que je n’ai pas modifié l’image ? A-t-elle vraiment existé ? Une recherche sur le web vous le confirmera, mais OpenTimestamps se contentera de répondre “Ce fichier a bien été créé avant le 15 octobre 2019”.
Quand bien même l’information serait juste, l’horodatage ne prouve pas l’authenticité.
Par ailleurs, il est tout à fait possible de faire croire la justesse d’une prédiction. Il suffit d’en réaliser plusieurs, de les horodater et enfin, de publier la preuve de la prédiction la plus juste à une date antérieure.
En réalité, cet ancrage peut s’avérer pertinent pour limiter la surface d’attaque ou encore de faciliter l’identification de fraude à partir du moment cet outil s’intègre dans un processus cohérent.
TweetStamp, ou comment prouver l’existence d’un tweet
Le compte @tweet_stamp permet de prouver l’existence d’un tweet à l’aide d’OpenTimestamps. L’idée est plutôt séduisante puisqu’elle permet d’inscrire dans Bitcoin l’empreinte d’un tweet et ainsi prouver son existence même en cas de suppression de ce dernier.
Allons voir cela de plus près. Il suffit de préciser le mot clef “@tweet_stamp stamp” en réponse à un tweet pour que le robot @tweet_stamp enregistre et ancre le tweet d’origine dans le registre bitcoin.
Preuve en image, le robot nous donne le lien vers le site web fournissant les informations d’ancrage que l’on peut retrouver à cette adresse.
Le site semble être en maintenance, mais nous pouvons tout de même accéder aux informations du tweet et au lien de la preuve à l’adresse fournie par opentimestamps.org.
Comme nous pouvons le voir, l’empreinte du tweet est e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.
Il est à présent possible de vérifier par nous-mêmes cet ancrage. Il suffit de reprendre le tweet au format Stringifyed et d’en calculer l’empreinte.
Si vous disposez de linux, la commande sha256sum fera l’affaire. Dans le cas contraire, ce site vous permettra de calculer l’empreinte. Nous obtenons ce résultat : d1da0880b0b8e432d915ed875c8827bc187a83b7c621f1ecf19e754b40c1ad57.
Comme nous pouvons le constater, les empreintes ne correspondent pas. Cependant, si nous tentons de déterminer le sha256 d’une valeur vide, nous obtenons le même résultat que @tweet_stamps.
Ce qu’il faut comprendre, c’est que l’outil de @tweet_stamps ne fonctionne tout simplement pas (et depuis le début). Cette analyse a d’ailleurs été confirmée par Peter Todd, développeur d’OpenTimestamps.
Ceci nous rappelle que le simple fait d’utiliser Bitcoin et OpenTimestamps n’est pas une garantie suffisante et que nous ne devrions pas donner notre confiance sous prétexte d’usage d’une blockchain.
Comme la confiance ne suffit pas et qu’OpenTimestamps est un outil ouvert et documenté, nous allons analyser son fonctionnement en vérifiant l’ancrage de notre précédent ficher <genesis-block-newspaper-bitcoin.jpg>. Lors de mes premiers essais, OpenTimestamps.org m’a fourni la preuve temporaire que l’on peut retrouver sur ce lien. Derrière ce qui semble être du charabia, on peut identifier les éléments suivants :
- l’empreinte du fichier (50ec4f96a67e89d11b23b54260599d4df11b64c4351a86f43c5608ca6b9f34f5),
- une liste d’opérations,
- les serveurs de calendrier publics.
Pour vérifier l’empreinte SHA256 d’un fichier, rien de plus simple, la commande linux suivante permet de récupérer le résultat.
sha256sum genesis-block-newspaper-bitcoin.jpg
50ec4f96a67e89d11b23b54260599d4df11b64c4351a86f43c5608ca6b9f34f5 genesis-block-newspaper-bitcoin.jpg
Les opérations cryptographiques de la preuve temporaire se divisent en deux parties. La première est créée par le client OpenTimestamps et la seconde par le serveur de calendrier
La preuve prend la forme d’un arbre binaire dont la racine (1) est l’empreinte du fichier et les branches sont les opérations des serveurs de calendrier.
Hormis la racine, chaque étape reprend le résultat précédent et y applique une opération. Il en existe trois. Les deux premières permettent d’ajouter à droite (append) ou à gauche (prepend) du résultat précédent une valeur hexadécimale. La troisième opération permet de calculer l’empreinte numérique.
Prenons exemple avec notre empreinte précédente.
La première opération consiste à ajouter à 638e77329c80f59ea19168fd7b2c9ce4 à l’empreinte du fichier puis de le passer dans un sha256.
Il est possible de vérifier manuellement ces opérations sous Linux à l’aide de la commande suivante. Nous pouvons ainsi nous assurer manuellement du résultat.
echo -n "50ec4f96a67e89d11b23b54260599d4df11b64c4351a86f43c5608ca6b9f34f5638e77329c80f59ea19168fd7b2c9ce4" | xxd -r -p | sha256sum
8a306ab8ebb970f59e60da113b7ff5d8743199c67f647f4cffd985d49e76fb16
Le procédé est similaire pour les serveurs de calendrier. Ici il faudra :
- ajouter une chaine aléatoire à droite du précédent résultat,
- réaliser un sha256,
- ajouter une chaine aléatoire à gauche du sha256,
- ajouter une chaine aléatoire à droite du précédent résultat.
Dans ce bout de preuve, on peut voir que les opérations sont liées au serveur de calendrier dénommé Alice. Il existe deux autres que l’on retrouve sous Bob et Finney en hommage au regretté et emblématique cypherpunk Hal Finney.
Pour obtenir la preuve finale, il suffit de patienter une à deux journées et de soumettre la preuve temporaire et le fichier d’origine <genesis-block-newspaper-bitcoin.jpg> sur le démonstrateur opentimestamp.org. Ce dernier fourni le fichier de preuve finale qu’il vous faudra impérativement conserver.
On peut d’ailleurs la retrouver sur la page suivante : preuve finale. Comme nous pouvons le voir, cette preuve ressemble partiellement à la preuve temporaire. La différence significative est qu’elle donne les attestations des serveurs de calendriers ainsi que les opérations pour vérifier la véracité de ces dernières.
Reprenons le cas du serveur de calendrier Alice. A la suite des précédentes opérations de la preuve temporaire, nous trouvons de nouvelles opérations, la transaction d’ancrage ainsi que les attestations des serveurs de calendrier.
Pour étudier cette preuve, il est important de comprendre l’importance de l’arbre de merkle et son double usage.
Il s’agit d’une structure de données permettant de valider l’intégrité des données qu’il comporte. Pour Bitcoin, il est utilisé par les portefeuilles légers (SPV) pour vérifier l’existence d’une transaction dans un bloc en disposant uniquement de la racine de l’arbre (présent dans l’entête du bloc) et des cousins de la branche de l’arbre dans lequel est présente la transaction. Pour plus détails, je vous invite à lire l’article sur bitcoin.fr.
Nous retrouvons deux arbres de merkle dans une preuve finale. La première correspond aux opérations d’agrégations des serveurs de calendriers. Cet arbre permettra de vérifier que l’empreinte de notre fichier a bien été intégrée par le serveur dans la transaction d’ancrage.
Comme nous pouvons le voir sur la preuve finale, nous pouvons identifier le premier arbre de merkle correspondant à l’agrégation des fichiers réalisé par le serveur de calendrier.
En trichant un peu, on peut retrouver cet arbre en allant sur l’explorateur blockchair (lien de la transaction).
Le second arbre permet à l’instar des portefeuilles légers de vérifier que la transaction d’ancrage existe bien dans le bloc annoncé par le serveur de calendrier.
En suivant la liste des opérations fournies par les serveurs de calendrier, il est possible de vérifier les deux arbres de merkle. Il serait fastidieux de faire la vérification manuellement cependant, il est tout de même possible de vérifier la première opération du second arbre de merkle.
Petite note préalable, les transactions sont affichées en petit-boutiste alors que le calcul de l’arbre doit se faire en grand boutiste (calcul de l’arbre de merkle : et boutisme / endianness). Il faut donc inverser l’identifiant de la transaction octet par octet pour réaliser le calcul.
Comme nous pouvons le voir ici, nous réalisons une double opération sha256 sur la concaténation de notre transaction et de la transaction adjacente à notre transaction d’ancrage (44e984db70c1f5cfe9ac6ec115ba3d63d311de2535691e3f75d9ead1480ce280)
Nous obtenons ainsi le premier niveau de la branche de l’arbre dans lequel notre transaction est présente.
Pour s’assurer que notre transaction existe bien dans le bloc de l’attestation fournie par le calendrier, il suffit de réaliser toutes les opérations jusqu’à la dernière. Comme pour les transactions, la racine de l’arbre de merkle est inversée par rapport au calcul de ce dernier.
A l’aide de cette seule preuve et sans dépendre d’un explorateur de bloc, nous venons de vérifier que l’empreinte numérique de notre fichier existe dans la transaction et que cette dernière a bien été intégrée dans le bloc 599469.
Pour les plus téméraires, il est possible de croiser cette vérification avec son propre nœud bitcoin.
- Il faut d’abord obtenir le hash du block de l’attestation.
# bitcoin-cli getblockhash 599469
000000000000000000125ae96cdf952185d0a02a84b0fbe7db7a46bfe0b5b226
- Nous regardons si notre transaction d’ancrage est bien dans le bloc
# bitcoin-cli getblock 000000000000000000125ae96cdf952185d0a02a84b0fbe7db7a46bfe0b5b226 | grep 1b21f050178f143c210713343855b7d9d6885b7bc02f54f2e2264642e4761740
- On récupère la transaction brute
# bitcoin-cli getrawtransaction 1b21f050178f143c210713343855b7d9d6885b7bc02f54f2e2264642e4761740
01000000000101e8ea9f68336d582a64d6b849a...1252ada60726448a4f87df6063b64144acd7d33424d0b960cee715687fc2a839ac250900
- Et on la décode
# bitcoin-cli decoderawtransaction 01000000000101e8...0b960cee715687fc2a839ac250900
L’implémentation python est terriblement plus simple à utiliser. Vous la trouverez sur github.
Il vous suffira de mettre le fichier d’origine et sa preuve dans le même répertoire et de lancer la commande suivante.
# ots verify genesis-block-newspaper-bitcoin.jpg.ots
Si vous disposez de votre propre nœud bitcoin, vous serez au plus haut degré de minimisation de la confiance requise pour vérifier la preuve.
Pour résumé et conclure, OpenTimestamps est un outil très puissant pour horodater ses fichiers. Il est relativement souple puisqu’il peut même être utilisé avec Litecoin. Bien que l’usage des serveurs de calendriers publics est commode, il est possible de faire tourner son propre serveur et même de ne pas en utiliser du tout.
Concernant les serveurs de calendriers, bien qu’ils soient utilisés comme tiers de confiance, ils n’ont pas la capacité de fabriquer une fausse preuve. Tout au plus, ils peuvent ne pas fournir le service correctement et il reste possible d’installer son propre serveur ou encore de ne pas en utiliser du tout.
Malgré sa souplesse, il subsiste plusieurs limitations. Citons notamment le fait qu’une preuve ne puisse pas certifier la propriété ou encore que son format binaire n’est pas commode à manipuler dans un processus métier.
Jonathan Fraga
De formation réseau et sécurité, je suis tombé en 2014 dans Bitcoin. J'ai vécu la popularisation des "technologies blockchains" avec l'émergence de Ethereum et survécu à l'euphorie de 2017. J'aime analyser Bitcoin à travers ses concepts et sa technologie. J'aime encore plus partager mes découvertes.
