Qué es la attestation móvil y por qué es el eslabón que faltaba

Qué es la attestation móvil

La attestation móvil es una prueba criptográfica de que una petición a tu backend —o una solicitud para descifrar un secreto— viene realmente de una instancia genuina y sin modificar de tu app, ejecutándose en hardware real. No en un emulador, no en un dispositivo con root, no en un script haciéndose pasar por tu app.

Apple lo llama App Attest. Google lo llama Play Integrity. Ambos funcionan de forma parecida: el sistema operativo y un enclave seguro respaldado por hardware generan un par de claves ligado a esa instalación concreta, y cada solicitud de attestation produce una declaración firmada que el fabricante puede verificar como generada por hardware real ejecutando tu binario real.

Por qué esto importa para secretos, no solo para logins

La mayoría de sistemas de autenticación responden a una pregunta: ¿tiene este usuario credenciales válidas? Eso te dice quién pregunta. No te dice desde dónde llega la petición, ni si el cliente que la ejecuta es realmente el que tú construiste.

Si tu app móvil necesita descifrar una API key, una credencial de base de datos o un token OAuth en el propio dispositivo, las credenciales solas no bastan. Un token de sesión robado, un APK reempaquetado o un script que ataca directamente tu API pueden suplantar una sesión legítima sin tocar nunca tu binario real.

Ese es exactamente el hueco que cierra la attestation móvil: verifica el cliente, no solo al usuario.

Cómo la usa Koove

Koove es un gestor de secretos zero-knowledge: los secretos se cifran en el cliente con cifrado por sobre X25519 + AES-256-GCM (HKDF-SHA256 para derivar claves), y el servidor solo almacena texto cifrado. Nunca ve el secreto en claro, y tampoco puede descifrarlo.

Eso significa que la clave privada que abre un secreto tiene que vivir en algún sitio — y ese sitio es el dispositivo. La attestation es lo que permite a Koove confiar en ese dispositivo antes de entregarle el material de claves.

En concreto:

• En móvil, el paquete @koove/sdk se encarga de esto por ti. Inicializas un cliente y init() ejecuta la attestation y registra el dispositivo:

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

const client = new KooveClient({
  apiUrl: 'https://api.koove.io',
  appId: 'app_xxxxxx',
  appToken: 'tok_xxxxxx',
});

await client.init(); // hace attestation + registra el dispositivo
const secret = await client.decryptSecret(envelope); // requiere biometría

• init() ejecuta App Attest en iOS o Play Integrity en Android por debajo. Solo cuando esa attestation tiene éxito, el dispositivo se añade como destinatario válido de secretos cifrados.
• decryptSecret() exige además biometría: la attestation demuestra que la instancia de la app es genuina, la biometría demuestra que la persona que la sostiene está autorizada.

Desde el 14 de julio de 2026 en iPhone y el 17 de julio de 2026 en Pixel, esta attestation se verifica de extremo a extremo sobre hardware físico en ambas plataformas. No existe un modo de bypass para desarrollo — no puedes saltarte la attestation en producción para facilitar las pruebas, y es intencionado. Un atajo "solo para dev" es exactamente el tipo de agujero que acaba llegando a producción por accidente.

De dónde vienen realmente los secretos

En la práctica, la mayoría de equipos gestiona esta asimetría con @koove/secrets-cli:

koove set STRIPE_SECRET_KEY sk_live_xxx --env prod
koove set DATABASE_URL postgres://... --env prod
koove list --env prod

Tu código nunca ve el valor real en el momento de escribirlo — tú o tu asistente de IA lo guardáis una vez vía CLI, y el código de la aplicación solo lo referencia por nombre. Esto importa cada vez más: las herramientas de programación asistida por IA pegan credenciales reales en commits, logs de chat y ficheros .env generados constantemente, porque no saben que esa cadena es un secreto. Lo tratamos con más detalle en nuestro artículo sobre seguridad en la era de la IA.

Cuando un cliente móvil necesita ese secreto, no le está pidiendo al servidor "envíame STRIPE_SECRET_KEY". Está presentando una identidad atestiguada, descifrando un sobre cifrado que ya tiene (o que se le acaba de entregar, todavía cifrado), y solo entonces expone el valor en claro en la memoria de tu app, detrás de biometría.

Gestionar dispositivos

La attestation ocurre por instalación, así que el ciclo de vida del dispositivo importa. La CLI te da visibilidad y control:

koove devices --env prod
koove device-approve <device-id>
koove device-revoke <device-id>
koove rewrap --env prod

device-revoke elimina un dispositivo como destinatario válido a partir de ese momento. rewrap vuelve a cifrar los secretos para el conjunto actual de destinatarios aprobados. Hay que ser precisos con lo que esto hace y lo que no: revocar un dispositivo impide que descifre peticiones futuras y sobres reempaquetados — no puede, y no puede, "deshacer" la entrega de un valor que un dispositivo comprometido ya descifró y leyó antes de la revocación. Ningún sistema de secretos, incluido Koove, puede afirmar lo contrario; si un secreto quedó expuesto, hay que rotarlo.

Lo que la attestation no resuelve

Ser claros con los límites es parte de generar confianza aquí:

• La attestation no protege frente a un sistema operativo totalmente comprometido o un exploit a nivel de kernel que, de alguna forma, siga pasando la verificación — eleva mucho el listón, pero no hace que una app sea "inhackeable".
• El esquema de cifrado de Koove no tiene forward secrecy (no hay ratchet estilo Signal). Es cifrado por sobre con envoltura de clave por destinatario, no un protocolo de mensajería, y no decimos lo contrario.
• La attestation confirma la instancia de la app y, con biometría, a la persona — no sustituye a la política de control de acceso. Sigues siendo tú quien decide quién accede a qué entorno.

El eslabón que faltaba

El cifrado solo protege los datos en tránsito y en reposo. El control de acceso solo protege quién puede preguntar. La attestation móvil es lo que conecta ambas cosas con lo que realmente se está ejecutando — la pieza que la mayoría de herramientas de gestión de secretos se salta, porque construirla es genuinamente más difícil que hacer un formulario de login.

Si quieres ver la arquitectura completa —cómo encajan la envoltura de claves, la recuperación y el binding de attestation—, está documentada en nuestra página de seguridad y confianza. Los precios para equipos que necesitan esto en móvil están en /plans, y puedes resolver dudas concretas en /faq.

Pruébalo

Si tu app descifra secretos en un teléfono —para un proxy de backend, una herramienta interna, o un cliente que habla directamente con APIs de terceros—, la attestation no es un endurecimiento opcional, es la base. Crea una cuenta en Koove e integra @koove/sdk en una tarde; solo por koove set ya merece la pena.