L'audit de Pera Wallet par Hacken ne relève aucune faille critique, mais une vulnérabilité High dans du code partagé

Pera Wallet a publié un examen de sécurité indépendant de l'application mobile qu'elle a reconstruite cet été, et l'auditeur n'y a trouvé aucune faille critique. Hacken¹ a passé en revue l'application, la garde de ses clés et ses passkeys au cours des mois de septembre et octobre 2026.

Pera Wallet² est un portefeuille Algorand auto-dépositaire : seul l'utilisateur détient les clés privées. Sa refonte 7.0³, cet été, a remplacé les applications Swift et Kotlin distinctes par une base de code React Native unique pour les deux plateformes.

Cet examen constitue la vérification dont notre article d'août sur cette refonte signalait l'absence. Il porte sur la base de code que les deux boutiques diffusent aujourd'hui.

Ce qui a été audité

L'étude de cas de Hacken situe l'audit en septembre et octobre 2026 et nomme quatre dépôts. Il s'agit de l'application portefeuille React Native, du paquet de base partagé wallet-provider, des extensions keystore et compte construites sur ce dernier, ainsi que du module natif de remplissage automatique des passkeys pour Android et iOS. Seul le dépôt de l'application appartient à Pera. Les trois autres sont des projets de la Fondation Algorand, ce que décrit le billet de blog⁴ de Pera lorsqu'il indique qu'une partie du périmètre couvrait l'infrastructure open source partagée maintenue par Algorand, y compris des composants qui font tourner Rocca Wallet. Rocca est le framework de portefeuille de la Fondation sur lequel Pera affirme que la version 7.0 s'appuie en partie. Le dépôt de l'application est celui qu'a produit la refonte : un seul audit couvre donc désormais les deux plateformes.

Le journal des modifications du rapport⁵ date la version préliminaire du 1er septembre 2026 et le rapport final du 19 octobre 2026. Le billet de blog de Pera et l'étude de cas de Hacken ont tous deux été mis en ligne le 10 novembre.

La liste auditée comprend quatre dépôts et aucune extension de navigateur. La page d'accueil de Pera en fait pourtant la promotion, sous le slogan « Pera Is Now in Your Browser⁶ ».

Ce qui a été trouvé

L'étude de cas de Hacken fait état de 21⁷ constats et affirme qu'aucun problème de gravité critique n'a été identifié pendant l'audit. Son décompte des remédiations indique 16⁸ constats résolus, 4⁹ acceptés et 1¹⁰ atténué. Hacken consigne également une couverture de branches, sur les quatre dépôts, allant de la fin des années 60 à 100¹¹ % selon le paquet, la plupart des paquets sensibles sur le plan de la sécurité se situant entre 80¹² et 97 %.

Le billet de blog de Pera, publié le même jour, indique que l'audit s'est « conclu en octobre 2026¹³ » et que « chaque constat identifié a depuis été résolu¹⁴ ». Il ajoute : « Aucune vulnérabilité critique n'a été trouvée, et tous les constats identifiés ont été traités.¹⁵ » Le « traités » de Pera recouvre donc des correctifs, une atténuation et quatre constats acceptés en l'état.

L'unique constat High

Un problème a reçu la note High et, comme l'utilisateur est seul détenteur des clés, une faiblesse à ce niveau ne dispose d'aucun filet de sécurité côté serveur. Hacken décrit ce constat comme un utilitaire inutilisé dans le paquet de keystore partagé, inactif dans les flux de production de Pera Wallet. Cet utilitaire dérivait sa clé de chiffrement d'une valeur qui n'est pas secrète : quiconque détenait cette valeur pouvait reproduire la clé et déchiffrer. Les projets autres que Pera qui s'appuient sur le paquet partagé peuvent appeler le code concerné, précise la note du rapport. Hacken indique que le problème a été signalé au mainteneur du paquet le jour même où il a été soulevé. Pera disposait de pull requests de remédiation liées à chaque constat environ deux semaines avant la clôture de la fenêtre de remédiation.

Cette description compte pour quiconque serait tenté de lire la note High comme une alerte générale sur l'application. L'auditeur situe la faille hors des chemins empruntés par l'application Pera, dans du code partagé par d'autres portefeuilles et projets.

Où se concentraient les constats

Le résumé de Hacken regroupe une bonne partie de l'audit autour des passkeys et de la gestion de WebAuthn. Son rapport mentionne un chemin Android qui indiquait à une partie de confiance qu'un utilisateur avait été vérifié alors qu'aucune invite biométrique n'avait été déclenchée. Il mentionne du code de nettoyage susceptible d'effacer tout l'espace de noms du keystore partagé du portefeuille, et pas seulement les entrées propres aux passkeys. Il mentionne aussi une dérivation déterministe fondée sur le nom d'affichage d'un compte plutôt que sur son identifiant utilisateur WebAuthn stable, si bien que deux comptes partageant un nom pouvaient aboutir au même matériel de clé. Le dernier de ces points figure parmi les quatre constats acceptés, aux côtés d'une observation sur la façon dont le verrouillage après plusieurs essais de PIN décompte le temps.

Cette surface appartient au type de portefeuille le plus récent. Le guide des passkeys¹⁶ de Pera, mis à jour le 28 octobre 2026, précise que les passkeys ne sont disponibles que pour les Universal Wallets, et non pour les portefeuilles Algo25 hérités. Elles sont dérivées de l'Universal Wallet et stockées sur l'appareil, et le guide indique que la prise en charge du protocole Liquid Auth est « à venir ». Un Universal Wallet tire jusqu'à 50 comptes d'une phrase BIP-39 de 24¹⁷ mots. La partie la plus profonde de l'audit concerne donc le type de portefeuille qui utilise les passkeys, et uniquement les détenteurs qui les ont configurées.

Qui a réalisé l'audit

C'est Pera qui a commandé les travaux : l'étude de cas de Hacken qualifie Pera Wallet d'affilié d'Algorand ayant engagé Hacken pour évaluer son application portefeuille ainsi que l'infrastructure de garde des clés et de passkeys qui la sous-tend. « Indépendant » décrit qui a fait le travail, pas qui l'a demandé.

Will Beaumont, responsable de l'ingénierie chez Pera, est cité dans l'étude de cas sur l'importance de cet examen. Il a déclaré que le code devait être examiné par des experts externes autant que par les ingénieurs sécurité de Pera.

Ce que le lecteur fait maintenant

Pera affirme que la version auditée est celle diffusée sur les boutiques : pour un détenteur, l'étape consiste donc à mettre à jour depuis la boutique d'applications. Quiconque souhaite se faire son propre avis sur l'audit peut ouvrir le rapport, qui liste chaque constat avec sa gravité et son statut.

21

Constats identifiés

16

Résolus

4

Acceptés

1

Atténués

• Constats identifiés: 21.
• Résolus: 16.
• Acceptés: 4.
• Atténués: 1.