Todos hablan sobre la Abstracción de Cuentas (AA) y su potencial para revolucionar la experiencia del usuario en el espacio de blockchain. Sin embargo, el principal malentendido sobre AA es que va más allá de simplemente abstraer las tarifas de gas o habilitar transacciones por lotes. ¿Cómo? A través de sistemas de gestión de claves programables.

Estos sistemas pueden proporcionar seguridad a nivel de hardware para dispositivos cotidianos e integrar métodos de autenticación de Web2 en entornos de Web3, lo que nos permite ir más allá de las frases de semilla tradicionales de 12 palabras. Hoy, explicaré diferentes sistemas de gestión de claves que los desarrolladores pueden utilizar y los casos de uso específicos donde son más útiles.

Más allá de 12 palabras

Nuestra industria ama las palabras de moda, y "sin semillas" es una de las últimas en captar la atención. Si bien todos estamos de acuerdo en que esperar que los usuarios almacenen sus claves privadas de forma segura es impráctico y ha resultado en la pérdida de millones de dólares, la pregunta sigue siendo: si no mostramos a los usuarios las frases de semilla, ¿dónde almacenamos las claves?

Sin la Abstracción de Cuenta (AA), la mayoría de las soluciones existentes confían en la Computación Multiparte (MPC) para distribuir las claves en varias partes y crear un umbral para hacer transacciones. Estas soluciones a menudo afirman ser auto custodiales. Sin embargo, esto no es del todo preciso. Por ejemplo, Binance almacena una parte de la clave, actuando como custodio en caso de que los usuarios pierdan sus dispositivos. Esta configuración significa que, a pesar de las afirmaciones, los usuarios no tienen realmente el control de sus claves, y todavía hay una dependencia de una entidad centralizada para la recuperación de claves.

Además, si se filtra alguna de las claves, no hay forma de revocar la clave de la cuenta principal. La revocación es imposible porque las Cuentas Propiedad Externa (EOA) no admiten rotación de claves, lo que significa que las claves filtradas siempre serán parte de la cuenta. Esto representa un riesgo de seguridad significativo, ya que las claves comprometidas no pueden ser reemplazadas o eliminadas, dejando la cuenta vulnerable indefinidamente.

Si quieres aprender más sobre cómo AA abre el camino para cuentas programables y rotación de claves, puedesverifica mi artículo.

1. Cuentas totalmente programables: Abstracción de cuenta

La Abstracción de Cuenta permite a los desarrolladores construir diferentes sistemas de gestión de claves. Una cuenta puede ser controlada con múltiples claves y diferentes métodos de autenticación, todos ellos con soporte para rotación de claves. Aún mejor, el poder de las claves puede ser diferenciado. Esto significa que los usuarios pueden utilizar diferentes claves para la misma cuenta, cada una adaptada a diferentes casos de uso. Más adelante explicaré estos casos de uso con más detalle.

Con AA, los fondos se almacenan en contratos inteligentes, y la propiedad de la cuenta está definida por estos contratos inteligentes. Las cuentas compatibles con EIP-4337 tienen dos partes en sus transacciones.

1. La primera parte es la verificación, donde se verifica la propiedad de la cuenta en la cadena.
2. La segunda parte es la ejecución, que ejecuta el mensaje.

Las dos partes son totalmente programables; por ejemplo, puedes definir dos claves (i, ii), y la primera clave (i) puede ejecutar transacciones inmediatas, mientras que la segunda clave (ii) solo puede ejecutar transacciones después de un bloqueo de tiempo. Esto significa que podemos definir el poder de las claves, agregar un bloqueo de tiempo o habilitar otras condiciones para ejecutar una transacción.

Entonces, cuando hablamos de cuentas tradicionales (EOAs), la autenticación es igual a la autorización. Con AA, la autorización es programable, por lo que los desarrolladores pueden definir un esquema de control de acceso basado en roles y hacer cumplir el principio de privilegio mínimo.

Hay muchos métodos de autenticación (es decir, sistemas de gestión de claves) en el espacio criptográfico que pueden habilitar esquemas de control de acceso basados en roles, y el uso de una sola clave no puede resolver todos los problemas asociados con la gestión de claves. Los aspectos más importantes de los sistemas de gestión de claves son: dónde se almacena la clave y quién la autentica.

Pros y contras de diferentes sistemas de gestión de claves

Haré un resumen rápido de los Passkeys (Consumer Secure Enclaves), soluciones basadas en MPC, soluciones basadas en TEE en la nube, soluciones custodiales, las tradicionales 12 palabras y las claves de sesión. Después de eso, explicaré las mejores combinaciones.

1. 12 palabras tradicionales - (secp256k1) -

Bitcoin y Ethereum soportan elsecp256k1Algoritmo ECC (criptografía de curva elíptica) para crear claves privadas y almacenarlas en los dispositivos de los usuarios. Este método se utiliza ampliamente en EOAs y también se puede aplicar acuentas inteligentes. Para usarlo, la aplicación de billetera genera una clave privada utilizando un algoritmo de generación de claves aleatorias y luego almacena la clave privada en un almacenamiento compartido.

Usar secp256k1 tiene varias ventajas: no incurre en costos de gas adicionales, es económico y fácil de verificar en cadena a través del precompilado ecrecover. También es autónomo porque solo el usuario puede acceder a la clave.

Sin embargo, hay algunas desventajas:

1. Es desafiante educar a los usuarios sobre cómo almacenar de forma segura sus claves en caso de que pierdan sus dispositivos.
2. Un troyano o malware podría robar la clave privada de los dispositivos de los usuarios, ya que se almacena en un almacenamiento compartido.

NIST no admite la curva secp256k1, lo que significa que no es compatible con los marcos populares ni con la mayoría del hardware.

2. Passkeys (Recintos Seguros del Consumidor)

Casi todos los dispositivos modernos tienen dos componentes principales: un sistema operativo (con almacenamiento compartido asociado) y una Enclave Segura. El sistema operativo maneja la mayoría de las operaciones excepto las tareas sensibles como proteger los datos biométricos, las claves criptográficas, el cifrado y el desbloqueo del dispositivo.

Los desarrolladores crearon un microchip dedicado llamado Secure Enclave para gestionar estas operaciones sensibles de forma independiente. Secure Enclave funciona de manera similar a una cartera de hardware; opera de forma independiente, gestionando de forma segura datos sensibles, e incluso el propietario del dispositivo no puede acceder a su contenido. Afortunadamente, Secure Enclave admite operaciones criptográficas, como la creación de claves privadas y la firma de mensajes con ellas. Desafortunadamente, Secure Enclave no admite la curva que Ethereum soporta (secp256k1), en su lugar, admite la curva p256. Para habilitar la verificación nativa de P256, nosotros (@getclave"">@getclave equipo) propuso elRIP-7212y casi todos los grandes rollups ahora lo admiten.

Y la mejor parte de los Secure Enclaves es que podemos crear una clave privada dentro de los Secure Enclaves con solo autenticación biométrica, lo que permite una experiencia de incorporación de un solo clic con la mejor seguridad disponible en dispositivos modernos a nivel de hardware. Pero también tiene algunas desventajas:

• La verificación P256 sin RIP-7212 es costosa y aumenta el riesgo de errores.
• Dado que la clave no se puede extraer, la recuperabilidad es una característica que falta aquí (Passkeys permite una recuperabilidad limitada pero no es suficiente)
• Si el dominio web de la contraseña o la aplicación Secure Enclave (SE) deja de funcionar, los usuarios no pueden acceder a la clave privada porque el Secure Enclave está diseñado para ser aislado e independiente. Sin la aplicación o el dominio web asociado, no hay forma de recuperar o interactuar con la clave privada, lo que deja a los usuarios incapaces de realizar operaciones criptográficas necesarias. - Explicaré cómo resolver este problema.

3. Soluciones de gestión de claves basadas en SSS

Las soluciones SSS (Shamir's Secret Sharing) crean una forma de eliminar el único punto de falla que tienen los sistemas tradicionales de gestión de claves. Básicamente, dividen las claves en diferentes partes y establecen un umbral para acceder a la clave. Al distribuir estas partes, SSS garantiza que ninguna entidad única posea la clave completa, mejorando así la seguridad.

Examinemos dónde almacenan las claves y cómo alcanzan el quórum para acceder a la clave privada. La mayoría de los protocolos existentes utilizan tres partes de clave: una parte se almacena en el dispositivo del usuario, otra se guarda en su servidor (o en una Red MPC) y otra se reserva como respaldo. Algunas aplicaciones, como Google Drive, utilizan soluciones de almacenamiento en la nube para almacenar estas partes de clave.

Entonces, los usuarios delegan el control de su billetera a otras partes con un quórum. MPC (Computación de varias partes) es poderoso para delegar responsabilidades de gestión de claves a diferentes partes, pero también tiene algunas desventajas:

La mayoría de las soluciones de MPC requieren una parte centralizada, y a veces, lo que llaman descentralizado no es verdaderamente descentralizado. MPC con AA es poderoso porque la rotación de claves es posible, pero muchas soluciones de MPC incluyen alguna funcionalidad para el gatekeeping. Además, en muchos casos, las claves anteriores aún podrían ser utilizadas incluso después de la rotación, por lo que se necesita confiar en que las claves realmente se desechen. Algunas soluciones de MPC pueden censurar a los usuarios, por lo que depender únicamente de MPC no siempre es factible.

Otra gran desventaja de SSS es que reconstruye la clave privada, generalmente en el navegador. Es un riesgo de seguridad masivo que una clave de texto plano esté disponible en el lado del cliente. TSS nunca reconstruye la clave y utiliza MPC para federar la firma en las partes clave.

4. Soluciones basadas en la nube de TEE

No creo que los Entornos de Ejecución Confiables (TEEs) basados en la nube y las soluciones basadas en SSS sean tan diferentes, pero aún así quería explicar cómo funcionan. Los Entornos de Ejecución Confiables funcionan exactamente como están codificados; son inmutables (al menos dicen serlo), y los TEEs no muestran lo que hay adentro ni siquiera al propietario del TEE. Están diseñados para trabajar con integridad, haciendo lo correcto incluso si nadie está mirando. Por lo tanto, las claves nunca se exponen al cliente siempre que los TEE estén haciendo su trabajo correctamente.

Al utilizar TEEs, podemos construir capas de gestión de claves donde los desarrolladores pueden utilizar diferentes métodos de autenticación, y el TEE puede verificarlos. Después de la verificación, el TEE firma un mensaje con la clave privada asociada con el usuario y lo verifica en la cadena.

La clave privada principal que controla los fondos de los usuarios se almacena dentro del TEE y no se puede extraer. Esto amenaza la descentralización porque si el servicio decide cerrar o censurar a los usuarios, no hay nada que un desarrollador de dApp pueda hacer.

Los TEE basados en la nube parecen prometedores en teoría, pero en el pasado, hemos visto vulnerabilidades comosgx.failen cloud TEEs. Sin embargo, la ventaja de los TEEs es que incluso si hay una puerta trasera o vulnerabilidad, el atacante necesitaría acceso físico al TEE, por eso el hardware de consumo (Secure Enclave - Passkeys) es tan poderoso ya que el hardware de consumo almacena la clave dentro del Secure Enclave de los usuarios y solo el propietario puede acceder a la clave, mientras que los Cloud TEE almacenan las claves dentro de una nube y esto lo hace vulnerable a ataques.

No es tu enclave seguro, no son tus monedas.

Como mencioné, los TEE tienen algunas ventajas, como el uso de casi todos los métodos de autenticación sin bloqueadores criptográficos. Sin embargo, también tienen algunas desventajas:

Si los proveedores de servicios apagan el servidor, los fondos de los usuarios quedan congelados y nadie puede acceder a ellos. Las claves se almacenan dentro de Cloud TEE, lo que significa que pueden censurar a los usuarios. Depender únicamente de TEEs para la gestión de claves crea un único punto de fallo.

Claves de sesión: Una nueva forma de permisos limitados

Hemos hablado de claves permanentes. ¿Qué pasaría si pudiéramos generar una clave temporal que tenga acceso limitado a los activos y desaparezca después de un tiempo que el usuario decida? La Clave de Sesión nos permite hacerlo:

En el mundo web2, las claves de sesión son como contraseñas temporales utilizadas durante una conversación entre dos dispositivos (como tu computadora y un servidor). Se crean al inicio de la conversación, se utilizan para mantener segura la información compartida y luego se descartan después de que la conversación finaliza. Por lo tanto, incluso si un hacker de alguna manera descubre esta contraseña, no puede usarla para escuchar futuras conversaciones porque cada vez se crea una contraseña nueva y diferente (o clave de sesión).

Como en el mundo de Web3, definimos las claves de sesión como un marco que potencialmente puede cambiar cómo los usuarios interactúan con dApps. El objetivo de las claves de sesión es permitir a los usuarios establecer aprobaciones previas por un tiempo específico en una variedad de escenarios y realizar transacciones sin firmar. Pero, ¿cómo funciona?

Los usuarios crean permisos limitados como una clave de sesión que puede gastar activos solo según lo especificado por el usuario, durante un tiempo limitado y es revocable en cualquier momento. Después de eso, un servicio backend permite a los usuarios realizar transacciones firmando en su nombre. Esta configuración crea una ventana de confianza temporal entre la dApp y los usuarios. Es mucho mejor que las aprobaciones infinitas porque la aprobación que dan los usuarios es solo para activos específicos y por un período definido. Incluso si la dApp es hackeada, los usuarios no necesitan preocuparse por una clave de sesión creada hace meses 🙂.

Las mejores combinaciones de autenticación y gestión de claves para diferentes casos de uso

He explicado diferentes sistemas de gestión de claves y sus pros y contras. Con el poder de AA, podemos combinar estos sistemas de gestión de claves y crear estructuras potentes con mínimos compromisos. Vamos a explicarlo C.1) Passkey + recuperación con bloqueo temporal - Clave - una aplicación fintech que almacena fondos valiosos.

Los métodos de autenticación basados en Secure Enclave (contraseñas) proporcionan seguridad a nivel de hardware; sin embargo, su recuperabilidad suele ser insuficiente para la mayoría de los usuarios. Afortunadamente, AA permite a los desarrolladores combinar diferentes métodos de firma y utilizarlos en una cuenta. Al agregar un firmante de recuperación a una cuenta inteligente, podemos resolver el problema de recuperabilidad que tienen las contraseñas.

Existen varias opciones de recuperación como la recuperación social, la recuperación universal (recuperación basada en ZK-Email) y la recuperación basada en MPC. Sin embargo, en mi opinión, para una aplicación fintech que está diseñada para ser completamente auto custodial, la recuperación social resuelve la mayoría de los problemas. En Clave, construimos un módulo de recuperación social y estamos trabajando en la Recuperación Universal.

Este enfoque maximiza la seguridad, lo cual es excelente para aplicaciones financieras. Pero tiene una importante desventaja: la aplicación requiere autenticación biométrica para cada transacción que el usuario desea realizar. Imagina que quieres compartir un contenido en una aplicación de redes sociales y la aplicación muestra una pantalla de firma biométrica... ¡Terrible, ¿verdad?

Aplicaciones no financieras como aplicaciones sociales-Fi y juegos descentralizados necesitan una forma más fácil de realizar transacciones, idealmente sin requerir que los usuarios firmen cada transacción. ¿Cómo? Aquí está la respuesta:

1. Passkey + recuperación con timelock + claves de sesión - aplicación social móvil

Las claves de sesión permiten a los usuarios realizar transacciones sin una pantalla de firma. Los juegos o aplicaciones sociales basados en NFT pueden heredar claves de sesión para tener acceso temporal y limitado a los activos de los usuarios. Si piensa que esto añade una suposición de confianza adicional, vamos a explicar cómo funcionan los frontends de hoy en día:

Hoy en día, la mayoría de los usuarios ni siquiera revisan lo que están firmando cuando juegan un juego o interactúan con una dApp. Esto es peligroso porque un front-end malintencionado puede hacer que los usuarios pierdan todos sus activos.

Las claves de sesión son una mejor alternativa a esto. Los usuarios pueden verificar cuánto tiempo estará activa la sesión y a qué activos puede acceder la sesión, lo que reduce la necesidad de confiar en la dApp. Después de que expire el tiempo de la sesión, los usuarios no necesitan preocuparse por las aprobaciones = No más necesidad derevoke.cashMe gustan las aplicaciones :)

2. MPC o firmante basado en TEE en la nube + firmante auto custodial para escape

La desventaja de las capas de gestión de claves de terceros basadas en MPC o Cloud TEE es que la mayoría no son autosustentadas y tienen componentes centralizados significativos. Sin embargo, algunos dApps requieren billeteras integradas sin costos adicionales de gas, lo que hace necesarias soluciones basadas en MPC o Cloud TEE. Agregar un firmante adicional para hacer un "rage quit" puede resolver el problema de censura que tienen estos sistemas de gestión de claves y también mitigar posibles problemas legales que estos dApps puedan enfrentar. Necesitas una billetera inteligente para construir esto porque la rotación de claves no es posible con EOAs.

Ya hay varias aplicaciones que utilizan esta arquitectura de gestión de claves.

3. 12 palabras + Hardware Signer para maximizar la seguridad - Experiencia de la extensión del navegador para DeFi

A los usuarios de DeFi les encanta la experiencia de la extensión del navegador, y cambiar el comportamiento del usuario es una de las cosas más difíciles en el mundo moderno. Entonces, ¿por qué no construir una mejor alternativa? Combinar un firmante de hardware (Secure Enclave o Passkey Signer) con frases de semilla de 12 palabras accesibles a través de una extensión también podría resolver el problema de las claves privadas filtradas. Este enfoque mejora la seguridad sin necesidad de cambiar el comportamiento de los usuarios. Varios equipos en la industria AA están trabajando para habilitar esto. (por ejemplo. @myBraavos)

Las cuentas inteligentes no son lo suficientemente inteligentes

Imagina que eres un usuario que generó por primera vez un EOA con @MetaMasky luego descubrió una alternativa como Zerion. Tú decides usar @zerion, y todo lo que necesitas hacer es importar tu frase semilla, simple. Ahora, imagina tratar de hacer lo mismo en Starknet, donde todas las carteras son cuentas inteligentes. No puedes, porque Braavos y Argent no son compatibles. Este problema también existe en el ecosistema EIP-4337 y @zkSyncAA nativo de .

Necesitamos normas (no guardianes) o al menos una mejor manera de financiar nuevas carteras. De lo contrario, nunca habrá una adopción generalizada de carteras inteligentes, y los actores existentes seguirán siendo los que toman decisiones, dictando prácticas de la industria incluso si no son correctas.

Además, “rage quit” debería ser una característica predeterminada, ya que los actores centrales en casi todos los sistemas de gestión de claves pueden ser cerrados. Debería ser más fácil para los usuarios cambiar firmantes o cambiar contratos inteligentes, y el autohospedaje debería ser la opción predeterminada para los usuarios. Hay dos estándares de cuentas inteligentes modulares: ERC-6900 y ERC-7579. Ambos intentan lograr un objetivo similar: hacer que las cuentas inteligentes sean más inteligentes.

Un agradecimiento especial aDerek ,Konrad, yNoampara comentarios y opiniones!

Descargo de responsabilidad:

1. Este artículo es reimpreso de [BEYONDX]. Todos los derechos de autor pertenecen al autor original [2077Investigación]. Si hay objeciones a esta reimpresión, por favor póngase en contacto con el Gate Learnequipo, y lo resolverán rápidamente.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen asesoramiento de inversión.
3. El equipo de gate Learn tradujo el artículo a otros idiomas. Se prohíbe copiar, distribuir o plagiar los artículos traducidos a menos que se mencione.