Web3 se está expandiendo rápidamente: surgen nuevas aplicaciones, protocolos y características a diario. Sin embargo, para muchos usuarios, la verdadera barrera de entrada no es la falta de funcionalidad en la cadena (on-chain), sino el desafío de salvaguardar y recuperar de forma segura las claves de la billetera.
Actualmente, el estándar de la industria sigue siendo la frase semilla (mnemónica). Aun así, este enfoque presenta desafíos en el mundo real: los usuarios a menudo hacen capturas de pantalla de sus frases, sincronizándolas inadvertidamente con álbumes en la nube; otros las escriben en papel solo para perderlas o dañarlas, lo que resulta en la pérdida permanente de activos. Historias como estas son demasiado comunes. A menudo, estos riesgos no provienen de fallos técnicos, sino de lapsos en los hábitos diarios.
En los últimos años, ha surgido un número creciente de soluciones de billetera de estilo "Web2", que permiten a los usuarios crear, respaldar y recuperar billeteras utilizando métodos de inicio de sesión familiares. Si bien su objetivo es reducir la barrera de entrada, existen diferencias significativas en cómo se implementan, específicamente, si siguen siendo verdaderamente descentralizadas y de autocustodia.
El riesgo de fragmentación centralizada: Algunas soluciones dividen la clave privada en múltiples "partes" o "fragmentos" (shards). La división en sí misma no es el problema. El riesgo crítico surge si una única entidad participante (como el backend del proveedor de servicios) posee suficientes fragmentos para cumplir con el umbral de recuperación. Si lo hacen, técnicamente poseen la capacidad de reconstruir la clave completa, lo que convierte la "autocustodia" en una mera promesa nominal.
El riesgo de dependencias de Módulos de Seguridad de Hardware (HSM): Otras soluciones almacenan claves privadas dentro de Módulos de Seguridad de Hardware (HSM), afirmando que solo firmarán transacciones de acuerdo con reglas estrictas. Si bien esto parece sólido, si la aplicación de reglas o la ejecución de políticas ocurre fuera del límite de confianza (es decir, externo al HSM), puede, en escenarios extremos, omitirse o manipularse, lo que resulta en firmas que no reflejan la intención del usuario.
Cómo es diferente la billetera sin clave de OneKey
La billetera sin clave de OneKey utiliza un enfoque de "Inicio de sesión en Google/Apple + PIN", integrando la facilidad de uso con la verdadera autocustodia en un solo diseño.
Usted realiza el inicio de sesión y la recuperación utilizando sistemas de cuentas familiares, pero la arquitectura subyacente emplea un mecanismo distribuido de gestión y firma de claves. Esto asegura que ninguna parte única, incluida OneKey, pueda reconstruir su clave completa o iniciar transferencias unilateralmente.
En otras palabras: incluso si nuestros servidores, un componente específico o una única entidad participante se vieran comprometidos, un atacante no podría simplemente violar OneKey para "robar su billetera".
Solución de OneKey
La billetera sin clave de OneKey está construida sobre un mecanismo distribuido de gestión de claves. Su objetivo es liberarlo de la carga de alto riesgo de escribir, almacenar y transportar frases semilla. En su lugar, puede crear y recuperar su billetera utilizando un método que ya conoce: Inicio de sesión en Google / Apple + PIN.
Carga reducida, autocustodia sin compromisos
Las billeteras tradicionales dependen de frases semilla (típicamente 12 o 24 palabras), lo que requiere que los usuarios las almacenen de forma segura y las restablezcan manualmente cuando sea necesario. La billetera sin clave le permite administrar sus activos simplemente recordando un PIN. La capacidad de recuperar su billetera se basa en una arquitectura distribuida, asegurando que el control total nunca se entregue a ningún proveedor de servicios único.
Doble autenticación: Cuenta + PIN
La billetera sin clave utiliza dos factores de autenticación:
Su cuenta de Google / Apple
Su PIN
Esto significa que incluso si su cuenta de Google o Apple se ve comprometida, las operaciones críticas no se pueden realizar sin el PIN. A la inversa, tener solo el PIN es insuficiente para recuperar o acceder a la billetera sin iniciar sesión en la cuenta asociada. Ambos factores son indispensables, lo que reduce significativamente el riesgo de un único punto de fallo.
La frase semilla reaparece solo después de la verificación
En el diseño de la billetera sin clave, la frase semilla o clave privada completa nunca se almacena en texto plano en una sola ubicación durante períodos prolongados. Solo cuando verifica con éxito tanto su cuenta como su PIN en su dispositivo, la billetera completa los procesos necesarios de recuperación y activación localmente.
Cómo funciona la copia de seguridad y la recuperación:
Almacenamiento cifrado: Los datos relacionados con la frase semilla se almacenan en el servidor en forma cifrada para garantizar la disponibilidad (por ejemplo, para la recuperación entre dispositivos).
Mecanismo de fragmentación (Sharding): Los materiales críticos necesarios para el descifrado se dividen y distribuyen entre varias partes o nodos.
Por lo tanto, a menos que complete la verificación y active la recuperación en su dispositivo, ninguna parte única (incluida OneKey) puede reconstruirla unilateralmente en una clave utilizable en texto plano.
Inmersión técnica profunda
Esta sección explica lo que sucede tanto en el lado del cliente (su dispositivo) como en el lado del servidor cuando crea una nueva billetera sin clave usando Google o Apple. También aclara por qué los procesos de "Copia de seguridad" y "Recuperación" son fáciles de usar y al mismo tiempo garantizan que ninguna parte única pueda acceder jamás a su clave privada completa.
Copia de seguridad de una billetera sin clave
Al crear una billetera sin clave durante el proceso de incorporación (onboarding), puede:
Seleccionar "Continuar con Google" en la pantalla de inicio.
O tocar el botón "•••" → Billetera sin clave (Keyless Wallet) → Seleccionar Google o Apple.
Nota importante: La billetera sin clave y las billeteras tradicionales de frase semilla son dos sistemas distintos e independientes. Actualmente, no se admite la migración de una "billetera de frase semilla existente" a una billetera sin clave; existen en paralelo.
Repasemos el proceso técnico que ocurre cuando un usuario crea una billetera usando su cuenta de Google o Apple.
Paso 1: Generar, cifrar y almacenar el texto cifrado de la frase semilla en el dispositivo
Generación local: El dispositivo genera localmente una nueva frase semilla (que sirve como fuente aleatoria para el material clave de la billetera).
Creación de clave simétrica: El dispositivo genera simultáneamente una clave simétrica.
Cifrado: El dispositivo utiliza esta clave simétrica para cifrar la frase semilla, produciendo el texto cifrado de la frase semilla (Seed Ciphertext).
Almacenamiento seguro: Solo el texto cifrado de la frase semilla se transmite al backend de OneKey para su almacenamiento seguro (garantizando la disponibilidad para la recuperación entre dispositivos).
Puntos clave:
Procesamiento solo local: Tanto la frase semilla en texto plano como la clave simétrica se generan y procesan exclusivamente en el dispositivo. Nunca se transmiten directamente fuera del dispositivo.
Texto cifrado inutilizable: El texto cifrado en sí mismo no se puede utilizar para firmar. Sin la clave simétrica, es imposible descifrar el texto cifrado de nuevo a una frase semilla o material clave utilizable.
Paso 2: División de la clave simétrica en dos partes "2 de 2"
De vuelta en el dispositivo, la clave simétrica se divide en dos partes utilizando el Secreto de Shamir (SSS) con un umbral de 2 de 2:
Parte del backend (Backend Share): Mantenida por el backend de OneKey.
Parte de Juicebox (Juicebox Share): Almacenada dentro del protocolo de almacenamiento descentralizado, Juicebox.
Puntos clave:
Bajo un umbral de 2 de 2, ninguna parte única es suficiente para reconstruir la clave simétrica. Incluso si OneKey posee tanto el "Texto cifrado de la frase semilla" como la "Parte del backend", no puede recuperar unilateralmente la billetera ni iniciar una firma de transacción.
Paso 3: Escritura de la parte de la red en la red distribuida, protegida por PIN
La Parte de Juicebox se escribe en la red Juicebox.
El usuario establece un PIN, que sirve para proteger el acceso para recuperar esta parte de Juicebox.
Implementación técnica: La parte se divide aún más en múltiples subpartes (Sub-shares) y se distribuye entre diferentes nodos para su almacenamiento. Para recuperar la parte, se debe ingresar el PIN correcto para pasar la verificación del umbral de la red.
Recuperación de una billetera sin clave
Paso 1: Autenticación y recuperación del texto cifrado de la frase semilla + Parte del backend
El dispositivo realiza la autenticación utilizando su cuenta de Google / Apple.
Tras la verificación exitosa, el dispositivo recupera dos elementos de datos del backend de OneKey:
Texto cifrado de la frase semilla
Parte del backend
Paso 2: Ingresar el PIN para recuperar la parte de Juicebox
Usted ingresa su PIN en el dispositivo.
El dispositivo utiliza el PIN para recuperar la Parte de Juicebox del protocolo de almacenamiento distribuido de Juicebox.
Paso 3: Reconstrucción de la clave simétrica y descifrado
El dispositivo combina la Parte del backend + Parte de Juicebox para reconstruir la clave simétrica original.
Utiliza esta clave simétrica para descifrar el texto cifrado de la frase semilla, restaurando la frase semilla original localmente en el dispositivo.
Una vez completada la recuperación, la billetera funciona normalmente dentro de la aplicación OneKey, como una billetera estándar.
Análisis exhaustivo
Estado final (Distribución de datos)
Usuario: Tiene acceso a su cuenta de Google / Apple y recuerda el PIN.
Cliente OneKey (Dispositivo): Posee la frase semilla utilizable y descifrada (temporalmente para su uso).
Servidor OneKey: Almacena el Texto cifrado y la Parte del backend.
Reinos de Juicebox: Almacenan individualmente las Subpartes de Juicebox (necesarias para reconstruir la Parte de Juicebox).
Propiedades de seguridad
Compromiso de la base de datos del servidor OneKey: Incluso si un atacante obtiene acceso tanto al Texto cifrado como a la Parte del backend, no pueden reconstruir unilateralmente la clave simétrica. Por lo tanto, es imposible que descifren la frase semilla.
Compromiso de los Reinos/Nodos de Juicebox: Siempre que un atacante no obtenga un número suficiente de Subpartes de Juicebox (no cumpla con el umbral de recuperación), no puede restaurar la Parte de Juicebox y, por lo tanto, no puede ayudar a reconstruir la clave simétrica.
Compromiso de la cuenta: El acceso a la cuenta de Google o Apple por sí solo es insuficiente para recuperar las Subpartes de Juicebox del lado de Juicebox. El proceso de recuperación está estrictamente protegido por el PIN; sin el PIN, la cadena de recuperación no se puede completar.
Seguridad
El objetivo de diseño de la billetera sin clave de OneKey es minimizar la barrera de entrada sin centralizar el "control" en manos de ninguna parte única. Dado que la recuperación de la billetera es una de las operaciones más sensibles, colocamos los límites de seguridad y los modelos de amenazas del protocolo en el centro de nuestro diseño. Esto asegura que la mejora de la usabilidad no se produzca a expensas de la seguridad.
Objetivos de seguridad
Nuestra arquitectura está diseñada para cumplir los dos siguientes objetivos críticos:
Sin acceso unilateral: Ningún tercero (incluida OneKey) debe poder reconstruir o utilizar unilateralmente la clave privada o la frase semilla del usuario.
Condiciones de recuperación estrictas: La única forma en que un usuario puede recuperar su billetera es satisfaciendo simultáneamente dos requisitos de verificación:
Autenticándose con éxito a través de su cuenta de Google / Apple;
Y demostrando la posesión del PIN.
Por qué OneKey no puede reconstruir su clave (unilateralmente)
Para restaurar una frase semilla o material clave utilizable en su dispositivo, deben estar presentes todos los siguientes elementos simultáneamente:
El texto cifrado de la frase semilla
Ambas partes de la clave simétrica (Parte del backend + Parte de Juicebox)
Esta arquitectura conduce a varias conclusiones directas:
Actores maliciosos dentro de Juicebox: Si menos que el número umbral de Reinos/nodos de Juicebox actúan de manera maliciosa, el atacante no puede reconstruir una Parte de Juicebox válida y, por lo tanto, no puede reconstruir la clave simétrica.
Compromiso total de la red distribuida: Incluso en el escenario hipotético en el que toda la red de fragmentación distribuida se vea comprometida, al atacante aún le faltaría la Parte del backend o el Texto cifrado que posee el backend de OneKey, lo que hace imposible la recuperación independiente.
Compromiso del backend de OneKey: Incluso si se atacara el backend de OneKey, al atacante aún le faltaría la parte almacenada en el lado de Juicebox. Sin la Parte de Juicebox, los datos del backend por sí solos son insuficientes para reconstruir la clave simétrica o descifrar el texto cifrado de la frase semilla.
Por qué "Cuenta + PIN" son ambos indispensables
En cuanto al control de identidad y acceso, la billetera sin clave separa "Quién es usted" (Identidad de la cuenta) de "Lo que sabe" (PIN):
El lado de la cuenta: OneKey utiliza flujos establecidos de inicio de sesión/autorización OAuth 2.0 para interactuar con Google y Apple para la verificación de identidad y la autorización.
El lado del PIN: El PIN protege el proceso de recuperación de la parte crítica del protocolo de almacenamiento distribuido (Juicebox). Incluso si un atacante compromete su cuenta, no puede recuperar la parte correspondiente ni completar la recuperación sin conocer el PIN.
Cifrado y gestión de claves
En el nivel de cifrado y división de claves, la billetera sin clave se adhiere al principio de que "El texto cifrado se puede almacenar, pero las claves nunca deben centralizarse":
Cifrado de frase semilla: La frase semilla/material clave se cifra mediante algoritmos de cifrado autenticado (AES-256) para generar el texto cifrado, lo que garantiza la verificación de integridad durante la recuperación.
División y reconstrucción de claves: Se utiliza el Secreto de Shamir (SSS) para dividir y reconstruir la clave simétrica de acuerdo con las reglas de umbral.
Cifrado en reposo del backend: Las partes almacenadas en el backend se cifran primero utilizando Cloud KMS y algoritmos de cifrado antes del almacenamiento. Esto garantiza que nunca se vea texto plano durante todo el proceso, garantizando la seguridad de los datos clave.
Fiabilidad
Un punto crítico a entender sobre la billetera sin clave de OneKey es que la recuperación se basa en el cumplimiento de dos condiciones simultáneamente: debe poder iniciar sesión en la cuenta correspondiente de Google o Apple Y debe recordar su PIN.
A diferencia de los flujos tradicionales de "Olvidé mi contraseña" de Web2, OneKey no puede recuperar su PIN por usted, ni podemos reconstruir su clave privada o frase semilla en su nombre. Esto no es un defecto del producto, sino una parte deliberada del límite de seguridad: si un proveedor de servicios tuviera la capacidad de acceder a cualquiera de estos elementos, el atributo central de "autocustodia" se vería fundamentalmente comprometido.
Por lo tanto, una verdadera solución de "Confianza Cero" inevitablemente requiere que el usuario asuma una porción de la responsabilidad: mantener el acceso a su cuenta y recordar su PIN.
¿Qué pasa si olvido mi PIN?
Sin embargo, hay una red de seguridad: la frase semilla de una billetera sin clave existe en una forma utilizable en dispositivos donde ya ha iniciado sesión.
Si olvida su PIN pero aún tiene acceso a un dispositivo donde la billetera ha iniciado sesión y funciona, normalmente puede restablecer el PIN en ese dispositivo. Este proceso creará una nueva configuración de respaldo, asegurando que conserve la capacidad de recuperarse entre dispositivos en el futuro.
Recordatorios periódicos de verificación de PIN
Para mitigar el riesgo de olvidar su PIN con el tiempo, OneKey le pedirá que verifique su PIN en intervalos apropiados.
Si, durante una de estas comprobaciones, se da cuenta de que no puede recordar su PIN, debe aprovechar la oportunidad para restablecer su PIN inmediatamente mientras aún tiene acceso al dispositivo, y luego regenerar/actualizar su configuración de respaldo.
El límite definitivo de disponibilidad
En resumen, generalmente conservará el acceso a su billetera sin clave siempre que cumpla al menos una de las siguientes condiciones:
Todavía posee un dispositivo funcional con sesión iniciada; O
Puede iniciar sesión en su cuenta de Google / Apple Y recuerda su PIN (lo que le permite recuperarse en un nuevo dispositivo).
Nuestra recomendación: Realice un "Simulacro de recuperación entre dispositivos"
Dado que el proceso de recuperación es esencialmente "Iniciar sesión en la cuenta + Ingresar PIN", recomendamos encarecidamente que realice un simulacro de recuperación en un segundo dispositivo inmediatamente después de crear su billetera sin clave.
Al hacerlo, asegurará:
Un punto de acceso en el Dispositivo A.
Un punto de acceso en el Dispositivo B.
Confianza verificada en su ruta de respaldo (Cuenta + PIN) para futuras recuperaciones en nuevos dispositivos.
Conclusión
Para muchos usuarios nuevos, aunque las frases semilla son el estándar de la industria, usarlas a menudo está lejos de ser intuitivo. Ingresar una frase semilla en un nuevo dispositivo implica una fricción significativa, y saber cómo o dónde almacenarla de forma segura es una fuente frecuente de confusión.
La billetera sin clave de OneKey tiene como objetivo lograr un equilibrio diferente:
Reduce la barrera de entrada utilizando un método familiar (Google / Apple + PIN). Al mismo tiempo, a través de una arquitectura distribuida de gestión de claves, garantiza que ninguna parte única (incluida OneKey) pueda reconstruir unilateralmente su clave completa. Esto logra un compromiso entre la "facilidad de uso" y los "límites de la seguridad de autocustodia" que es muy adecuado para el público en general.