Lors de Consensus 2026, Charles Hoskinson de Cardano a déclaré que « les utilisateurs ne devraient probablement jamais avoir leurs clés privées », ajoutant que « quelque chose devrait détenir les clés privées pour les utilisateurs ».
Il a fait valoir que les puces sécurisées déjà intégrées dans les iPhone, les téléphones Android et les appareils Samsung surpassent celles présentes dans les dispositifs Ledger et Trezor, et que la plupart des utilisateurs de cryptoportefeuilles portent déjà dans leurs poches un matériel de signature supérieur sans même s'en rendre compte.
La gestion des clés privées a été un goulot d'étranglement pour l'adoption grand public depuis les premiers jours de Bitcoin. Les utilisateurs éprouvent des difficultés avec leur phrase-seed de 12 ou 24 mots, qu'ils oublient souvent, photographient, stockent dans des notes en cloud ou perdent complètement.
Les portefeuilles matériels ont résolu le problème d'extraction, car un Ledger ou un Trezor génère et stocke des clés qui ne sortent jamais du dispositif en texte clair, tout en introduisant une friction que les utilisateurs grand public ont constamment rejetée.
FIDO a rapporté le 7 mai qu'il existe désormais 5 milliards de passkeys actifs dans le monde, dont 75 % des consommateurs en ont activé au moins une. Les utilisateurs acceptent déjà les identifiants liés à l'appareil et déverrouillés par biométrie comme faisant partie normale de l'authentification.
Le portefeuille intelligent de Coinbase rend cela opérationnel en permettant aux utilisateurs de s'inscrire sans phrase de récupération, en utilisant les passkeys d'Apple ou de Google, et en créant un identifiant non exportable lié à du matériel sécurisé. Face ID ou un code PIN deviennent la seule interface dont l'utilisateur a besoin.
Hoskinson a raison de dire que les téléphones grand public contiennent un matériel de sécurité sérieux. Le Secure Enclave d'Apple est un sous-système dédié isolé du processeur principal, et l'entreprise affirme qu'il protège les données sensibles même si un attaquant compromet le noyau du processeur d'application.
Le système Keystore d'Android supporte des clés appuyées sur du matériel qui peuvent rester non exportables et se lier à un environnement d'exécution fiable ou à un élément sécurisé, tandis que les implémentations StrongBox ajoutent un CPU dédié et des exigences supplémentaires d'isolation.
Le système Knox de Samsung offre une protection des clés appuyée sur du matériel via TrustZone, avec DualDAR ajoutant des couches supplémentaires de chiffrement pour les données des profils de travail gérés.
Hoskinson a décrit le profil de travail Knox comme « un système d'exploitation distinct, des circuits séparés dans le matériel ».
| Modèle | Où vit la clé | Peut-on extraire la clé ? | Un logiciel malveillant peut-il encore tromper la signature ? | Comment les détails de la transaction sont vérifiés | Meilleur cas d'utilisation |
|---|---|---|---|---|---|
| Portefeuille à phrase-seed | Dérivée d'une phrase de récupération de 12 ou 24 mots, souvent stockée dans un logiciel ou notée par l'utilisateur | Oui, potentiellement — le secret peut être exposé par un mauvais stockage, des captures d'écran, des sauvegardes en cloud, du phishing ou une compromission de l'appareil | Oui — si l'application ou l'appareil du portefeuille est compromis, l'attaquant peut tromper l'utilisateur ou voler directement le secret | Généralement via l'interface de l'application du portefeuille sur le même appareil | Inscription à faible friction, petits soldes, utilisateurs à l'aise avec la sauvegarde manuelle |
| Portefeuille à matériel sécurisé sur téléphone | À l'intérieur du matériel sécurisé d'un téléphone, tel que le Secure Enclave d'Apple, le Keystore/TEE/StrongBox d'Android ou les protections appuyées par Knox de Samsung | Généralement non — la clé peut rester non exportable et liée au matériel de l'appareil | Oui — la clé peut rester protégée, mais une application ou un système d'exploitation compromis pourrait toujours essayer de faire signer quelque chose de malveillant | Par l'interface utilisateur du téléphone, la biométrie, le code PIN et les invites du portefeuille ; la sécurité dépend fortement de l'UX d'approbation et de la vérification de l'intention | Paiements quotidiens, auto-gestion courante, utilisateurs grand public, inscription sans phrase-seed ou avec passkey |
| Portefeuille matériel dédié | À l'intérieur d'un appareil de signature séparé comme Ledger ou Trezor | Généralement non — les clés sont conçues pour rester sur l'appareil et ne pas sortir en texte clair | Beaucoup plus difficile, mais pas impossible — la clé est mieux isolée, bien que les attaquants puissent encore essayer de tromper l'utilisateur pour qu'il approuve une transaction malveillante | Sur l'écran sécurisé propre au portefeuille, physiquement séparé du téléphone ou de l'ordinateur | Soldes importants, stockage à long terme, utilisateurs souhaitant une isolation plus forte et un modèle de menace plus propre |
Les portefeuilles dédiés présentent un avantage
Le matériel sécurisé sur téléphone et les appareils de signature dédiés fonctionnent selon des modèles de menace différents.
Le élément sécurisé de Ledger alimente un écran sécurisé sur l'appareil lui-même, ce qui permet aux utilisateurs de vérifier les détails de la transaction même lorsque le téléphone ou l'ordinateur connecté est sous attaque.
L'écran de confiance de Trezor affiche la transaction en cours de signature, quel que soit ce que montre la machine hôte. Les nouveaux modèles Safe 3, Safe 5 et Safe 7 de Trezor intègrent également des éléments sécurisés, donc la critique selon laquelle les portefeuilles matériels manquent de silicium sécurisé est désormais obsolète.
La lacune identifiée par Hoskinson est l'accessibilité, puisque Ledger et Trezor nécessitent un appareil séparé, une application complémentaire et un flux de signature qui interrompt la transaction.
Pour les volumes de transactions quotidiens et l'auto-gestion courante, les téléphones constituent des signataires primaires plausibles. Pour les soldes importants ou les utilisateurs souhaitant le modèle de menace le plus robuste, les appareils dédiés avec écrans isolés gardent l'écran de signature physiquement séparé de la machine compromise, garantissant que le logiciel malveillant de l'hôte ne peut pas atteindre l'écran.
L'intégration de l'IA dans les paiements ajoute une couche à la pile. Les agents IA ont besoin d'une autorité de paiement pour être utiles, mais accorder à un agent l'accès à une clé privée maître est quelque chose que la plupart des utilisateurs n'accepteraient pas consciemment.
L'architecture viable est la délégation bornée, consistant en un agent autorisé à dépenser dans des limites prédéfinies, pendant une période définie, sans accès à l'identifiant qui contrôle le portefeuille global.
La documentation de Base sur les permissions de dépenses présente déjà les achats effectués par des agents IA comme un cas d'utilisation central pour les autorisations récurrentes et à portée limitée. L'intégration AgentCore Payments de Coinbase et l'outil de paiement pour agents stablecoins d'AWS mettent en œuvre le même modèle d'agents opérant sous contrôles budgétaires, avec des journaux d'audit complets, sans accès direct aux clés privées.
La Ethereum EIP-4337 a permis plus de 26 millions de portefeuilles intelligents et 170 millions d'UserOperations, et l'EIP-7702 de Pectra étend le comportement programmable des portefeuilles aux comptes externes, permettant le regroupement, le parrainage de gaz, la logique de récupération et des contrôles personnalisés.
L'infrastructure pour les portefeuilles compatibles avec les agents et basés sur des permissions existe déjà à une échelle significative.
Un graphique en barres montre 5 milliards de passkeys actifs, 170 millions d'UserOperations et 26 millions de portefeuilles intelligents, avec 75 % des consommateurs activant au moins un passkey.
Vos clés, mais vous ne les voyez jamais
« Pas vos clés, pas vos coins » a toujours été autant une position philosophique qu'une position technique, et elle suppose que les utilisateurs devraient manipuler directement les secrets cryptographiques.
Pourtant, cette position pourrait ne pas survivre au contact avec une distribution grand public. La version la plus durable de l'auto-gestion ressemble à une authentification basée sur la biométrie et à la génération d'une clé non exportable dans du matériel sécurisé, sans voir le matériel brut de la clé.
Ce que l'utilisateur contrôle, ce sont les plafonds de dépenses, les clés de session, les autorisations déléguées, la logique de récupération et les flux d'approbation lisibles par l'homme.
Le mécanisme d'intention sécurisée d'Apple permet au matériel de confirmer physiquement l'intention de l'utilisateur d'une manière que même le logiciel root ou kernel ne peut pas falsifier. Android Keystore supporte des exigences d'authentification par opération.
Ces capacités déplacent la garde de « pouvez-vous garder un secret » vers « pouvez-vous vérifier ce que vous vouliez autoriser ».
La limite la plus nette dans le raisonnement de Hoskinson est qu'une application ou un système d'exploitation compromis pourrait être incapable d'extraire une clé appuyée sur du matériel tout en pouvant encore l'utiliser sur l'appareil.
La non-extractabilité des clés et la sécurité des transactions sont des garanties distinctes, et l'histoire récente montre à quel point cette différence peut être catastrophique.
L'analyse de CertiK sur l'incident de Bybit a révélé que les attaquants avaient trompé les signataires pour qu'ils autorisent une transaction malveillante. L'attaque a réussi même si la clé privée n'avait jamais quitté le matériel.
Chainalysis a signalé que les escroqueries par usurpation d'identité avaient augmenté de plus de 1 400 % en 2025, et que les escroqueries alimentées par l'IA rapportaient 4,5 fois plus que les escroqueries traditionnelles.
Un modèle d'auto-gestion natif sur téléphone masquerait les clés privées aux utilisateurs tout en faisant de l'intention de transaction, de l'UX d'approbation et des limites de dépenses la surface principale de sécurité.
Deux trajectoires
Si les portefeuilles résolvent suffisamment bien l'UX d'intention pour gagner la confiance des consommateurs grâce à des plafonds de dépenses standardisés, à une délégation révocable et à des invites d'approbation claires, l'auto-gestion sur téléphone pourrait représenter de 70 % à 85 % des nouveaux utilisateurs grand public d'ici 2028.
L'inscription sans phrase-seed deviendra la norme, l'abstraction de compte passera d'une fonctionnalité avancée à une attente de base, et la phrase-seed deviendra une option de configuration pour les utilisateurs qui le souhaitent.
Si les incidents de signature mobile, le phishing, les flux d'approbation compromis ou les mécanismes de récupération confus continuent de provoquer des pertes médiatisées, l'auto-gestion sur téléphone stagnera entre 20 % et 35 % du marché grand public.
Les utilisateurs qui perdent des fonds suite à une attaque de manipulation de portefeuille sur téléphone la qualifient d'escroquerie et retournent aux exchanges.
Un graphique de scénario projette que l'auto-gestion sur téléphone pourrait atteindre de 70 % à 85 % des nouveaux utilisateurs grand public d'ici 2028 dans le cas favorable, et de 20 % à 35 % dans le cas défavorable.
La subtexte inconfortable dans chacune des deux trajectoires est la dépendance vis-à-vis des plateformes. Si l'auto-gestion passe au matériel intégré dans les téléphones, alors Apple, Google, Samsung et les principaux fournisseurs d'API de portefeuille deviendront des centres très puissants dans l'architecture de sécurité de la crypto.
Le modèle reste non conservatoire au sens technique, mais la sécurité du portefeuille dépend davantage des API du système d'exploitation, des politiques d'accès aux enclave et des règles de distribution des applications.
La publication Charles Hoskinson de Cardano dit que l'avenir des portefeuilles crypto sera à l'intérieur des iPhones et des Androids est apparue en premier sur CryptoSlate.