Aller au contenu
Financial Context Wiki

Attaques PoS à longue portée : clés historiques, risque d'amorçage et points de contrôle

Une attaque PoS à longue portée présente un historique alternatif signé avec l'autorité d'anciens validateurs. Découvrez quels nœuds sont exposés, ce que l'attaquant doit reproduire et comment les points de contrôle de faible subjectivité et les règles de synchronisation propres au protocole limitent le risque.

Mis à jour

Analyse de sécurité des protocoles à visée éducative uniquement. La résistance aux attaques à longue portée dépend du protocole et de sa version ; obtenez les données d’amorçage auprès de sources authentifiées et vérifiées indépendamment avant de vous fier à un nœud nouvellement synchronisé ou resté longtemps hors ligne.

Réponse directe

Une attaque proof-of-stake à longue portée tente de rendre crédible un historique conflictuel en utilisant une autorité de validation qui était légitime dans un passé lointain. Une forme courante, souvent appelée corruption postérieure, consiste à acquérir ou compromettre les clés de validateurs après leur sortie, lorsque leur garantie ne peut plus être soumise au slashing. Comme la production d’anciennes signatures n’exige pas de reproduire l’énergie consommée par le proof-of-work, l’adversaire peut parfois construire une branche cohérente à un coût faible par rapport au coût historique de la chaîne honnête.

La cible est généralement un nœud dépourvu de vue récente authentifiée : un nœud lancé pour la première fois, restauré depuis une ancienne sauvegarde ou resté hors ligne au-delà de l’horizon de synchronisation sûr du protocole. Un nœud qui observe continuellement le réseau connaît déjà un ancêtre finalisé ou autrement protégé et devrait rejeter toute branche qui entre en conflit avec lui. Une attaque par éclipse ou une source de données compromise peut donc amplifier l’attaque en masquant la vue honnête au nœud en cours de synchronisation.

Les clés historiques ne constituent pas à elles seules un outil universel de falsification. L’historique alternatif doit respecter les domaines de signature, les transitions d’état, l’évolution de l’ensemble des validateurs, les règles temporelles, les preuves de finalité ou de sélection de chaîne, ainsi que les éventuelles contraintes d’évolution des clés ou de points de contrôle du protocole visé. Certains protocoles PoS exigent un point de contrôle récent de faible subjectivité ; d’autres définissent un amorçage depuis la genèse ou des hypothèses différentes de confiance et de disponibilité. Il faut analyser la chaîne, le réseau, la version de fork, le client et le mode de synchronisation exacts, plutôt que de traiter le « PoS » comme un mécanisme unique.

Un point de contrôle n’est pas simplement un numéro de bloc pratique. Il associe un réseau et un état de consensus précis à une racine ou à un hachage, à une époque, un slot ou une hauteur donnés. Une fois authentifié, il limite les historiques que le nœud acceptera d’examiner. Le reste de la chaîne peut alors être vérifié à partir de cette ancre selon les règles du protocole. C’est le principe de la faible subjectivité : une donnée externe limitée lors de l’amorçage, suivie d’une validation objective pendant la période supposée, plutôt qu’une confiance permanente dans la tête de chaîne annoncée par un pair.

Parcours de l’attaque et de la vérification

  1. Choisir un ancien point de divergence. L’adversaire repère un état historique dont l’autorité de validation a depuis été renouvelée ou qu’un nouveau nœud peut difficilement authentifier de manière indépendante.
  2. Obtenir une puissance de signature historique suffisante. Après la sortie des validateurs, leurs clés peuvent être achetées, volées, conservées, récupérées depuis des sauvegardes ou exposées par des systèmes de signature compromis. Le poids et les types de messages requis dépendent du protocole ; posséder une seule ancienne clé de proposant de bloc ne suffit pas automatiquement.
  3. Construire une alternative valide selon le protocole. L’adversaire produit des blocs, des votes, des certificats et des changements d’ensemble de validateurs qui passent les contrôles historiques du client victime. Une transition d’état invalide, un domaine erroné, une chronologie impossible ou une preuve manquante peut toujours invalider la branche.
  4. Prolonger et présenter la branche. La production peu coûteuse de signatures peut permettre de remplir un long historique, mais le nombre brut de blocs n’est pas décisif. La branche doit gagner ou contourner la procédure de sélection précise employée par ce mode de synchronisation.
  5. Contrôler la vue d’amorçage. La victime est isolée d’un point de contrôle récent authentifié ou des preuves de pairs honnêtes, et l’historique alternatif lui est présenté comme l’unique candidat ou le candidat privilégié.
  6. Provoquer une dépendance en aval. Si le nœud accepte le mauvais état, son RPC, son portefeuille, son indexeur, son moniteur de pont ou son application peut afficher des soldes, des événements et une composition des validateurs valides selon le protocole sur la branche de l’attaquant, alors même que le réseau actif suit une autre chaîne.

Le défenseur doit reproduire ce parcours en sens inverse : authentifier une ancre, confirmer l’identité de sa chaîne et de son réseau, vérifier que le candidat en descend, exécuter tous les contrôles de consensus et de transition d’état, puis comparer l’état finalisé ou sélectionné sur des infrastructures indépendantes. La réussite d’un téléchargement ne prouve pas que l’historique sélectionné est canonique.

Exemple détaillé

Supposons que l’ensemble de validateurs V_old contrôlait une chaîne PoS hypothétique à l’époque 120,000. Des années plus tard, plus de 2/3 de ce poids historique a quitté le système et n’est plus exposé aux pénalités du protocole. Un adversaire obtient ces anciennes clés et commence un historique conflictuel immédiatement après le point de contrôle C_old.

Sur la branche fabriquée, l’adversaire signe les votes exigés par ce protocole hypothétique, modifie ensuite la composition des validateurs et poursuit jusqu’à l’époque 420,000. Le réseau honnête a lui aussi atteint l’époque 420,000 ; des numéros d’époque identiques ou un fichier plus long ne permettent donc pas à un nœud en cours d’amorçage de savoir quelle branche est canonique sur les plans social et opérationnel. L’admissibilité même de la branche fabriquée dépend de chacune des règles historiques du protocole.

Le nœud N_live a observé le véritable point de contrôle finalisé C_recent à l’époque 419,936. Comme la branche d’attaque ne descend pas de C_recent, N_live la rejette. Le nœud N_new, en revanche, part de la genèse, se connecte uniquement à des pairs adverses et ne possède aucune ancre récente authentifiée. Si son protocole et son mode de synchronisation ne peuvent pas distinguer les historiques à partir de leurs seules preuves internes, il peut accepter la branche d’attaque.

Fournir à N_new la paire authentifiée C_recent = (root, 419,936) modifie la frontière de décision. Le client doit exiger que le chemin de synchronisation contienne exactement ce point de contrôle et s’arrêter de manière sûre si ce n’est pas le cas. Les époques et le seuil de 2/3 de cet exemple illustrent un modèle de finalité particulier ; ils ne constituent ni des paramètres universels du PoS ni les réglages actuels d’un réseau nommé.

Contrôles et liste de vérification

Conception du protocole

  • Documenter précisément le modèle de sécurité à longue portée : corruption postérieure, rotation des validateurs, compromission adaptative des clés, isolement réseau et disponibilité des données.
  • Définir quels états finalisés ne peuvent jamais être annulés et comment la règle de choix de branche traite un conflit avec une ancre approuvée localement.
  • Borner les sorties et retraits des validateurs ainsi que la rotation de l’ensemble, afin que les hypothèses de sécurité restent pertinentes tout en permettant de détecter et de sanctionner les doubles votes.
  • Définir la période de faible subjectivité, ou une autre hypothèse de sûreté de synchronisation, comme une valeur dérivée de l’état courant et des constantes du protocole, et non comme une durée calendaire immuable.
  • Envisager des signatures à évolution de clé ou résistantes à une compromission ultérieure lorsque le protocole le permet ; la simple suppression des clés est une bonne mesure d’hygiène, mais pas une défense de consensus complète.
  • Tester séparément la première synchronisation, la synchronisation par point de contrôle, la restauration d’un instantané et la reprise après une longue période hors ligne. Une règle de choix de branche sûre en fonctionnement normal ne garantit pas automatiquement un amorçage sûr.

Amorçage et exploitation des nœuds

  • Avant la synchronisation, consigner la racine du point de contrôle ou le hachage du bloc, l’époque ou la hauteur, l’identifiant de chaîne, le réseau, la version de fork, l’heure d’obtention et le fournisseur.
  • Obtenir les ancres par des canaux authentifiés et comparer plusieurs sources réellement indépendantes. Plusieurs sites web reposant sur le même nœud ou le même opérateur ne sont pas indépendants.
  • Rejeter les points de contrôle périmés, mal formés, associés au mauvais réseau ou contradictoires. Ne pas revenir silencieusement à une synchronisation sans ancre après un échec de validation.
  • Exiger que la chaîne synchronisée contienne l’ancre exacte et vérifier tous ses descendants avec les clients de consensus et d’exécution prévus.
  • Diversifier les pairs, les clients, les opérateurs et les RPC ; surveiller les situations d’éclipse, les divergences de racines finalisées, les retours en arrière inhabituels et les pannes prolongées de finalité.
  • Revérifier l’ancre après la restauration d’une ancienne base de données ou sauvegarde, et l’actualiser pendant la période sûre documentée par le protocole.

Dépendance des applications

  • Ne pas libérer de dépôts, de messages de pont ou de transactions irréversibles au seul motif qu’un RPC nouvellement synchronisé signale une réussite.
  • Avant toute action importante, rapprocher l’identité de la chaîne, le point de contrôle finalisé et l’ascendance des événements entre plusieurs nœuds indépendants.
  • Distinguer l’historique du consensus de la vérité applicative : une chaîne canonique ne prouve ni l’exactitude d’un oracle, ni la sûreté d’un contrat, ni la disponibilité de données hors protocole, ni la solvabilité d’un dépositaire.
  • Préparer une politique d’arrêt en cas de points de contrôle finalisés ou d’ancres de confiance contradictoires. Cette situation peut révéler une défaillance du consensus, des données d’amorçage corrompues ou un mauvais réseau ; elle ne doit pas être résolue automatiquement en choisissant la branche la plus longue.

Idées reçues courantes

  • Toutes les chaînes PoS sont vulnérables de la même manière. La résistance à longue portée dépend de l’évolution des validateurs, des signatures, de la finalité, du choix de branche, des points de contrôle et des hypothèses de synchronisation du protocole.
  • Les anciennes clés permettent de réécrire n’importe quelle transaction sans contrainte. L’attaquant doit toujours produire un historique accepté par l’ensemble des règles de validation de la victime ; l’autorité historique n’est nécessaire que dans certaines constructions d’attaque et peut ne pas être suffisante.
  • La chaîne qui comporte le plus de blocs, d’époques ou de signatures est la véritable chaîne. La sélection repose sur la validité, le poids, les certificats et les ancres propres au protocole, et non sur une comparaison universelle de longueur.
  • La finalité suffit à un nœud partant de la genèse pour identifier la chaîne reconnue socialement. Deux historiques finalisés et valides en interne peuvent être ambigus pour un nœud sans vue récente authentifiée ; la finalité protège un nœud qui connaît déjà le point de contrôle pertinent.
  • Le slashing dissuade toujours l’attaque. Les validateurs ayant entièrement retiré leurs fonds peuvent ne plus avoir de garantie à pénaliser, et les preuves doivent être attribuables et traitées tant que les sanctions restent applicables.
  • Un point de contrôle revient à faire confiance à une entreprise pour toujours. La confiance peut être limitée à une ancre récente précise et réduite grâce à une distribution authentifiée, à des recoupements indépendants et à une vérification locale ultérieure.
  • Supprimer les clés retirées résout le problème du protocole. L’effacement sécurisé réduit le risque de compromission, mais des règles robustes de consensus et d’amorçage doivent tolérer que certaines clés historiques deviennent disponibles.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...