Comment utiliser WalletConnect pour connecter les portefeuilles en toute sécurité

Architecture du protocole de base

1. WalletConnect fonctionne via un système de messagerie basé sur un relais où ni le DApp ni le portefeuille n'établissent une communication directe peer-to-peer.

2. Une connexion WebSocket est initiée entre l'interface DApp et le serveur de relais officiel WalletConnect à l'adresse wss://relay.walletconnect.com.

3. Le DApp génère un sujet unique et une paire de clés temporaires, en les intégrant dans un URI formaté selon la spécification EIP-1328.

4. Cet URI est rendu sous forme de code QR visible sur l'interface DApp, contenant des métadonnées de session cryptées, y compris l'horodatage d'expiration et l'identifiant du protocole de relais.

5. Lors de l'analyse, le portefeuille mobile analyse l'URI, extrait le sujet et la clé symbolique et s'abonne au même canal relais en utilisant des paramètres de cryptage identiques.

Exigences d'intégration du portefeuille

1. Les portefeuilles doivent implémenter le SDK client WalletConnect V2, prenant en charge la négociation d'espace de noms EIP-155 pour une compatibilité multi-chaînes.

2. Chaque blockchain prise en charge doit être déclarée avec son identifiant de chaîne et les méthodes demandées, telles que eth_sendTransaction ou personal_sign.

3. Le portefeuille applique une portée stricte des autorisations : il n'expose jamais les clés privées, signe uniquement les charges utiles à l'aide de modules cryptographiques locaux de l'appareil.

4. L'approbation de la session nécessite une confirmation explicite de l'utilisateur de l'identité DApp, des chaînes demandées et des autorisations fonctionnelles avant d'établir une liaison RPC.

5. Tous les messages ultérieurs, y compris les demandes de transaction et les invites de signature, sont chiffrés de bout en bout à l'aide de l'AES-256-GCM dérivé du secret Diffie-Hellman partagé.

Mécanismes d'application de la sécurité

1. Les clés privées restent entièrement isolées dans l'environnement d'exécution sécurisé du portefeuille : jamais transmises, jamais exposées à la mémoire accessible par les contextes Web.

2. Le serveur relais ne peut pas décrypter les charges utiles ; il transmet uniquement le texte chiffré entre les points de terminaison sans interpréter le contenu.

3. L'expiration de la session est appliquée à la fois côté client et côté relais, avec des limites par défaut fixées à 7 jours, sauf dérogation lors de la proposition.

4. Chaque session porte un identifiant d'appariement immuable, permettant une révocation déterministe via des commandes de déconnexion initiées par le portefeuille.

5. Aucune session ne persiste après le redémarrage de l'application, sauf si l'utilisateur l'approuve explicitement à nouveau : la reconnexion automatique est désactivée par conception.

Gestion des espaces de noms multi-chaînes

1. Les DApp déclarent les espaces de noms requis dans leur proposition de session, en spécifiant des chaînes telles que eip155:1 (Ethereum Mainnet) et eip155:137 (Polygone).

2. Les portefeuilles répondent avec des espaces de noms approuvés, qui peuvent différer en fonction de la sélection de l'utilisateur ou des contraintes de capacité du portefeuille.

3. Le changement de chaîne pendant les sessions actives déclenche de nouvelles invites d'autorisation : aucun repli silencieux ni autorisation automatique ne se produit.

4. Les requêtes RPC sont acheminées exclusivement vers les chaînes incluses dans l'espace de noms approuvé, évitant ainsi les fuites entre chaînes ou les transactions mal orientées.

5. Une seule session WalletConnect peut maintenir simultanément des contextes actifs sur plusieurs chaînes compatibles EVM sans duplication de session.

Gestion du cycle de vie des sessions

1. L'initiation de la connexion commence par la génération d'URI et le rendu QR : aucune négociation réseau n'a lieu avant la fin de l'analyse.

2. Une fois couplé, le portefeuille stocke l'état de la session localement à l'aide d'un stockage crypté lié à la biométrie ou au code PIN de l'appareil.

3. Les utilisateurs peuvent afficher toutes les sessions actives dans l'interface utilisateur du portefeuille sous « Applications connectées », avec des indicateurs d'état en temps réel pour chaque DApp.

4. La révocation d'une session met fin à tous les abonnements associés, invalide la clé partagée et purge immédiatement le contexte de signature mis en cache.

5. Les métadonnées de session, notamment l'origine du DApp, la portée de la chaîne et l'heure de la dernière interaction, ne sont jamais partagées avec des services d'analyse ou de télémétrie tiers.

Foire aux questions

Q : WalletConnect stocke-t-il les clés privées sur ses serveurs relais ? Les serveurs relais WalletConnect ne gèrent ni ne stockent les clés privées. Ils transmettent uniquement des charges utiles chiffrées sans capacité de décryptage.

Q : Un DApp malveillant peut-il déclencher des transactions non autorisées après la connexion ? Non. Chaque demande de transaction nécessite l'approbation explicite de l'utilisateur dans l'interface du portefeuille. Aucune opération ne s'exécute sans confirmation manuelle.

Q : Est-il possible de connecter le même portefeuille à deux DApps différentes simultanément ? Oui. WalletConnect prend en charge les sessions simultanées. Chaque DApp reçoit un contexte de session isolé avec des autorisations et des étendues de chaîne distinctes.

Q : Que se passe-t-il si le serveur relais se déconnecte pendant une session active ? Les sessions actives continuent de fonctionner car le chiffrement des messages et la logique de routage résident entièrement dans les implémentations côté client. L'indisponibilité du relais affecte uniquement les nouvelles tentatives de connexion.