Construire un agent IA dénué de confiance : Guide d'audit de sécurité ERC-8004

null

Avec le déploiement officiel de la norme ERC-8004 (Trustless Agents) sur le mainnet Ethereum, la gestion de l’identité et de la réputation de l’IA Agent est entrée dans une nouvelle phase de vérification et de confidentialité. La norme offre aux agents un « système d’identité » vérifiable en chaîne via trois registres principaux : le registre d’identité, le registre de réputation et le registre de vérification. Cet article analysera les points de risque de chaque registre du point de vue des audits de sécurité, combinés aux détails techniques de l’ERC-8004, et fournira un guide pratique d’audit pour les développeurs et auditeurs.

Détails techniques et points d’audit

La clé de l’ERC-8004 réside dans ses trois registres :

1. Registre d’identité

Un handle minimal on-chain basé sur ERC-721 avec une extension URIStorage qui analyse le fichier d’enregistrement de l’agent, fournissant à chaque agent un identifiant portable résistant à la censure.

Dans l’architecture d’ERC-8004, le registre d’identité est construit au-dessus d’ERC-721 et étend la fonctionnalité URIStorage. En d’autres termes, chaque agent correspond à un NFT unique en chaîne, appelé un AgentID.

Lorsqu’un développeur crée un agent, il appelle la fonction registre du contrat de registre pour frapper un nouvel AgentID. Ce jeton est lié à un tokenURI qui pointe vers un fichier JSON stocké hors chaîne - le soi-disant « fichier d’enregistrement proxy ». Les documents d’enregistrement doivent suivre des spécifications strictes et incluent généralement trois catégories principales :

• Informations de base telles que le nom, la description, l’URL de l’avatar ;

• Le point de terminaison du service, qui est l’adresse réseau accessible par le proxy, prend en charge divers protocoles tels que HTTP, WebSocket, Libp2p, A2A, MCP, etc.

• Les instructions de capacité, qui sont des listes de tâches que les agents peuvent accomplir, telles que la génération d’images, le trading d’arbitrage ou l’audit de code.

L’auto-déclaration seule ne suffit clairement pas à instaurer la confiance, donc ERC-8004 introduit un mécanisme de validation de domaine. Les agents doivent héberger un document signé sous leur nom de domaine revendiqué à l’adresse /.well-known/agent-card.json. Le registre en chaîne vérifie ce lien pour lier l’AgentID en chaîne au nom de domaine DNS correspondant. L’importance de cette étape est de prévenir les attaques de phishing et d’usurpation d’identité, et le proxy ne peut pas prétendre arbitrairement appartenir à un nom de domaine, mais doit prouver le contrôle par une signature cryptographique.

Points d’audit :

● Vérifier le contrôle d’accès de la fonction setTokenURI pour s’assurer que seuls les propriétaires de proxy ou les rôles autorisés (comme onlyOwnerAfterMint) sont autorisés à mettre à jour l’URI.

● Vérifier si l’URI prend en charge des scénarios de stockage immuables (par exemple, IPFS, Arweave). Si vous utilisez un lien HTTP centralisé, vous devez évaluer la sécurité de votre contrôle de noms de domaine pour éviter tout détournement DNS.

● Vérifier la légitimité du format URI afin d’éviter les exceptions contractuelles causées par des pointeurs vides ou des URI invalides.

● Vérifier que le contrat effectue strictement une vérification des signatures cryptographiques (comme EIP-712) lors de la vérification des signatures de noms de domaine afin d’éviter la falsification de signature ou les attaques de relecture.

● Vérifier le mécanisme d’expiration des certificats de propriété de nom de domaine afin d’éviter la réutilisation de signatures valides à long terme.

● S’assurer que le processus de résolution de noms de domaine ne dépend pas d’oracles centralisés, évitant ainsi des points de défaillance ou de manipulation isolés.

2. Registre de la réputation

Interface standard pour publier et obtenir des signaux de rétroaction. Le scoring et l’agrégation se font à la fois en chaîne (composabilité) et hors chaîne (algorithmes complexes), permettant un écosystème de services professionnels composé de notation d’agents, de réseaux d’audit et de pools d’assurance.

Utilisé pour évaluer et revenir sur les agents IA enregistrés. Une simple soumission de rétroaction est effectuée sur la chaîne, et la chaîne hors chaîne complexe peut être étendue et agrégée sur la chaîne.

ERC-8004 peut également prévenir les scores malveillants via le mécanisme de « Payment-Proof Linking ». Lorsque l’agent A termine d’évaluer l’agent B, appelez la fonction giveFeedback. Cette fonction accepte non seulement les hachages de score (0-100) et de commentaires, mais permet aussi de passer dans un champ paymentProof, généralement le hachage d’une transaction x402. Cela rend le coût des avis de brossage extrêmement élevé et réduit considérablement le risque d’attaques de Sybil. Au final, l’ensemble du système récompense naturellement des agents constants et de haute qualité.

Points d’audit :

● Vérifier que la fonction giveFeedback applique le paramètre paymentProof et vérifier qu’il s’agit d’un hachage de transaction x402 valide (ou qu’il respecte d’autres normes de paiement). La preuve de paiement doit être assurée qu’il n’est pas réutilisable (par exemple, enregistrer les hachages utilisés) afin d’éviter plusieurs évaluations lors d’un seul paiement.

● Vérifier si la plage de score (0-100) est appliquée au niveau du contrat afin d’éviter de dépasser la limite de la limite qui brise la logique d’agrégation.

● Évaluer la résistance des algorithmes d’agrégation hors chaîne : par exemple s’il faut utiliser des médianes, des extrêmes raccourcis ou des moyennes pondérées, et sanctionner les comportements anormaux (comme un grand nombre d’évaluations en peu de temps).

● Examiner si les conditions de coupure sont claires et vérifiables, par exemple si elles s’appuient sur des preuves sur la chaîne ou des oracles tiers pour soumettre des preuves de fraude.

● Assurez-vous que la logique de la barre oblique n’inclut pas de privilèges centralisés (par exemple, les administrateurs peuvent confisquer les fonds en stash à volonté), et que les conditions de déclenchement de la barre blanche doivent être entièrement exécutées automatiquement par le contrat intelligent.

● Tester la période de verrouillage et les conditions pour les retraits de dépôts afin d’empêcher les agents de retirer des fonds d’urgence avant d’être rendus.

3. Registre de validation

Accroches universelles pour demander et documenter des vérifications indépendantes des validateurs (par exemple, validateurs zkML, oracles TEE, juges de confiance).

La réputation reflète le passé, mais dans des scénarios à haut risque (comme la planification de grands capitaux), l’histoire seule ne suffit pas. Le registre de validation permet aux agents de soumettre les résultats à des systèmes tiers ou automatisés pour vérification, et les requêtes peuvent être vérifiées ou rejetées à l’aide d’outils tels que la réexécution d’inférence sécurisée par staking, les validateurs zkML ou les oracles TEE.

Le premier modèle est la vérification cryptoéconomique, basée sur la conception de la sécurité en théorie des jeux. Les agents doivent miser un certain nombre de jetons natifs ou de stablecoins dans le registre. Si un agent ne remplit pas ou fournit un résultat incorrect, le réseau de validation peut soumettre une preuve de fraude, ce qui déclenche la perte automatique de la part du contrat intelligent. Ce modèle convient aux tâches où les résultats sont facilement vérifiables mais où le processus informatique est opaque, comme le scraping de données ou les services API simples.

Le second modèle est la vérification cryptographique, qui est une conception sécurisée fondée sur des principes mathématiques. La certification TEE (Trusted Execution Environment) permet aux agents de fonctionner dans un environnement matériel sécurisé, tel qu’Intel SGX ou AWS Nitro. Le registre de validation peut stocker et valider les rapports d’authentification à distance du matériel pour prouver que l’agent exécute une version spécifique du code qui n’a pas été modifiée.

zkML (Zero-Knowledge Machine Learning) est une autre méthode pour vérifier la cryptographie. L’agent soumet une preuve à connaissance nulle en même temps que le résultat d’inférence. Cette preuve peut être vérifiée par des contrats de validation en chaîne à un coût très faible, garantissant mathématiquement que la sortie est bien générée par un modèle spécifique (comme Llama-3-70B) sous des entrées spécifiques. Cela empêche les attaques de « vol de modèles », où les fournisseurs de services prétendent utiliser des modèles haut de gamme mais utilisent en réalité des modèles de bas ordre pour économiser des coûts.

Points d’audit

Pour la vérification cryptoéconomique, vérifiez :

● Vérifier la fenêtre de soumission pour des preuves de fraude : Les validateurs ont-ils suffisamment de temps pour découvrir et soumettre les preuves ? Une période de fenêtre trop courte peut manquer un comportement malveillant, et si elle est trop longue, cela conduira à un long blocage des fonds.

● Logique d’adjudication pour vérifier les preuves de fraude : repose-t-elle sur des ensembles de validateurs multisig ? Si tel est le cas, le degré de décentralisation et les paramètres de seuil choisis par le validateur doivent être examinés ; Si la décision est entièrement sur la chaîne, il est nécessaire de s’assurer que la base de l’attribution (comme les résultats vérifiables sur la chaîne) existe et est sans ambiguïté.

● Assurez-vous que le montant de la mise de gage correspond au risque pour prévenir des comportements malveillants à faible coût (comme un engagement trop faible, les bénéfices du mal sont bien supérieurs aux pertes).

Pour la certification TEE, vérifiez :

● Vérifier si le contrat vérifie la rapidité des épreuves TEE (par exemple en incluant les horodatages ou les hauteurs de blocs) afin d’empêcher l’acceptation des épreuves expirées.

● Vérifier si le contenu de la preuve contient le hachage de code du proxy et le résumé entrée/sortie afin de s’assurer que la preuve est liée à une tâche spécifique afin d’éviter la réutilisation croisée des tâches.

● Évaluer si la logique de vérification de la preuve TEE repose sur des oracles externes (tels qu’Intel IAS), et si oui, auditer la sécurité et la décentralisation des oracles.

Pour la validation zkML, vous devez vérifier :

● Confirmer que le contrat s’intègre aux bibliothèques de vérification zk auditées (par exemple, SnarkVerifier) et configure correctement la clé de vérification pour des systèmes de preuve spécifiques (par exemple, Groth16, PLONK).

● Vérifier si le contrat de vérification restreint le modèle et la plage d’entrée applicables à la preuve pour prévenir les attaques d’échange de modèles (par exemple, la preuve est générée pour un petit modèle mais prétend être la sortie d’un grand modèle).

● Évaluer la décentralisation de la génération de preuves : repose-t-elle sur un seul provecteur ? S’il y a plusieurs provers, un mécanisme de consensus devrait être conçu pour empêcher les provers malveillants.

Épilogue

ERC-8004 fournit une norme pour établir la confiance dans les agents IA, et sa sécurité est essentielle pour l’ensemble de l’écosystème des agents en chaîne. Les audits de sécurité exigent une compréhension approfondie de l’intention de conception et des risques potentiels des trois registres. De plus, la complexité et les vulnérabilités courantes des interactions inter-contractuelles ne peuvent être ignorées. Un audit complet et rigoureux est nécessaire pour garantir que l’ERC-8004 tient véritablement sa promesse de « confidentialité », posant ainsi les bases de l’avenir des agents autonomes.