Qué significa zero-knowledge de verdad (y cómo detectar cuándo es solo marketing)

Zero-knowledge es una de las palabras más usadas y menos verificadas en seguridad de producto. Cualquier gestor de secretos, cualquier password manager, cualquier backend "seguro" puede escribirla en su landing. El problema es que muy pocos explican qué implica realmente en su arquitectura.

Si vas a confiar tus API keys, tokens de producción o credenciales de base de datos a un proveedor, merece la pena entender qué significa la etiqueta antes de comprarla.

Qué significa "zero-knowledge" en un sistema real

En criptografía aplicada, zero-knowledge (en este contexto, no la prueba de conocimiento cero académica) significa algo concreto: el proveedor del servicio no puede leer tus datos aunque quiera, aunque le hackeen, aunque reciba una orden judicial mal ejecutada, aunque un empleado malintencionado tenga acceso root a la base de datos.

Eso solo es cierto si se cumplen tres condiciones a la vez:

1. El cifrado ocurre en el cliente, antes de que el dato salga del dispositivo o del entorno del desarrollador.
2. El servidor nunca ve la clave de descifrado, solo texto cifrado (ciphertext) y metadatos operativos mínimos.
3. El descifrado solo es posible con una clave privada que nunca sale del dispositivo autorizado, ni siquiera en tránsito hacia el servidor.

Si falta cualquiera de las tres, no es zero-knowledge. Es "cifrado en tránsito y en reposo" — que está bien, es estándar, pero es una categoría distinta y mucho menos exigente.

Las preguntas que separan lo real del marketing

1. ¿Quién genera y guarda las claves?

Pregunta directamente: ¿las claves privadas se generan en el servidor en algún momento? ¿Se transmiten sin cifrar en algún paso del flujo, aunque sea "solo durante el registro"? Si la respuesta es sí a cualquiera de las dos, el proveedor técnicamente puede leer tus secretos, aunque diga que no lo hace.

2. ¿Qué pasa si el servidor se ve comprometido?

Un atacante con acceso total a la base de datos de un sistema zero-knowledge real solo se lleva ciphertext. Sin las claves privadas de los dispositivos autorizados, ese ciphertext es inútil. Pídele al proveedor que te describa ese escenario en detalle técnico, no en un eslogan.

3. ¿Cómo se verifica que el cliente que pide el secreto es legítimo?

El cifrado extremo a extremo protege el dato en tránsito y en reposo, pero no protege contra un cliente falso que se hace pasar por una app legítima. Aquí es donde entra la atestación de dispositivo: verificar criptográficamente, contra el hardware real (Apple App Attest, Google Play Integrity), que quien pide el secreto es la app auténtica corriendo en un dispositivo no manipulado — no un emulador, no un binario parcheado.

4. ¿Qué propiedades criptográficas tiene, exactamente?

"Cifrado extremo a extremo" no es una sola cosa. Hay diferencias enormes entre:

• Un envelope encryption con X25519 + AES-256-GCM (cifrado de clave pública para transportar la clave simétrica, luego AES-GCM para el dato).
• Un protocolo con forward secrecy tipo Signal, donde cada mensaje usa material de clave nuevo y comprometer una clave no compromete el historial.

Ambos son legítimos, pero resuelven problemas distintos. Un gestor de secretos no necesita las propiedades de un protocolo de mensajería efímera; necesita que el secreto esté cifrado en reposo y que solo lo descifre quien está autorizado en ese momento. Si un proveedor de gestión de secretos usa el lenguaje de "grado Signal" sin ratchet real, está vendiendo más de lo que tiene.

Cómo lo hace Koove (y dónde están sus límites)

En Koove usamos envelope encryption con X25519 para el intercambio de claves y AES-256-GCM para el contenido, con HKDF-SHA256 para derivar el material de clave. Las primitivas son de código abierto (@koove/crypto), así que no hay caja negra: puedes auditar exactamente qué hace encryptSecret, sealKey o computeAttestationBinding.

# El desarrollador (o su asistente de IA) guarda el secreto una sola vez
koove set STRIPE_SECRET_KEY sk_live_xxx --env prod

# El código solo referencia el nombre, nunca el valor
koove list --env prod

En el móvil, el secreto solo se descifra tras verificar biometría y atestación de dispositivo:

import { KooveClient } from '@koove/sdk';

const client = new KooveClient({ apiUrl, appId, appToken });
await client.init(); // atestación + registro del dispositivo

// decryptSecret solo se ejecuta tras autenticación biométrica
const value = await client.decryptSecret(envelope);

La atestación está verificada extremo a extremo contra hardware físico real en iPhone y Pixel — sin bypass de desarrollo, sin emuladores aceptados. El servidor de Koove solo almacena ciphertext: sin la clave privada del dispositivo autorizado, ese dato no significa nada.

Ahora los límites, dichos sin rodeos:

• No hay forward secrecy. No usamos un ratchet tipo Signal. Si la clave privada de un dispositivo se compromete, un atacante con esa clave puede descifrar los secretos a los que ese dispositivo tenía acceso. Para el caso de uso — gestión de secretos de aplicación, no mensajería — este es el modelo de amenaza correcto, pero no es lo mismo que forward secrecy real.
• No tenemos certificaciones SOC 2 ni ISO 27001 en este momento. La arquitectura zero-knowledge no depende de un sello de auditoría, pero si tu empresa necesita ese papel para compliance, hoy no lo tenemos.
• Puedes revisar la arquitectura completa y el modelo de confianza en /security.

Checklist rápida antes de creerte cualquier "zero-knowledge"

• ¿Las claves privadas se generan y quedan en el cliente, siempre?
• ¿El proveedor puede describir, en detalle técnico, qué se lleva un atacante si compromete su base de datos?
• ¿Cómo verifica que el cliente que pide el secreto es legítimo (atestación, no solo un token)?
• ¿Qué primitivas criptográficas usa exactamente, y son auditables?
• ¿Qué NO garantiza el sistema? (Si nadie te lo dice, pregúntalo.)

La documentación completa de la CLI y el SDK está en /docs/sdk, y las respuestas a las dudas más comunes sobre nuestro modelo de amenaza están en /faq.

Por qué esto importa más en la era del código generado por IA

Los asistentes de IA escriben código rápido, y muchas veces ese código incluye la clave hardcodeada porque es la ruta de menor resistencia. Un sistema zero-knowledge real, con el secreto fuera del repositorio desde el primer commit, es una de las pocas defensas que no depende de que el desarrollador (o su copiloto) se acuerde de hacerlo bien. Escribimos sobre esto con más detalle en /ai-security.

Si quieres probarlo con tus propios proyectos, puedes registrarte en /register y ver los planes disponibles en /plans.