Passkeys sur l’EVM… Un retour du terrain

Le problème de l’onboarding

Nous sommes tous d'accord que les wallets non-custodiaux actuels posent de nombreux défis pour les utilisateurs novices, allant de la configuration et la gestion de la seed-phrase jusqu'au onramp pour pouvoir faire des transactions…

L'émergence de l'abstraction de compte (AA) nous permet de répondre à bon nombre de problèmes avec des fonctionnalités telles que les transactions “gasless” (sans payer le coût en gaz), le batching de transaction et les systèmes de gardiens (social recovery). Cependant, cela ne résout pas entièrement le problème de l'expérience utilisateur pour l'adoption grand public.

Les modèles MPC (ou calcul multipartite sécurisé), utilisés par des entreprises comme Web3Auth ou Magic Link, offrent une expérience utilisateur acceptable (souvent avec des popups ou code pin) mais ne préservent pas la vie privée ou ne maintiennent pas une offre “non-custodiale” complète, créant une dépendance à un service centralisé. Elles permettent à des développeurs novices de gagner du temps à l’implémentation.

On pourrait alors se demander : est-il possible d'atteindre une bonne expérience utilisateur sans compromettre la vie privée et la sécurité des usagers ?

Depuis 2023, les Passkeys gagnent en popularité dans l’écosystème blockchain, promettant une meilleure expérience utilisateur et une meilleure sécurité grâce à des fonctionnalités clés.

Que sont exactement les Passkeys ?

Les Passkeys sont une information d'identification numérique basée sur la norme webAuthn, visant à fournir une alternative plus pratique et plus sûre aux mots de passe.

La principale distinction entre les Passkeys et WebAuthn réside dans leurs capacités de synchronisation. Pour cette raison, j'utiliserai le terme Passkeys tout au long de cet article.

L'utilisation de mots de passe met beaucoup de responsabilité sur les utilisateurs. Choisir des mots de passe forts et s'en souvenir à travers divers comptes peut être difficile. De plus, même les utilisateurs les plus avertis sont souvent trompés lors de tentatives de phishing. La 2SV (2FA/MFA) aide, mais met à nouveau l'utilisateur sous pression avec une friction supplémentaire indésirable et ne protège pas complètement contre les attaques de phishing et les attaques ciblées comme les "échanges de SIM" pour la vérification par SMS. WebAuthn aide à résoudre tous ces problèmes.

Dans les Passkeys, la clé privée vit sur vos appareils et dans certains cas, elle reste uniquement sur l'appareil sur lequel elle a été créée. Dans d'autres cas, votre système d'exploitation ou une application semblable à un gestionnaire de mots de passe peut la synchroniser avec d'autres appareils que vous possédez. Les fournisseurs de synchronisation de Passkeys comme le gestionnaire de mots de passe de Google et le trousseau iCloud utilisent un chiffrement de bout en bout pour garder vos passkeys privés.

Qu’est ce que le standard WebAuthn ?

WebAuthn, ou l'API d'authentification Web, est une spécification rédigée par le W3C et l'alliance FIDO. Elle fonctionne sur toutes les principales plateformes et navigateurs, et permet aux utilisateurs de se connecter en déverrouillant leur ordinateur ou appareil mobile avec leur empreinte digitale, reconnaissance faciale ou un PIN local.

L'API permet aux serveurs d'enregistrer et d'authentifier les utilisateurs en utilisant la cryptographie à clé publique au lieu d'un mot de passe.

Une paire de clés privée-publique (connue sous le nom de credential) basée sur l'ECDSA est créée pour un site web. La clé privée est stockée de manière sécurisée sur l'appareil de l'utilisateur, la clé publique et un ID d'identification généré aléatoirement sont envoyés au serveur pour y être stockés. Le serveur peut alors utiliser cette clé publique pour prouver l'identité de l'utilisateur par une cérémonie centrée autour de la signature et de la vérification d'un défi.

Quel est le rapport avec la blockchain ? Où veux-tu en venir ?

Avec les Passkeys, les identifiants sont créés en suivant les meilleures règles de sécurité:

Stockés au niveau hardware : Les identifiants sont stockés dans le Module de Sécurité Hardware de l'appareil (dans des puces spécialisées telles que l'enclave sécurisée iOS ou le strongbox d’Android…)

Signature dans l'enclave : Toutes les signatures se produisent directement dans l'enclave, pas dans le client ou le navigateur.

Gardiens biométriques : Les verrous biométriques sont appliqués directement dans l'enclave de l'appareil. Les clés privées sont inaccessibles via des API externes ; elles sont exclusivement activées pour la signature numérique par les protocoles de l'écran de verrouillage du système.

Identifiants liés à un domaine : Les identifiants sont également limités à un domaine, atténuant le risque d'attaques par phishing, d'attaques homme du milieu ou par rejeu. Puisque l'authentificateur ne répond qu'aux demandes légitimes de l'origine qui a créé l'identifiant, et signe un challenge qui est unique pour chaque authentification.

Une autre caractéristique intéressante est que le challenge signé est un message de 32 octets qui peut contenir N'IMPORTE QUOI... Un message, un hash... Vous voyez où je veux en venir ?

Pourquoi ne pas l'utiliser dans la blockchain et signer un hash de transaction ?

Mais… C'est tout ? Comment est-ce possible ? Quelle est cette sorcellerie ?

Deux innovations clés nous permettent de réaliser cela :

Vérification de signature P256 onchain: Nous éliminons le composant serveur de la cérémonie de signature des Passkeys, le remplaçant par un contrat intelligent capable de vérifier la signature onchain. Opclave a introduit la première implémentation d'un tel vérificateur, suivie d'une version optimisée développée par l'équipe de Ledger.

Abstraction de compte (AA) : Les portefeuilles intelligents nous permettent d'utiliser une courbe différente de celle d'Ethereum (secp256k1 dans ce cas) pour la signature de messages et la vérification.

Un peu de contexte

Je m'appelle Yoan, je travaille comme développeur fullstack/blockchain chez Cometh, un pionnier dans le domaine des jeux web3 qui fournit des middleware et des outils pour des projets et applications blockchain. Je suis le lead développeur de Cometh Connect, un SDK d'abstraction de compte construit sur les Passkeys et le smart wallet Gnosis Safe.

Connect est en ligne pour plusieurs clients dans le monde entier, avec une activité quotidienne qui nous fournit des retours précieux de la part des utilisateurs.

Implémentation des passkeys par Cometh Connect

Au début de 2023, Cometh a travaillé avec Renaud Dubois et l'équipe cryptographique de Ledger sur l'une des premières implémentations de sa librairie FCL, permettant d'optimiser la vérification de la courbe elliptique secp256r1 onchain (mention spéciale à kelvyne). La première implémentation était une petite dapp démontrant la faisabilité de l'implémentation dans un cas d'usage réel.

https://x.com/Cometh/status/1641728767864320001?s=20

Ce qui a commencé comme un POC a évolué en un produit que nous proposons à d'autres projets et applications, menant à la naissance de Cometh Connect. L'idée était d'offrir un wallet intelligent avec un signataire qui serait capable de signer et de vérifier les messages en utilisant l’EIP1271 et les Passkeys à travers la librairie FCL. De cette manière, nous pourrions combiner la sécurité et la modularité d'un wallet intelligent avec la sécurité et une meilleure expérience utilisateur fournie par les passkeys (biométrie, TouchID…).

A la suite de ça, nous avons commencé à réfléchir aux fonctionnalités que notre produit devrait offrir :

P256 signer implémentation sur Safe: Nous avons développé le premier signer p256 pour un Safe, en optimisant pour minimiser les frais de déploiement et de signature, et adapté la signature passkey pour qu'elle corresponde au format de safe. Nous avons décidé de ne pas utiliser la version précalculée de la librairie FCL en raison de notre utilisation du “lazy deployment”, car prédire l'adresse du wallet s'avère plus difficile avec le précalcul. Cependant, nous restons ouverts à revoir cette décision en fonction de l'activité des wallets et des besoins des clients.

SDK pour les interactions côté Client : Nous avons développé une suite de SDK (ethers, viem et unity) conçue pour faciliter les interactions passkeys/wallet côté client. Cette suite prend en charge les implémentations de passkeys sur différents systèmes d'exploitation (iOS, Android, Windows, etc.) et les différents types d'authentification webauthn (plateform, cross-platform…).

Respect de la vie privée : Cometh Connect ne nécessite pas de données personnelles telles que l'email, numéros de téléphone, ou même les noms d'utilisateur, car il repose uniquement sur l'adresse publique du wallet et la passkey pour l'authentification.

Synchronisation des Passkeys : Comme dit précédemment, les passkeys vous permettent d'accéder de manière sécurisée aux identifiants à travers plusieurs appareils, à condition qu'ils soient synchronisés. Nous utilisons cette fonctionnalité pour permettre la récupération et la connexion d'un wallet sur différents appareils sans aucun backend (lorsqu’ils sont synchronisés).

Système de gardien : Selon le scénario, votre clé pourrait être stockée sur un appareil unique que vous pouvez perdre, perdant donc l’accès à votre wallet. Pour atténuer ce risque, nous avions besoin d’un système décentralisé de gardien entièrement onchain, nous utilisons le safe recovery hub.

Lazy deployment : Nous voulons être capables de prédire l'adresse du wallet intelligent et de le déployer uniquement lorsque nécessaire. Pour cela, nous générons un identifiant de clé publique webauthn lors de la génération de la première instance du wallet. Cette clé peut ensuite être passée à la factory de contrat safe et à la factory de signer p256, nous permettant de prédire les adresses des deux contrats avec l'opcode CREATE2

Compatibilité hors ligne : La signature via passkey peut fonctionner hors ligne tant que l'api webAuthn est prise en charge par le navigateur.

Combiner toutes ces fonctionnalités nous a donné une base assez solide pour un produit qui, selon nous, aidera de nombreux projets. Nous travaillons déjà sur d'autres fonctionnalités qui vont permettre d’améliorer l'expérience des utilisateurs.

Voici une démo si vous voulez tester le rendu final.

En construisant notre solution, nous avons rencontré certains défis techniques que je souhaitais partager dans cet article :

Optimisation cryptographique : Comme mentionné précédemment, Cometh a travaillé avec Renaud Dubois sur l'implémentation du vérificateur P256, et nous avons eu à faire face à des challenges cryptographiques assez complexes (voici une vidéo si vous souhaitez approfondir le sujet).

Identifiants liés à un domaine : Étant donné que les identifiants sont liées aux appareils et aux domaines (URL), nous avons dû développer des moyens sécurisés de gérer plusieurs appareils utilisant le même wallet lorsque les identifiants ne sont pas partagées entre appareils (non synchronisées à travers les passkeys).

Malléabilité des signatures :  Étant donné que la courbe Secp256r1 est basée sur l'ECDSA, elle est supposément vulnérable à la malléabilité des signatures. Dans notre cas, comme nous l'utilisons avec une implémentation de Gnosis Safe, nous sommes déjà protégés par le nonce, prévenant toute attaque par rejeu.

Implémentations des passkeys par navigateur/OS : L'intégration des passkeys varie considérablement en fonction du navigateur et du système d'exploitation utilisé. Par exemple, Windows ne supporte les passkeys basées sur P256 que depuis Windows 11 et Firefox ne supporte que les "roaming passkeys" (stockées dans un dispositif matériel, comme un yubikey), le support sur Mac et iOS est impeccable (merci Apple !), de même pour Android... Dans l'ensemble, il est clair que les géants de la tech s'orientent tous vers les passkeys comme authentification par défaut.

Un peu de contexte

Permettez-moi de me présenter, je suis Quentin, CTO de Frak-labs. Notre mission est de révolutionner la distribution et la consommation de contenu grâce à la blockchain.

Actuellement, nous avons plus de 17 000 utilisateurs pour notre MVP initial. Notamment, environ 20 % d'entre eux utilisent des EOA (externally owned account), tandis que le reste utilise des wallets intelligents, spécifiquement le Kernel Smart Wallet. Ce type de wallet adhère aux standards ERC-4337 et ERC-6900, offrant une modularité autour du signer et du wallet.

Implémentation des passkeys par Frak

Dans nos premiers travaux sur l'abstraction de compte à la fin de l’année 2023, nous avons formé des partenariats avec Pimlico pour la couche d'infrastructure (bundler et paymaster) et ZeroDev pour l'aspect wallet. Nous avons contribué de manière significative à ces deux projets, améliorant l'expérience des développeurs lors de l'interaction avec leurs SDK.

Nous avons notamment contribué au Kernel Smart Account, en introduisant un nouveau type de Validateur. Il s'agit d'un module autour d'un contrat intelligent qui valide les opérations et les signatures des utilisateurs.

Actuellement, nous travaillons sur un POC (restez à l'écoute pour les updates !) qui offre une solution alternative au paywall d'abonnement traditionnel, qui peut souvent être une source de friction pour les utilisateurs. Pour ce faire, nous introduisons un paywall pay-as-you-go qui utilise les passkeys et Kernel Smart Wallet.

En utilisant les fonctionnalités des passkeys, cette nouvelle approche présente de nouvelles opportunités pour les entreprises. Elles peuvent sponsoriser des transactions que les utilisateurs peuvent valider d'un simple geste, permettant ainsi un accès presque instantané aux articles.

Pour atteindre cet objectif, inspirés par le travail de Cometh, nous avons suggéré un nouveau validateur utilisant les passkeys à ZeroDev.

Malgré le fait que Cometh avait déjà une implémentation, nous avons dû repartir de zéro pour garantir la compatibilité avec le wallet Kernel. Nous avons construit un SDK client compact (qui n'est pas encore disponible, mais nous espérons l'intégrer bientôt dans le SDK kernel), et un nouveau validateur pour valider la signature des passkeys de manière économe en gaz (minimisant le nombre d'éléments nécessitant un déploiement, et exploitant de nouvelles stratégies pour réduire le gaz). Vous pouvez trouver ce travail ici : ZeroDev Kernel Pull Request.

Notre POC a fourni de nombreux apprentissages, qui font écho avec l’expérience de Yoan. Voici les principales conclusions :

Les passkeys deviennent plus accessibles : Malgré le fait que les passkeys ne soient pas encore largement adoptées et puissent sembler complexes à implémenter, elles sont en réalité bien documentées et il existe déjà une quantité significative de travail effectué pour faciliter leur intégration (merci Cometh !).

Optimisation cryptographique : Le travail de Renaud avec l'équipe de Ledger sur la version optimisée de la vérification de la courbe p256 est vraiment remarquable.

Compatibilité ERC4337 : Nous avons rencontré quelques obstacles avec l'un des prérequis de l'ERC-4337 pour sponsoriser la transaction. Le paymaster nécessite une signature factice pour calculer le coût de validation de la transaction, mais demander à nos utilisateurs d'effectuer deux signatures pour une transaction est loin d'être idéal. Créer cette signature factice pour chaque transaction, tout en trouvant le bon schéma de données, a posé un sérieux challenge.

Les passkeys sont l'avenir: Les passkeys, surtout lorsqu'elles sont utilisées avec la biométrie, représentent une bouffée d'air frais par rapport aux méthodes traditionnelles comme la vérification de mot de passe ou la 2FA. Cette expérience a vraiment souligné comment le web2 est à la traîne et m'a convaincu que la combinaison de cette norme avec la blockchain sera une des clés de l'adoption massive du web3.

Pour mieux comprendre les différentes approches et décisions prises par chaque entreprise, identifions d'abord les points communs. Cometh et Frak sont tous deux engagés en faveur de l'adoption généralisée du web3, et pas seulement pour les transactions financières. Cometh, fidèle à son esprit pionnier, propose l'un des premiers SDK d'abstraction de compte basé sur les passkeys pour l'onboarding des utilisateurs. Frak vise à révolutionner la manière dont les utilisateurs interagissent avec le contenu, tels que les articles de journaux, les vidéos en ligne, le streaming musical et plus encore.

Wallet intelligent pour la modularité

En raison de leur modèle, Frak avait besoin d'une solution innovante capable de gérer potentiellement des millions de micro-transactions par jour à grande vitesse. Cela nécessitait une stack technique hautement optimisée, surtout en termes de frais de gaz, étant donné qu’ils traitent des microtransactions où les frais de gaz pourraient dépasser le montant de la transaction elle-même. Ils ont choisi le wallet ZeroDev, qui se distingue de la nouvelle vague de comptes par sa modularité et son efficacité. Cependant, les nouveaux wallets comme Kernel subissent des mises à jour fréquentes, avec des changements majeurs occasionnels tous les trois à six mois.

Pour Cometh, choisir Safe leur fournit une suite de contrats et de modules entièrement auditées avec des options telles que les clés de session, le système de gardien ou même le récent support de l’ERC4337. Étant donné que leur wallet intelligent gère déjà 70 milliards d'actifs, c'était un choix évident pour les besoins de Cometh. L'application mobile Safe permet également à leurs utilisateurs d'utiliser directement le wallet Safe créé via Cometh, d'ajouter un signer “classique” (metamask, rabby…), et de l'utiliser dans tout écosystème web3. Cependant, cela nécessite pour l'instant le déploiement d’un signer (p256) pour chaque utilisateur.

Si vous souhaitez aller plus en détail sur les différences de gaz, voici un benchmark sur lequel nous travaillons en utilisant Foundry.

Passkeys pour l'UX

De notre point de vue, bien que les Passkeys soient un mécanisme de "lancement" idéal pour embarquer un nouvel utilisateur, cela ne doit pas forcément être la seule solution de signer au sein d'un wallet intelligent. Dans certains cas, nous avons envisagé un portefeuille intelligent qui peut être initié par une Passkey, mais qui peut ajouter d'autres signers par la suite et même se retirer si nécessaire. Cela éliminerait toute friction pour l'onboarding des utilisateurs, leur permettant d'apprendre et d'expérimenter la crypto au lieu de les jeter directement dans la jungle web3.

ERC4337 pour la décentralisation

L'ERC4337, nouveau standard pour l'abstraction de compte, était encore en phase de draft et subissait des mises à jour fréquentes au début de 2023, incitant Cometh à attendre qu'il se stabilise et gagne une adoption plus large.

Avec leur migration de wallet à la fin de 2023, Frak a décidé de l’adopter immédiatement. Cette décision leur a permis de tirer parti de différents bundlers et paymasters en fonction de la vitesse de transaction, offrant une versatilité significative et assurant une performance optimale.

À mesure que l'ERC4337 mûrit et voit son adoption augmenter, Cometh se prépare à lancer une version de leur SDK compatible 4337.

SDK intégration

Cometh a choisi de développer son propre SDK pour simplifier la gestion des passkeys et toutes les fonctionnalités liées à l'abstraction de compte pour leurs clients. Ils ont produit des versions TypeScript, y compris des adaptateurs pour ethers et viem/wagmi, ainsi qu'une version Unity adaptée aux jeux vidéo. À travers Connect, Cometh fournit une suite complète de SDK qui permet aux startups et aux entreprises de passer en toute transparence du web2 au web3, en assurant une expérience utilisateur fluide et sécurisée.

Frak, en revanche, propose un wallet personnalisé avec un SDK pour que les entreprises de contenu puissent l'intégrer et l'ajouter à leurs paywalls existants. Ils ont choisi de le développer avec Pimlico permisionless.js, qui était l'un des premiers SDK ERC-4337 à fonctionner avec Viem et Wagmi. Étant donné qu'un nombre significatif de leurs utilisateurs sont des utilisateurs mobiles, certains avec des appareils plus anciens, il était crucial de sélectionner un SDK léger et rapide.

Performance

Du point de vue des utilisateurs finaux, les différences entre les deux solutions peuvent ne pas être immédiatement perceptibles, à part un léger avantage de vitesse que Frak pourrait posséder, tandis que Cometh permet plus de flexibilité et d'interopérabilité avec tous les modules disponibles.

L'impact sur l'utilisateur est relativement mineur, les principaux changements affectant l'expérience des développeurs, le potentiel d'améliorations futures, et la fiabilité et la sécurité globale du système.

Avec l'émergence de ces nouvelles solutions, nous assistons à l'avènement d'un futur où atteindre les standards UX du grand public sans compromettre les principes fondamentaux de la blockchain devient une réalité. La combinaison des Passkeys et de l'abstraction de compte permet aux projets d'offrir à leurs utilisateurs le meilleur des deux mondes. Notre prédiction est que nous verrons de nombreuses applications où les wallets deviendront invisibles, permettant à l'expérience utilisateur de prendre le devant de la scène tandis que la technologie blockchain fonctionnera de manière transparente en arrière-plan.

Cependant, des défis demeurent. Voici quelques développements potentiels que nous envisageons qui pourraient encourager l'adoption de ces technologies :

Vérification native de la courbe P256 : Une implémentation native EVM de la courbe P256 pourrait considérablement réduire les frais de gaz pour la vérification de signature, actuellement de l'ordre de 180 à 300k de gaz, à environ 3,45k de gaz avec l'EIP-7212. L'équipe d'Opclave pousse dans cette direction avec l'EIP-7212, et un RIP est en cours d'adoption à l'heure actuelle.

Adoption complète des Passkeys par les clients/hardware : Les Passkeys sont déjà largement adoptées, mais certains navigateurs accusent du retard, et certains systèmes d'exploitation ne commencent leur transition que maintenant (Windows Hello n'a ajouté les algorithmes ECC que depuis Windows 11).

“Clear-signing” pour la signature Passkey : Un autre problème est que, avec les implémentations actuelles, le mode par défaut est la signature aveugle (“blind signing”). Cela ne pose pas de problème pour la plupart des applications, mais cela peut être nécessaire pour des cas d'usage où une signature claire est requise (la Defi par exemple).

Web wallet centré autour des Passkeys : Une autre idée intéressante serait d'avoir un web wallet capable de gérer les signatures passkey. De cette manière, vous pourriez contourner les restrictions de domaine et obtenir une compatibilité à travers plusieurs URLs. Cependant, cette approche introduit des préoccupations en matière de sécurité, car la dépendance à un URL spécifique pourrait devenir un point de défaillance centralisé. Cometh explore activement des solutions pour adresser ce problème.

Abstraction de compte native : Si nous élargissons le spectre des chaînes EVM, quelques ZK rollups (Starknet et zkSync par exemple) intègrent l'abstraction de compte nativement dans leur architecture. Couplée à de potentielles implémentations de passkeys, cela pourrait mener à des innovations et un coût relativement bas pour la vérification de signature. Certains projets travaillent déjà sur cela, comme Cartridge.

Support des Dapps pour les signatures de portefeuille intelligent : Beaucoup de Dapps ne supportent pas les signatures EIP1271 actuellement. Des applications majeures comme Opensea ou Uniswap font avancer les choses, mais il reste encore beaucoup de travail à faire. Cometh a notamment construit une librairie pour faciliter la vérification des signatures pour d'autres projets.

Merci d’avoir pris le temps de nous lire !