Zero-knowledge que puedes auditar, no solo creer

Qué significa (y qué NO significa) zero-knowledge

Zero-knowledge significa que EL SERVICIO no puede leer tus secretos: cada secreto se cifra en tu máquina o dispositivo antes de salir de él, y el servidor solo ve sobres cifrados.

No significa que nadie pueda leerlos: tú (con tu identidad controladora), tus dispositivos verificados y quien posea tu código de recuperación sí pueden. La promesa se hace contra Koove — y por eso es verificable en el código abierto, no un acto de fe.

Cómo se cifra cada secreto

Envelope encryption con primitivas modernas y auditadas (@noble): cada secreto se cifra una sola vez con una clave de datos (DEK) aleatoria usando AES-256-GCM; esa DEK se sella para cada destinatario autorizado con su clave pública X25519 (ECDH + HKDF-SHA256).

El servidor almacena el ciphertext y las DEKs selladas. Autorizar un dispositivo, revocarlo o rotar claves es siempre un re-sellado (re-wrap) que ejecuta un cliente autorizado — nunca el servidor, que no posee claves privadas.

Las primitivas son código abierto en @koove/crypto: los tests fijan el layout criptográfico contra vectores independientes.

Solo descifran dispositivos verificados

Un dispositivo móvil solo se convierte en destinatario elegible tras superar attestation criptográfica real: Apple App Attest y Google Play Integrity — ambos verificados extremo a extremo en dispositivo físico. El servidor verifica la cadena de certificados contra la raíz de Apple/Google y liga la prueba a la clave pública del dispositivo.

El descifrado local está además protegido por biometría (Face ID / huella). Y el binding challenge→clave se computa con una única implementación compartida por iOS, Android y servidor — no puede divergir.

Recuperación y revocación — con su límite honesto

Cada app tiene dos destinatarios permanentes: una identidad controladora (tu tooling, nunca en nuestro servidor) para aprobar dispositivos y ejecutar el kill criptográfico, y una identidad de recuperación derivada de un código BIP39 de 24 palabras que se muestra UNA vez y jamás se almacena.

Revocar un dispositivo lo saca inmediatamente del descubrimiento (no recibe secretos nuevos ni se le sirven) y el kill criptográfico lo elimina de todos los sobres existentes.

El límite honesto: ningún sistema puede "des-entregar" un plaintext que un dispositivo ya descifró y cacheó. Para un kill total, rota el valor del secreto. Lo decimos aquí, en la CLI y en la documentación — desconfía de quien te prometa revocación instantánea.

Defensa en profundidad en el servidor

El cliente nunca es de confianza: attestation, biometría y pinning suben el coste del ataque, pero el control real vive en el servidor, donde un cliente comprometido no puede falsearlo.

Detección de anomalías sobre el audit trail (IPs nuevas, velocidad de lectura, attestations fallidas repetidas), canary honeytokens (leer un señuelo = brecha confirmada, alerta inmediata), rate-limiting compartido fail-closed y registro de auditoría exportable.

Open-core: la prueba de la promesa

Todo lo que corre en TU lado es código abierto y auditable: las primitivas de cifrado (@koove/crypto), el escritor CLI (@koove/secrets-cli) y el SDK móvil (@koove/sdk), publicados en npm y GitHub.

Lo cerrado es nuestro plano de control (verificación de attestation, motor de anomalías, dashboard) — que por diseño nunca ve un secreto en claro.

Evidencia que puedes verificar hoy mismo (no nos creas)

Origen del código: los paquetes en npm llevan atestación de procedencia SLSA — se publican por OIDC desde GitHub Actions, sin tokens. Compruébalo: `npm view @koove/crypto dist.attestations`.

Sin scripts de instalación: nuestros paquetes no ejecutan ningún script al instalarse (`preinstall`/`postinstall`) — superficie de supply-chain cero, alineado con el nuevo comportamiento por defecto de npm.

Attestation iOS verificada en dispositivo físico (App Attest real, cadena de certificados contra la raíz de Apple pineada, sin dev-bypass); attestation Android también verificada en hardware físico (Play Integrity real, veredicto MEETS_DEVICE_INTEGRITY, sin dev-bypass). Documentamos también el caso negativo: un dispositivo no destinatario NO puede descifrar.

Divulgación responsable: publicamos un /.well-known/security.txt y una política VDP con puerto seguro.

Threat model público: documentamos qué garantizamos, cómo, y qué NO — en github.com/kooveio/koove-crypto (SECURITY-MODEL.md).

Compliance: dónde estamos hoy (roadmap honesto)

Honestidad primero: hoy Koove NO cuenta con certificación SOC 2 ni ISO 27001. Lo que ofrecemos hoy es más fuerte que un sello: una arquitectura donde el proveedor no puede leer tus datos, con el código del cliente abierto para que tu equipo lo verifique.

Roadmap fechado: auditoría criptográfica independiente de @koove/crypto (objetivo H2 2026, publicaremos el informe completo) → certificación organizacional (ISO 27001 / SOC 2) cuando un contrato la exija. Actualizaremos esta página en cada hito.

Pagos vía Stripe (PCI-DSS nivel 1); Koove nunca ve tu tarjeta. Somos una empresa de la UE: mantenemos lista de subprocesadores y DPA disponibles.