Dónde guarda CardanoWall tus claves en el navegador

Cuando desbloqueas CardanoWall en el navegador, la semilla desbloqueada y las claves privadas derivadas de ella viven en la memoria de sesión — memoria de aplicación corriente que desaparece cuando bloqueas, cierras sesión o cierras la pestaña. El almacenamiento persistente del navegador (IndexedDB, sessionStorage) solo conserva el texto cifrado de la bóveda y metadatos no secretos. Las semillas de identidad y las claves privadas derivadas en texto plano nunca se escriben ahí.

Esa distinción es lo que importa de verdad. El navegador tiene que manejar material de claves para firmar y descifrar localmente — así es como funciona la criptografía, sin más. La pregunta de seguridad nunca es «¿puede el navegador tocar las claves?». Tiene que hacerlo. La pregunta es dónde viven esas claves y qué se escribe en disco. El modelo web de CardanoWall está construido para que lo que sobrevive a una recarga sea texto cifrado, no secretos.

¿Qué necesita el navegador mientras una identidad está desbloqueada?

Necesita el material de clave privada para el trabajo que estás haciendo de verdad — y nada más duradero que la propia sesión.

Después de desbloquear una identidad, la app puede necesitar:

• firmar un registro Label 309;
• descifrar un registro sellado dirigido a ti;
• hacer un descifrado de prueba de los registros sellados entrantes para encontrar los destinados a tu bandeja de entrada;
• volver a cifrar la bóveda después de que añadas o quites un passkey;
• revelar tu semilla cuando pides verla de forma explícita;
• reconstruir las cachés locales cifradas.

Nada de eso es posible solo con las claves públicas. Cada operación necesita material privado derivado de tu semilla de identidad. El diseño mantiene ese material en la memoria de sesión y lo borra al bloquear o cerrar sesión — en la medida de lo posible, por razones que veremos más abajo.

¿Qué es aquí la memoria de sesión?

La memoria de sesión es memoria de aplicación temporal, dentro del proceso, que la app descarta cuando termina la sesión de desbloqueo.

En la app web de CardanoWall, la semilla viva y las claves derivadas de ella se mantienen fuera del estado normal de la interfaz, en mapas de memoria internos. El estado reactivo de la interfaz solo guarda datos no secretos: qué identidad está desbloqueada, cuándo se desbloqueó, qué metadatos de registro de passkeys aparecen en pantalla durante la configuración. Los bytes secretos nunca entran en ese estado reactivo.

Esta separación importa porque el estado normal de la interfaz es la parte de una app con más probabilidad de ser inspeccionada, serializada, persistida o pasada por accidente a un componente que la registre en un log. El material secreto merece una superficie más pequeña y enumerada de forma deliberada. Cada punto de la app capaz de entregar bytes secretos — la clausura de firma, las claves de descifrado, la vía de escape para revelar la semilla, la ruta de reconstrucción de la bóveda — está listado en un único archivo, y cada uno devuelve una copia defensiva en lugar del búfer vivo.

El navegador sigue manejando los secretos mientras estás desbloqueado. Sencillamente, no se tratan como datos normales de la app.

¿Qué se escribe en IndexedDB?

El texto cifrado de la bóveda — los mismos bytes que almacena el servidor, no las semillas que contienen.

IndexedDB se usa como caché local de tu bóveda de identidad cifrada: una fila por cuenta, que contiene exactamente el texto cifrado con age que guarda el servidor. Almacenarlo en caché permite que la app se rehidrate tras una recarga con un solo toque del passkey, sin una ida y vuelta para volver a recuperar la bóveda.

Un atacante que solo lea esa base de datos local ve bytes de bóveda cifrados dirigidos a tus passkeys — no semillas en texto plano. La caché sigue siendo dato de servicio sensible, y la app la borra al cerrar sesión, al eliminar la cuenta y al cambiar los passkeys. Pero no es la identidad en sí; es una caja cerrada cuyas únicas llaves viven dentro de tus autenticadores. (Para ver cómo se sella esa caja, consulta cómo CardanoWall almacena tu identidad y cómo los passkeys protegen tu bóveda de identidad.)

Estas escrituras se suprimen por completo en el modo de ordenador público y cuando eliges no recordar el dispositivo.

¿Qué va en sessionStorage?

Solo metadatos de registro no secretos — nunca material de claves.

Durante la creación de una identidad, la app replica los metadatos de registro del passkey en sessionStorage para que una recarga accidental a medio configurar no borre el estado visible. Esos metadatos son no secretos por construcción: identificadores de credencial, claves públicas, transportes, indicadores de tipo de dispositivo y de copia de seguridad, y datos similares de los que un atacante no saca nada.

Lo que se deja explícitamente fuera de sessionStorage:

• semillas de identidad;
• claves privadas derivadas;
• salidas de la PRF (función pseudoaleatoria) de WebAuthn — los secretos que un passkey devuelve para desbloquear la bóveda;
• el texto plano de la bóveda;
• el contenido sellado descifrado.

La línea es sencilla. La continuidad de la interfaz puede persistir a través de una recarga; los secretos de la identidad no deberían.

¿Qué no debe estar nunca en el almacenamiento del navegador?

El material de identidad en texto plano — en ningún almacén.

Esto se mantiene fuera de localStorage, sessionStorage, IndexedDB, las cookies, los logs y el estado normal de la app:

• la semilla de identidad;
• las claves privadas de firma Ed25519;
• las claves privadas de recepción X25519;
• los secretos de recepción híbridos poscuánticos (la semilla detrás de la dirección opcional age1pqc...);
• las salidas de la PRF de WebAuthn;
• el texto plano de la bóveda;
• el contenido sellado descifrado, salvo que lo guardes de forma explícita en una caché local cifrada con un control claro sobre él.

El razonamiento es el mismo que recorre todo el diseño: cuantos más lugares se escribe un secreto, más difícil resulta razonar sobre su borrado y mayor es la superficie que un compromiso puede leer.

¿Qué es el modo de ordenador público?

Es el modo explícito de dispositivo compartido: mientras está activo, no se escribe en el almacenamiento del navegador absolutamente nada relacionado con la identidad.

Actívalo y la app se salta todas las vías de persistencia relacionadas con la identidad — sin bóveda de PIN, sin caché de bóveda en IndexedDB, sin fijación de versión, sin réplica de registro en sessionStorage. Las claves desbloqueadas viven solo en la memoria de sesión: sobreviven a la navegación dentro de la app en esa pestaña, pero mueren al cerrarla o recargarla. El propio interruptor es solo de memoria a propósito: persistir «estoy en un ordenador público» sería en sí mismo una escritura en el almacenamiento del navegador, y una máquina compartida siempre debería reabrirse en el valor por defecto seguro de volver a preguntar. Úsalo en el ordenador de una biblioteca, un portátil prestado, una máquina de una conferencia, un quiosco de una redacción — cualquier cosa que no controles.

Lo que no hace es volver seguro un dispositivo en el que no confías. Si la máquina ya está comprometida mientras escribes una semilla o desbloqueas una identidad, todavía puede observar secretos en memoria. El modo reduce lo que queda después de que te vayas; no derrota al malware local activo. El modo de ordenador público cubre el flujo de trabajo completo.

¿Qué significa la zeroización en JavaScript?

Significa sobrescribir los arreglos de bytes secretos — rellenarlos con ceros — en cuanto la app termina de usarlos.

CardanoWall zeroiza sus búferes de clave Uint8Array cuando una identidad se bloquea o cierras sesión, en lugar de esperar y confiar en que el recolector de basura los recupere. Es buena higiene y vale la pena hacerlo.

Pero JavaScript no es un entorno endurecido para manejar secretos, y es honesto decirlo. Las cadenas son inmutables, así que un secreto que alguna vez se convirtió en cadena no puede borrarse en su sitio. El momento de la recolección de basura no está bajo el control de la app. Los motores pueden copiar memoria internamente. Las herramientas de desarrollo, las extensiones y un origen comprometido cambian por completo el modelo de riesgo.

Así que aquí la zeroización es una medida en la medida de lo posible, no un borrado garantizado. Reduce de forma significativa la ventana en la que una copia perdida persiste; no promete que los bytes hayan desaparecido en todas partes.

¿Y si la página se compromete mientras está desbloqueada?

Entonces la identidad corre un riesgo real — este es el límite más difícil de toda criptografía basada en el navegador.

Una extensión del navegador maliciosa con acceso al contenido de la página, un dispositivo comprometido o un fallo grave de cross-site scripting (XSS) que se ejecute durante una sesión desbloqueada podría leer secretos de la memoria, o hacer que la app firme o descifre cosas que no querías. Ninguna app web puede eliminar esto del todo: el código que llega por la red y luego maneja claves queda expuesto a cualquier otra cosa que se ejecute en ese mismo origen.

CardanoWall se apoya en la defensa en profundidad para reducir la ventana: una Content Security Policy estricta que confina los scripts al propio origen de la app — sin scripts en línea, sin eval y sin cargar ningún script de terceros — más cabeceras de seguridad estampadas en cada respuesta en el borde, una superficie de secretos deliberadamente pequeña, ninguna persistencia en texto plano, y desbloqueo y descifrado solo por acción explícita del usuario — nunca de forma automática al enfocar la pestaña. Estas medidas reducen las probabilidades y el radio de impacto. No vuelven inofensivo a un script malicioso dentro de un origen desbloqueado; esa sigue siendo la amenaza de mayor impacto que el modelo del navegador acepta.

Para tus identidades más sensibles, la respuesta correcta es sacar el material de claves de la superficie web compartida. Mantenlas en un dispositivo dedicado y de confianza, y prefiere un flujo de trabajo en el que el secreto nunca toque un navegador — la CLI en la automatización o CardanoWall Desktop, que mantiene tus claves en un núcleo local de Rust en lugar de en un origen web. (Para el principio más amplio, consulta por qué las claves nunca salen del dispositivo.)

¿Qué deberías hacer en la práctica?

Usa el modelo del navegador de forma deliberada, y ajusta las precauciones a la sensibilidad del trabajo.

Para el uso diario:

• guarda tu semilla de identidad en un lugar seguro — es la copia de seguridad de verdad;
• añade un passkey para el desbloqueo diario;
• bloquea o cierra sesión cuando termines;
• usa «recordar este dispositivo» solo en máquinas en las que confías;
• mantén tu navegador y tu sistema operativo actualizados;
• evita las extensiones del navegador de alto riesgo;
• activa el modo de ordenador público en cualquier dispositivo compartido.

Para el trabajo sensible, añade:

• un perfil de navegador dedicado o, mejor, un dispositivo dedicado;
• nada de desbloquear en máquinas prestadas;
• una llave de seguridad por hardware como factor de desbloqueo;
• separación entre las identidades de alto riesgo y las corrientes;
• cuidado con los registros sellados — un destinatario que puede descifrar también puede filtrar el texto plano después.

La versión corta

La app web de CardanoWall necesita claves privadas mientras una identidad está desbloqueada, así que las mantiene en la memoria de sesión en lugar de en el almacenamiento persistente. IndexedDB solo guarda en caché el texto cifrado de la bóveda; sessionStorage solo conserva metadatos de configuración no secretos. La semilla de identidad y las claves privadas nunca se escriben como datos normales del navegador.

El modelo de bóveda alojada y el modelo de almacenamiento del navegador se refuerzan mutuamente: el servidor guarda un texto cifrado que no puede descifrar, y el navegador se esfuerza por no dejar atrás la semilla. Ninguna de las dos afirmaciones es una garantía frente a un dispositivo que ya está comprometido — y ser claros sobre ese límite es parte de tomárselo en serio. Para el panorama completo de lo que el servicio puede y no puede observar, consulta qué puede ver CardanoWall.