Faille de sécurité du Bitcoin : l'attaque par distorsion temporelle
TechFlow SélectionTechFlow Sélection
Faille de sécurité du Bitcoin : l'attaque par distorsion temporelle
Dans cet article, nous analysons une vulnérabilité de sécurité du Bitcoin, connue sous le nom d'attaque par distorsion temporelle.
Dédié à des analyses Web3 approfondiesRédaction : BitMEX Research
Synthèse
Le 26 mars 2025, le développeur Bitcoin Antoine Poinsot a publié une nouvelle proposition d'amélioration du protocole Bitcoin (BIP). Il s'agit d'une proposition de bifurcation souple appelée « Grand nettoyage du consensus ». Cette mise à niveau corrige plusieurs vulnérabilités et failles présentes depuis des années dans le protocole Bitcoin. L'une de ces failles est le problème des transactions en double que nous avons récemment abordé. Une autre vulnérabilité plus grave, qui sera corrigée par ce nettoyage via bifurcation souple, est connue sous le nom d'« attaque par distorsion temporelle », sujet principal de cet article.
Règles de protection contre la manipulation des horodatages dans Bitcoin
Avant d’aborder l’attaque par distorsion temporelle, rappelons les règles actuelles de protection contre la manipulation du temps :
Règle du Temps Médian du Passé (MPT) — L’horodatage doit être postérieur au temps médian des onze derniers blocs.
Règle des blocs futurs — Selon la constante MAX_FUTURE_BLOCK_TIME, un horodatage ne peut excéder de plus de 2 heures le temps médian des pairs du nœud. Un écart maximal de 90 minutes entre le temps fourni par les pairs et l’horloge système locale est autorisé, constituant une sécurité supplémentaire.
La règle MPT vise à empêcher qu’un bloc ne remonte trop loin dans le passé, tandis que la règle des blocs futurs évite qu’il ne saute trop en avant. Notons qu’une règle similaire à celle des blocs futurs ne peut pas être appliquée pour empêcher des horodatages passés, car cela pourrait nuire à la synchronisation initiale de la blockchain. L’attaque par distorsion temporelle implique de falsifier les horodatages afin de les reporter largement dans le passé.
L'erreur d'indexation dite « off-by-one » de Satoshi
Dans Bitcoin, un cycle de réglage de difficulté comprend 2016 blocs, soit environ deux semaines avec un objectif de 10 minutes par bloc. Pour calculer l’ajustement de difficulté, le protocole mesure la différence entre les horodatages du premier et du dernier bloc de cette fenêtre de 2016 blocs. Cette fenêtre couvre en réalité 2015 intervalles entre blocs (soit 2016 moins un). Ainsi, le temps cible pertinent devrait être de 60 secondes × 10 minutes × 2015 intervalles = 1 209 000 secondes. Or, le protocole Bitcoin utilise le chiffre 2016 dans son calcul : 60 secondes × 10 minutes × 2016 = 1 209 600 secondes. C’est une erreur d’indexation. Une erreur facile à commettre, où Satoshi semble avoir confondu nombre de blocs et nombre d’intervalles entre blocs.
Code original de Satoshi
Source : https://sourceforge.net/p/bitcoin/code/1/tree//trunk/main.cpp#l687
Cette erreur signifie que le temps cible est plus long de 0,05 %. Par conséquent, l’intervalle cible de Bitcoin n’est pas exactement 10 minutes, mais 10 minutes et 0,3 seconde. Cette faille n’a pas grande importance. En réalité, depuis le lancement de Bitcoin, l’intervalle moyen a été de 9 minutes 36 secondes, nettement inférieur à 10 minutes, en raison de la croissance continue de la puissance de calcul moyenne depuis 2009. C’est pourquoi la dernière halving a eu lieu en avril 2024 plutôt qu’en janvier 2025. Nous avons pris de l’avance. En tout état de cause, cette erreur de 0,3 seconde due à Satoshi est négligeable à l’échelle globale. Peut-être qu’un jour, dans un lointain futur où le prix et la puissance de calcul cesseront de croître, cette faille nous remettra sur la bonne trajectoire.
Bien que la faille de 0,3 seconde ne soit pas critique en soi, elle est liée à un problème plus sérieux. Le calcul de difficulté repose sur les premier et dernier blocs de chaque fenêtre de 2016 blocs. Ce choix est également erroné. À notre avis, la période pertinente devrait correspondre à l’intervalle entre le dernier bloc de la fenêtre précédente et le dernier bloc de la fenêtre actuelle. Cela apparaît comme la méthode la plus logique pour mesurer la durée d’un cycle d’ajustement, en assurant une continuité temporelle entre cycles successifs. Si cette approche était adoptée, alors 2016 serait effectivement le bon nombre d’intervalles à utiliser dans le calcul cible. Peut-être que Satoshi a commis cette erreur parce qu’il devait tenir compte du tout premier cycle d’ajustement, pour lequel aucun bloc terminal du cycle précédent n’était disponible.
Attaque par distorsion temporelle
L’attaque par distorsion temporelle dans Bitcoin aurait été découverte vers 2011, exploitant l’erreur de Satoshi dans le calcul de difficulté. Supposons que le minage soit entièrement centralisé et que le mineur puisse fixer n’importe quel horodatage autorisé par le protocole. Dans cette attaque, pour presque tous les blocs, le mineur règle l’horodatage à une seconde après celui du bloc précédent, faisant ainsi progresser régulièrement la chaîne dans le temps tout en respectant la règle MTP. Pour ralentir au maximum l’avancement temporel, le mineur peut maintenir six blocs consécutifs avec le même horodatage, puis avancer d’une seconde au septième bloc, et ainsi de suite. Cela signifie que l’horodatage progresse d’une seconde toutes les six unités de temps.
Cette attaque fait que la blockchain retarde de plus en plus par rapport au temps réel, augmentant artificiellement la difficulté et rendant le minage plus ardu. Toutefois, pour renforcer l’efficacité de l’attaque, lors du dernier bloc de chaque cycle de difficulté, le mineur attribue un horodatage correspondant au temps réel. Le bloc suivant, premier bloc de la nouvelle fenêtre d’ajustement, est alors daté du passé, précisément une seconde après l’avant-dernier bloc de la fenêtre précédente. Cette manipulation reste conforme à la règle MTP, car une anomalie ponctuelle n’affecte pas la médiane des 11 blocs.
Avec cette stratégie, la difficulté n’est pas modifiée après le premier cycle. En revanche, dès le deuxième cycle d’ajustement après le début de l’attaque, la difficulté diminue. Le mineur peut alors produire des blocs à très haute vitesse, générant massivement des bitcoins, qu’il pourrait vendre pour réaliser un profit.
Explication simplifiée
Étant donné que les cycles de difficulté comprennent 2016 blocs, illustrer cette attaque graphiquement peut s’avérer complexe. Nous proposons donc le scénario suivant pour en faciliter la compréhension :
-
Chaque fenêtre d’ajustement de difficulté contient 5 blocs
-
L’intervalle cible est de 10 minutes
-
La règle MTP repose sur les trois derniers blocs
-
Chaque bloc voit son horodatage augmenter d’une minute, sauf le dernier bloc de chaque cycle, qui reçoit un horodatage réel
Illustration de l’attaque par distorsion temporelle
Comme indiqué sur le graphique ci-dessus, deux courbes sont visibles :
-
Une courbe représentant le temps réel du dernier bloc de chaque fenêtre d’ajustement de difficulté. À mesure que le mineur trouve des blocs plus rapidement, la difficulté diminue et la pente de la courbe s’aplatit
-
Une ligne droite représentant les horodatages manipulés des autres blocs
Calcul de l’attaque par distorsion temporelle dans Bitcoin
Le tableau ci-dessous montre comment un mineur peut exploiter cette attaque de manière extrême pour forcer une baisse de la difficulté.
Note : L’ajustement maximal de difficulté autorisé par le protocole est limité à un facteur 4, seuil non atteint dans ce tableau
L’ajustement descendant de la difficulté tend asymptotiquement vers une valeur légèrement supérieure à 2,8 fois. En effet, à mesure que chaque cycle se raccourcit dans le temps, la vitesse de décélération de l’ajustement diminue.
Au onzième cycle du tableau, le 39ᵉ jour de l’attaque, plus de 6 blocs sont produits par seconde, précisément 10,9 blocs par seconde. À ce stade, la limite imposée aux horodatages entre blocs commence à jouer différemment. Selon la règle MTP, le temps doit avancer d’au moins une seconde toutes les six unités. À partir de ce point, selon notre analyse, les horodatages commencent à progresser plus vite que le temps réel, et l’horloge de la blockchain se remet à avancer, se rapprochant du temps réel bien qu’elle reste encore largement en retard. Néanmoins, l’attaque peut se poursuivre, la difficulté continuant de baisser jusqu’à atteindre sa valeur minimale autorisée.
Faisabilité de l’attaque
Bien que théoriquement dévastatrice, cette attaque présente plusieurs obstacles pratiques. Sa mise en œuvre nécessiterait probablement la majorité de la puissance de calcul. La présence de mineurs honnêtes fournissant des horodatages corrects rendrait l’attaque plus difficile. La règle MTP et les horodatages honnêtes pourraient limiter la capacité du mineur malveillant à reculer dans le temps. De plus, si un mineur honnête produit le premier bloc d’une fenêtre d’ajustement, le cycle d’attaque échoue. Un autre facteur atténuant est que l’attaque serait visible par tous : toute personne pourrait observer la manipulation des horodatages durant environ quatre semaines avant la baisse de difficulté, ce qui laisserait potentiellement assez de temps pour déployer un correctif d’urgence via une bifurcation souple.
Solution
Corriger cette vulnérabilité est relativement simple, bien que cela puisse nécessiter une modification du protocole par bifurcation souple. Modifier directement l’algorithme d’ajustement de difficulté pour mesurer l’intervalle entre les blocs terminaux de fenêtres successives de 2016 blocs, corrigeant complètement l’erreur d’indexation, serait techniquement complexe et pourrait même exiger une bifurcation dure. Une autre approche consisterait à supprimer la règle MTP et d’exiger que chaque nouveau bloc ait un horodatage strictement supérieur au précédent. Toutefois, cela pourrait entraîner un blocage du temps trop loin dans le futur, ou poser problème aux mineurs utilisant une horloge précise si un autre mineur dispose d’une horloge avançant de quelques secondes, rendant leurs blocs invalides.
Heureusement, une solution plus simple existe. Pour prévenir l’attaque par distorsion temporelle, il suffit d’exiger que le premier bloc d’un nouveau cycle de difficulté n’ait pas d’horodatage antérieur à un certain nombre de minutes avant le dernier bloc du cycle précédent. Ce délai minimal a fait l’objet de discussions, avec des propositions allant de 10 minutes à 2 heures. Pour ce qui est de contrer l’attaque par distorsion temporelle, les deux options sont envisageables.
Dans la proposition de « grand nettoyage du consensus » d’Antoine Poinsot, ce délai est fixé à 2 heures. Ce laps de temps représente seulement environ 0,6 % de la durée cible d’un cycle d’ajustement, limitant ainsi fortement la possibilité de manipulation descendante de la difficulté. Le tableau ci-dessous résume les discussions relatives à la durée appropriée de ce délai de grâce :
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@BitMEX
