Beosin : Analyse de l’audit de sécurité de l’EIP-7702 et du portefeuille AA de nouvelle génération

L’abstraction de compte (AA) est une direction importante de l’exploration à long terme dans l’écosystème Ethereum, visant à briser la frontière entre les comptes externes (EOA) et les comptes contractuels, afin que le portefeuille ait une programmabilité, une sécurité et une évolutivité plus fortes. EIP-4337 est actuellement la solution de mise en œuvre AA la plus courante, et a été largement utilisée dans un certain nombre de portefeuilles de contrats intelligents basés sur EntryPoint (tels que Safe, Stacks et Argent). Cependant, l’EIP-4337 présente encore certaines limitations en termes de native on-chain, de complexité opérationnelle et de compatibilité écologique en raison de son introduction d’un pool de transactions indépendant et d’un mécanisme de contrat de rampe d’accès.

Afin de réduire davantage la barrière à l’entrée et d’améliorer la prise en charge native des abstractions de compte, Vitalik a proposé l’EIP-7702 en 2024 et l’a inclus dans la mise à niveau de Pectra. L’idée de base de l’EIP-7702 est de permettre à un EOA original d’exécuter le code de contrat (contract_code) d’une adresse spécifiée lors de l’initiation d’une transaction, et d’utiliser ce code pour définir la logique d’exécution de la transaction.

L’EIP-7702 introduit un nouveau mécanisme d'« injection de code au niveau de la transaction », qui permet aux comptes d’utilisateurs de spécifier dynamiquement la logique d’exécution dans chaque transaction, plutôt que de s’appuyer sur du code contractuel pré-déployé. Cela rompt avec le modèle traditionnel d’autorisation basé sur le code statique, apporte une plus grande flexibilité et introduit de nouveaux défis de sécurité : les contrats qui reposent sur une logique de jugement telle que isContract et extcodehash peuvent devenir invalides, et certains systèmes qui supposent que l’appelant est un pur EOA peuvent également être contournés. Pour les auditeurs, il est important non seulement de vérifier la sécurité du code injecté lui-même, mais aussi d’évaluer son impact potentiel sur d’autres systèmes contractuels dans un contexte dynamique.

Dans cet article, l’équipe de sécurité de Beosin se concentrera sur les principes de conception et les principales caractéristiques de l’EIP-7702, triera systématiquement les risques de sécurité auxquels le portefeuille AA construit sur cette base peut être confronté lors de l’audit, et proposera le processus d’audit et des suggestions d’un point de vue pratique pour aider les chercheurs en sécurité à mieux faire face aux défis techniques de ce nouveau paradigme.

1. Introduction à l’EIP-77021

. Présentation technique de

l’EIP-7702EIP-7702 introduit un nouveau type de transaction, 0x 04 (SetCode), qui permet à EOA d’autoriser le code de contrat qui doit être exécuté par le biais de cette transaction, avec la structure de transaction suivante :

1. rlp([chain_id, nonce, max_priority_fee_per_gas, max_ fee_per_gas, gas_limit,

2. destination, valeur, données, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

Lorsque authorization_list contient plusieurs listes d’autorisations, et peut également contenir des actions d’autorisation de personnes non initiatrices de transactions, la structure interne est la suivante :

1. authorization_list = [[chain_id, address, nonce, y_parity, r, s]].

où chain_id représente la chaîne dans laquelle l’autorisation de l’utilisateur prend effet, et sa valeur doit être égale à l’ID de chaîne de la chaîne d’exécution ou à 0. Lorsque chain_id est égal à 0, l’autorisation prend effet pour toutes les chaînes EVM qui prennent en charge EIP-7702, mais uniquement si d’autres paramètres (tels que nonce) correspondent. Adresse Indique l’adresse du contrat cible autorisée par l’utilisateur.

Une fois l’autorisation terminée, le système modifiera le champ de code de l’utilisateur autorisé en 0x ef 0100 || adresse, où adresse est l’adresse contractuelle autorisée. Si vous souhaitez annuler l’autorisation, il vous suffit d’initier une transaction SetCode avec l’adresse définie sur 0.

deux. Avantages de l’EIP 7702

(1) Flexibilité et personnalisation

Comptes abstraitsEn écrivant la logique de compte dans des contrats intelligents, vous pouvez personnaliser les fonctions de manière flexible en fonction de vos besoins. Par exemple, les utilisateurs peuvent configurer la multi-signature, la récupération sociale et le contrôle des quotas pour répondre aux besoins des particuliers ou des entreprises dans différents scénarios. Cette conception améliore considérablement l’évolutivité fonctionnelle du compte et brise les limites des comptes externes traditionnels (EOA).

(2) Sécurité

renforcéeLes comptes offrent un mécanisme de sécurité à plusieurs niveaux, y compris l’authentification multifacteur, les limites de transaction et la récupération sociale. Même si un utilisateur perd sa clé privée, il peut récupérer son compte grâce à des contacts de confiance ou à l’authentification multifacteur, évitant ainsi la perte permanente d’actifs causée par la perte de la clé privée dans les comptes traditionnels. Dans le même temps, des fonctions telles que le contrôle des limites peuvent également empêcher le vol malveillant de grosses quantités de fonds.

(3) Le

compte d’extraction optimisé pour le gaz prend en charge un mécanisme flexible d’extraction de gaz, permettant aux utilisateurs de payer le gaz par l’intermédiaire d’un tiers, et même d’utiliser directement d’autres jetons pour payer les frais de transaction. Ce mécanisme réduit non seulement le coût d’opération des utilisateurs, mais simplifie également davantage l’utilisation de la blockchain, ce qui convient particulièrement aux utilisateurs novices ou aux scénarios de transaction complexes en plusieurs étapes.

(4) Promouvoir la popularisation du Web3En

optimisant l’expérience et la sécurité, les comptes abstraits cachent la complexité de la blockchain dans des endroits que les utilisateurs ne peuvent pas voir, offrant des opérations pratiques plus proches du Web2. Cette conception réduit le coût d’apprentissage des utilisateurs ordinaires, permet à davantage de personnes de participer aux applications Web3 sans barrières et favorise la popularisation de la technologie décentralisée.

2. Analyse des risques de sécurité dans l’EIP-7702 En pratique

Bien que l’EIP-7702 ait donné un nouvel élan à l’écosystème Ethereum et élargi une multitude de scénarios d’application, en même temps, il a inévitablement introduit de nouveaux risques de sécurité :

1. Attaque par rejeu d’autorisation

Dans le modèle EIP-7702, si l’utilisateur autorise le chain_ Si le champ id est défini sur 0, l’autorisation peut prendre effet sur plusieurs chaînes. Bien que cette conception de « l’autorisation universelle inter-chaînes » améliore la flexibilité dans certains scénarios, elle introduit également des risques de sécurité évidents.

Il est important de noter que même si l’identité du compte de la même adresse est la même sur différentes chaînes, la mise en œuvre du contrat peut être complètement différente. Cela signifie qu’un attaquant pourrait déployer une version malveillante du contrat sur une autre chaîne et effectuer des actions involontaires en utilisant l’autorisation de la même adresse sur la chaîne, posant ainsi des risques pour les actifs de l’utilisateur.

Par conséquent, pour les fournisseurs de services de portefeuille ou les plateformes d’interaction frontale, lorsque les utilisateurs effectuent de telles opérations d’autorisation, ils doivent clairement vérifier si le chainId déclaré dans l’autorisation de l’utilisateur est cohérent avec le réseau de connexion actuel ; Si un utilisateur est détecté en train de définir le chainId sur 0, un avertissement de risque clair doit être émis pour rappeler à l’utilisateur que l’autorisation prendra effet sur toutes les chaînes compatibles EVM et qu’elle peut être utilisée de manière abusive par des contrats malveillants.

En outre, le fournisseur de services doit également évaluer s’il doit restreindre ou interdire l’autorisation avec chainId 0 par défaut au niveau de la couche d’interface utilisateur afin de réduire le risque de mauvaise utilisation ou d’attaques de phishing.

2. Compatibilité du contrat

1) Compatibilité du rappel de contrat

du transfert d’argent vers une adresse contractuelle pour des contrats de jetons existants tels que ERC-721, ERC-777 et ERC 1155, ils appelleront des interfaces de rappel standard (telles que onERC 721 Received, tokensReceived) pour terminer l’opération de transfert. Si l’adresse de réception n’implémente pas l’interface correspondante, le transfert échouera, voire entraînera le verrouillage de l’actif.

Dans l’EIP-7702, une adresse utilisateur peut être transformée en compte de contrat en recevant un code de contrat via l’opération « set_code ». Dans ce cas :

• L’adresse de l’utilisateur est considérée comme un contrat ;

• Si le contrat n’implémente pas l’interface de rappel nécessaire, le transfert de jeton échouera ;

• Les utilisateurs peuvent ne pas être en mesure de recevoir des jetons grand public à leur insu.

Par conséquent, les développeurs doivent s’assurer que le contrat cible délégué par l’utilisateur implémente l’interface de rappel appropriée pour assurer la compatibilité avec les jetons grand public.

(2) Échec de la vérification « tx.origin »Dans

contrats traditionnels, « tx.origin » est souvent utilisé pour déterminer si la transaction est directement initiée par l’utilisateur, et est utilisé pour empêcher les contrôles de sécurité tels que les appels de contrat.

Toutefois, dans le scénario EIP-7702,

• l’utilisateur signe une transaction d’autorisation et le relayer ou l’offre groupée la diffuse pour le compte de l’utilisateur. Lorsqu’une transaction est exécutée, « tx.origin » est l’adresse du relayer, et non l’adresse de l’utilisateur.

• « msg.snder » est un contrat de portefeuille qui représente l’identité de l’utilisateur.

Par conséquent, la vérification des autorisations basée sur « tx.origin == msg.sender » entraînera le rejet des opérations utilisateur légitimes et la perte de fiabilité, et les mêmes appels de contrat restreints tels que « tx.origin == user » seront également invalidés. Il est recommandé d’abandonner « tx.origin » comme base de jugement de sécurité et d’utiliser à la place un mécanisme de vérification de signature ou d’autorisation.

(3) « isContract » mal jugéDe nombreux

contrats empêchent les comptes contractuels de participer à certaines opérations, telles que les airdrops, les ventes flash, etc., via « isContract(address) » :

require( !isContract(msg.sender), « Contracts not allowed »).

En vertu du mécanisme EIP-7702, l’adresse de l’utilisateur peut être remplacée par un compte contractuel par le biais d’une transaction « set_code », et « isContract » renvoie true, et le contrat identifiera par erreur l’utilisateur légitime comme étant le compte contractuel et refusera de participer à l’opération, ce qui entraînera l’impossibilité pour l’utilisateur d’utiliser certains services et le blocage de l’expérience.

Avec la popularisation progressive des portefeuilles de contrats, la conception consistant à s’appuyer sur « isContract » pour déterminer si « un utilisateur humain » n’est plus sécurisée, et il est recommandé d’utiliser des méthodes d’identification des utilisateurs plus précises telles que la vérification de la signature.

3. Attaque de phishingAprès

la mise en œuvre du mécanisme de délégation de l’EIP-7702, les actifs du compte de l’utilisateur seront entièrement contrôlés par le contrat intelligent délégué. Une fois qu’un utilisateur autorise un contrat malveillant, un attaquant peut prendre le contrôle total des actifs du compte, ce qui entraîne un transfert rapide ou un vol de fonds, ce qui est extrêmement risqué.

Par conséquent, pour les fournisseurs de services de portefeuille, il est nécessaire de prendre en charge le mécanisme de résolution des transactions et d’identification des risques EIP-7702 dès que possibleCrucial. Lorsqu’un utilisateur signe une transaction de mandat, le front-end doit afficher clairement et bien en évidence l’adresse du contrat cible et combiner des informations complémentaires telles que la source du contrat et les informations de déploiement pour aider les utilisateurs à identifier les comportements potentiels d’hameçonnage ou de fraude, réduisant ainsi le risque de mauvaise signature. En outre, le service de portefeuille doit intégrer des fonctionnalités d’analyse de sécurité automatique pour le contrat cible, telles que la vérification du statut open source du code du contrat, l’analyse du modèle d’autorisation et l’identification des opérations potentiellement dangereuses, afin d’aider les utilisateurs à porter des jugements plus sûrs avant l’autorisation.

En particulier, l’EIP-7702 introduit un format de signature délégué qui n’est pas compatible avec les normes de signature existantes EIP-191 et EIP-712. Sa signature peut facilement contourner l’avertissement de signature d’origine et l’invite d’interaction du portefeuille, ce qui augmente encore le risque que les utilisateurs soient trompés et signent des opérations malveillantes. Par conséquent, l’introduction du mécanisme d’identification et de traitement de la structure de signature dans la mise en œuvre du portefeuille sera un lien clé pour assurer la sécurité des utilisateurs.

4. Risques liés aux contrats de portefeuille

(1) Gestion de l’autorité contractuelle du portefeuille

De nombreux contrats de portefeuille EIP-7702 adoptent une architecture proxy (ou des autorisations de gestion intégrées) pour prendre en charge les mises à niveau logiques. Cependant, cela présente également un risque plus élevé de gestion des droits. Si les privilèges d’escalade ne sont pas strictement limités, un attaquant peut remplacer le contrat de mise en œuvre et injecter un code malveillant, ce qui entraîne la falsification du compte de l’utilisateur ou le vol de fonds.

Recommandations de sécurité

• : Utilisez des mécanismes d’authentification multi-signature, multifacteur ou de verrouillage temporel pour contrôler les privilèges d’escalade.

• Les modifications de code et d’autorisation sont soumises à un audit rigoureux et à une validation de sécurité.

• Le processus de mise à niveau est ouvert et transparent afin de garantir le droit des utilisateurs de savoir et de participer.

(2) Le risque de conflits de stockage et d’isolation des données, les

versions de contrat de portefeuille ou différents fournisseurs de services de portefeuille peuvent réutiliser le même emplacement de stockage. Si l’utilisateur change de fournisseur de services de portefeuille ou met à niveau la logique du portefeuille, la réutilisation de l’emplacement de stockage entraînera un conflit de variables d’état, l’écrasement des données, des exceptions de lecture et d’autres problèmes. Non seulement cela peut perturber le fonctionnement normal du portefeuille, mais cela peut également entraîner la perte de fonds ou d’autorisations anormales.

Recommandations de sécurité :

• utilisez un schéma d’isolation de stockage spécialisé, tel que la norme EIP-1967, ou exploitez un espace de noms unique pour gérer les emplacements de stockage.

• Lors de la mise à niveau du contrat, assurez-vous que la disposition du stockage est compatible et évitez les variables qui se chevauchent.

• Testez rigoureusement la plausibilité de l’état stocké pendant le processus de mise à niveau.

(3) La gestion des nonce à l’intérieur du wallet

Le contrat de wallet met généralement en place un nonce à l’intérieur et se gère lui-même pour assurer l’ordre d’exécution des opérations des utilisateurs et prévenir les attaques par rejeu. Si le nonce n’est pas utilisé correctement, l’opération utilisateur ne sera pas exécutée correctement.

Recommandation de sécurité :

• Le nonce doit être vérifié de force pour une valeur équivalente (ou un incrément) et ne peut pas être ignoré.

• Il est interdit aux fonctions de modifier directement le nonce, et le nonce ne sera mis à jour que lorsque l’opération utilisateur est exécutée.

• Concevez des mécanismes de tolérance aux pannes et de récupération pour les exceptions de nonce afin d’éviter les interblocages de nonce.

(4) Vérification de l’autorisation de l’appelant de la fonctionAfin

d’assurer la sécurité, le contrat de portefeuille doit garantir que l’appelant de la fonction clé est le compte propriétaire du portefeuille. Les deux méthodes courantes sont les suivantes :

• signature hors chaîne autorise

les utilisateurs à signer un ensemble d’opérations via la clé privée, et le contrat de portefeuille vérifie si la signature est légitime, expirée et satisfait au nonce correspondant sur la chaîne. Cette méthode est applicable au mode de transaction relais préconisé par EIP-7702 (signature hors ligne de l’utilisateur + relais envoie la transaction au nom de l’utilisateur).

• de contrainte d’appel (msg.sender == address(this))

ne peut être déclenchée que par le contrat lui-même, qui est essentiellement un mécanisme de contrôle du chemin d’appel qui garantit que l’initiateur externe doit être le compte lui-même. Cela équivaut effectivement à exiger que l’appelant soit l’EOA d’origine, puisque l’adresse du contrat est l’adresse EOA.

3. Perspectives : La proposition de l’EIP-7702 et de la future norme de portefeuille AA

EIP-7702 n’est pas seulement une innovation du modèle de compte traditionnel, mais aussi une promotion majeure de l’écosystème de l’abstraction de compte. La possibilité de charger le code contractuel qu’il introduit ouvre un large espace d’exploration pour la conception future de portefeuilles et de systèmes contractuels, et met également en avant de nouvelles exigences pour les normes d’audit de sécurité.

1. Co-évolution avec EIP-4337 : Vers une compatibilité bimodeBien que

l’EIP-7702 et l’EIP-4337 aient des objectifs de conception différents, le premier reconstruit le mécanisme de chargement de code du compte, et le second construit un écosystème complet de saisie et d’empaquetage des transactions. Cependant, les deux ne sont pas en conflit, mais présentent une forte complémentarité :

● EIP-4337 fournit un « canal de transaction commun » et une « interface d’exécution de compte abstraite » ;

● L’EIP-7702 permet aux comptes d’utilisateurs d’accorder dynamiquement des capacités de logique contractuelle sans modifier l’adresse ;

Par conséquent, à l’avenir, les portefeuilles pourraient adopter une « architecture de prise en charge bimode » : utilisez EIP-7702 comme remplacement léger sur les chaînes qui ne prennent pas en charge EIP-4337, et continuez à s’appuyer sur la pile de protocoles complète d’EIP-4337 dans les scénarios qui nécessitent un empaquetage hors chaîne et une agrégation multi-utilisateurs.

Ce mécanisme bimode permettra également aux portefeuilles de prendre en charge des modèles d’autorisation de compte plus flexibles, des mécanismes de rétrogradation et des schémas de restauration au niveau de la couche noyau.

2. La prise en charge et l’inspiration de nouvelles logiques de portefeuille telles que MPC et ZK, et le mécanisme de

contrat de compte préconisé par EIP-7702 ont un potentiel d’intégration naturel avec le portefeuille MPC populaire, le portefeuille ZK, le portefeuille modulaire et d’autres nouvelles architectures :

● Dans le modèle MPC, le comportement de signature ne repose plus sur une seule clé privée, mais est une prise de décision collaborative multipartite. Les signatures générées par la convergence de l’EIP-7702 et du MPC contrôlent la logique contractuelle chargée dynamiquement, ce qui permet des stratégies d’exécution plus flexibles.

● Le portefeuille ZK vérifie l’identité ou l’autorisation de l’utilisateur à l’aide de preuves à divulgation nulle de connaissance, sans exposer les informations de clé privée. Combiné avec l’EIP-7702, les portefeuilles ZK peuvent injecter temporairement des contrats logiques spécifiques une fois la vérification terminée, afin de réaliser le déploiement de comportements personnalisés après l’informatique de confidentialité, tels que l’exécution automatique d’une certaine logique uniquement après que certaines conditions de confidentialité sont remplies.

● Les portefeuilles modulaires peuvent utiliser l’EIP-7702 pour désassembler la logique de compte en plusieurs modules et les charger dynamiquement si nécessaire.

Par conséquent, l’EIP-7702 fournit un « conteneur d’exécution » plus natif pour les portefeuilles avancés mentionnés ci-dessus : différentes logiques de contrat peuvent être injectées avec la même adresse utilisateur, évitant ainsi le problème de dépendance d’adresse dans le processus de déploiement de contrat traditionnel, et éliminant le besoin de pré-déploiement, améliorant considérablement la flexibilité et la combinaison du comportement du compte.

3. Implications pour les développeurs et

entraînera un profond changement dans le paradigme du développement. Les développeurs de contrats ne traitent plus simplement l’appelant comme un EOA traditionnel ou un compte contractuel fixe, mais doivent s’adapter à un nouveau mécanisme : l’identité de l’appelant peut être commutée dynamiquement entre l’EOA et le statut du contrat pendant la transaction, et la logique de comportement du compte n’est plus solidifiée statiquement, mais peut être modifiée de manière flexible en fonction de la demande. Cela exige des développeurs et des auditeurs qu’ils :

• introduisent une logique plus stricte de vérification de l’appelant et de jugement d’autorisation ;

• Vérifiez si le chemin d’appel est affecté par la logique de contrat dynamique ;

• identifier les vulnérabilités potentielles qui reposent sur des comportements tels que msg.sender.code.length == 0, isContract(), etc. ;

• Clarifier les « dépendances contextuelles » de la logique contractuelle, telles que le contrôle des limites des appels statiques et des appels délégués ;

• Au niveau de la chaîne d’outils, la simulation et l’analyse inverse des scénarios setCode sont prises en charge.

En d’autres termes, la sécurité du code n’est plus seulement un « problème de pré-déploiement » mais un « processus dynamique qui doit être vérifié lors de l’invocation et de la transaction ».

4.

introduit une implémentation plus légère, native et flexible de l’abstraction de compte (AA), de sorte que l’EOA ordinaire peut porter la logique contractuelle et l’exécuter en une seule transaction. Ce mécanisme brise les hypothèses statiques traditionnelles sur le comportement du compte, et les développeurs ne peuvent plus simplement se fier à l’état du code de l’adresse du compte pour juger de son modèle de comportement, mais doivent reconstruire la compréhension de l’identité et de la limite d’autorité de l’appelant.

Cela s’accompagne d’un changement de paradigme dans l’analyse de la sécurité. L’audit ne se limite plus à « savoir si une adresse dispose d’autorisations », mais à « ce que la logique contractuelle portée dans la transaction peut faire dans le contexte actuel ». Chaque transaction peut comporter une définition indépendante du comportement, ce qui donne au compte une plus grande fonctionnalité et met en avant des exigences plus élevées pour les audits de sécurité.