SevenX Ventures : Comment WebAuthn et les clés d'accès peuvent-elles sauver l'expérience crypto médiocre ?
TechFlow SélectionTechFlow Sélection
SevenX Ventures : Comment WebAuthn et les clés d'accès peuvent-elles sauver l'expérience crypto médiocre ?
Pour garantir la sécurité des transactions, il est nécessaire d'authentifier l'identité des utilisateurs autorisés.
Dédié à des analyses Web3 approfondiesAuteur : Rui @Ruisnakes, SevenX Ventures
TL;DR
La clé privée est essentielle pour signer des transactions sur Ethereum. Pourtant, même sous forme lisible comme la phrase de récupération (aussi appelée « seed phrase »), la gestion des clés privées par les utilisateurs reste un cauchemar. Or, nous savons tous que transformer la blockchain en jeu complexe n’a jamais été notre objectif.
Pour garantir la sécurité des transactions, il est nécessaire d’authentifier l’utilisateur autorisé. Au fil de l’évolution de la sécurité Internet et de l’expérience utilisateur, nous sommes passés de la vérification par mot de passe à des technologies biométriques telles que la reconnaissance faciale ou l’empreinte digitale. Dans ce progrès, WebAuthn constitue une étape clé. Cet article met l’accent sur trois termes :
-
WebAuthn : une norme d’authentification web qui utilise des identifiants basés sur la cryptographie asymétrique, généralement créés par un authentificateur externe. Elle permet une authentification sécurisée sans mot de passe.
-
Secure Enclave : zone matérielle sécurisée intégrée dans les dispositifs informatiques, conçue pour protéger les données sensibles. Des versions de Secure Enclave existent sur les appareils iOS, Android et Windows. Appliqué à WebAuthn, il peut servir d’authentificateur externe offrant une sécurité au niveau matériel. Toutefois, comme la clé privée est liée au périphérique local, cela rend difficile l’opération multi-appareils.
-
Passkey : application système de WebAuthn, avec des règles personnalisées selon le fournisseur d’appareil ou de système. Par exemple, les Passkeys d’Apple utilisent la clé stockée dans iCloud Keychain pour synchroniser entre appareils. Cette méthode fonctionne toutefois principalement au sein d’un écosystème fermé et ne permet pas l’interopérabilité entre systèmes (Apple-Android).
Comme indiqué ci-dessus, le déploiement de WebAuthn s’aligne sur nos objectifs pour les utilisateurs quotidiens de blockchain : sécurité avancée contre le phishing et expérience fluide. Voici une proposition d’intégration de WebAuthn dans la blockchain :
-
Couche clé : les utilisateurs peuvent s’authentifier via des méthodes intuitives comme la reconnaissance faciale ou l’empreinte digitale. En arrière-plan, cela repose sur un processeur matériel sécurisé (comme Secure Enclave) ou un service cloud (comme iCloud ou Google Cloud) pour la gestion des clés. J’aborderai plus en détail les questions multi-appareils et multi-plateformes plus tard.
-
Couche compte : les comptes à contrat intelligent (SCA) peuvent attribuer n’importe quel signataire (ex. SE et Passkey) et mécanismes de seuil. Leur conception modulaire améliore la flexibilité et la mise à jour. Par exemple, un SCA peut ajuster dynamiquement ses exigences de signature selon le volume de transactions, le temps ou l’adresse IP. En revanche, les comptes externes traditionnels (EOA) peuvent être étendus via un service MPC. Cette combinaison offre une meilleure interopérabilité et efficacité coûts, mais manque des fonctionnalités avancées du SCA, notamment la rotation des clés, qui reste plus complexe.
-
Couche signature : Ethereum prend nativement en charge la courbe k1, mais la validation des signatures WebAuthn implique un coût plus élevé car elle utilise la courbe r1. Ainsi, des solutions Layer 2 comme zkSync prévoient d’intégrer nativement la courbe r1 via un précompilé EIP-7212. D’autres alternatives existent : services tiers, validateurs Solidity, validateurs ZK et systèmes distribués de gestion des clés, tous capables de valider les signatures r1 de manière plus économique.
* Avertissement :
Le progrès technologique ne garantit pas le succès commercial ; tous les appareils et plateformes n’adoptent pas encore les Passkeys ; l’utilisation de comptes à contrat intelligent peut être plus coûteuse que celle des comptes externes ; les solutions proposées évolueront continuellement avec les avancées technologiques.
L’expérience utilisateur en cryptographie est mauvaise ? La gestion des clés est désastreuse !
Dans l’univers blockchain, le véritable contrôle des actifs numériques n’appartient ni à l’utilisateur ni au fournisseur de portefeuille, mais à la clé privée. Cette clé détermine le succès ou l’échec d’une transaction sur Ethereum. Pour mieux comprendre, prenons l’exemple d’un compte externe :
-
Génération de clé : un nombre aléatoire choisi sur la courbe elliptique secp256k1 devient la clé privée. Multiplié par un point prédéfini sur cette courbe, il génère la clé publique. L’adresse Ethereum est dérivée des 20 derniers octets du hachage de la clé publique. Généralement, on utilise une phrase mnémonique pour convertir la clé privée en mots lisibles servant de sauvegarde, permettant ainsi de régénérer la paire clé publique/privée.
-
Signature de transaction : la clé privée signe une transaction contenant des détails comme le nonce, le montant, le prix du gaz et l’adresse du destinataire. Ce processus utilise l’algorithme ECDSA (Elliptic Curve Digital Signature Algorithm) basé sur la courbe secp256k1, produisant une signature composée de valeurs (r, s, v), puis diffusée avec la transaction originale sur le réseau.
-
Vérification de transaction : une fois reçue par un nœud Ethereum, la transaction est validée dans son pool mémoire. Pour confirmer l’identité du signataire, le nœud utilise la signature et le hachage de la transaction pour retrouver la clé publique de l’expéditeur, puis valide en comparant l’adresse extraite à celle de l’expéditeur.
Comme expliqué, la clé privée est une entité fondamentale sur la chaîne. Initialement, les comptes Ethereum — les comptes externes — dépendaient entièrement d’une seule clé privée, ce qui posait un risque majeur : perdre la clé équivalait à perdre tout accès au compte.
Beaucoup pensent que l’abstraction de compte (AA) est la solution ultime aux problèmes d’expérience utilisateur. Je dirais que non. L’abstraction de compte rend programmable la règle de validité (validity rule) sur Ethereum, rendue possible par les comptes à contrat intelligent. Puissante, AA permet d’envoyer plusieurs transactions en parallèle (abstraction du nonce), de sponsoriser le gaz, de payer le gaz avec des tokens ERC-20 (abstraction du gaz), et surtout — pertinent ici — brise la validation fixe de signature (abstraction ECDSA). Contrairement aux comptes externes, les comptes à contrat peuvent attribuer n’importe quel signataire ou mécanisme, comme des multisigs ou des clés limitées (clés de session). Toutefois, malgré leur flexibilité accrue, ces comptes nécessitent toujours une clé pour signer les transactions.
Même convertie en 12 mots mnémoniques, la gestion des clés privées reste difficile, exposée à la perte ou aux attaques de phishing. Les utilisateurs doivent choisir entre des solutions décentralisées complexes ou des services centralisés — aucun n’étant idéal.
Pourquoi l’expérience crypto est-elle si mauvaise ? En grande partie à cause de la mauvaise gestion des clés. L’utilisateur doit constamment faire des compromis entre expérience, sécurité et décentralisation. Cet article explore les meilleures solutions potentielles pour gérer les clés.
Couche de gestion des clés
Il n’existe aucune solution universelle. La meilleure façon de gérer les clés dépend du cas d’usage spécifique et de nombreux facteurs : type d’utilisateur (institutionnel ou individuel), montant en capital, fréquence des transactions, types d’interactions, etc.
Précisons d’emblée que je n’utiliserai pas les termes populaires tels que « auto-hébergé, semi-hébergé, entièrement hébergé ». À mes yeux, l’auto-hébergement véritable signifie signer indépendamment sans dépendre d’autrui, même si certaines solutions (ex. stockage dans un environnement d’exécution fiable décentralisé) ne sont pas considérées comme « hébergées » au sens traditionnel. Juger une solution uniquement par son type d’hébergement est trop simpliste et ignore sa pertinence contextuelle. Pour évaluer finement les méthodes de gestion des clés, j’analyserai selon trois dimensions distinctes.
Responsabilité
Répartition de la responsabilité de gestion des clés entre différentes parties.
Les utilisateurs particuliers rencontrent souvent des difficultés dans la gestion des clés, donc répartir cette responsabilité devient naturellement une stratégie d’atténuation des risques. Ces méthodes incluent la signature collaborative via plusieurs clés (ex. multisig), ou le fractionnement de la clé privée via un schéma de partage secret (SSS) ou le calcul multipartite (MPC).
-
Multisignature (Multi-sig) : nécessite plusieurs clés privées complètes pour générer une signature. Cette méthode exige une communication en chaîne entre signataires, augmente les frais de transaction et nuit à la confidentialité, car le nombre de signataires est visible sur la chaîne.
-
Schéma de Partage Secret (SSS) : la clé privée est générée à un seul endroit, puis divisée en plusieurs fragments distribués à différentes parties. Toutes doivent reconstruire la clé complète pour signer. Mais cette reconstruction temporaire peut introduire des vulnérabilités.
-
MPC-TSS (Threshold Signature Scheme) : une implémentation du MPC où plusieurs parties effectuent un calcul tout en gardant leurs entrées privées. Chaque partie crée indépendamment un fragment de clé, permettant de signer sans rencontrer physiquement les autres. Étant hors chaîne, cette méthode coûte moins cher et évite le point de défaillance unique du SSS.
Stockage
Stockage de la clé ou de ses fragments, influencé par la sécurité, l’accessibilité, le coût et la décentralisation.
-
Services cloud centralisés, comme AWS, iCloud, etc. Facile pour les transactions fréquentes, mais plus sensible à la censure.
-
Stockage décentralisé, comme IPFS ou Filecoin.
-
Ordinateur / mobile local : clé stockée dans le stockage sécurisé du navigateur.
-
Portefeuille papier : impression de la clé privée ou d’un code QR.
-
Environnement d’Exécution Fiable (TEE) : zone sécurisée isolée du système principal, où s’exécutent ou stockent des données sensibles.
-
Secure Enclave : sur les appareils modernes, Secure Enclave est isolé du processeur principal, offrant une couche supplémentaire de sécurité, protégeant même si le noyau du processeur est compromis.
-
Portefeuilles matériels : dispositifs physiques comme Ledger ou Trezor, dédiés au stockage sécurisé des clés privées.
-
Modules de Sécurité Matériels (HSM) : équipements matériels spécialisés pour la gestion sécurisée des clés et opérations cryptographiques, utilisés en entreprise, offrant un haut niveau de sécurité.
Accès
Comment vérifier l’identité de l’utilisateur pour accéder à la clé stockée.
L’accès à la clé stockée nécessite une authentification. Il faut vérifier que la personne tentant d’accéder est bien autorisée. Historiquement, les méthodes d’accès se classent ainsi :
-
Ce que vous savez : mot de passe, code PIN, réponse à une question de sécurité ou un motif spécifique.
-
Ce que vous possédez : carte intelligente, jeton matériel (OTP basé sur le temps), ou éléments numériques comme la vérification de compte social ou un code SMS.
-
Qui vous êtes : caractéristiques biologiques uniques comme l’empreinte digitale, la reconnaissance faciale (Face ID d’Apple ou Windows Hello), vocale ou scan de l’iris/rétine.
Sur cette base, l’authentification à deux facteurs (2FA) ou multifacteur (MFA) combine au moins deux éléments, par exemple SMS et notification push, renforçant la sécurité du compte.
Analyse des produits existants
MetaMask permet aux utilisateurs d’accéder à la clé stockée localement dans le navigateur via un mot de passe.
Trust Wallet permet d’accéder à la clé locale via mot de passe ou FaceID, et offre aussi un backup cloud de la clé privée.
Privy permet divers modes de connexion sociale (email, etc.), utilisant un schéma de partage secret pour diviser la clé en trois fragments :
-
Fragment appareil : navigateur - iFrame, mobile - Secure Enclave.
-
Fragment Auth : stocké par Privy, lié à l’identifiant Privy.
-
Fragment Recovery : mot de passe utilisateur ou stocké chiffré par Privy dans un HSM.
Particle permet la connexion sociale via MPC-TSS, divisant la clé en deux parties :
-
Fragment appareil : navigateur - iFrame
-
Fragment serveur : côté Particle
Nouvelles solutions
Couche clé : WebAuthn, Secure Enclave et Passkey
Les solutions existantes ont joué un rôle clé pour attirer les utilisateurs vers le Web3. Mais de nouveaux défis apparaissent : les mots de passe peuvent être oubliés ou victimes de phishing, la 2FA est plus sûre mais fastidieuse. De plus, tous ne veulent pas déléguer la gestion des clés à un tiers, restant dépendants de la disponibilité et fiabilité du système quand l’accès direct est bloqué.
Cela nous pousse à chercher une solution plus efficace — presque sans confiance, très sécurisée et offrant une expérience transparente. Cette quête nous conduit vers les meilleures pratiques du Web2. Comme mentionné en introduction, plusieurs termes sont liés à ce sujet : WebAuthn est la norme d’authentification, tandis que Secure Enclave et Passkey en sont des implémentations ou composants.
WebAuthn
WebAuthn normalise l’interface d’authentification des applications web. L’utilisateur peut se connecter sans mot de passe en utilisant un authentificateur externe. Celui-ci peut être un authentificateur portable (Yubikey, Titan Key) ou intégré (trousseau natif sur appareils Apple).
La technologie derrière WebAuthn a été initialement développée par l’alliance FIDO (Fast IDentity Online). En mars 2019, W3C a officialisé WebAuthn comme standard web. Avec cette standardisation, les principaux navigateurs (Google Chrome, Mozilla Firefox, Microsoft Edge, Apple Safari) l’ont adopté, étendant largement son usage. Il est désormais pris en charge par de nombreux appareils avancés.
Avantages de WebAuthn :
-
Meilleure sécurité : suppression de la dépendance aux mots de passe, réduction des risques de phishing, de force brute et d’attaques par rejeu.
-
Expérience utilisateur améliorée : connexion plus simple et rapide, souvent par un clic ou une vérification biométrique.
-
Confidentialité : aucun secret partagé n’est transmis pendant l’authentification, et aucun site ne reçoit d’informations personnelles identifiables.
-
Extensibilité et standardisation : en tant que norme web, WebAuthn assure cohérence et interopérabilité entre navigateurs et plateformes.
WebAuthn basé sur appareil, ex. Secure Enclave
Nous pouvons désormais utiliser un processeur matériel comme authentificateur, comme Secure Enclave sur Apple, Trustzone sur Android ou Strongbox sur Google Pixel.
-
Génération de clé : chiffrement asymétrique selon la norme WebAuthn, généralement sur la courbe P-256 r1. La clé publique est envoyée au serveur, la clé privée ne quitte jamais le Secure Enclave. L’utilisateur n’interagit jamais avec la clé en clair, assurant sa sécurité.
-
Stockage : la clé privée est stockée en toute sécurité dans le Secure Enclave, un sous-système durci isolé du processeur principal. Même si le système principal est compromis, la clé reste inaccessible. Le seuil de compromission est extrêmement élevé, c’est pourquoi les données les plus sensibles (Apple Pay, FaceID) y sont stockées.
-
Authentification : l’utilisateur utilise la reconnaissance faciale ou l’empreinte digitale pour accéder, le Secure Enclave signe le défi du serveur avec la clé privée, et le serveur valide avec la clé publique.
Avantages du WebAuthn basé sur appareil :
-
Sécurité équivalente au matériel : Secure Enclave, gestionnaire matériel indépendant, renforce la sécurité.
-
Résistance au phishing : aucune saisie d’information sur un appareil ou site potentiellement compromis.
-
Expérience pratique : plus conviviale. L’utilisateur n’a plus à retenir des mots de passe complexes différents.
Inconvénients du WebAuthn basé sur appareil :
-
Limitation aux appareils : si l’appareil est perdu ou endommagé, la clé privée ne peut être exportée ni récupérée, empêchant l’usage multi-appareils.
WebAuthn basé sur le cloud, Passkey
Pour résoudre le problème du multi-appareils, les géants technologiques ont lancé des déploiements WebAuthn basés sur le cloud, dont Passkey popularisé par Apple.
Prenons l’exemple de Passkey d’Apple :
-
Génération de clé : l’appareil macOS, iOS ou iPadOS agit comme authentificateur, générant paire publique/privée lors de la création du compte. La clé publique est envoyée au serveur, la clé privée stockée dans le trousseau iCloud. Les données sont chiffrées avec une clé liée au matériel, stockée dans un HSM. Apple ne peut pas accéder à cette clé.
-
Synchronisation multi-appareils : similaire à l’accès iCloud. Authentification via code SMS, puis saisie du mot de passe sur un des appareils.
Avantages du WebAuthn basé sur cloud :
-
Multi-appareils : Passkey facilite l’accès sur tous les appareils habituels. Actuellement limité aux appareils Apple. Plus difficile sur Android, vu la fragmentation des versions et du matériel.
-
Résistance au phishing : comme ci-dessus.
-
Expérience pratique : comme ci-dessus.
Inconvénients du Passkey basé sur cloud :
-
Dépendance au cloud : comparé au WebAuthn basé sur appareil, le Passkey basé sur cloud déplace la sécurité du Secure Enclave matériel vers le trousseau iCloud, que certains considèrent comme « hébergé ». Points critiques : compromission du compte AppleID iCloud ; bien que le trousseau soit chiffré de bout en bout, des erreurs ou failles restent possibles.
-
Limitation de plateforme : par exemple, utiliser un Passkey iCloud sur Android est très difficile. De plus, contrairement aux méthodes traditionnelles, Apple et Google n’envoient pas d’assertions spécifiques à l’appareil. On ne peut donc pas vérifier le type d’appareil ayant généré la clé, soulevant des doutes sur la fiabilité des métadonnées.
Couche compte : comptes à contrat et comptes externes
Jusqu’ici, nous voyons que maintenir la sécurité matérielle tout en assurant compatibilité multi-appareils et multi-plateformes est un défi. Aussi importante est l’option de récupération sociale, comme ajouter plusieurs gardiens (guardians) pour renforcer la sécurité. Ici, la blockchain peut nous guider.
Attention : en tentant de déployer WebAuthn du Web2 vers le Web3, une différence notable apparaît. Le Web2 exige seulement de prouver la propriété, alors que le Web3 requiert aussi d’autoriser des transactions. Avec un simple Passkey, les développeurs ne contrôlent pas le message signé, souvent générique (ex. « sign in »), ce qui peut entraîner des manipulations frontales — l’utilisateur signe « à l’aveugle ». Ce problème semble mineur, mais est crucial.
Un compte à contrat est lui-même un contrat intelligent. En tant qu’entité en chaîne, il peut désigner n’importe quel signataire. Cette flexibilité permet à l’utilisateur de configurer différents appareils et plateformes (ex. smartphone Android, Macbook, iPhone). De plus, les comptes modulaires sont mis à jour, permettant d’échanger des signataires ou de modifier le seuil (ex. 2/3 vers configuration plus complexe).
Imaginez un portefeuille ajustant automatiquement sa sécurité : sur une adresse IP familière, il accepte une signature unique, mais exige plusieurs signataires pour une IP inconnue ou une transaction importante. Grâce à la modularité et programmabilité, seuls nos rêves limitent l’innovation. De nombreux fournisseurs développent cette techn
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@SevenXVentures
