La sécurité du portefeuille MPC doit être améliorée ? Analyse approfondie de la défense de ZenGo contre les attaques des utilisateurs privilégiés

ZenGo est un portefeuille Web 3 sécurisé utilisant la technologie de calcul multipartite (MPC).
Récemment, l'équipe SkyFall de CertiK a mené un audit et une recherche approfondis sur de nombreux portefeuilles mobiles et a découvert que la solution MPC de ZenGo offre des défenses de sécurité plus solides que les portefeuilles mobiles ordinaires – les utilisateurs de portefeuille ZenGo, en particulier ceux possédant des portefeuilles de grande valeur, sont protégés contre les attaques directes d'attaquants avancés : par exemple, exploiter des vulnérabilités du jour zéro ou des logiciels malveillants avancés pour obtenir un accès root sur l'appareil de l'utilisateur.
Cette menace est la dernière en date et n'a été découverte que par l'équipe CertiK, les développeurs de portefeuilles MPC doivent donc prêter attention aux détails de l'attaque !
Se défendre contre des attaquants privilégiés est un véritable défi. Nous proposons une nouvelle méthode d'attaque et un nouveau vecteur d'attaque pour la méthode MPC dans ZenGo dans les résultats du rapport. Nous avons donc immédiatement signalé ce problème de sécurité à ZenGo, et ZenGo a répondu rapidement et résolu le problème.
Dans cet article, nous plongerons dans les détails techniques de la découverte et partagerons comment nous travaillons avec ZenGo pour améliorer la sécurité globale du portefeuille MPC.
Sur la base de notre examen approfondi de la conception de sécurité de ZenGo et de leurs réponses professionnelles aux problèmes, CertiK estime que ZenGo peut être considérée comme la solution de portefeuille la plus sécurisée actuellement sur le marché.
 Qu’est-ce que le MPC ?
Le calcul multi-parties (MPC), parfois également appelé calcul multi-parties sécurisé (SMPC), est un domaine de la cryptographie. Il permet à plusieurs parties de signer conjointement des transactions tout en garantissant que les clés de chaque partie ne sont pas compromises.
Étant donné que la technologie MPC peut distribuer des clés entre plusieurs parties, éliminant ainsi tout point de défaillance unique, elle permet aux utilisateurs de mieux protéger les clés privées Web 3. Cette méthode est également communément appelée « signature de seuil » et est actuellement utilisée par de nombreux Web 3. Adoptée par. dépositaires et développeurs de portefeuilles pour protéger les actifs Web 3. Parmi eux, ZenGo est l’un des développeurs de portefeuilles MPC les plus connus et les plus utilisés.
Comme le montre la figure ci-dessous, le portefeuille n'utilise pas de clé privée traditionnelle pour contrôler la signature des transactions. Au lieu de cela, plusieurs clés privées sont fragmentées pour participer au processus de signature de la transaction et générer une signature finale pour vérification.
 Conception MPC commune qui génère des signatures
Grâce à cette recherche, nous avons reconnu les défis et les risques de sécurité potentiels associés à l'approche MPC et l'importance de la protection des actifs Web 3. Nous souhaitons donc mieux protéger les utilisateurs du Web3 en explorant et en résolvant ces défis.
Nous pouvons donc réfléchir à cette question : pourquoi les portefeuilles MPC peuvent-ils offrir une sécurité supérieure par rapport aux portefeuilles cryptographiques traditionnels ? Comment ça se fait ?
 Conception du ZenGo MPC et assurance de sécurité
Grâce à cette recherche, nous avons reconnu les défis et les risques de sécurité potentiels associés à l'approche MPC et l'importance de la protection des actifs Web 3. Nous souhaitons donc mieux protéger les utilisateurs du Web3 en explorant et en résolvant ces défis.
Nous pouvons donc réfléchir à cette question : pourquoi les portefeuilles MPC peuvent-ils offrir une sécurité supérieure par rapport aux portefeuilles cryptographiques traditionnels ? Comment ça se fait ?
Après avoir évalué les conceptions de différents portefeuilles Web 3, nous avons examiné les portefeuilles Web 3 de MPC – nous avons évalué l'un des portefeuilles MPC les plus respectés du marché et le principal portefeuille MPC auto-hébergé – ZenGo.
Pour cette évaluation, nous avons utilisé le même modèle de menace que celui décrit dans nos recherches précédentes : « Si votre appareil est infecté par un logiciel malveillant, ce portefeuille protégera-t-il toujours vos actifs ?
 Présentation de l'architecture de sécurité ZenGo
Comme le montre l'image ci-dessus, le portefeuille ZenGo a une conception de sécurité unique, et l'architecture de sécurité et le processus de récupération sont plus complexes que les portefeuilles traditionnels. Les fonctionnalités de sécurité fournies par ZenGo incluent, sans s'y limiter :
Schéma de signature bipartite : la conception MPC de ZenGo implémente un schéma de signature bipartite. Chaque utilisateur implique deux fragments de clé lors de la génération d'une signature de transaction : l'un stocké sur les serveurs de ZenGo (clé principale ①) et l'autre stocké sur l'appareil de l'utilisateur (clé principale ②). Ni ZenGo ni l'utilisateur ne savent quelles clés l'autre détient.
Protection basée sur TEE : De plus, afin de prévenir les attaques de type « man-in-the-middle » et « APP hijacking », l'application ZenGo utilise une solution TEE (Trusted Execution Environment) et utilise une clé privée TEE pour signer le HTTPS. contenu de communication pour demander les API associées. Cette clé de périphérique basée sur TEE est générée dans le TEE lorsque l'utilisateur configure le périphérique et ne peut pas être extraite même par le système d'exploitation lui-même.
Avec ces fonctionnalités de sécurité en place, les attaquants ne peuvent plus voler les clés privées des utilisateurs de la mémoire ou des fichiers de stockage et prendre le contrôle des actifs des utilisateurs de ZenGo. ZenGo utilise également TEE pour protéger l'interaction entre le serveur et le client contre toute falsification. Cela signifie également que les attaques de type « homme du milieu » et « détournement d'application » sont efficacement bloquées et défendues.
Notre audit a confirmé que ZenGo dispose d'une conception et d'une mise en œuvre sécurisées capables de résister à ces attaques, et il s'agit du plus haut niveau de conception de sécurité parmi les portefeuilles audités avec lesquels nous avons été en contact.
La conception et la mise en œuvre de la sécurité de ZenGo protègent avec succès contre les attaques, notamment les privilèges et les attaques ci-dessus. Cependant, gérer tous les types d’attaques privilégiées n’est pas facile, d’autant plus que les attaquants peuvent lire (et dans certains cas écrire) de la mémoire arbitraire.
En auditant l'intégralité du portefeuille, nous avons pu découvrir un problème d'implémentation dans ZenGo qui nous permettait d'agir comme un attaquant privilégié et de contourner certaines protections.
Mais avant d’aborder les détails, passons en revue le mécanisme de sécurité du portefeuille ZenGo.
 Pratiques sûres pour le portefeuille ZenGo
Grâce à cette recherche, nous avons reconnu les défis et les risques de sécurité potentiels associés à l'approche MPC et l'importance de la protection des actifs Web 3. Nous souhaitons donc mieux protéger les utilisateurs du Web3 en explorant et en résolvant ces défis.
Nous pouvons donc réfléchir à cette question : pourquoi les portefeuilles MPC peuvent-ils offrir une sécurité supérieure par rapport aux portefeuilles cryptographiques traditionnels ? Comment ça se fait ?
Un portefeuille Web 3 classique ne nécessite qu'une clé privée. Cependant, il est toujours possible que l'utilisateur révèle la clé privée ou la phrase mnémonique. Ils pourraient donc perdre leurs clés privées et voir ensuite un attaquant prendre possession des actifs.
Le portefeuille MPC fonctionne différemment. Le portefeuille ne possède pas une seule clé privée. L’utilisateur ne détient désormais qu’un seul fragment de clé privée et ne sait rien des fragments de clé privée restants. De ce point de vue, même si l'attaquant obtient la clé personnelle de l'utilisateur, il ne peut pas transférer directement des fonds. Afin de protéger davantage les utilisateurs, ZenGo utilise divers moyens pour renforcer sa conception de sécurité : non seulement le système de signature bipartite mentionné ci-dessus et la protection des appareils basée sur TEE, mais également l'authentification biométrique basée sur la numérisation faciale et le cryptage par clé supplémentaire.
 Mesures de protection lors de l'enregistrement de l'utilisateur et de la récupération du compte utilisateur
Pendant le processus d'enregistrement de l'utilisateur et de récupération de compte, ZenGo adopte les mesures de protection suivantes pour protéger les actifs des utilisateurs.
Protection de l'identification de l'utilisateur : le système de signature bipartite exige que les utilisateurs ne puissent utiliser leurs fonds que lorsqu'ils interagissent avec une autre partie (le côté serveur dans les paramètres de ZenGo). Afin de pouvoir identifier l'utilisateur et les partages de clés associés stockés sur le serveur, ZenGo nécessite l'e-mail de l'utilisateur afin de créer un compte.
Pour éviter le piratage des e-mails, ZenGo utilise la technologie de numérisation faciale (Zoom by FaceTec) pour lier les informations biométriques aux comptes d'utilisateurs. Pendant le processus de récupération de compte après l'enregistrement et la vérification de l'e-mail, les utilisateurs doivent « glisser leur visage » pour s'authentifier.
Protection des communications application-serveur : pour garantir que les serveurs ZenGo interagissent avec les appareils des utilisateurs légitimes, ZenGo génère et enregistre une clé asymétrique dans l'environnement TEE pendant le processus d'enregistrement et de récupération de compte. Toutes les interactions entre l'application ZenGo et le serveur doivent être signées par cette clé spécifique. Parce qu'elle est protégée par une solution de sécurité matérielle, cette clé ne peut pas être directement lue par un attaquant et il est difficile d'en abuser.
 Processus d’enregistrement des utilisateurs ZenGo et de récupération de compte
Protection du partage de clé utilisateur : permettre aux utilisateurs de stocker et de sauvegarder leurs fragments de clé est risqué, car cela peut compromettre toutes les mesures de sécurité fournies par ZenGo. Pour résoudre ce problème de sécurité, ZenGo génère une clé de cryptage lors du processus d'inscription. La clé de chiffrement chiffre le partage de clé de l'utilisateur et stocke le texte chiffré sur son serveur.
Cependant, les clés de cryptage ne sont pas partagées avec ZenGo, forçant plutôt la synchronisation avec Google Drive ou iCloud de l'utilisateur. La clé cryptée ne peut être partagée et déchiffrée qu'après que l'utilisateur a réussi la vérification du courrier électronique et l'authentification biométrique sur le serveur. Parmi eux, l'authentification biométrique basée sur un serveur (reconnaissance faciale FaceTec) est presque impossible à « tromper » par la reconstruction faciale 2D/3D conventionnelle.
 Processus de transaction ZenGo de génération de signature de transaction
Afin de signer une transaction, l'application ZenGo effectue une série d'interactions avec le serveur ZenGo. Pendant l'interaction, ZenGo utilise sa solution open source de signature bipartite et le partage de clés utilisateur pour générer des signatures bipartites. Le serveur ZenGo va ensuite plus loin en signant et en diffusant la transaction. Toutes les demandes de ce processus sont horodatées et signées dans le TEE pour maintenir l'intégrité et la non-rejouabilité des informations.
 Découverte de problèmes dans la conception ZenGo MPC
Comme nous l'avons déjà évoqué, la conception de la sécurité de ZenGo implique de nombreuses clés de cryptage, chacune ayant des responsabilités différentes. Dans le tableau ci-dessous, nous montrons quelles clés sont utilisées par ZenGo et comment elles sont protégées.
A travers ce tableau, nous pouvons voir que trois clés sont utilisées côté client : la clé principale ②, la clé de l'appareil et la clé de chiffrement. Un attaquant doit obtenir à la fois la clé principale② et la clé de l'appareil pour interagir avec le serveur ZenGo et voler les fonds des utilisateurs.
Comme introduit dans la section précédente sur les détails de la transaction, la clé principale ② est en mémoire sous forme de texte participant à la génération des signatures des deux parties, ce qui permet à un attaquant de lire la mémoire du processus et d'extraire la clé principale ②. En guise de solution partielle, toutes les demandes de transaction adressées au serveur ZenGo doivent être signées par une clé de périphérique, qui ne peut être ni lue ni extraite. Ce processus est effectué dans le TEE et n'a aucun contrôle sur l'attaquant.
Cependant, malgré les nombreux aspects de la conception de sécurité de ZenGo, l'équipe SkyFall de CertiK y a quand même découvert une vulnérabilité. Après avoir effectué un audit détaillé de toutes les API de l'application ZenGo, nous avons remarqué que certaines API permettent à un attaquant d'usurper les serveurs ZenGo et de générer facilement une nouvelle clé d'appareil à utiliser sur d'autres appareils.
Cette API enregistrée par clé de périphérique ne dispose pas des protections de sécurité nécessaires : un attaquant peut générer une nouvelle clé à courbe elliptique NIST P-256 sur un autre appareil, puis l'attaquant peut exploiter l'API enregistrée par clé de périphérique et enregistrer une nouvelle clé. , faites semblant d'être un nouvel appareil utilisateur et demandez une transaction.
Nous appelons ce dispositif d’attaque attaque par forking.
 Attaque de forking d'appareil sur le portefeuille ZenGo
Comme mentionné ci-dessus, un attaquant aurait besoin de disposer de la clé principale de l'utilisateur ZenGo ② et d'une clé d'appareil valide pour voler ses actifs.
Clé principale ② : La clé principale ② est une clé fixe qui est utilisée comme texte brut en mémoire pour participer au processus de signature des deux parties. En raison de la complexité et du caractère unique des algorithmes de signature des deux parties, ce processus ne peut pas être réalisé dans TEE. Par conséquent, un attaquant privilégié pourrait simplement vider la mémoire du processus ou détourner certaines API du système pour extraire la clé principale. La capture d'écran ci-dessous montre la clé principale que nous pouvons extraire sur la plateforme iOS ②.
Clé d'appareil : pendant le processus d'enregistrement ou de récupération de compte, une clé d'appareil valide est générée sur l'appareil de l'utilisateur dans le TEE comme solution à la menace d'extraction de texte en clair susmentionnée. La clé de l'appareil ne peut pas être lue par un attaquant privilégié. Cependant, un attaquant peut utiliser la même API d'enregistrement de clé de périphérique pour enregistrer une autre paire de clés et l'utiliser.
L'API d'enregistrement de la clé de l'appareil ne dispose que d'un mécanisme d'authentification très basique : un attaquant peut utiliser un jeton JWT en texte brut commun stocké localement et la clé principale extraite ② pour l'authentification de l'API. De par sa conception, le code du serveur impliqué dans cette API doit également être authentifié biométriquement Face Tec. Cependant, dans la pratique, le code ne parvient pas à effectuer cette étape en raison de défauts logiques.
Dans notre attaque simulée, nous avons simulé un attaquant privilégié et surveillé en permanence l'appareil de la victime. Dès le lancement de l'application ZenGo, nous extrayons la clé principale de la mémoire et lisons le token API de la base de données locale. Et ces informations suffisent à l’attaquant pour voler tous les fonds de l’utilisateur !
Une fois que nous avons le jeton API, nous générons une nouvelle clé de périphérique et appelons l'API d'enregistrement de clé de périphérique pour enregistrer la clé de périphérique auprès du serveur ZenGo. Nous avons ensuite construit toutes les requêtes API pour interagir avec le serveur ZenGo afin d'initier des transactions. Pour le portefeuille MPC, générer des signatures des deux parties est un processus unique et complexe. Heureusement, le processus de développement de ZenGo a toujours adhéré à l'esprit open source, nous avons donc pu compiler la bibliothèque de signatures bipartite utilisée dans l'application officielle ZenGo et l'exécuter localement.
L'image ci-dessus montre comment nous extrayons la clé principale ② et enregistrons une nouvelle clé de périphérique au nom de la victime. Nous avons ensuite utilisé ces deux clés pour envoyer 0,00222 ETH sur le « compte de l'attaquant ». L’ensemble du processus ne prend que quelques secondes et ne connaît absolument pas la victime.
Pour résoudre ce problème, ZenGo a implémenté l'authentification biométrique FaceTec côté serveur pour l'enregistrement des appareils. Les solutions de contournement au niveau de l'API du serveur éliminent la possibilité de cette attaque et ne nécessitent pas de mise à jour du code client.
 Résumer
Dans l’évaluation de ZenGo par CertiK, nous avons soigneusement examiné et audité toutes les mesures de sécurité mises en place pour protéger les actifs des utilisateurs. Ceux-ci incluent des systèmes de signature mutuelle, une protection des appareils basée sur TEE et des données biométriques pour l'enregistrement et la récupération des comptes.
Bien que ZenGo soit très sensibilisé à la sécurité et ait pris de nombreuses mesures pour améliorer sa sécurité, CertiK a découvert un risque clé d'authentification d'accès API exploitable dans la mise en œuvre de ZenGo. Cette vulnérabilité pourrait permettre à un attaquant privilégié de contourner les mesures de sécurité existantes et de voler les fonds d'un utilisateur si son appareil est compromis.
ZenGo a rapidement résolu le problème et déployé un correctif, et CeritK a ensuite mené un audit approfondi et déterminé que le correctif corrigeait les risques mentionnés dans le rapport.
Avec le déploiement de correctifs, nous pensons que ZenGo peut empêcher efficacement les utilisateurs privilégiés d'accéder illégalement aux fonds des utilisateurs à l'avenir. Se défendre contre les attaquants privilégiés est une tâche difficile, et les pratiques de sécurité de ZenGo nous montrent une approche globale de la protection des utilisateurs. Ce portefeuille fait plus que la plupart des portefeuilles conventionnels actuellement sur le marché.
Nous sommes fiers de nous associer à ZenGo et de travailler avec ZenGo pour protéger la sécurité des utilisateurs du Web 3 et résoudre les problèmes de sécurité. Nous tenons également à remercier ZenGo pour sa réponse rapide aux vulnérabilités que nous avons découvertes et pour ses actions de correction efficaces.
En tant que praticiens du secteur de la sécurité, nous sommes très heureux de voir une des principales sociétés de portefeuilles Web 3 prendre la sécurité si au sérieux et avoir un sens aussi élevé des responsabilités à l'égard des utilisateurs et de leurs fonds. Nous espérons que sur la voie de la sécurité à l'avenir, nous pourrons améliorer la sécurité d'un plus grand nombre de projets et donner à leurs utilisateurs une « tranquillité d'esprit ».