Dans les systèmes informatiques classiques, « faire tourner une clé » peut signifier générer un nouveau secret, le déployer puis révoquer l’ancien. En crypto, ce vocabulaire masque plusieurs réalités très différentes.
Une adresse Bitcoin ne permet pas de remplacer magiquement la clé privée qui la contrôle. Une EOA Ethereum ne change pas de clé. Un multisig peut parfois remplacer un signataire sans changer d’adresse. Un validateur peut disposer de mécanismes de rotation spécifiques au protocole.
Avant de parler de rotation, il faut donc comprendre ce qui doit réellement être remplacé.
Une clé n’est pas toujours remplaçable derrière la même adresse
Pour un wallet classique basé sur une seed, changer de secret implique généralement de créer un nouveau wallet et de déplacer les actifs.
Sur Bitcoin, une nouvelle seed produit de nouvelles clés et de nouvelles adresses. La migration consiste donc à générer un nouveau wallet sain, vérifier sa sauvegarde puis transférer les UTXO vers des adresses contrôlées par ce nouveau wallet.
Pour une EOA sur Ethereum ou une chaîne compatible EVM, la logique est similaire : l’adresse est dérivée de la clé. On ne « change » pas la clé privée d’une EOA existante. Il faut créer une nouvelle identité et déplacer les actifs, mais aussi transférer les rôles, allowances, droits administratifs et permissions associés à l’ancienne adresse.
Le solde n’est donc qu’une partie de la migration.
Les smart accounts et multisigs changent la logique
Une architecture de smart account ou de multisig peut séparer l’adresse du système et les clés autorisées à agir.
Dans ce cas, remplacer un signataire peut être possible sans déplacer tous les actifs vers une nouvelle adresse. La procédure peut consister à ajouter une nouvelle clé, vérifier son fonctionnement, modifier le quorum puis retirer l’ancienne.
Cette souplesse est puissante, mais elle crée une nouvelle exigence : les règles de modification des signataires doivent elles-mêmes être protégées.
Un multisig 2-sur-3 dont deux signataires compromis peuvent modifier la politique ne devient pas sûr simplement parce qu’une quatrième clé a été ajoutée.
Quand faut-il envisager une rotation ?
Une rotation n’a pas besoin d’être périodique pour être pertinente. Les déclencheurs les plus importants sont souvent événementiels :
- seed ou clé potentiellement exposée ;
- doute sur la qualité de génération ;
- vulnérabilité affectant un appareil ou un firmware ;
- perte ou vol d’un support ;
- départ d’un collaborateur ou changement de responsabilités ;
- changement de modèle de gouvernance ;
- sauvegarde devenue trop accessible ;
- dépendance excessive à un fabricant ou à un emplacement ;
- évolution importante de la valeur protégée.
Une rotation « tous les six mois » sans raison peut augmenter le risque si elle multiplie les manipulations de secrets et les transferts.
Commencer par l’inventaire des dépendances
La première étape n’est pas de générer une nouvelle seed. C’est d’identifier tout ce qui dépend de l’ancienne clé.
Selon le système, cela peut inclure :
- balances et UTXO ;
- tokens ;
- positions DeFi ;
- approvals et allowances ;
- rôles d’administration de smart contracts ;
- délégations de staking ;
- whitelist d’adresses ;
- comptes d’exchange ;
- multisigs ;
- DNS ou services liés à une adresse ;
- clés de validateur ou comptes opérateur.
Oublier une dépendance peut laisser une capacité critique attachée à l’ancienne clé après la migration apparente des fonds.
Générer le nouveau secret dans un environnement propre
Lorsque la rotation est déclenchée par une suspicion de compromission, il faut éviter de réutiliser le même environnement sans analyse.
Nouveau secret ne signifie pas nécessairement nouvel appareil, mais la méthode de génération doit être suffisamment indépendante du problème initial. Si la cause concerne un firmware, une méthode d’entropie ou un fabricant, recréer immédiatement une seed dans le même contexte peut reproduire le risque.
La sauvegarde du nouveau secret doit être vérifiée avant d’y déplacer une valeur significative.
Migrer par étapes lorsque le contexte le permet
Une migration contrôlée peut suivre une séquence simple :
- créer la nouvelle clé ou architecture ;
- vérifier les sauvegardes et la récupération ;
- enregistrer les nouvelles adresses ou signataires dans les systèmes concernés ;
- effectuer une opération de faible valeur ;
- vérifier le résultat sur une source indépendante ;
- déplacer les actifs ou responsabilités principales ;
- révoquer les permissions de l’ancienne clé lorsque c’est possible ;
- surveiller les droits ou fonds résiduels.
En cas de compromission active, cette séquence doit évidemment être adaptée à l’urgence. Le principe reste cependant le même : ne pas créer une nouvelle perte en voulant corriger la première.
Révoquer est aussi important que migrer
Une ancienne adresse vide peut encore conserver du pouvoir.
Sur les systèmes programmables, il faut rechercher les approvals, rôles, délégations et permissions qui restent actifs. Dans une organisation, il faut également supprimer les accès opérationnels associés à l’ancien signataire.
La fin d’une rotation doit donc répondre à deux questions :
- le nouveau dispositif contrôle-t-il tout ce qu’il doit contrôler ?
- l’ancien dispositif contrôle-t-il encore quelque chose qu’il ne devrait plus contrôler ?
Le cas des validateurs
Les validateurs ajoutent une complexité particulière : la clé de consensus, la clé de retrait, le compte opérateur et les droits de gouvernance peuvent être séparés selon le réseau.
Certaines blockchains permettent de remplacer une clé de consensus. D’autres nécessitent une procédure spécifique, une période d’attente ou un nouveau validateur. Il faut également éviter qu’une ancienne et une nouvelle instance signent simultanément lorsque le protocole sanctionne les signatures contradictoires.
La rotation d’un validateur est donc une opération de protocole autant qu’une opération de sécurité.
Conserver l’historique sans conserver inutilement le secret
Après migration, il peut être utile de conserver la documentation expliquant pourquoi la rotation a été effectuée, quelles transactions ont servi à la migration et quelles permissions ont été révoquées.
Cela ne signifie pas que l’ancienne seed doit rester facilement accessible indéfiniment. La politique dépend du besoin de récupération, du risque résiduel et de l’architecture choisie.
Une capacité à prévoir dès la conception
La meilleure rotation est celle qui n’a pas besoin d’être inventée pendant un incident.
Une architecture de custody mature prévoit les mécanismes de remplacement des clés, les dépendances à mettre à jour et les personnes autorisées à déclencher la procédure.
GLOV Secure peut accompagner l’analyse et la préparation de ces migrations dans une logique non-custodial, sans détenir les fonds ni conserver les secrets. Pour une architecture existante, un audit de sécurité crypto permet notamment d’identifier les dépendances qui rendraient une future rotation difficile.