Le Web3 est en expansion rapide : de nouvelles applications, protocoles et fonctionnalités émergent chaque jour. Cependant, pour de nombreux utilisateurs, la véritable barrière à l'entrée n'est pas un manque de fonctionnalités sur la chaîne, mais plutôt le défi de sauvegarder et de récupérer en toute sécurité les clés du portefeuille.
Actuellement, la norme de l'industrie reste la phrase de récupération (mnémonique). Pourtant, cette approche présente des défis concrets : les utilisateurs font souvent des captures d'écran de leurs phrases, les synchronisant ainsi involontairement vers des albums cloud ; d'autres les écrivent sur papier pour ensuite les perdre ou les endommager, entraînant la perte permanente des actifs. De telles histoires sont monnaie courante. Souvent, ces risques ne proviennent pas de défaillances techniques, mais de lacunes dans les habitudes quotidiennes.
Ces dernières années, un nombre croissant de solutions de portefeuille de type "Web2" sont apparues, permettant aux utilisateurs de créer, sauvegarder et récupérer des portefeuilles en utilisant des méthodes de connexion familières. Bien que leur objectif soit d'abaisser la barrière à l'entrée, il existe des différences significatives dans la manière dont elles sont mises en œuvre — plus précisément, si elles restent véritablement décentralisées et auto-gardées.
Le risque de fragmentation centralisée : Certaines solutions divisent la clé privée en plusieurs "parts" ou "fragments". La division elle-même n'est pas le problème. Le risque critique survient si une entité participante unique (comme le backend du fournisseur de services) détient suffisamment de parts pour atteindre le seuil de récupération. Si c'est le cas, elle possède techniquement la capacité de reconstruire la clé complète, rendant l'"auto-garde" simplement une promesse nominale.
Le risque de dépendances HSM : D'autres solutions stockent les clés privées dans des modules de sécurité matérielle (HSM), prétendant qu'ils ne signeront des transactions que selon des règles strictes. Bien que cela semble solide, si l'application des règles ou l'exécution des politiques se produit en dehors de la frontière de confiance (c'est-à-dire à l'extérieur du HSM), cela peut — dans des scénarios extrêmes — être contourné ou manipulé, entraînant des signatures qui ne reflètent pas l'intention de l'utilisateur.
En quoi le portefeuille sans clé de OneKey est différent
Le portefeuille sans clé de OneKey utilise une approche "Connexion Google/Apple + Code PIN", intégrant la facilité d'utilisation avec une véritable auto-garde dans une seule conception.
Vous effectuez la connexion et la récupération en utilisant des systèmes de compte familiers, mais l'architecture sous-jacente emploie un mécanisme distribué de gestion et de signature de clés. Cela garantit qu'aucune partie unique — y compris OneKey — ne peut reconstruire votre clé complète ou initier unilatéralement des transferts.
En d'autres termes : même si nos serveurs, un composant spécifique ou une entité participante unique étaient compromis, un attaquant ne pourrait pas simplement forcer OneKey pour "voler votre portefeuille."
La solution de OneKey
Le portefeuille sans clé de OneKey est construit sur un mécanisme de gestion de clés distribué. Son objectif est de vous libérer du fardeau à haut risque de noter, stocker et transporter des phrases de récupération. Au lieu de cela, vous pouvez créer et récupérer votre portefeuille en utilisant une méthode que vous connaissez déjà : Connexion Google / Apple + Code PIN.
Charge réduite, auto-garde sans compromis
Les portefeuilles traditionnels reposent sur des phrases de récupération (généralement 12 ou 24 mots), obligeant les utilisateurs à les stocker en toute sécurité et à les restaurer manuellement en cas de besoin. Le portefeuille sans clé vous permet de gérer vos actifs simplement en vous souvenant d'un code PIN. La capacité de récupérer votre portefeuille est basée sur une architecture distribuée, garantissant que le contrôle total n'est jamais transféré à un seul fournisseur de services.
Authentification double : Compte + Code PIN
Le portefeuille sans clé utilise deux facteurs d'authentification :
Votre compte Google / Apple
Votre code PIN
Cela signifie que même si votre compte Google ou Apple est compromis, les opérations critiques ne peuvent pas être effectuées sans le code PIN. Inversement, avoir le code PIN seul est insuffisant pour récupérer ou accéder au portefeuille sans se connecter au compte associé. Les deux facteurs sont indispensables, réduisant considérablement le risque d'un point de défaillance unique.
La phrase de récupération n'apparaît qu'après vérification
Dans la conception du portefeuille sans clé, la phrase de récupération complète ou la clé privée n'est jamais stockée en texte brut dans un emplacement unique pendant de longues périodes. Ce n'est que lorsque vous vérifiez avec succès à la fois votre compte et votre code PIN sur votre appareil que le portefeuille effectue les processus de récupération et d'activation nécessaires localement.
Comment fonctionnent la sauvegarde et la récupération :
Stockage chiffré : Les données relatives à la phrase de récupération sont stockées sur le serveur sous forme chiffrée pour garantir la disponibilité (par exemple, pour la récupération multi-appareils).
Mécanisme de fragmentation : Les matériaux critiques nécessaires au déchiffrement sont divisés et distribués entre plusieurs parties ou nœuds.
Par conséquent, à moins que vous n'effectuiez la vérification et ne déclenchiez la récupération sur votre appareil, aucune partie unique (y compris OneKey) ne peut la reconstruire unilatéralement en une clé utilisable en texte clair.
Plongée technique
Cette section explique ce qui se passe côté client (votre appareil) et côté serveur lorsque vous créez un nouveau portefeuille sans clé à l'aide de Google ou d'Apple. Elle clarifie également pourquoi les processus de "Sauvegarde" et de "Récupération" sont conviviaux tout en garantissant qu'aucune partie unique ne peut jamais accéder à votre clé privée complète.
Sauvegarder un portefeuille sans clé
Lors de la création d'un portefeuille sans clé pendant le processus d'intégration, vous pouvez :
Sélectionner "Continuer avec Google" sur l'écran d'accueil.
Ou appuyer sur le bouton "•••" → Portefeuille sans clé → Sélectionner Google ou Apple.
Note importante : Le portefeuille sans clé et les portefeuilles traditionnels à phrase de récupération sont deux systèmes distincts et indépendants. Actuellement, la migration d'un "portefeuille à phrase de récupération existant" vers un portefeuille sans clé n'est pas prise en charge ; ils coexistent en parallèle.
Examinons le processus technique qui se produit lorsqu'un utilisateur crée un portefeuille à l'aide de son compte Google ou Apple.
Étape 1 — Génération, chiffrement et stockage du texte chiffré de la phrase de récupération sur l'appareil
Génération locale : L'appareil génère localement une nouvelle phrase de récupération (servant de source aléatoire pour le matériel clé du portefeuille).
Création de la clé symétrique : L'appareil génère simultanément une clé symétrique.
Chiffrement : L'appareil utilise cette clé symétrique pour chiffrer la phrase de récupération, produisant le texte chiffré de la phrase de récupération.
Stockage sécurisé : Seul le texte chiffré de la phrase de récupération est transmis au backend OneKey pour un stockage sécurisé (assurant la disponibilité pour la récupération multi-appareils).
Points clés :
Traitement uniquement local : La phrase de récupération en clair et la clé symétrique sont générées et traitées exclusivement sur l'appareil. Elles ne sont jamais transmises directement hors de l'appareil.
Texte chiffré inutilisable : Le texte chiffré lui-même ne peut pas être utilisé pour la signature. Sans la clé symétrique, il est impossible de déchiffrer le texte chiffré pour retrouver une phrase de récupération ou un matériel clé utilisable.
Étape 2 — Diviser la clé symétrique en deux parts "2 sur 2"
De retour sur l'appareil, la clé symétrique est divisée en deux parts en utilisant le Partage de secret de Shamir (SSS) avec un seuil de 2 sur 2 :
Part de backend : Maintenue par le backend OneKey.
Part Juicebox : Stockée au sein du protocole de stockage décentralisé, Juicebox.
Points clés :
Sous un seuil de 2 sur 2, aucune part unique n'est suffisante pour reconstruire la clé symétrique. Même si OneKey possède à la fois le "Texte chiffré de la phrase de récupération" et la "Part de backend", il ne peut pas unilatéralement récupérer le portefeuille ou initier une signature de transaction.
Étape 3 — Écrire la part réseau sur le réseau distribué, protégée par le code PIN
La part Juicebox est écrite sur le réseau Juicebox.
L'utilisateur définit un code PIN, qui sert à protéger l'accès pour récupérer cette part depuis Juicebox.
Implémentation technique : La part est ensuite divisée en plusieurs sous-parts et distribuée sur différents nœuds pour le stockage. Pour récupérer la part, le code PIN correct doit être entré pour passer la vérification du seuil du réseau.
Récupération d'un portefeuille sans clé
Étape 1 — Authentification et récupération du texte chiffré de la phrase de récupération + Part de backend
L'appareil effectue l'authentification à l'aide de votre compte Google / Apple.
Après vérification réussie, l'appareil récupère deux éléments de données auprès du backend OneKey :
Texte chiffré de la phrase de récupération
Part de backend
Étape 2 — Saisie du code PIN pour récupérer la part Juicebox
Vous saisissez votre code PIN sur l'appareil.
L'appareil utilise le code PIN pour récupérer la part Juicebox auprès du protocole de stockage décentralisé Juicebox.
Étape 3 — Reconstruction de la clé symétrique et déchiffrement
L'appareil combine la part de backend + la part Juicebox pour reconstruire la clé symétrique originale.
Il utilise cette clé symétrique pour déchiffrer le texte chiffré de la phrase de récupération, restaurant la phrase de récupération originale localement sur l'appareil.
Une fois la récupération terminée, le portefeuille fonctionne normalement dans l'application OneKey, comme un portefeuille standard.
Analyse complète
État final (Distribution des données)
Utilisateur : A accès à son compte Google / Apple et se souvient du code PIN.
Client OneKey (Appareil) : Possède la phrase de récupération déchiffrée utilisable (temporairement pour l'usage).
Serveur OneKey : Stocke le texte chiffré et la part de backend.
Royaumes Juicebox : Stockent individuellement les sous-parts Juicebox (nécessaires pour reconstruire la part Juicebox).
Propriétés de sécurité
Compromission de la base de données du serveur OneKey : Même si un attaquant accède à la fois au texte chiffré et à la part de backend, il ne peut pas reconstruire unilatéralement la clé symétrique. Il est donc impossible pour lui de déchiffrer la phrase de récupération.
Compromission des royaumes/nœuds Juicebox : Tant qu'un attaquant n'obtient pas un nombre suffisant de sous-parts Juicebox (ne respectant pas le seuil de récupération), il ne peut pas restaurer la part Juicebox, et par conséquent, ne peut pas aider à la reconstruction de la clé symétrique.
Compromission du compte : L'accès au compte Google ou Apple seul est insuffisant pour récupérer les sous-parts Juicebox du côté Juicebox. Le processus de récupération est strictement protégé par le code PIN ; sans le code PIN, la chaîne de récupération ne peut être complétée.
Sécurité
L'objectif de conception du portefeuille sans clé de OneKey est de minimiser la barrière à l'entrée sans centraliser le "contrôle" entre les mains d'une seule partie. Étant donné que la récupération du portefeuille est l'une des opérations les plus sensibles, nous plaçons les frontières de sécurité du protocole et les modèles de menace au cœur de notre conception. Cela garantit qu'une meilleure convivialité ne se fait pas au détriment de la sécurité.
Objectifs de sécurité
Notre architecture est conçue pour atteindre les deux objectifs critiques suivants :
Aucun accès unilatéral : Aucune tierce partie (y compris OneKey) ne devrait pouvoir reconstruire ou utiliser unilatéralement la clé privée ou la phrase de récupération de l'utilisateur.
Conditions de récupération strictes : La seule façon pour un utilisateur de récupérer son portefeuille est de satisfaire simultanément deux exigences de vérification :
S'authentifier avec succès via son compte Google / Apple ;
Et prouver la possession du code PIN.
Pourquoi OneKey ne peut (unilatéralement) pas reconstruire votre clé
Pour restaurer une phrase de récupération ou un matériel clé utilisable sur votre appareil, tous les éléments suivants doivent être présents simultanément :
Le texte chiffré de la phrase de récupération
Les deux parts de la clé symétrique (Part de backend + Part Juicebox)
Cette architecture conduit à plusieurs conclusions directes :
Acteurs malveillants au sein de Juicebox : Si moins que le nombre seuil de royaumes/nœuds Juicebox agissent malveillamment, l'attaquant ne peut pas reconstruire une part Juicebox valide et, par conséquent, ne peut pas reconstruire la clé symétrique.
Compromission totale du réseau distribué : Même dans le scénario hypothétique où l'ensemble du réseau de fragmentation distribué est compromis, l'attaquant manquerait toujours la part de backend ou le texte chiffré détenus par le backend de OneKey, rendant la récupération indépendante impossible.
Compromission du backend OneKey : Même si le backend OneKey était attaqué, l'attaquant manquerait toujours la part stockée du côté Juicebox. Sans la part Juicebox, les données du backend seules sont insuffisantes pour reconstruire la clé symétrique ou déchiffrer le texte chiffré de la phrase de récupération.
Pourquoi "Compte + Code PIN" sont tous deux indispensables
Concernant le contrôle d'identité et d'accès, le portefeuille sans clé sépare "Qui vous êtes" (Identité du compte) de "Ce que vous savez" (PIN) :
Le côté compte : OneKey utilise des flux d'autorisation/de connexion OAuth 2.0 établis pour interagir avec Google et Apple pour la vérification d'identité et l'autorisation.
Le côté code PIN : Le code PIN protège le processus de récupération de la part critique à partir du protocole de stockage distribué (Juicebox). Même si un attaquant compromet votre compte, il ne peut pas récupérer la part correspondante ni compléter la récupération sans connaître le code PIN.
Chiffrement et gestion des clés
Au niveau du chiffrement et du partage de clés, le portefeuille sans clé adhère au principe que "le texte chiffré peut être stocké, mais les clés ne doivent jamais être centralisées" :
Chiffrement de la phrase de récupération : La phrase de récupération/le matériel clé est chiffré à l'aide d'algorithmes de chiffrement authentifié (AES-256) pour générer le texte chiffré, assurant la vérification d'intégrité lors de la récupération.
Partage et reconstruction des clés : Le Partage de secret de Shamir (SSS) est utilisé pour diviser et reconstruire la clé symétrique selon les règles de seuil.
Chiffrement du backend au repos : Les parts stockées sur le backend sont d'abord chiffrées à l'aide de Cloud KMS et d'algorithmes de chiffrement avant le stockage. Cela garantit que aucun texte brut n'est jamais visible tout au long du processus, garantissant la sécurité des données clés.
Fiabilité
Un point critique à comprendre concernant le portefeuille sans clé OneKey est que la récupération dépend de la satisfaction simultanée de deux conditions : vous devez être capable de vous connecter au compte Google ou Apple correspondant, et vous devez vous souvenir de votre code PIN.
Contrairement aux flux traditionnels de type "Mot de passe oublié" du Web2, OneKey ne peut pas récupérer votre code PIN pour vous, ni reconstruire votre clé privée ou phrase de récupération en votre nom. Ce n'est pas un défaut du produit, mais une partie délibérée de la frontière de sécurité : si un fournisseur de services avait la capacité d'accéder à l'un de ces éléments, l'attribut fondamental d'"auto-garde" serait fondamentalement compromis.
Par conséquent, une véritable solution "Zero Trust" exige inévitablement que l'utilisateur assume une partie de la responsabilité : maintenir l'accès à votre compte et vous souvenir de votre code PIN.
Et si j'oublie mon code PIN ?
Cependant, il existe un filet de sécurité : la phrase de récupération d'un portefeuille sans clé existe sous une forme utilisable sur les appareils où vous êtes déjà connecté.
Si vous oubliez votre code PIN, mais que vous conservez l'accès à un appareil où le portefeuille est connecté et fonctionne, vous pouvez généralement réinitialiser le code PIN sur cet appareil. Ce processus créera une nouvelle configuration de sauvegarde, vous assurant de conserver la possibilité de récupérer sur différents appareils à l'avenir.
Rappels périodiques de vérification du code PIN
Pour atténuer le risque d'oublier votre code PIN avec le temps, OneKey vous invitera à vérifier votre code PIN à des intervalles appropriés.
Si, lors de l'une de ces vérifications, vous réalisez que vous ne vous souvenez pas de votre code PIN, vous devez en profiter pour réinitialiser votre code PIN immédiatement pendant que vous avez toujours accès à l'appareil, puis régénérer/mettre à jour votre configuration de sauvegarde.
La limite ultime de disponibilité
En résumé, vous conserverez généralement l'accès à votre portefeuille sans clé tant que vous remplissez au moins l'une des conditions suivantes :
Vous possédez toujours un appareil fonctionnel et connecté ; OU
Vous pouvez vous connecter à votre compte Google / Apple ET vous vous souvenez de votre code PIN (vous permettant de récupérer sur un nouvel appareil).
Notre recommandation : Effectuer un "Test de récupération multi-appareils"
Étant donné que le processus de récupération est essentiellement "Connexion au compte + Saisie du code PIN", nous vous recommandons fortement d'effectuer un test de récupération sur un deuxième appareil immédiatement après avoir créé votre portefeuille sans clé.
En faisant cela, vous sécuriserez :
Un point d'accès sur l'Appareil A.
Un point d'accès sur l'Appareil B.
Une confiance vérifiée dans votre chemin de sauvegarde (Compte + Code PIN) pour une récupération future sur de nouveaux appareils.
Conclusion
Pour de nombreux nouveaux utilisateurs, bien que les phrases de récupération soient la norme de l'industrie, leur utilisation est souvent loin d'être intuitive. Saisir une phrase de récupération sur un nouvel appareil entraîne une friction importante, et savoir comment ou où la stocker en toute sécurité est une source fréquente de confusion.
Le portefeuille sans clé de OneKey vise à trouver un équilibre différent :
Il abaisse la barrière à l'entrée en utilisant une méthode familière (Google / Apple + Code PIN). Simultanément, grâce à une architecture de gestion de clés distribuée, il garantit qu'aucune partie unique (y compris OneKey) ne peut reconstruire unilatéralement votre clé complète. Cela réalise un compromis entre la "facilité d'utilisation" et les "limites de la sécurité auto-gardée" qui convient parfaitement au grand public.