Déformations temporelles, vulnérabilités minières, attaques DOS, etc.
Mining in Verge : quand 5 algorithmes sont surpuissants
Traditionnellement, dans les crypto-monnaies basées sur le protocole de preuve de travail, les blocs sont extraits à l'aide d'un seul algorithme, le plus souvent SHA-256. Dans Verge, il était possible d'utiliser 5 algorithmes différents (pour les curieux - Scrypt, X17, Lyra2rev2, myr-groestl et blake2s.). La raison de l'utilisation de plusieurs algorithmes est décrite ci-dessous.
Certains critiques de Bitcoin soutiennent qu'au fil du temps Minage de bitcoins est devenu trop spécialisé et centralisé, la majeure partie de l'exploitation minière est effectuée sur des ASIC (abréviation de circuit intégré spécifique à l'application) - des appareils conçus exclusivement pour l'extraction de devises, et l'essentiel de l'extraction de Bitcoin est effectué dans plusieurs pools de minage par des groupes de mineurs qui mettent en commun leurs ressources et partager ce qu'ils gagnent entre eux. Ces tendances vers différents types de « centralisation », disent-ils, contredisent le principe fondamental des crypto-monnaies. L'utilisation d'une pièce avec plusieurs algorithmes de minage contrebalance ces tendances. La raison en est que la gestion de cinq algorithmes différents en termes de matériel, de production et de gestion des ressources sera inévitablement plus difficile que le contrôle d'un algorithme, permettant à Verge d'obtenir une plus grande décentralisation et distribution de l'exploitation minière.
La situation est la suivante : le seul moyen d'obtenir un fonctionnement correct - et le concept de "fonctionnement correct" dans ce cas comprend le maintien d'un intervalle de 30 secondes entre les blocs, le maintien de la faisabilité économique des cinq algorithmes pour les mineurs et la prévention de la domination de un algorithme (ce qui rendrait toute l'expérience dénuée de sens) - pour faire en sorte que chaque algorithme ait son propre paramètre de difficulté, qui serait ajusté indépendamment des quatre autres. En d'autres termes, la difficulté d'extraction dans l'algorithme Scrypt est ajustée pour observer un intervalle de 30 secondes pour chaque bloc, comme dans X17 et d'autres algorithmes.
Cela signifie que notre hacker n'a pas vraiment réduit la difficulté de minage pour l'ensemble du réseau ; il ne l'a déclassé que pour ceux qui ont miné en utilisant l'un des cinq algorithmes - Scrypt. Et tandis que les mineurs de Scrypt profitaient d'un minage ridiculement facile, pour le reste des mineurs travaillant sur d'autres algorithmes, la complexité des tâches n'a pas diminué, ce qui signifie que toute leur puissance combinée ne contribuera pas à assurer la sécurité du réseau. Cela signifiait que l'attaquant ne travaillait qu'avec l'algorithme Scrypt et devait rivaliser avec d'autres utilisateurs qui faisaient de même ; ainsi, la puissance de hachage requise pour notre attaquant n'était pas supérieure à 50 % (domination sur l'ensemble du réseau), mais seulement supérieure à 10 % (domination sur les autres mineurs Scrypt).
Nous allons maintenant entrer dans le domaine de la spéculation, mais il semble que la situation était encore pire. Nous avons supposé un chiffre de 10%, basé sur le fait qu'approximativement la même quantité de ressources devrait être allouée pour chaque algorithme (c'est l'essence du mécanisme de définition de la difficulté de minage). En réalité, cependant, les axiomes d'une économie de marché ne sont pas toujours respectés. La communauté pense que divers facteurs - par exemple, l'existence d'ASIC non activés pour Scrypt, ainsi que des ressources gratuites disponibles à la location via Nicehash, etc. - ont conduit au fait que la domination de l'exploitation minière sur Scrypt pendant l'attaque a été beaucoup moins cher que n'importe quel autre des quatre algorithmes. Il est prudent de supposer que le taux de hachage requis a fini par être bien inférieur à 10% - selon certaines estimations préliminaires données sur Reddit, le taux de hachage pourrait être aussi bas que 0,4%.
Pour résumer : les faux horodatages ont considérablement réduit la complexité du minage ; l'utilisation de cinq algorithmes a permis de réduire la complexité pour un seul d'entre eux, ce qui a grandement simplifié la capture de l'ensemble du réseau ; le statut économique et de production de cet algorithme de minage particulier a rendu la capture encore plus facile ; et enfin, en raison de la complexité réduite de l'exploitation minière, le temps de formation des blocs a été fortement réduit, ce qui a rendu l'attaque environ 30 fois plus rentable.
Leçons apprises
Quelle conclusion peut-on tirer de cette situation ? Les conséquences à court terme du piratage étaient prévisibles chaotiques et incompréhensibles. Quelques jours plus tard, les principaux développeurs ont corrigé plusieurs bugs à l'aide d'utilitaires, dans lesquels des erreurs peuvent également se glisser, et finalement un hard fork a été effectué sur le réseau, ce qui aurait pu initialement se produire par accident (ou pas par accident) . En termes de réaction mondiale, dans la semaine qui a suivi le piratage, le prix de Verge a augmenté de 30% et la semaine suivante, il a été annoncé que la devise Verge serait acceptée comme frais d'abonnement sur pornhub.com. Comment le plus grand piratage de crypto-monnaie au niveau du protocole aurait-il pu conduire à la croissance de la valeur de cette monnaie et, plus tard, à la conclusion d'un partenariat avec le site porno le plus visité - je laisserai cette question ouverte. Personnellement, je pense que c'est juste qu'il n'y a pas de sens dans le monde, et les gens sont complètement fous.
Mais je m'égare. Plus globalement, plusieurs enseignements peuvent être tirés de cette situation :
Premièrement, la technique consistant à utiliser des horodatages pour réduire artificiellement la complexité est en fait connue depuis longtemps et a même réussi à obtenir le nom - la vulnérabilité "time-warp". Il y a plusieurs années, un vecteur d'attaque a été discuté sur le forum Bitcoin. Dans une certaine mesure, l'utilisation du nouvel algorithme d'ajustement de la difficulté Dark Gravity Well, dans lequel la difficulté est ajustée à chaque nouveau bloc, a aidé à mettre en œuvre l'attaque sur Verge. En Bitcoin, la difficulté ne change que tous les 2016 blocs. Malgré le fait qu'un réglage de difficulté aussi long et intermittent puisse sembler une décision étrange, le piratage Verge a clairement indiqué qu'il s'agissait en fait d'une mesure de sécurité : s'il existe un moyen dans Bitcoin de réduire la complexité de l'exploitation minière, alors un attaquant ne peut le faire qu'une fois toutes les 2 semaines, ce qui rend les résultats de l'attaque insignifiants par rapport à Verge, où les pirates peuvent réduire la difficulté de minage toutes les 30 secondes.
Fait intéressant, l'un des prétendus avantages de Dark Gravity Wave est qu'il doit être immunisé contre une vulnérabilité de distorsion temporelle. Compte tenu de la force avec laquelle cette hypothèse a été réfutée, les autres devises utilisant cet algorithme devraient au moins devenir nerveuses.
Quant à l'utilisation des cinq algorithmes : bien qu'à première vue, cela semble être une expérience valable dans un environnement décentralisé économiquement stimulant, il introduit de nouvelles complexités qui augmentent inévitablement la probabilité que des vulnérabilités imprévues se produisent.
Dans les deux cas, ce hack constitue un argument de poids en faveur de mécanismes éprouvés, et appelle à la prudence pour compliquer et introduire des risques inutiles liés aux actifs financiers des personnes. Dans ces domaines, l'équipe Bitcoin s'est montrée à son meilleur.
La question est un peu plus large : les développeurs de logiciels, bien qu'ils hésitent à l'admettre, ne sont finalement que des humains. Même lorsque les principes de sécurité de base semblent parfaitement fondés, il peut toujours y avoir une marge d'erreur. Il y a des attaques inattendues, les compromis ne sont pas toujours payants et, bien sûr, personne n'a annulé la possibilité de bons vieux bugs. Les logiciels ne fonctionnent pas toujours comme nous le souhaitons, et personne en 2018 ne sera surpris que des bogues comme celui-ci puissent entraîner une perte de fonds. Mais quand le logiciel само il est l'argent, nous devons être particulièrement prudents.
Considérant que la plupart d'entre nous n'ont pas le temps libre pour effectuer une revue de code approfondie de chaque projet dans lequel nous investissons, la meilleure protection contre les catastrophes est la confiance dans des systèmes éprouvés avec une expérience de travail positive et une approche conservatrice du développement.
Et si vous souhaitez parier sur certains fonds dans des projets pilotes liés au transfert d'argent, vous devez au moins être conscient des risques. En fin de compte, la meilleure défense est lorsque la communauté exige que des mesures appropriées soient prises pour prévenir de futures catastrophes. Si je ne me trompe pas, George Santayana a déclaré : « Ceux qui ne peuvent pas apprendre des failles de sécurité du passé sont condamnés à les répéter encore et encore à l'avenir. » Ces mots doivent être rappelés afin que nous ne répétions pas, de manière inattendue pour nous-mêmes, les erreurs du passé.