Une alerte de sécurité ne doit pas déclencher uniquement une mise à jour ou un transfert. Elle doit aussi servir à examiner l’ensemble de l’architecture : appareils, seeds, sauvegardes, logiciels, personnes et procédures.
L’objectif d’un audit n’est pas de chercher une perfection théorique. Il est d’identifier les risques réels et d’établir un ordre d’action.
Cartographier les wallets
La première étape consiste à dresser une liste des wallets utilisés, de leur fonction et des actifs concernés.
Il faut distinguer les usages quotidiens, le stockage long terme, les trésoreries, les tests, les wallets multisig et les dispositifs de succession.
Cette séparation permet de comprendre quelles zones sont prioritaires et d’éviter une migration globale inutilement risquée.
Retracer l’origine des seeds
Pour chaque seed, notez le modèle et le firmware utilisés lors de la génération, la date approximative, les apports d’entropie supplémentaires, la passphrase éventuelle et les imports successifs.
Une seed déplacée vers un nouvel appareil conserve son historique. C’est donc l’origine du secret qu’il faut auditer, pas seulement le matériel actuel.
Examiner les sauvegardes
Une sauvegarde doit être lisible, complète, confidentielle et récupérable. Vérifiez le nombre de copies, leur emplacement, les matériaux utilisés et les personnes qui connaissent leur existence.
Pour un multisig, les seeds ne suffisent pas toujours. Les descripteurs, clés publiques étendues, empreintes et chemins de dérivation peuvent être nécessaires à la reconstruction.
Vérifier les dépendances logicielles
L’audit doit inclure le logiciel compagnon, les ordinateurs, les méthodes de mise à jour et les sources de téléchargement.
Une adresse doit pouvoir être vérifiée sur l’écran de l’appareil. Les firmwares doivent provenir de sources officielles et, lorsque cela est prévu, être authentifiés avant installation.
Tester la récupération
Une sauvegarde non testée reste une hypothèse. Les procédures de récupération doivent être validées dans un environnement contrôlé, avec des montants limités et sans exposer les secrets.
Le test doit confirmer les adresses attendues, l’accès à la passphrase éventuelle et, pour le multisig, la capacité d’un quorum de secours à signer.
Évaluer les personnes et les rôles
Qui peut agir ? Qui connaît le dispositif ? Qui peut remplacer un signataire absent ? Qui reçoit les alertes de sécurité ?
Un dispositif techniquement solide peut rester fragile s’il dépend d’une seule personne ou si les responsabilités ne sont pas documentées.
Construire un plan de correction
Les actions doivent être classées : urgence immédiate, migration planifiée, amélioration de sauvegarde, mise à jour documentaire ou changement de gouvernance.
Pour chaque migration, prévoyez une nouvelle seed vérifiée, une transaction de test, un contrôle d’adresse sur l’appareil et une période de confirmation avant le retrait de l’ancien dispositif.
Transformer l’incident en maturité
Une alerte peut révéler des dépendances qui existaient déjà : fabricant unique, seed complète en un seul lieu, absence de procédure ou récupération jamais testée.
Une Custody Architecture transforme ces constats en dispositif durable. GLOV Secure accompagne ce travail sans prendre custody des fonds ni conserver les secrets.
Pour organiser une revue confidentielle, demandez un audit de sécurité crypto ou contactez GLOV.