💻 computer science

WebAuthn PRF-Based Vault Key Wrapping and Zero-Knowledge PWA Storage Architecture

Este artículo presenta una arquitectura de seguridad del lado del cliente para bóvedas de credenciales basadas en la web que logra propiedades sólidas de conocimiento cero mediante la combinación de la extensión PRF de WebAuthn con criptografía simétrica y patrones de almacenamiento optimizados en el navegador.

Autores originales: Ian Pinto

Publicado 2026-07-08✓ Author reviewed ⓘ

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Ian Pinto

Artículo original bajo licencia CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que tienes una caja fuerte digital (una "bóveda") donde guardas tus secretos más importantes, como contraseñas o notas privadas. Normalmente, para abrir esta caja fuerte, necesitas una llave maestra (una contraseña). Pero, ¿qué pasaría si pudieras abrirla usando tu rostro, tu huella digital o una llave de seguridad física? Y, ¿qué pasaría si, incluso si un hacker robara una copia del contenido de tu caja fuerte, todavía no pudiera leer ni una sola palabra sin tu clave biométrica específica?

Este artículo de Ian Pinto describe una nueva forma de construir ese tipo de caja fuerte digital ultra segura para los navegadores web. Combina algunos conceptos de alta tecnología en un sistema que mantiene tus datos en "conocimiento cero" (zero-knowledge)—lo que significa que el servidor o el sistema de almacenamiento no sabe nada sobre lo que hay dentro, ni siquiera la clave para abrirlo.

Así es como funciona, desglosado en partes sencillas:

1. La Llave Mágica: WebAuthn PRF

Piensa en tu passkey (la que usas para iniciar sesión con tu rostro o huella digital) no solo como un portero de "Sí/No", sino como un generador de recetas secretas.

La forma antigua: Demuestras que eres tú, y el sistema dice "Acceso Concedido".
La nueva forma (PRF): Cuando demuestras que eres tú, tu dispositivo ejecuta secretamente una compleja receta matemática (llamada Función Pseudoaleatoria o PRF) utilizando una "sal" especial (un ingrediente aleatorio). Esta receta produce una "salsa secreta" única y de alta calidad (un código de 32 bytes) que solo tu dispositivo específico sabe cómo fabricar.
El truco: Esta salsa secreta se crea dentro del chip seguro de tu dispositivo. Nunca sale del dispositivo y nunca se guarda en el disco duro. Existe por una fracción de segundo, lo suficiente para desbloquear tu caja fuerte, y luego se borra inmediatamente.

2. El Candado: Envolver la Llave de la Bóveda

Tu bóveda tiene una llave maestra (llamémosla Llave K) que realmente bloquea los datos.

El sistema toma esa fugaz "salsa secreta" de tu passkey y la utiliza para envolver la Llave K en un sobre digital (encriptación).
Una vez envuelta, la Llave K queda encerrada dentro de este sobre. El sistema guarda este sobre en el almacenamiento de tu navegador (IndexedDB).
Punto crucial: El sistema nunca guarda la salsa secreta ni la Llave K sin envolver. Solo guarda el sobre cerrado. Si un hacker roba el almacenamiento, solo tiene una caja cerrada y sin llave.

3. La Casa de Seguridad: Almacenamiento IndexedDB

El artículo propone una forma específica de organizar estos datos en el almacenamiento del navegador (IndexedDB), que es como un archivador digital.

El sistema de archivos: El sistema crea tres carpetas específicas:
1. Las Bóvedas (The Vaults): Donde viven los sobres cerrados (las llaves envueltas).
2. Las Credenciales (The Credentials): Una lista de tus passkeys y sus "números de serie" (para asegurar que nadie esté usando una copia falsa de tu llave).
3. Los Metadatos (The Meta): Notas generales para la aplicación.
Garantía de Conocimiento Cero: El artículo argumenta que, debido a que el almacenamiento solo contiene los sobres cerrados y los metadatos públicos, un ladrón que robe todo el archivador no puede reconstruir la llave. Se quedará atrapado con la caja cerrada y sin forma de abrirla sin tu dispositivo físico.

4. El Plan de Respaldo: El "Fallback de Contraseña"

¿Qué pasa si tu navegador no admite esta sofisticada función de "salsa secreta" (como en algunas tabletas Android)?

El sistema tiene un plan de respaldo llamado pw-v1. En lugar de usar la salsa secreta de la passkey, utiliza un rompecabezas matemático muy lento y pesado (scrypt) basado en una contraseña tradicional que tú escribes.
Esto es más lento y menos conveniente, pero asegura que aún puedas abrir tu caja fuerte incluso si la función de hardware avanzado no está disponible. Es como tener una cerradura de llave física junto al escáner biométrico.

5. Verificaciones de Seguridad: Detener Ataques de Replay

El artículo enfatiza un "control de replay" (repetición).

Imagina que un ladrón graba tu señal de "desbloqueo" e intenta reproducirla más tarde para abrir la caja fuerte.
El sistema mantiene un contador (como un odómetro en un coche). Cada vez que desbloqueas la caja fuerte, el contador sube. Si el sistema ve una señal con un número de contador antiguo, sabe que es una grabación y la rechaza.
Nota: El artículo admite que esto no es perfecto para todos los dispositivos (algunas passkeys sincronizadas no actualizan el contador), pero añade una capa de defensa.

6. Lo que este artículo NO hace

El autor es muy cuidadoso al decir contra qué no protege este sistema:

No protege contra un virus en tu computadora. Si un hacker ya está dentro de tu navegador observándote escribir, pueden robar la llave mientras se está usando. Este sistema solo protege los datos en reposo (cuando están guardados en el almacenamiento).
No protege contra filtraciones de "canal lateral" (side-channel). Si la aplicación comprime los datos antes de bloquearlos, o si el tamaño de la caja cerrada cambia según la longitud de tu contraseña, un hacker astuto podría adivinar qué hay dentro simplemente midiendo el tamaño de la caja. El artículo advierte a los desarrolladores que rellenen sus datos (hacer que todas las cajas tengan el mismo tamaño) para evitar esto.

Resumen

Este artículo presenta un plano para una bóveda de contraseñas basada en la web que es matemáticamente probada como ilegible para cualquiera que no tenga tu passkey física específica. Utiliza tu passkey para generar un código temporal de un solo uso que bloquea tus datos, asegura que ese código nunca se guarde, y organiza el almacenamiento de modo que incluso un robo total de la base de datos no arroje más que cajas cerradas. Es un sistema de "Conocimiento Cero" donde el proveedor de almacenamiento (o un hacker) no sabe nada sobre tus secretos.

Resumen Técnico: Arquitectura de Almacenamiento de PWA con Almacenamiento de Conocimiento Cero y Envoltura de Clave de Bóveda Basada en PRF de WebAuthn

Planteamiento del Problema
El documento aborda el desafío de implementar una seguridad robusta de conocimiento cero para las bóvedas de credenciales dentro de las Aplicaciones Web Progresivas (PWA). Si bien WebAuthn y las llaves de paso (passkeys) proporcionan una fuerte autenticación de clave pública, tradicionalmente no exponen un secreto simétrico de alta entropía a la aplicación web para cifrar los datos del usuario. Las soluciones existentes suelen depender de la confianza del servidor o de contraseñas maestras, las cuales pueden ser vulnerables a ataques fuera de línea o requieren modelos de confianza complejos. El problema específico es cómo derivar de forma segura una clave de cifrado simétrico a partir de una credencial de llave de paso utilizando la extensión PRF (Función Pseudoaleatoria) de WebAuthn, envolver una clave de bóveda y almacenar el estado resultante en el almacenamiento del navegador (IndexedDB de tal manera que los datos persistidos no revelen nada sobre los secretos del usuario sin una ceremonia de autenticación activa en el autenticador.

Metodología
La arquitectura propuesta combina la extensión WebAuthn PRF con criptografía simétrica y un esquema de almacenamiento en IndexedDB rigurosamente diseñado.

Esquema de Envoltura de Claves (Key Wrapping):
- Inscripción: Durante la inscripción, la aplicación solicita una salida PRF de 32 bytes al autenticador utilizando un salt único y aleatorio de 32 bytes. Esta salida sirve como el Material de Clave de Entrada (IKM) para HKDF-SHA256.
- Derivación: El HKDF utiliza una etiqueta de separación de dominio congelada y versionada ("webauthn-prf-zktv vault key wrap v1") y un salt vacío para derivar una clave de envoltura $K_w$ de AES-256-GCM no extraíble.
- Cifrado: La clave de la bóveda ( $K_v$ ) se cifra utilizando $K_w$ y un nonce fresco de 96 bits.
- Almacenamiento: Solo se persiste el WrappedSecretRecord resultante. Este registro contiene el identificador del esquema (prf-v1), el texto cifrado, el nonce y el salt del PRF. Crucialmente, la salida del PRF y la clave de envoltura derivada nunca se almacenan; se eliminan de la memoria inmediatamente después de su uso.
- Alternativa (Fallback): Para clientes donde PRF no está disponible (por ejemplo, Android WebView), se proporciona un esquema pw-v1. Este utiliza una derivación scrypt de alto costo (con parámetros de costo elevados fijos) a partir de una contraseña de usuario en lugar del PRF, manteniendo la misma estructura de registro.
Desenvoltura y Verificación:
- Protección contra Replay: El proceso de desenvoltura incluye un paso obligatorio de verificación de replay. La aplicación reevalúa el PRF con el salt almacenado y verifica los datos del cliente (desafío, origen) y el contador de firma. El contador debe ser estrictamente creciente (a menos que sea cero, un comportamiento conocido de las llaves de paso sincronizadas) para prevenir ataques de replay.
- Gestión de Errores: El sistema está diseñado para ser genérico en sus modos de fallo. Los fallos de descifrado (debido a una clave incorrecta o manipulación) lanzan un DecryptError genérico que no distingue entre una clave errónea y datos corruptos, evitando la filtración por canales laterales.
Arquitectura de Almacenamiento (IndexedDB):
- La librería (webauthn-prf-zktv) define un esquema con tres almacenes de objetos: vaults, credentials y meta.
- El almacén vaults utiliza una clave primaria compuesta [vaultId, scheme], lo que permite que una sola bóveda contenga simultáneamente un registro prf-v1 y un registro de respaldo pw-v1.
- El almacén credentials contiene metadatos no secretos, incluyendo el último contador de firma verificado y el salt del PRF, pero nunca las claves secretas mismas.
- El esquema impone invariantes estructurales (por ejemplo, longitud del nonce, tamaño del salt) en cada carga para asegurar la integridad de los datos.

Contribuciones Clave
El documento formaliza y proporciona una implementación de código abierto de:

Un Esquema de Envoltura de Clave de Bóveda Basado en PRF: Un método para utilizar la salida del PRF de WebAuthn como raíz de confianza para derivar una clave de envoltura simétrica, utilizando HKDF con estricta separación de dominios.
Un Esquema de IndexedDB de Conocimiento Cero: Un patrón de almacenamiento donde el estado persistido no contiene entradas de clave recomputables. La seguridad de los datos almacenados depende enteramente del secreto de la clave interna del autenticador.
La Librería webauthn-prf-zktv: Una librería de TypeScript tipada y reutilizable que encapsula la lógica criptográfica, la gestión de almacenamiento y las rutas de migración (incluyendo un adaptador de un solo paso para registros heredados de TrustVault-PWA).
Verificación de Replay en el Cliente: La integración de verificaciones de contador de firma y de desafío/origen directamente en el algoritmo de desbloqueo de la bóveda, una característica que suele omitirse en las librerías auxiliares genéricas de PRF.

Resultados y Evaluación
El documento evalúa la arquitectura a través de tres ejes:

Seguridad: El argumento de conocimiento cero postula que sin el autenticador, el texto cifrado almacenado es computacionalmente inútil. El esquema depende de la pseudoaleatoriedad del PRF del autenticador, la seguridad de HKDF-SHA256 y la seguridad IND-CPA/INT-CTXT de AES-256-GCM. El documento señala que, si bien la capa simétrica es adecuada para la era post-cuántica (AES-256), la capa de autenticación asimétrica sigue siendo vulnerable a ataques cuánticos, aunque esto no compromete la confidencialidad de la clave de la bóveda almacenada.
Rendimiento: La latencia de desbloqueo está dominada por el gesto de verificación del usuario requerido por el autenticador. Las operaciones criptográficas (derivación HKDF y descifrado AES-GCM de un payload de 32 bytes) son insignificantes. El fallback de contraseña (scrypt) es intencionadamente costoso para disuadir ataques fuera de línea, aunque esto puede causar latencia en dispositivos móviles de gama baja.
Usabilidad y Robustez: El sistema soporta la degradación elegante mediante el fallback pw-v1 para clientes no compatibles. Emplea un enfoque de "mejor esfuerzo" para la detección de credenciales clonadas (manejando el caso límite del contador cero de las llaves de paso sincronizadas) y asegura que los fallos parciales (por ejemplo, caídas durante las actualizaciones del contador) no bloqueen permanentemente al usuario, priorizando la disponibilidad sobre la protección estricta contra replay en casos críticos.

Significancia y Reivindicaciones
El documento afirma proporcionar un patrón formalizado y listo para producción para lograr el almacenamiento de conocimiento cero en aplicaciones web utilizando tecnología moderna de llaves de paso. Su significancia radica en:

Eliminación de la Confianza en el Servidor: Desplaza el límite de confidencialidad enteramente al cliente, asegurando que incluso si el servidor o una copia de seguridad sincronizada se ven comprometidos, los secretos del usuario permanecen seguros siempre que el autenticador no esté comprometido.
Estandarización de Patrones: Al definir un formato v1 congelado y etiquetas específicas de separación de dominios, evita la invalidación silenciosa de los registros debido a cambios en los algoritmos y proporciona un camino claro de migración para futuras versiones (por ejemplo, prf-v2).
Seguridad Holística: Aborda explícitamente los vectores de filtración no criptográficos (como la compresión previa al cifrado y la correlación del tamaño del registro) en la guía de la capa de aplicación, reconociendo que la capa de almacenamiento por sí sola no puede garantizar el conocimiento cero si la aplicación filtra metadatos.

El autor enfatiza que la librería es una herramienta para que los desarrolladores adopten estos patrones sin tener que volver a derivar la compleja higiene de claves y la disciplina de almacenamiento requerida para las bóvedas seguras en el lado del cliente.