Aller au contenu
Financial Context Wiki

Portefeuille à clé de session

Découvrez comment les clés de session des comptes intelligents délèguent une autorité limitée, quelles contraintes appliquer et comment vérifier, révoquer et gérer une clé compromise.

Mis à jour

Contenu fourni uniquement à titre éducatif, sans conseil en investissement. Une clé de session divulguée ou dotée de privilèges excessifs peut entraîner une perte irréversible d’actifs numériques.

Réponse directe

Une clé de session de portefeuille est généralement une clé de signature secondaire, ou un justificatif délégué qui lui est lié, qu’un compte intelligent n’accepte que selon des règles définies. Ces règles peuvent limiter la durée, les contrats cibles, les sélecteurs de fonction, les montants de jetons, le nombre de transactions ou d’autres conditions. L’objectif est de permettre à une application d’effectuer des actions répétées sans demander au titulaire d’approuver chaque opération avec le signataire principal.

La « clé de session » est un modèle de conception, pas une norme Ethereum universelle. ERC-4337 fournit une validation programmable du compte et une validation temporelle de UserOperation, tandis que des systèmes modulaires comme ERC-7579 peuvent héberger validateurs, exécuteurs et hooks. Le code déployé du compte et de ses modules détermine finalement ce que la clé peut faire. L’expiration seule ne sécurise pas une session, et supprimer une copie du navigateur ne révoque pas nécessairement une autorité enregistrée on-chain ou contenue dans une délégation encore valide.

Fonctionnement

Un parcours type comporte 5 étapes :

  1. Le titulaire crée une nouvelle paire de clés sur un appareil ou autorise un justificatif identifiant le signataire de session. La clé privée de session ne doit jamais être envoyée au serveur de l’application, sauf si la conception désigne explicitement ce serveur comme dépositaire de confiance.
  2. Le titulaire autorise une politique avec le portefeuille principal. Certains systèmes installent la clé et la politique on-chain ; d’autres utilisent une délégation signée que le compte valide lorsqu’une opération arrive.
  3. L’application prépare une opération et la signe avec la clé de session. Dans un parcours ERC-4337, la logique validateUserOp vérifie la signature et la politique ; la simulation du bundler est un contrôle d’admission, pas une preuve d’exécution ou de sécurité.
  4. Le compte doit appliquer chaque restriction avant l’exécution. L’autorité effective se résume par A_effective = K ∩ P ∩ S : la possession de la clé (K), la politique configurée (P) et l’état actuel du compte ou de la chaîne (S) doivent tous autoriser l’action.
  5. La session prend fin par expiration, épuisement du nonce ou du quota, révocation explicite, retrait du module ou autre voie d’invalidation propre à l’implémentation. Vérifiez l’état final du compte sur la bonne chaîne.

Avant d’autoriser une session, vérifiez :

  • l’ID de chaîne, l’adresse du compte intelligent, l’implémentation du compte et l’adresse du validateur ou du module ;
  • la clé publique de session ou l’identifiant du justificatif et le lieu de stockage du matériel privé ;
  • chaque cible, sélecteur de fonction, jeton et règle de destinataire autorisés, ainsi que la limite de valeur native et le plafond par appel ou cumulé ;
  • validAfter, validUntil, les règles de nonce, le nombre d’utilisations et si le temps provient de l’horodatage du bloc ou d’une autre source ;
  • si les lots, appels imbriqués, delegatecall, autorisations de jetons, installations de modules, mises à niveau du compte et signatures de messages ERC-1271 sont bloqués sauf nécessité explicite ;
  • qui peut révoquer, si le titulaire garde une voie de récupération indépendante et si la révocation exige du Gas ou un bundler ou paymaster opérationnel.

La politique doit examiner l’action réellement exécutée. Vérifier uniquement la cible externe d’un lot peut laisser les appels internes sans restriction ; vérifier uniquement le destinataire en ignorant la fonction et la valeur crée le même problème. Une limite n’a de sens que si le code chargé de l’appliquer couvre chaque voie d’exécution.

Exemple

Un portefeuille de jeu crée une session de 24 heures. Elle autorise uniquement les appels à un contrat de jeu vérifié, bloque delegatecall et les autorisations de jetons, plafonne la valeur native à 0.02 ETH par appel et les dépenses totales à 20 USDC. Le jeu peut envoyer des actions autorisées sans confirmations répétées, mais une demande de transfert d’un NFT sans rapport doit échouer à la validation.

Avant l’utilisation, le titulaire consigne le compte, la chaîne, le module, la clé publique de session, l’expiration, les plafonds et la méthode de révocation. Il teste une action de faible valeur, vérifie l’appel décodé et l’événement du compte, puis teste séparément la révocation. Cela confirme le parcours configuré, mais ne prouve ni l’absence de faille du module ni l’impossibilité pour un appareil compromis de dépenser jusqu’aux limites restantes.

Risques et contrôles

  • Politique trop large : cibles génériques, sélecteurs sans restriction, autorisations illimitées, lots ou delegatecall peuvent donner à une clé « limitée » une autorité proche de celle du titulaire. Utilisez des listes d’autorisation explicites et bloquez les actions administratives.
  • Vol de clé : stockage du navigateur, journaux, sauvegardes, extensions, logiciels malveillants et appareils partagés peuvent l’exposer. Préférez un stockage isolé ou protégé par matériel, s’il est pris en charge, une durée courte et de faibles plafonds cumulés.
  • Application défectueuse : compte, validateur, exécuteur ou hook peut mal décoder les appels ou oublier une autre voie. Utilisez des déploiements vérifiés, du code relu, des audits et des tests de contournement.
  • Rejeu et confusion de contexte : une gestion faible du nonce ou l’absence de lien avec la chaîne, le compte, le module ou la politique prévus peut permettre une réutilisation. Vérifiez le domaine signé exact et la protection on-chain contre le rejeu.
  • Hypothèses sur l’expiration : validUntil peut limiter une opération ERC-4337 sans supprimer automatiquement une clé enregistrée, une autorisation de jeton ou une autre délégation. Contrôlez l’état réel de chaque droit après expiration.
  • Échec de la révocation : supprimer des données locales n’enlève qu’une copie du secret. Utilisez la voie documentée et vérifiez le résultat on-chain ; conservez assez de Gas et une voie de secours contrôlée par le titulaire.
  • Modules évolutifs ou malveillants : ils peuvent disposer de puissants droits d’exécution, et une mise à niveau peut modifier la politique. Vérifiez titulaires, délai de mise à niveau, pouvoirs de pause, adresse d’implémentation et procédure de retrait.
  • Abus de Gas et de parrainage : la session peut consommer les fonds du compte en Gas ou devenir inutilisable si un paymaster la refuse. Limitez les frais si possible et gardez une voie d’envoi indépendante.

Si une clé peut être exposée, cessez d’utiliser l’application concernée, conservez l’identifiant de session et les hachages pertinents, puis révoquez ou désactivez la clé depuis un appareil propre contrôlé par le titulaire. Examinez ensuite les opérations en attente et récentes, les autorisations, les modules installés, les mises à niveau et les soldes sur toutes les chaînes prises en charge. Ne déplacez les actifs restants que si la conception rend la révocation peu fiable ; se précipiter vers un site de « récupération » non vérifié peut aggraver la perte.

Idées reçues

  • « Une clé de session ne peut pas déplacer d’actifs. » Elle peut effectuer toute action permise par la politique, notamment transferts, swaps, autorisations ou signatures.
  • « ERC-4337 définit les droits des clés de session. » ERC-4337 fournit un cadre de validation et d’exécution ; la politique reste propre au portefeuille ou au module.
  • « Une courte expiration limite la perte maximale. » La perte dépend aussi des plafonds unitaires et cumulés, de la fréquence, du Gas, des autorisations, des prix et de toutes les voies accessibles.
  • « Se déconnecter révoque la clé. » Cela peut supprimer une copie locale, sans prouver que l’enregistrement on-chain ou une délégation signée est invalide.
  • « Une simulation réussie signifie que l’opération est sûre. » Elle peut montrer l’acceptation actuelle, mais ne prouve ni l’intention, ni l’inclusion future, ni l’exécution, ni la finalité, ni l’absence de faille.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...