Aller au contenu
Financial Context Wiki

Rotation des signataires multisig

Une procédure axée sur la vérification pour remplacer des signataires multisig tout en préservant le quorum, en contrôlant l'ensemble des propriétaires et le seuil exacts on-chain et en réagissant sûrement à une clé compromise.

Mis à jour

À des fins éducatives uniquement ; ne constitue pas un conseil en investissement, juridique ou de sécurité. Une erreur de rotation peut transférer le contrôle, invalider des approbations en attente ou verrouiller définitivement un compte multisig.

Réponse directe

La rotation des signataires multisig modifie les comptes autorisés à approuver des transactions. Elle ne nécessite normalement ni nouvelle adresse de portefeuille ni transfert d’actifs : une transaction privilégiée modifie l’ensemble des propriétaires du compte et parfois son seuil d’approbation. Les implémentations diffèrent ; vérifiez donc le contrat déployé et l’état on-chain actuel au lieu de supposer que les libellés de l’interface décrivent correctement les pouvoirs.

Une rotation sûre prouve d’abord le contrôle de chaque nouveau signataire, conserve pendant tout le changement un quorum exécutable mais non concentré, retire l’ancien signataire et vérifie l’état final on-chain. Perdre le quorum requis avant l’exécution peut rendre impossible une rotation ordinaire des propriétaires ; abaisser le seuil par commodité peut créer une fenêtre de prise de contrôle.

La personne, l’appareil de signature, la clé privée et l’adresse de propriétaire on-chain sont des éléments distincts. Documentez l’adresse exacte, le dépositaire, le domaine de contrôle indépendant, l’état de la sauvegarde et le motif de la rotation. Aucune rotation légitime n’exige qu’une personne révèle une phrase de récupération ou une clé privée.

Fonctionnement

  1. Inventorier les pouvoirs actuels. À partir d’une chaîne et d’une adresse de compte vérifiées indépendamment, lisez l’implémentation déployée, la liste des propriétaires, le seuil, le nonce, les modules activés, les guards, le fallback handler, la voie de récupération et tout timelock. Un module ou un mécanisme de récupération peut exécuter hors du seuil ordinaire des propriétaires, tandis qu’un guard restrictif peut bloquer une rotation autrement valide.
  2. Définir l’état cible avant de signer. Consignez l’ensemble exact des propriétaires et le seuil après le changement. Confirmez que le seuil ne dépasse pas le nombre de propriétaires et qu’au moins autant de signataires indépendants resteront opérationnels. Une séparation géographique n’est pas une indépendance si une même personne, un coffre de mots de passe, un compte cloud ou un administrateur contrôle tous les appareils.
  3. Enrôler et authentifier le nouveau signataire. Générez ou restaurez la nouvelle clé dans son environnement de conservation prévu, vérifiez l’adresse sur un appareil de confiance et prouvez le contrôle au moyen d’un défi convenu ou d’une signature de test. Confirmez l’adresse par un second canal authentifié ; ne vous fiez pas uniquement à un texte copié depuis une discussion ou à une interface de portefeuille.
  4. Choisir un ordre aux états intermédiaires sûrs. Certains contrats peuvent remplacer atomiquement un propriétaire. Safe, par exemple, expose swapOwner ; il expose aussi addOwnerWithThreshold, removeOwner et changeThreshold. Si une implémentation exige plusieurs transactions, analysez l’ensemble des propriétaires et le seuil après chaque étape. Ajoutez et vérifiez la capacité avant de la retirer, sauf si une compromission active rend cet ordre dangereux.
  5. Décoder et simuler la transaction exacte. Vérifiez indépendamment le chain ID, l’adresse du compte, la cible, le sélecteur de fonction, les anciennes et nouvelles adresses de propriétaire, le seuil résultant, le nonce, la valeur et le type d’opération. Traitez delegatecall, le regroupement, les changements de module et les changements de guard comme des effets à haut risque distincts. Chaque signataire doit approuver le même payload décodé et le même hachage de transaction.
  6. Exécuter avec les pouvoirs existants. Le quorum valide actuel autorise la rotation, sauf indication contraire d’une voie de récupération documentée. En cas d’urgence, coordonnez-vous uniquement par des contacts authentifiés et utilisez des signataires non compromis. Si ni le quorum normal ni une autorité de récupération préconfigurée ne restent disponibles, un appel standard de gestion des propriétaires ne peut pas restaurer l’accès.
  7. Vérifier et clôturer le changement. Après confirmation, interrogez directement l’ensemble des propriétaires et le seuil, examinez les événements émis ou les traces selon l’implémentation et confirmez que l’ancienne adresse n’est plus autorisée. Faites participer le nouveau signataire à une transaction approuvée, à faible risque ou de valeur nulle, qui exige le seuil prévu. Examinez les transactions en attente, révoquez les accès hors chaîne et les sauvegardes de l’ancien signataire, puis archivez la proposition, les signatures, le hachage de transaction, le bloc et l’état final.

Exemple détaillé

Supposons qu’un compte 3-of-5 ait pour propriétaires A, B, C, D et E, et que B doive être remplacé par F. L’équipe vérifie d’abord que F contrôle l’adresse exacte proposée et reste indépendant des autres propriétaires. Pour un déploiement Safe compatible, elle prépare swapOwner(prevOwner, B, F). L’appel est lui-même une transaction Safe et nécessite donc 3 confirmations valides de l’ensemble actuel des propriétaires. Son résultat décodé doit conserver un total de 5 propriétaires et un seuil de 3.

Après confirmation de la transaction, l’équipe lit getOwners et getThreshold, vérifie que B est absent et F présent, puis fait exécuter par F et deux autres propriétaires un test approuvé de valeur 0. Elle examine également les transactions en attente : une signature ou préapprobation de B peut ne plus satisfaire les contrôles de propriétaire après son retrait. Les propositions concernées doivent donc être annulées ou reconstruites, et non présumées exécutables.

Si B est peut-être compromis, l’équipe ne lui demande pas d’approuver son retrait. Trois autres propriétaires non compromis exécutent le remplacement, puis inspectent les modules, les droits de récupération, les allowances, les session keys et les transactions déjà exécutées. En effet, retirer B n’annule pas les actions antérieures et ne révoque pas les pouvoirs accordés par une autre voie. Si moins de 3 propriétaires non compromis sont disponibles, seule une voie de récupération ou d’administration configurée auparavant peut éventuellement aider ; partager des phrases de récupération ou faire confiance à un service de « récupération » non sollicité ne remplace pas le quorum.

Risques et contrôles

  • Compte ou adresse erronés. Vérifiez le chain ID, l’adresse multisig, l’implémentation et l’adresse du nouveau propriétaire sur des appareils et auprès de sources indépendants. L’empoisonnement d’adresse et les erreurs de copie peuvent donner le contrôle à un attaquant.
  • Perte de quorum. Modélisez chaque état intermédiaire. Retirer trop tôt un propriétaire, relever le seuil au-delà des signataires disponibles ou faire tourner ensemble plusieurs appareils corrélés peut rendre le compte inutilisable.
  • Concentration temporaire. Un seuil plus faible ou un signataire nouvellement ajouté peut créer une période pendant laquelle moins de parties contrôlent le compte. Préférez un remplacement atomique lorsqu’il est pris en charge et n’abaissez pas le seuil uniquement pour simplifier la procédure.
  • Conservation corrélée. Des adresses différentes ne sont pas indépendantes si leurs phrases de récupération, appareils, sauvegardes, communications ou administrateurs partagent un même domaine de défaillance. Testez la récupération sans centraliser les secrets.
  • Pouvoir caché. Les modules, guards, fallback handlers, session keys, timelocks et contrats de récupération peuvent contourner ou bloquer la voie des propriétaires. Inventoriez-les et vérifiez-les avant et après la rotation.
  • Course avec le signataire compromis. Avant la confirmation du retrait, un signataire suspect peut passer devant, vider les actifs, modifier la configuration ou approuver une autre transaction. Utilisez les procédures d’incident, l’acheminement privé des transactions lorsque cela convient et une surveillance continue de l’état ; ne supposez pas qu’une transaction soumise a gagné la course.
  • Approbations en attente obsolètes. Les changements de propriétaires et de seuil peuvent invalider les signatures recueillies ou modifier les approbations suffisantes. Réévaluez chaque transaction en file par rapport à l’état final et annulez les propositions obsolètes.
  • Fausse finalisation. Une notification de succès dans l’interface ne prouve pas l’état voulu. Attendez la politique de confirmation requise, puis lisez l’état du contrat et vérifiez le payload de transaction, les événements et le résultat d’exécution.
  • Départ incomplet. Retirer un propriétaire on-chain n’efface pas les clés copiées, les accès de l’organisation, les identifiants de relayer, les entrées du coffre de mots de passe ni les pouvoirs dans d’autres contrats et chaînes. Révoquez chaque élément séparément et conservez une piste d’audit.

Idées reçues courantes

  • « Une rotation signifie déplacer tous les actifs vers un nouveau portefeuille. » De nombreux multisigs de comptes intelligents mettent à jour les propriétaires à la même adresse de compte. Une migration est une opération différente et peut n’être requise que par une implémentation ou un plan d’incident particulier.
  • « Ajouter d’abord le nouveau signataire est toujours sûr. » Cela protège la disponibilité, mais peut temporairement élargir l’ensemble autorisé. Lors d’une compromission active, un remplacement atomique ou un autre ordre d’urgence peut être plus sûr.
  • « Un seuil 3-of-5 signifie que trois personnes nommées quelconques sont disponibles. » Le contrat compte les comptes de propriétaire valides, pas les personnes, services ou appareils. La garde partagée et les clés inaccessibles réduisent l’indépendance et la disponibilité effectives.
  • « Retirer un propriétaire compromis annule les dégâts. » Après confirmation, le retrait empêche l’utilisation future de cette voie de propriétaire ; il n’annule pas les transactions exécutées ni les autorisations créées ailleurs.
  • « L’interface du portefeuille constitue une preuve suffisante. » Les interfaces et services d’indexation peuvent être obsolètes, mal configurés ou malveillants. Décodez la transaction et lisez l’état final du contrat depuis un endpoint vérifié indépendamment.
  • « Sans quorum, l’assistance peut réinitialiser le portefeuille. » Un multisig auto-détenu ne possède que les voies d’autorité encodées ou préconfigurées on-chain. Sans quorum valide ni voie de récupération, l’accès peut être perdu définitivement.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...