Niveaux de portefeuilles, politique de transaction et processus de signature

Des clés solides ne servent à rien si une seule personne peut leur ordonner de signer n’importe quoi. Les contrôles entourant la signature déterminent où se trouvent les clés, quelles transactions sont autorisées, qui doit les approuver et ce que les signataires voient réellement. C’est là que la plupart des pertes institutionnelles sont soit évitées, soit rendues possibles. Cette leçon suit une transaction depuis sa demande jusqu’à sa diffusion sur le réseau.

Portefeuilles chauds, tièdes et froids

Les dépositaires et les plateformes d’échange répartissent les actifs en différents niveaux. Chaque niveau privilégie soit la rapidité, soit la sécurité.

Le portefeuille chaud ne devrait contenir que ce dont les opérations ont besoin. À titre d’illustration, prenons une plateforme d’échange qui détient 2 milliards USD d’actifs clients et dont les retraits nets quotidiens moyens s’élèvent à 30 millions USD. Elle pourrait conserver 40 à 60 millions USD en portefeuille chaud (2 à 3 %), soit suffisamment pour une journée normale avec une marge de sécurité. Les dépôts excédentaires sont régulièrement transférés vers le stockage tiède ou froid, et le portefeuille chaud est réapprovisionné selon un processus contrôlé. Ces chiffres sont donnés à titre d’exemple et ne constituent pas une norme. Le montant approprié dépend des habitudes de retrait, des engagements de niveau de service et des conditions d’assurance.

« Froid » ne signifie pas à l’abri de toutes les attaques. Les clés froides sont hors ligne, mais des personnes doivent toujours approuver les transactions, et les processus d’approbation peuvent être trompés. Le vol de Bybit en février 2025 a commencé par un transfert courant depuis un portefeuille froid (voir la leçon Menaces et contrôles de la sécurité opérationnelle).

Moteurs de politique

Un moteur de politique vérifie chaque demande de transaction par rapport à un ensemble de règles avant que toute clé ou part de clé ne signe. Voici des types de règles courants :

Deux éléments de conception sont importants. Premièrement, la politique doit être appliquée là où la signature a lieu : dans l’environnement sécurisé du HSM, par les cosignataires MPC ou dans le portefeuille de contrats intelligents. Si elle est vérifiée uniquement dans une application Web, une personne ayant accès au serveur peut la contourner. Deuxièmement, les modifications apportées à la politique sont elles-mêmes des transactions à haut risque. L’ajout d’un approbateur, le relèvement d’une limite ou la modification de la liste d’autorisation devraient nécessiter leur propre quorum et un délai.

Un moteur de politique produit également des preuves. Chaque demande, évaluation de règle, approbation et rejet devrait être consigné dans un registre inaltérable, avec l’utilisateur, l’appareil et l’heure. Les auditeurs vérifient les contrôles à l’aide de ces journaux, et les équipes d’intervention en cas d’incident s’en servent pour reconstituer les événements. Les demandes rejetées méritent aussi une attention particulière : une série de tentatives bloquées vers de nouvelles adresses peut être le premier signe d’une attaque.

Quorums et séparation des tâches

Un quorum correspond au nombre d’approbations nécessaires, exprimé sous la forme m sur n (par exemple, 3 sur 5). Le quorum n’est efficace que si les approbateurs sont réellement indépendants.

La séparation des tâches distingue les rôles qui pourraient autrement être combinés à des fins frauduleuses :

• L’initiateur crée la demande, mais ne peut pas l’approuver.
• Les approbateurs examinent et approuvent la demande, mais ne peuvent pas modifier le destinataire.
• Les signataires ou dépositaires des clés utilisent les clés, souvent sans pouvoir lancer de transactions.
• Les administrateurs de la politique gèrent les règles et les utilisateurs, mais ne peuvent pas déplacer de fonds.

Parmi les défaillances courantes figure l’effondrement du quorum : dans un quorum de 3 sur 5 où trois approbateurs appartiennent à la même équipe, un seul responsable ou une seule campagne d’hameçonnage peut atteindre le quorum. D’autres problèmes sont le maintien des accès d’employés ayant changé de rôle et le partage d’identifiants. Les bonnes pratiques consistent à répartir les approbateurs entre différents services et lieux, à examiner les accès au moins une fois par trimestre, à révoquer les accès le jour même du départ d’une personne et à exiger un double contrôle, c’est-à-dire la présence de deux personnes à tout moment, pour l’accès physique au stockage froid.

Listes d’autorisation, limites de vélocité et verrous temporels

Les listes d’autorisation (également appelées listes blanches) limitent les retraits aux adresses préalablement approuvées. Elles empêchent la plupart des attaques par substitution d’adresse uniquement si l’ajout d’une adresse est suffisamment difficile. Un processus fiable exige :

• une demande étayée par des preuves indiquant qui est propriétaire de l’adresse
• une confirmation par un canal distinct, à l’aide d’un numéro de téléphone déjà enregistré et non d’un numéro fourni dans la demande
• un petit transfert de test que la contrepartie confirme
• une période de réflexion, souvent de 24 à 48 heures, avant que l’adresse puisse être utilisée

Les limites de vélocité plafonnent la valeur par transaction, par heure et par jour, idéalement en additionnant les montants dans une devise de référence pour l’ensemble des actifs, afin qu’un attaquant ne puisse pas fractionner un vol en de nombreux petits transferts.

Les verrous temporels ajoutent un délai entre l’approbation et la diffusion sur le réseau, ou entre la diffusion et la possibilité de dépenser les fonds. Cette fenêtre permet aux équipes de surveillance de repérer et d’annuler une mauvaise transaction. Ils peuvent fonctionner hors chaîne, sous la forme d’une file d’attente en attente sur la plateforme de conservation, ou sur chaîne. Bitcoin prend en charge les verrous temporels sur chaîne grâce à CHECKLOCKTIMEVERIFY (BIP 65) et CHECKSEQUENCEVERIFY (BIP 112), et les conceptions de « coffres » les utilisent pour laisser à une clé de récupération le temps de récupérer les fonds. Sur les chaînes EVM, les contrats de verrouillage temporel remplissent la même fonction. Le compromis est une réduction de la rapidité ; les contrats clients doivent donc préciser des délais de retrait qui tiennent compte de ces délais supplémentaires.

Simulation des transactions et signature en clair

Un signataire devrait savoir exactement ce que fera une signature. Deux techniques permettent de s’en assurer.

La simulation de transaction exécute la transaction sur l’état actuel de la chaîne avant sa signature. Elle indique ce qui va se passer : quels soldes vont changer, quelles autorisations de jetons vont être accordées, quels contrats seront appelés et si l’appel utilise delegatecall ou modifie les propriétaires ou le code du portefeuille. Une simulation indiquant « –5 000 000 USDC du portefeuille, +5 000 000 USDC vers 0xAb…9F, aucun autre changement » donne à l’approbateur des éléments concrets à vérifier.

La signature en clair signifie que l’appareil de signature affiche une signification compréhensible par un humain (destinataire, montant, nom de la fonction et paramètres) au lieu d’un hachage ou de données hexadécimales brutes. À l’opposé, la signature aveugle consiste à approuver des données que le signataire ne peut pas lire. Des normes telles que EIP-712 (données structurées typées) aident les portefeuilles à afficher le sens d’un message. Lorsqu’un appareil ne peut pas décoder une transaction, le choix sûr par défaut est de la refuser, et non de la signer quand même.

La signature en clair ne fonctionne que si l’affichage lui-même est fiable. Si l’ordinateur qui prépare la transaction est compromis, il peut afficher une chose et en envoyer une autre. Une bonne pratique consiste à vérifier les informations par un canal indépendant. Par exemple, calculez le hachage de transaction attendu sur une machine distincte et sécurisée, puis comparez-le au hachage affiché sur l’appareil matériel avant d’approuver.

Exemple détaillé : un retrait de 5 millions USD

Un client entreprise demande le retrait de 5 millions USD en USDC vers sa propre adresse.

1. Demande. Un analyste des opérations de trésorerie saisit la demande. La plateforme consigne l’identité de l’initiateur et l’heure.
2. Vérification de la politique. L’adresse du destinataire figure sur la liste d’autorisation depuis 60 jours. Le montant dépasse le seuil de 1 million USD ; le processus froid s’applique donc. La limite de vélocité quotidienne n’est pas encore atteinte. Il s’agit d’un simple transfert de jetons.
3. Approbations. Le quorum est de 3 sur 5 : un approbateur des opérations, un du service des risques et un cadre supérieur. L’initiateur ne peut pas faire partie des approbateurs.
4. Simulation et signature en clair. La simulation indique exactement que 5 000 000 USDC seront transférés vers l’adresse figurant sur la liste d’autorisation, sans aucun autre appel. Les signataires vérifient les mêmes détails sur leurs appareils et contrôlent le hachage sur une machine indépendante.
5. Verrou temporel et diffusion. Un délai de quatre heures permet l’annulation. La transaction est ensuite signée et diffusée, puis le rapprochement après transaction confirme la modification du solde sur chaîne par rapport au registre interne.

Chaque étape permet d’éviter un type de défaillance différent. La liste d’autorisation empêche les erreurs de saisie ou les substitutions d’adresse. Le quorum empêche un seul initié malveillant d’agir seul. La simulation et la vérification indépendante du hachage permettent de détecter une interface compromise. Le verrou temporel donne aux équipes de surveillance une dernière chance d’intervenir.

Points clés pour l’examen : les caractéristiques des portefeuilles chauds, tièdes et froids, et les raisons pour lesquelles le portefeuille chaud ne devrait contenir que ce dont les opérations ont besoin ; ce que vérifie un moteur de politique et pourquoi il doit être appliqué là où la signature a lieu ; la conception du quorum et la séparation des tâches (initiateur, approbateur, signataire, administrateur de la politique), ainsi que le risque d’effondrement du quorum ; un processus sécurisé d’ajout à la liste d’autorisation avec une vérification par un canal distinct et une période de réflexion ; les limites de vélocité et les verrous temporels (files d’attente hors chaîne ou verrous sur chaîne) ; la simulation des transactions, la signature en clair par opposition à la signature aveugle et la vérification indépendante de ce qui est signé.