Infraestructura de wallet y modelo de seguridad
Contexto del sector
Los sistemas de wallet suelen depender de uno o más métodos criptográficos fundamentales para proteger las claves privadas. Comprender estos enfoques aporta contexto al modelo de seguridad descrito en este documento.
Shamir's Secret Sharing (SSS)
SSS divide una clave privada en varios shares, exigiendo un umbral mínimo para reconstruir el original. Ofrece secreto perfecto: cualquier número de shares por debajo del umbral no revela nada sobre la clave. SSS es maduro, está bien cubierto por herramientas y es rápido (firma en 20–40 ms). La contrapartida es que la clave privada debe reensamblarse por completo para firmar, lo que crea un único punto de fallo en el momento de la reconstitución.
Threshold Signature Schemes (TSS)
TSS (conocido habitualmente como MPC) permite que varias partes produzcan conjuntamente una firma sin volver a ensamblar nunca la clave privada. Ello elimina el riesgo de reconstitución de SSS. La contrapartida es la inmadurez — el primer protocolo ECDSA eficiente de dos partes apareció solo en 2017 — y el rendimiento: cada firma implica idas y vueltas por la red, introduciendo latencia que puede alcanzar varios segundos.
Trusted Execution Environments (TEE)
Los TEE ejecutan operaciones criptográficas dentro de enclaves de hardware, asegurando que el material de clave nunca se expone y que solo corre código autorizado. Los clientes pueden verificar las operaciones mediante atestaciones. Los TEE escalan bien y evitan la latencia de ida y vuelta de TSS, pero su seguridad depende de la integridad del enclave, que históricamente ha sido vulnerable a exploits de canal lateral.
WebAuthn PRF Extension
La extensión WebAuthn PRF (Pseudo-Random Function) deriva un secreto determinista del hardware de passkey del usuario — Secure Enclave en dispositivos Apple, TPM en Windows, Titan chip en Android. Ese secreto está ligado al dispositivo y a la biometría o al PIN del usuario, se calcula en el dispositivo durante la autenticación y nunca se transmite. Permite una clase de diseños de wallet en los que el material de clave puede cifrarse con un secreto que ningún servidor ha visto jamás.
Protección de clave en tres partes
Descripción general
Las claves privadas en este sistema nunca se almacenan completas — ni en los dispositivos del usuario, ni en nuestros servidores, en ningún sitio. En su lugar, el material de clave se divide criptográficamente entre tres partes independientes mediante un esquema de 3-of-3 secret sharing. Las tres partes deben cooperar para reconstruir una clave. Menos de tres revelan matemáticamente cero información sobre la clave privada.
Es un modelo híbrido: combina cifrado en el cliente basado en passkey (PRF-as-KEK), secret sharing y un enclave aislado en el servidor en una sola arquitectura. La construcción resultante alcanza la misma garantía de seguridad en el sentido de la teoría de la información que Shamir's Secret Sharing — ningún subconjunto de partes por debajo del umbral obtiene información sobre la clave — al tiempo que vincula un share al hardware físico del authenticator del usuario, de modo que ningún compromiso solo del lado del servidor puede reconstruir la clave.
Es el modelo de seguridad predeterminado para todos los dispositivos modernos (todos los navegadores principales en iOS, macOS, Android y Windows).
Las tres partes
Parte 1 — El authenticator del usuario
El hardware de passkey del usuario calcula un secreto determinista ligado a ese dispositivo y a la biometría o al PIN del usuario. Esta salida — llamada PRF output — se produce en el dispositivo durante la autenticación y nunca se transmite a ningún sitio. No se almacena. No se registra en logs. Solo existe en RAM durante la operación de firma.
Ese secreto es la aportación del usuario a la reconstrucción de la clave. Sin él, las otras dos partes no tienen nada con lo que producir una clave privada utilizable.
Parte 2 — La API
La API almacena una copia cifrada del material de clave del usuario. Está cifrada con el secreto derivado por PRF del usuario, que la API nunca ha visto. La API controla el acceso — solo liberará este payload cifrado a una petición que presente una assertion WebAuthn válida firmada con el passkey registrado del usuario. No puede, sin embargo, descifrar el payload por sí misma.
La API actúa como mecanismo de entrega autenticado, no como custodio de claves.
Parte 3 — La Crypto Enclave
Un sistema separado y aislado — que opera de forma independiente de la API con sus propias claves de cifrado e infraestructura — guarda el share de clave del lado del servidor. Ese share está cifrado en reposo con un secreto que solo conoce el enclave. El enclave libera el share descifrado solo después de que la petición haya pasado la validación de assertion, y solo para combinarse con el share del usuario en el paso final de firma.
El enclave nunca ve el PRF output del usuario, el share de clave del usuario ni la clave privada ensamblada.
Propiedades de seguridad
Sin punto único de fallo
| Escenario | Consecuencia |
|---|---|
| Dispositivo del usuario robado | El atacante no puede reproducir la biometría/el PIN; el PRF output no es obtenible |
| API completamente comprometida | El atacante solo obtiene ciphertext cifrado con un secreto que nunca ha visto |
| Enclave completamente comprometida | El atacante obtiene un share de la clave; el otro share no está en ninguno de los sistemas comprometidos |
| API y Enclave ambas comprometidas | El atacante obtiene el payload cifrado del usuario y el share del servidor — pero aún no puede descifrar el payload del usuario sin el PRF output del authenticator físico |
El último escenario es el crítico. Incluso un compromiso completo de toda la infraestructura del lado del servidor es insuficiente para reconstruir una clave privada. El authenticator del usuario es la puerta criptográfica que ninguna brecha del lado del servidor puede eludir.
Seguridad en el sentido de la teoría de la información
El modelo híbrido hereda la misma clase de garantía de seguridad que Shamir's Secret Sharing: la división de la clave no es solo computacionalmente segura — es segura en el sentido de la teoría de la información. Un atacante con potencia computacional ilimitada que posea el material de dos de las tres partes no obtiene información sobre la clave privada. No existe algoritmo, por mucho tiempo o hardware que se disponga, que derive la clave solo con los datos de dos partes. Es la misma garantía que proporciona un one-time pad.
Sin custodia por diseño
Operamos tanto la API como el enclave. A pesar de ello, no podemos acceder unilateralmente a los fondos del usuario. El PRF output del usuario es la pieza que falta — se produce dentro del hardware del usuario y nunca se transmite. Nuestra incapacidad de acceder a los fondos no es una política ni un compromiso en los términos del servicio. Es una restricción matemática que se mantiene con independencia de los controles de acceso internos, la presión regulatoria o el compromiso de la infraestructura.
Cómo se firma una transacción
Toda la firma ocurre en el dispositivo del usuario. La clave privada nunca se ensambla en ningún servidor.
- El usuario aprueba una transacción en la aplicación. El dispositivo autentica al usuario mediante biometría o PIN.
- El dispositivo calcula localmente su secreto PRF ligado al hardware. Ese secreto nunca sale del dispositivo.
- La aplicación obtiene el payload cifrado del usuario desde la API y el share del servidor desde el enclave. Ninguna de estas piezas es utilizable por sí sola.
- En el dispositivo del usuario, en RAM: el secreto de hardware descifra el payload del usuario y produce el share de clave del usuario. Los dos shares se combinan en la clave privada completa.
- La clave privada firma la transacción — enteramente en el dispositivo.
- La clave privada se borra de inmediato de la RAM. No se cachea, no se persiste, no se registra en logs.
La clave privada completa existe solo unos milisegundos, solo en el dispositivo del usuario y solo durante la operación de firma. Ningún servidor la ve jamás.
Exportación de la clave privada
Si un usuario elige exportar su clave privada — por ejemplo, para migrar a otro wallet — se aplica el mismo principio. La clave se reconstruye y se entrega por completo en el dispositivo del usuario. El servidor proporciona los shares cifrados, pero el descifrado y el ensamblaje ocurren localmente. En ningún momento de la exportación la clave privada atraviesa ni resulta visible para ningún servidor.
Sincronización de passkey y acceso entre dispositivos
Las plataformas modernas — iCloud Keychain en Apple, Google Password Manager en Android — sincronizan los passkeys entre los dispositivos del usuario. El secreto ligado al hardware usado para la reconstrucción de la clave forma parte del material de passkey sincronizado, de modo que el mismo PRF output es reproducible en cualquier dispositivo del grupo de sincronización del usuario. Así se preserva el modelo de seguridad de tres partes entre dispositivos: cualquier dispositivo sincronizado puede participar en la firma sin cambiar la arquitectura del lado del servidor.
Se informa a los usuarios si su passkey se ha sincronizado con su cuenta en la nube, para que siempre tengan visibilidad sobre la recuperabilidad de su wallet.
Hay soporte PRF en iOS 18+, macOS Sequoia 15.4+, Android 14+ y la serie YubiKey 5. En plataformas sin soporte PRF se usa un fallback de firma del lado del servidor.
Comparación con la seguridad convencional de wallets
| Modelo | Ubicación de la clave privada | Quién puede acceder a los fondos |
|---|---|---|
| Self-custody estándar (seed phrase) | Almacenada por el usuario | Cualquiera con la seed phrase |
| Custodia en exchange / hot wallet | Almacenada por el operador | El operador (y quien comprometa al operador) |
| Hardware wallet | Almacenada en el dispositivo | Cualquiera con dispositivo físico + PIN |
| Este sistema | Nunca almacenada completa | Requiere el authenticator en vivo del usuario y la infraestructura del servidor a la vez |
Resumen
Este modelo híbrido — que combina cifrado en el cliente basado en PRF, secret sharing y un enclave aislado — distribuye la confianza entre tres partes genuinamente independientes de modo que ningún subconjunto de dos puede reconstruir una clave privada, con la misma garantía de seguridad en el sentido de la teoría de la información que Shamir's Secret Sharing. El secreto de hardware ligado a la biometría del usuario es el ancla criptográfica de todo el sistema. La infraestructura del lado del servidor, por muy a fondo que esté comprometida, no puede producir una firma válida sin la participación física del usuario.