Tout le monde parle de l'abstraction de compte (AA) et de son potentiel pour révolutionner l'expérience utilisateur dans l'espace blockchain. Cependant, le principal malentendu à propos de l'AA est qu'il va au-delà de la simple abstraction des frais de gaz ou de l'activation de transactions groupées. Comment? Grâce à des systèmes de gestion de clés programmables.

Ces systèmes peuvent fournir une sécurité au niveau matériel pour les appareils de tous les jours et intégrer des méthodes d'authentification Web2 dans des environnements Web3, nous permettant ainsi de dépasser les phrases de départ traditionnelles de 12 mots. Aujourd'hui, je vais expliquer les différents systèmes de gestion de clés que les développeurs peuvent utiliser et les cas d'utilisation spécifiques où ils sont les plus utiles.

Aller au-delà de 12 mots

Notre industrie adore les mots à la mode, et "sans graines" est l'un des derniers à attirer l'attention. Alors que nous sommes tous d'accord pour dire que s'attendre à ce que les utilisateurs stockent leurs clés privées de manière sécurisée est impraticable et a entraîné la perte de millions de dollars, la question demeure : si nous ne montrons pas aux utilisateurs les phrases de graine, où stockons-nous les clés ?

Sans Abstraction de compte (AA), la plupart des solutions existantes reposent sur le calcul multipartite (MPC) pour distribuer les clés en plusieurs parties et créer un seuil pour effectuer des transactions. Ces solutions prétendent souvent être auto-custodiales. Cependant, ce n'est pas tout à fait exact. Par exemple, Binance stocke une part de la clé, agissant en tant que gardien au cas où les utilisateurs perdraient leurs appareils. Cette configuration signifie qu'en dépit des revendications, les utilisateurs ne sont pas vraiment maîtres de leurs clés, et qu'il existe toujours une dépendance à une entité centralisée pour la récupération des clés.

De plus, si une clé est divulguée, il est impossible de révoquer la clé du compte principal. La révocation est impossible car les comptes détenus à l'extérieur (EOA) ne prennent pas en charge la rotation des clés, ce qui signifie que les clés divulguées feront toujours partie du compte. Cela présente un risque de sécurité important, car les clés compromises ne peuvent pas être remplacées ou supprimées, laissant le compte vulnérable indéfiniment.

Si vous souhaitez en savoir plus sur la façon dont AA ouvre la voie aux comptes programmables et à la rotation des clés, vous pouvezvérifier mon article.

1. Comptes entièrement programmables : Abstraction de compte

L'abstraction de compte permet aux développeurs de construire différents systèmes de gestion de clés. Un compte peut être contrôlé avec plusieurs clés et différentes méthodes d'authentification, toutes prenant en charge la rotation des clés. Mieux encore, la puissance des clés peut être différenciée. Cela signifie que les utilisateurs peuvent utiliser des clés différentes pour le même compte, chacune adaptée à des cas d'utilisation différents. Je vais expliquer ces cas d'utilisation plus en détail plus tard.

Avec AA, les fonds sont stockés dans des contrats intelligents, et la possession du compte est définie par ces contrats intelligents. Les comptes compatibles avec EIP-4337 ont deux parties dans leurs transactions.

1. La première partie est la vérification, où la propriété du compte est vérifiée on-chain.
2. La deuxième partie est l'exécution, qui exécute le message.

Les deux parties sont entièrement programmables ; par exemple, vous pouvez définir deux clés (i, ii), et la première clé (i) peut exécuter des transactions immédiates, tandis que la deuxième clé (ii) ne peut exécuter des transactions qu'après un verrouillage temporel. Cela signifie que nous pouvons définir la puissance des clés, ajouter un verrouillage temporel, ou activer d'autres conditions pour exécuter une transaction.

Ainsi, lorsque nous parlons de comptes traditionnels (EOAs), l'authentification est égale à l'autorisation. Avec AA, l'autorisation est programmable, donc les développeurs peuvent définir un schéma de contrôle d'accès basé sur les rôles et appliquer le principe du moindre privilège.

Il existe de nombreuses méthodes d'authentification (c'est-à-dire des systèmes de gestion des clés) dans l'espace crypto qui peuvent permettre des schémas de contrôle d'accès basés sur les rôles, et l'utilisation d'une seule clé ne peut pas résoudre tous les problèmes associés à la gestion des clés. Les aspects les plus importants des systèmes de gestion des clés sont : où la clé est stockée et qui l'authentifie.

Avantages et inconvénients de différents systèmes de gestion des clés

Je vais rapidement résumer les Passkeys (enclaves sécurisées pour les consommateurs), les solutions basées sur le MPC, les solutions basées sur le TEE basé sur le cloud, les solutions de garde, les 12 mots traditionnels et les clés de session. Ensuite, je vais expliquer les meilleures combinaisons.

1. 12 mots traditionnels - (secp256k1) -

Bitcoin et Ethereum supportent lesecp256k1L'algorithme ECC (cryptographie sur courbe elliptique) pour créer des clés privées et les stocker sur les appareils des utilisateurs. Cette méthode est largement utilisée dans les EOAs et peut également être appliquée àcomptes intelligents. Pour l'utiliser, l'application de portefeuille génère une clé privée à l'aide d'un algorithme de génération de clé aléatoire, puis stocke la clé privée dans un stockage partagé.

Utiliser secp256k1 présente plusieurs avantages : cela n'entraîne aucun coût supplémentaire en gaz, c'est peu coûteux et facile à vérifier onchain via la précompilation ecrecover. C'est également auto-géré car seul l'utilisateur peut accéder à la clé.

Cependant, il y a quelques inconvénients:

1. Il est difficile d'éduquer les utilisateurs sur la manière de stocker en toute sécurité leurs clés au cas où ils perdraient leurs appareils.
2. Un cheval de Troie ou un logiciel malveillant pourrait voler la clé privée des appareils des utilisateurs car elle est stockée dans un espace de stockage partagé.

NIST ne prend pas en charge la courbe secp256k1, ce qui signifie qu'elle n'est pas couramment prise en charge par les frameworks populaires et la plupart du matériel.

2. Passkeys (Enclaves de sécurité des consommateurs)

Presque tous les appareils modernes ont deux composants principaux: un système d'exploitation (avec un stockage partagé associé) et une Enclave sécurisée. Le système d'exploitation gère la plupart des opérations, sauf les tâches sensibles telles que la protection des données biométriques, les clés cryptographiques, le chiffrement et le déverrouillage de l'appareil.

Les développeurs ont créé une micro puce dédiée appelée Secure Enclave pour gérer ces opérations sensibles séparément. Le Secure Enclave fonctionne de manière similaire à un portefeuille matériel ; il fonctionne de manière indépendante, gère en toute sécurité les données sensibles, et même le propriétaire de l'appareil ne peut pas accéder à son contenu. Heureusement, le Secure Enclave prend en charge les opérations cryptographiques, telles que la création de clés privées et la signature de messages avec celles-ci. Malheureusement, le Secure Enclave ne prend pas en charge la courbe que Ethereum prend en charge (secp256k1), mais prend en charge la courbe P256. Pour activer la vérification native P256, nous ( @getclave"">@getclave équipe) a proposé leRIP-7212et presque tous les grands rollups le supportent maintenant.

Et la meilleure partie des enclaves sécurisées est que nous pouvons créer une clé privée à l'intérieur des enclaves sécurisées avec une simple authentification biométrique, ce qui permet une expérience d'intégration en un seul clic avec la meilleure sécurité disponible sur les appareils modernes - au niveau matériel. Mais cela a aussi quelques inconvénients:

• La vérification P256 sans RIP-7212 est coûteuse et augmente le risque de bug.
• Étant donné que la clé ne peut pas être extraite, la récupérabilité est une fonctionnalité manquante ici (Passkeys permet une récupérabilité limitée mais ce n'est pas suffisant)
• Si le domaine web de la clé d'accès ou de l'application Secure Enclave (SE) cesse de fonctionner, les utilisateurs ne peuvent pas accéder à la clé privée car la Secure Enclave est conçue pour être isolée et indépendante. Sans l'application ou le domaine web associé, il n'y a aucun moyen de récupérer ou d'interagir avec la clé privée, laissant les utilisateurs incapables d'effectuer les opérations cryptographiques nécessaires. - Je vais expliquer comment résoudre ce problème.

3. Solutions de gestion des clés basées sur SSS

Les solutions SSS (partage de secret de Shamir) créent un moyen d'éliminer le point unique de défaillance que les systèmes de gestion de clés traditionnels ont. Ils divisent essentiellement les clés en différentes parties et établissent un seuil pour accéder à la clé. En distribuant ces parties, SSS garantit qu'aucune entité unique ne détient la clé entière, renforçant ainsi la sécurité.

Examinons où ils stockent les clés et comment ils atteignent le quorum pour accéder à la clé privée. La plupart des protocoles existants utilisent trois parts de clé : une part est stockée sur l'appareil de l'utilisateur, une est conservée sur leur serveur (ou au sein d'un réseau MPC), et une est réservée en tant que sauvegarde. Certaines applications, comme Google Drive, utilisent des solutions de stockage cloud pour stocker ces parts de clé.

Ainsi, les utilisateurs délèguent le contrôle de leur portefeuille à d'autres parties avec un quorum. MPC (Calcul multipartite) est puissant pour déléguer les responsabilités de gestion des clés à différentes parties, mais il présente également certains inconvénients:

La plupart des solutions MPC nécessitent une partie centralisée, et parfois, ce qu'ils appellent décentralisé n'est pas vraiment décentralisé. MPC avec AA est puissant parce que la rotation des clés est possible, mais de nombreuses solutions MPC incluent une certaine fonctionnalité pour le contrôle d'accès. De plus, dans de nombreux cas, des clés précédentes peuvent encore être utilisées même après la rotation, il faut donc faire confiance que les clés sont réellement éliminées. Certaines solutions MPC peuvent censurer les utilisateurs, il n'est donc pas toujours possible de se fier uniquement à MPC.

Un autre inconvénient majeur de SSS est qu'il reconstruit généralement la clé privée dans le navigateur. C'est un risque de sécurité massif qu'une clé en texte brut soit disponible côté client. TSS ne reconstruit jamais la clé et utilise le MPC pour fédérer la signature à travers les parts de clé.

4. Solutions TEE basées sur le cloud

Je ne pense pas que les environnements d'exécution de confiance basés sur le cloud (TEE) et les solutions basées sur SSS soient si différentes, mais je voulais quand même expliquer comment elles fonctionnent. Les environnements d'exécution de confiance fonctionnent exactement comme ils sont codés ; ils sont immuables (du moins, ils prétendent l'être) et les TEE ne montrent pas ce qui se trouve à l'intérieur, même au propriétaire du TEE. Ils sont conçus pour fonctionner avec intégrité, en faisant ce qu'il faut même si personne ne regarde. Ainsi, les clés ne sont jamais exposées au client tant que les TEE font leur travail correctement.

En utilisant les TEE, nous pouvons construire des couches de gestion des clés où les développeurs peuvent utiliser différentes méthodes d'authentification et le TEE peut les vérifier. Après vérification, le TEE signe un message avec la clé privée associée à l'utilisateur et la vérifie sur la chaîne.

La clé privée principale qui contrôle les fonds des utilisateurs est stockée à l'intérieur du TEE et ne peut pas être extraite. Cela menace la décentralisation car si le service décide de fermer ou de censurer les utilisateurs, il n'y a rien qu'un constructeur d'application décentralisée puisse faire.

Les TEE basés sur le cloud semblent prometteurs en théorie, mais dans le passé, nous avons vu des vulnérabilités commeéchec sgxdans les TEE en nuage. Cependant, l'avantage des TEE est que même s'il y a une porte dérobée ou une vulnérabilité, l'attaquant aurait besoin d'un accès physique au TEE, c'est pourquoi le matériel grand public (Enclave sécurisée - Passkeys) est si puissant car il stocke la clé à l'intérieur de l'Enclave sécurisée des utilisateurs et seul le propriétaire peut accéder à la clé, tandis que les TEE en nuage stockent les clés à l'intérieur d'un nuage et cela les rend vulnérables aux attaques.

Pas votre enclave sécurisée, pas vos pièces.

Comme je l'ai mentionné, les TEE ont certains avantages, tels que l'utilisation de presque toutes les méthodes d'authentification sans aucun blocage cryptographique. Cependant, ils ont aussi quelques inconvénients :

Si les fournisseurs de services ferment le serveur, les fonds des utilisateurs sont gelés et personne ne peut y accéder. Les clés sont stockées à l'intérieur du Cloud TEE, ce qui signifie qu'ils peuvent censurer les utilisateurs. Se fier uniquement aux TEE pour la gestion des clés crée un point unique de défaillance.

Clés de session : Une nouvelle façon d'octroyer des autorisations limitées

Nous avons parlé des clés permanentes. Et si nous pouvions générer une clé temporelle qui a un accès limité aux actifs et qui disparaît après un certain temps décidé par l'utilisateur ? La clé de session nous permet de le faire :

Dans le monde web2, les clés de session sont comme des mots de passe temporaires utilisés pendant une conversation entre deux appareils (comme votre ordinateur et un serveur). Elles sont créées au début de la conversation, utilisées pour garder les informations partagées en sécurité, puis jetées après la fin de la conversation. Ainsi, même si un pirate informatique trouve d'une manière ou d'une autre ce mot de passe, il ne peut pas l'utiliser pour écouter les conversations futures car un nouveau mot de passe (ou clé de session) différent est créé à chaque fois.

Comme dans le monde Web3, nous définissons les clés de session comme un cadre qui peut potentiellement changer la façon dont les utilisateurs interagissent avec les dApps. L'objectif des clés de session est de permettre aux utilisateurs de définir des pré-approbations pour une durée spécifique dans divers scénarios et de réaliser des transactions sans signature. Mais comment ça fonctionne?

Les utilisateurs créent une autorisation limitée comme une clé de session qui peut dépenser des actifs uniquement comme spécifié par l'utilisateur, pendant une durée limitée et révocable à tout moment. Ensuite, un service backend permet aux utilisateurs d'effectuer des transactions en les signant en leur nom. Cette configuration crée une fenêtre de confiance temporaire entre la dApp et les utilisateurs. C'est bien mieux que les approbations infinies car l'approbation donnée par les utilisateurs est uniquement pour des actifs spécifiques et pour une période définie. Même si la dApp est piratée, les utilisateurs n'ont pas besoin de s'inquiéter d'une clé de session créée il y a des mois 🙂.

Meilleures combinaisons d'authentification et de gestion des clés pour différents cas d'utilisation

J'ai expliqué différents systèmes de gestion de clés et leurs avantages et inconvénients. Avec la puissance de AA, nous pouvons combiner ces systèmes de gestion de clés et créer des structures puissantes avec des compromis minimes. Expliquons cela C.1) Passkey + récupération avec timelock - Clave - une application fintech qui stocke des fonds précieux.

Les méthodes d'authentification basées sur Secure Enclave (passkeys) offrent une sécurité au niveau matériel ; cependant, leur capacité de récupération est souvent insuffisante pour la plupart des utilisateurs. Heureusement, AA permet aux développeurs de combiner différentes méthodes de signature et de les utiliser dans un seul compte. En ajoutant un signataire de récupération à un compte intelligent, nous pouvons résoudre le problème de récupération que posent les passkeys.

Il existe plusieurs options de récupération telles que la récupération sociale, la récupération universelle (récupération basée sur ZK-Email) et la récupération basée sur MPC. Cependant, à mon avis, pour une application fintech conçue pour être entièrement auto-gérée, la récupération sociale résout la plupart des problèmes. Chez Clave, nous avons développé un module de récupération sociale et travaillons sur la récupération universelle.

Cette approche maximise la sécurité, ce qui est idéal pour les applications financières. Mais elle présente un inconvénient important : l'application nécessite une authentification biométrique pour chaque transaction que l'utilisateur souhaite effectuer. Imaginez que vous vouliez partager un contenu dans une application de médias sociaux et que l'application affiche un écran de signature biométrique... Terrible, n'est-ce pas ?

Les applications non financières telles que les applications sociales-Fi et les jeux décentralisés ont besoin d'un moyen plus facile d'effectuer des transactions, idéalement sans exiger des utilisateurs de signer chaque transaction. Comment ? Voici la réponse :

1. Passkey + récupération avec verrouillage temporel + clés de session - application sociale mobile

Les clés de session permettent aux utilisateurs de réaliser des transactions sans écran de signature. Les jeux ou applications sociales basés sur les NFT peuvent hériter des clés de session pour avoir un accès temporaire et limité aux actifs des utilisateurs. Si vous pensez que cela ajoute une supposition de confiance supplémentaire, expliquons comment fonctionnent les interfaces frontales d'aujourd'hui :

Aujourd'hui, la plupart des utilisateurs ne vérifient même pas ce qu'ils signent lorsqu'ils jouent à un jeu ou interagissent avec une dApp. C'est dangereux car une interface malveillante peut causer la perte de tous leurs actifs.

Les clés de session sont une meilleure alternative à cela. Les utilisateurs peuvent vérifier la durée pendant laquelle la session sera active et les actifs auxquels la session peut accéder, réduisant ainsi le besoin de faire confiance à la dApp. Après l'expiration de la session, les utilisateurs n'ont pas besoin de se préoccuper des approbations = Plus besoin derevoke.cashcomme les applications :)

2. Signataire basé sur MPC ou cloud TEE + signataire auto-custodial pour escape

L’inconvénient des couches de gestion de clés tierces basées sur MPC ou Cloud TEE est que la plupart ne sont pas auto-dépositaires et ont des composants centralisés importants. Cependant, certaines dApps nécessitent des portefeuilles intégrés sans frais généraux de gaz supplémentaires, ce qui nécessite des solutions basées sur MPC ou Cloud TEE. L’ajout d’un signataire supplémentaire pour le « rage quit » peut résoudre le problème de censure de ces systèmes de gestion des clés et également atténuer les problèmes juridiques potentiels auxquels ces dApps peuvent être confrontées. Vous avez besoin d’un portefeuille intelligent pour créer cela, car la rotation des clés n’est pas possible avec les EOA.

Il existe déjà plusieurs applications qui utilisent cette architecture de gestion des clés.

3. 12 mots + Hardware Signer pour maximiser la sécurité - Expérience d'extension de navigateur DeFi

Les utilisateurs de DeFi adorent l'expérience de l'extension de navigateur et changer les comportements des utilisateurs est l'une des choses les plus difficiles dans le monde moderne. Alors, pourquoi ne pas construire une meilleure alternative? En combinant un signataire matériel (Secure Enclave ou Passkey Signer) avec des phrases de graine de 12 mots accessibles via une extension, on pourrait également résoudre le problème des clés privées divulguées. Cette approche améliore la sécurité sans avoir besoin de modifier les comportements des utilisateurs. Plusieurs équipes de l'industrie AA travaillent à la mise en place de cette solution. (par exemple. @myBraavos)

Les comptes intelligents ne sont pas assez intelligents

Imaginez que vous êtes un utilisateur qui a d'abord généré un EOA avec @MetaMasket ensuite découvert une alternative comme Zerion. Vous décidez d'utiliser @zerion, et tout ce que vous avez à faire, c'est d'importer votre phrase de récupération - simple. Maintenant, imaginez essayer de faire la même chose sur Starknet, où tous les portefeuilles sont des comptes intelligents. Vous ne pouvez pas, car Braavos et Argent ne sont pas compatibles. Ce problème existe également dans l'écosystème EIP-4337 et@zkSyncAA natif de ’s.

Nous avons besoin de normes (pas de gardiens) ou tout au moins d'un meilleur moyen de financer de nouveaux portefeuilles. Sinon, il n'y aura jamais une adoption généralisée des portefeuilles intelligents, et les acteurs existants resteront les décideurs, dictant les pratiques de l'industrie même si elles ne sont pas correctes.

De plus, la fonction "rage quit" devrait être une fonction par défaut, car les acteurs centraux de presque tous les systèmes de gestion clé peuvent être arrêtés. Il devrait être plus facile pour les utilisateurs de changer de signataires ou de passer à des contrats intelligents, et l'auto-hébergement devrait être l'option par défaut pour les utilisateurs. Il existe deux normes de compte intelligent modulaire : ERC-6900 et ERC-7579. Ils cherchent tous les deux à atteindre un objectif similaire - rendre les comptes intelligents plus intelligents.

Remerciements spéciaux à Derek ,Konrad, etNoampour les commentaires et les remarques!

Avertissement :

1. Cet article est repris de [BEYONDX]. Tous les droits d'auteur appartiennent à l'auteur original [2077Recherche]. If there are objections to this reprint, please contact the Gate Learnéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas des conseils en investissement.
3. L'équipe de gate Learn a traduit l'article dans d'autres langues. Copier, distribuer ou plagier les articles traduits est interdit sauf mention contraire.