← Todas las entradas

12 min de lectura

Por qué tus claves nunca salen del dispositivo

En CardanoWall, firmar, sellar y descifrar ocurren todos de forma local: el gateway publica pruebas y almacena texto cifrado, pero está diseñado para no recibir nunca tus claves privadas.

En CardanoWall, tus claves privadas se quedan en tu dispositivo. El software que firma, sella, hace descifrados de prueba y verifica se ejecuta de forma local; el gateway alojado está diseñado para no recibir nunca tu semilla de identidad, tu clave de firma, tus claves del destinatario ni el material que descifra un archivo sellado.

El gateway tiene mucho que hacer sin esos secretos. Puede calcular un presupuesto, aceptar para almacenarlo el texto que ya viene cifrado, enviar una transacción de Cardano, indexar registros y llevar la cuenta de tu saldo. Nada de eso requiere las claves que prueban la autoría o que abren una carga sellada. La división es deliberada: el servicio ayuda a mover la prueba, y tú conservas los secretos.

¿De qué claves estamos hablando?

Una identidad Label 309 parte de un único valor: una semilla de identidad de 32 bytes. A partir de esa semilla, cualquier software conforme deriva las claves que una identidad usa en la práctica, en tres roles:

  • una clave Ed25519 que firma registros;
  • una clave X25519 que recibe registros sellados de forma clásica;
  • una clave híbrida poscuántica que recibe registros sellados de forma poscuántica.

La derivación es determinista. Los mismos 32 bytes siempre producen los mismos tres pares de claves, en cualquier cliente conforme. Eso es lo que hace que la semilla sea portable, y lo que la convierte en lo único que merece la pena proteger. Quien tenga la semilla puede restaurar la identidad, firmar en su nombre y descifrar registros sellados dirigidos a ella. Por eso la semilla se mantiene privada, y todo lo demás se deduce de ahí.

¿Qué hace el cliente de forma local?

El cliente se encarga de toda operación que toca una clave privada:

  • generar o importar una semilla de identidad;
  • derivar de ella las claves de firma y de recepción;
  • firmar registros;
  • cifrar archivos antes de subirlos;
  • construir las ranuras de destinatario selladas que envuelven una clave de contenido;
  • hacer descifrados de prueba sobre los registros entrantes para encontrar los que van dirigidos a ti;
  • descifrar texto cifrado y recalcular el hash del texto plano;
  • verificar firmas y la estructura del registro.

La aplicación web, la aplicación de escritorio, la herramienta de línea de comandos y cualquier software construido sobre los SDK difieren en cómo almacenan las claves y cómo las desbloquean. El principio no cambia entre ellos: el material de clave privada no se envía al gateway.

¿Qué hace el gateway, entonces?

El gateway ejecuta el flujo de publicación. Puede:

  • calcular un presupuesto;
  • recibir el texto que ya viene cifrado y devolver una URI direccionada por contenido;
  • aceptar un registro de prueba ya preparado;
  • enviar una transacción de Cardano y esperar la confirmación;
  • gestionar reorganizaciones de la cadena y reembolsar automáticamente si una publicación falla de forma permanente;
  • indexar registros en un feed compartido;
  • llevar la cuenta del saldo de tu cuenta;
  • exponer su API y emitir eventos de ciclo de vida.

Son tareas reales, y constituyen la mayor parte del trabajo operativo. Pero ninguna de ellas necesita una clave que descifre tu contenido sellado. El gateway es una capa de transporte y de operaciones. No es tu bóveda de identidad, y no está diseñado para comportarse como si lo fuera.

¿Por qué importa esta separación?

Porque una prueba debería seguir siendo verificable sin confiar en el servicio que ayudó a crearla.

Si un servicio alojado tuviera la única copia de tus claves, ese servicio se convertiría en tu raíz de confianza. Si cerrara, cambiara sus condiciones, sufriera una brecha o bloqueara tu cuenta, tu capacidad de firmar, descifrar o incluso verificar podría depender de él. Esa es justamente la posición que Label 309 está diseñado para evitar.

Un registro Label 309 es verificable a partir de datos públicos. Un verificador solo necesita los metadatos de la transacción, opcionalmente los bytes del contenido y un explorador público de Cardano: ningún servidor del emisor en ningún paso. Un registro sellado lo puede abrir quien tenga la clave. Un registro firmado se puede comprobar contra su clave de firma. El gateway puede hacer que publicar sea mucho más fácil, pero, por diseño, no puede leer una carga correctamente sellada solo por haber ayudado a ponerla en la cadena.

Esa es la diferencia entre un servicio que te dice que tiene una prueba y una prueba que se sostiene por sí sola.

¿Puede el gateway leer mis archivos sellados?

Si el cliente selló el contenido correctamente, no: el gateway solo llega a ver texto cifrado.

Así se estructura un registro sellado. El registro público en la cadena se compromete con el hash del texto plano: ese hash, junto con el sello de tiempo del bloque, constituye la prueba del momento. La propia carga cifrada nunca va a la cadena; vive en una URI direccionada por contenido (como ar://). La clave de contenido se envuelve hacia una o varias claves públicas de destinatario, una ranura por destinatario. El destinatario (o el remitente) descarga el texto cifrado, lo descifra de forma local y recalcula el hash del texto plano para confirmar que coincide con el compromiso en la cadena.

El gateway puede ver que existe un registro sellado, y puede observar el tamaño del texto cifrado, el momento de la subida, la actividad de la cuenta, el estado de la transacción y los metadatos públicos. No está diseñado para ver el texto plano, y sin la clave privada correcta el texto cifrado permanece ilegible. Junto a eso conviene hacer dos salvedades honestas: el sellado protege la confidencialidad, no el anonimato —los metadatos observables siguen siendo metadatos—, y un destinatario que descifra un archivo siempre puede decidir filtrar el texto plano después. El cifrado protege los bytes en tránsito y en reposo, no lo que un lector autorizado haga a continuación.

¿Puede el gateway falsificar una prueba válida?

Está diseñado para no poder hacer que una prueba inválida pase una verificación independiente.

Un verificador comprueba el registro en la cadena, la estructura del registro, los hashes, las firmas y —para un registro sellado que pueda abrir— el hash del texto plano recalculado. Si un gateway mintiera sobre una transacción, alterara los bytes del registro, eliminara una firma o apuntara a unos bytes que no coinciden con el hash comprometido, un verificador independiente debería detectarlo.

Es una promesa precisa, y conviene no exagerarla. Un gateway sí puede portarse mal de las formas operativas habituales: puede no publicar, retrasar una transacción, devolver un error, informar mal de su propio estado, sufrir una caída o darte una mala experiencia. Lo que no debería poder hacer es convertir una prueba inválida en una que se verifique limpiamente contra datos públicos. La comodidad puede fallar; la afirmación criptográfica no depende de que el gateway sea honesto.

¿Y la aplicación web en concreto?

La aplicación web es software que se ejecuta en un navegador, y eso da forma a su modelo de confianza.

La frontera relevante incluye el navegador, el código de la aplicación que se carga, cualquier extensión instalada, el propio dispositivo y el flujo de desbloqueo. Un navegador es cómodo, pero no es el mismo entorno que una bóveda de escritorio o una herramienta de línea de comandos ejecutada desde una compilación que tú controlas. Un script malicioso en una sesión desbloqueada puede leer los secretos en memoria; una política de seguridad de contenido estricta, un mínimo de scripts y un paso de desbloqueo explícito reducen esa exposición, pero ninguna aplicación web puede afirmar que la elimina.

Esa es una de las razones por las que existe un cliente de escritorio dedicado, para quien quiera almacenamiento local y un control más estricto sobre cómo se guardan las claves. La invariante se mantiene en todos los clientes —el gateway no necesita tus claves privadas— aunque cada cliente proteja esas claves de forma distinta. Para una explicación más completa de dónde está la línea, consulta qué puede y qué no puede ver CardanoWall.

¿Y la aplicación de escritorio?

CardanoWall Desktop es una aplicación de código abierto y multiplataforma construida desde el principio en torno a una bóveda local cifrada.

Un núcleo en Rust posee la bóveda de identidad, la criptografía, el motor de sincronización, el descifrado de prueba y la verificación, con un webview que solo renderiza la interfaz. Las semillas y las claves privadas derivadas no se entregan al webview como cadenas de JavaScript corrientes; cuando hay que previsualizar contenido, los bytes descifrados se transmiten a la vista a través de un canal dedicado en lugar de pasar por la página como una cadena. Los secretos no se envían al gateway, y no cruzan al renderizador.

Esa arquitectura reduce la superficie de ataque; no la elimina. Un sistema operativo comprometido, una dependencia maliciosa, un keylogger o malware aprobado por el propio usuario pueden seguir venciendo la seguridad local: el mismo límite honesto que arrastra cualquier cartera de escritorio. Mantener las claves fuera del gateway y fuera del renderizador es una mejora real, no una garantía frente a un host totalmente comprometido. Para ver cómo funciona en detalle, consulta la introducción a CardanoWall Desktop y a las pruebas sin conexión.

¿Y la herramienta de línea de comandos y los SDK?

Importan porque ponen el mismo modelo a tu alcance sin pasar por el sitio web.

Una persona desarrolladora puede mantener una semilla de forma local, firmar registros de forma local, sellar archivos de forma local y enviar a través de cualquier gateway. Un sistema de integración continua puede publicar con credenciales de API acotadas mientras mantiene el material de identidad bajo los controles del propio equipo. Una empresa puede construir su propio cliente o integrar Label 309 en su software existente. La división se mantiene igual sin importar a qué interfaz recurras: el gateway publica, el cliente guarda los secretos.

La herramienta de línea de comandos y los SDK son de código abierto y agnósticos respecto al gateway, así que la frontera es algo que puedes inspeccionar en lugar de algo que tengas que dar por bueno por confianza.

¿Qué no debería enviarse nunca a un gateway?

Nunca envíes esto a un gateway —ni a ningún sitio web—:

  • tu semilla de identidad L309-SEED-1…;
  • la semilla en bruto en hexadecimal;
  • una clave privada de firma;
  • una clave privada de recepción X25519;
  • un secreto de recepción híbrido poscuántico;
  • una frase de contraseña que descifre contenido sellado;
  • texto plano que querías mantener en privado.

El gateway sí puede necesitar legítimamente claves públicas, firmas públicas, los bytes públicos del registro, texto cifrado, identificadores de presupuesto, tokens de API e identificadores de cuenta. Eso no es material de identidad privada. La regla es sencilla: si un flujo de trabajo te pide que pegues un secreto en algún sitio, detente y pregúntate por qué.

¿Qué sigue necesitando tu cuidado?

Las claves locales solo están tan seguras como el entorno que las rodea. La criptografía mantiene al gateway fuera de tus secretos; no puede proteger una semilla que un usuario copia en un formulario controlado por un atacante. Así que todavía tienes que:

  • proteger tu semilla de identidad y guardar una copia de seguridad real de ella;
  • verificar la dirección de recepción de un destinatario antes de sellar nada sensible;
  • evitar los sitios de phishing;
  • elegir con cuidado las extensiones del navegador;
  • mantener tus dispositivos actualizados;
  • usar cifrado de disco cuando encaje;
  • entender cómo se almacenan en caché los archivos descifrados;
  • ejecutar compilaciones de confianza de las herramientas de escritorio y de línea de comandos;
  • definir políticas de gestión de claves para los flujos compartidos o de equipo.

Conviene ser directo sobre los modos de fallo, porque no son simétricos. Pierde la semilla y tus factores de desbloqueo, y el uso futuro de esa identidad desaparece, aunque cualquier prueba que ya hayas publicado seguirá verificándose, para siempre, a partir de datos públicos. Una semilla robada es un compromiso total de la identidad: la respuesta es crear una nueva identidad y desactivar la antigua, no restablecer una contraseña. No hay restablecimiento; ese es el precio de que no haya custodio.

Por qué esto importa para un estándar abierto

Un estándar abierto de prueba no debería depender de un único operador de confianza.

Si CardanoWall desapareciera mañana, un registro Label 309 debería seguir teniendo sentido. Si una empresa ejecuta su propio gateway, sus registros deberían seguir siendo estándar. Si exportas tu semilla a otro cliente conforme, debería derivar exactamente las mismas claves. Eso solo funciona si la frontera se mantiene limpia: los registros son estándar, la verificación es independiente, los gateways son reemplazables, los clientes guardan los secretos y tú siempre puedes hacer una copia de seguridad de la raíz de la identidad por tu cuenta.

Así que «las claves nunca salen del dispositivo» no es un eslogan. Es parte de lo que hace que una prueba de existencia sea portable: una prueba que puedes llevar más allá de cualquier servicio aislado, incluido este.

La versión corta

El gateway ayuda a publicar la prueba. El cliente guarda los secretos.

Las claves privadas no se envían al gateway. El contenido se cifra antes de subirlo. El descifrado ocurre de forma local. La verificación no depende de fiarse de la palabra de un servicio. Esa es la forma de seguridad sobre la que se construye CardanoWall, y la forma que Label 309 está diseñado para mantener abierta.

Para seguir leyendo

securityidentitycardanowall