Por qué el cifrado de modelos en el dispositivo no puede sustituir la autorización de API

Descomposición de aplicaciones móviles de IA en siete clases de activos

La seguridad de la IA móvil a menudo se simplifica excesivamente a si el modelo está cifrado. En realidad, la superficie de ataque incluye al menos archivos de modelo, entornos de ejecución de inferencia, preprocesamiento de entrada, postprocesamiento de salida, prompts o reglas de negocio, credenciales de API remotas, datos de usuario y registros. Cada clase de activo conlleva diferentes consecuencias ante una filtración, mecanismos de actualización distintos y responsabilidades de propiedad separadas.

Copiar los pesos del modelo puede conducir al robo de propiedad intelectual y pérdida de capacidad comercial; modificar plantillas de prompts o lógica de postprocesamiento puede alterar el comportamiento del negocio; filtrar claves de API de larga duración puede resultar directamente en pérdidas financieras, acceso no autorizado a datos o abuso de recursos; los registros de entrada/salida pueden contener datos de privacidad del usuario. Proteger solo el archivo del modelo no cubre estos riesgos restantes.

Un registro de activos debe documentar la ubicación de almacenamiento, fuente de generación, ruta de transmisión, patrones de uso en tiempo de ejecución, mecanismos de actualización y reversión, principios de mínimo privilegio, alcance de registros y períodos de retención. Los activos sin un ciclo de vida definido no deben considerarse protegidos simplemente por activar un interruptor de cifrado.

Los archivos de modelo deben convertirse en material utilizable durante la ejecución

Ya sea que se utilice Core ML, LiteRT u otros entornos de ejecución en el dispositivo, los modelos deben cargarse, analizarse y participar en el cómputo. El cifrado a nivel de archivo reduce la facilidad de copiar directamente desde los paquetes de instalación o directorios de la aplicación, pero no puede impedir que la aplicación en ejecución acceda a los materiales del modelo. Si un atacante controla el proceso u observa el entorno de ejecución, el riesgo del modelo cambia de archivos estáticos a la carga, la memoria, las invocaciones de funciones y las salidas.

Esto no implica que el cifrado de modelos carezca de valor. Aumenta el costo de la copia de bajo esfuerzo, previene la sustitución directa y forma parte de una estrategia de defensa en profundidad junto con la protección del paquete, las verificaciones de integridad, la detección del entorno de ejecución y el emparejamiento de versiones. La clave es presentar el beneficio como un aumento del costo para el atacante y una reducción de la superficie de exposición, en lugar de afirmar que la extracción es imposible.

Las actualizaciones de modelos también introducen desafíos de compatibilidad. Las versiones del modelo deben emparejarse con la lógica de preprocesamiento, las formas de las características, las versiones del entorno de ejecución, las capacidades del hardware y las reglas de posprocesamiento. Los fallos en la actualización requieren retrocesos seguros para evitar combinaciones aleatorias de modelos antiguos y lógica nueva.

Las Claves API de Larga Duración y Alto Privilegio No Deben Ser Secretos del Cliente

La documentación de seguridad de Android establece explícitamente que las claves API incrustadas en el código fuente pueden descubrirse mediante descompilación después de compilar la aplicación. La ofuscación y el endurecimiento de aplicaciones pueden aumentar el costo de localizarlas, pero no pueden cambiar el hecho de que el cliente debe poseer y usar estas credenciales. Mientras una clave permanezca vigente por mucho tiempo y con altos privilegios dentro de un cliente genérico, el impacto de una filtración es difícil de contener.

Android Keystore puede mantener ciertos materiales de clave no exportables, pero la documentación oficial aclara que si el proceso de la aplicación se ve comprometido, los atacantes aún podrían usar las claves de la app para realizar operaciones. Es adecuado para proteger claves privadas vinculadas al dispositivo y cifrado local, pero no debe interpretarse erróneamente como una bóveda segura para secretos compartidos arbitrarios de larga duración destinados a servicios remotos.

Una arquitectura más robusta requiere que el cliente solicite tokens de corta duración, restringidos y revocables a su propio servicio basándose en la identidad del usuario y el contexto del dispositivo, o que un proxy del lado del servidor maneje las invocaciones de modelos de alto riesgo. El servidor debe hacer cumplir la autorización de cuenta, cuotas, limitación de tasa, alcance del modelo, alcance de datos y monitoreo de comportamiento anómalo.

• Aislar credenciales por entornos de desarrollo, pruebas y producción
• Garantizar que los tokens posean permisos mínimos de modelo y datos
• Habilitar la revocación del lado del servidor y hacer cumplir cuotas y límites de tasa
• Evitar que los clientes almacenen claves compartidas de alta privilegiada y larga duración

request = verify_user_session(input.session)
app = verify_app_evidence(input.attestation)
policy = load_policy(user=request.user, app=app.identity)

if policy.version_state == UNKNOWN:
    return CHALLENGE_OR_LIMIT
if policy.account_scope.allows(input.model_scope) == false:
    return DENY
if policy.risk_score >= HIGH:
    return STEP_UP_VERIFICATION

return issue_short_lived_token(
    scope=input.model_scope,
    quota=policy.quota,
    expires_in=policy.short_window
)

Las Señales de Integridad Solo Deben Informar Decisiones del Lado del Servidor

Play Integrity proporciona a los backends de Android señales sobre identificación de aplicaciones, integridad del dispositivo, licencias de cuenta y riesgos parciales del entorno. Apple App Attest ayuda al servidor a determinar si una solicitud proviene de una instancia válida de la aplicación mediante la generación de claves de dispositivo, emisión de desafíos únicos, verificación de la atestación en el servidor y procesamiento de aserciones posteriores. El punto en común es que la evidencia se valida finalmente en el servidor.

Estos mecanismos tienen límites claros. Las señales relacionadas con Play están influenciadas por las fuentes de distribución, el estado del dispositivo y las condiciones del servicio; la documentación de Apple señala que App Attest no es compatible con todos los tipos de dispositivo y que ninguna política única elimina todo el fraude. El servidor debe distinguir entre estados de aprobado, fallido, no disponible, errores transitorios y estados no configurados. No debe equiparar "no disponible" directamente con un ataque, ni realizar juicios finales localmente en el cliente.

Las señales de integridad y el cifrado de modelos abordan problemas diferentes. El primero ayuda a verificar instancias de aplicaciones y entornos de ejecución, mientras que el segundo reduce la exposición estática del modelo. La autorización real aún requiere contexto de cuenta, verificaciones de recursos comerciales, validación de versiones, análisis del contenido de la solicitud, aplicación de cuotas y contexto comportamental.

La validación de aplicaciones móviles de IA requiere vistas estáticas, de tiempo de ejecución y del lado del servidor

Las comprobaciones estáticas responden qué modelos, configuraciones, cadenas, credenciales y recursos de depuración existen en el paquete de instalación; las comprobaciones de tiempo de ejecución responden cómo se cargan los modelos, cómo se gestionan los fallos, si los registros filtran datos y si las actualizaciones pueden revertirse; las comprobaciones del lado del servidor responden si se aplican realmente la cuenta, la versión, la integridad, la cuota y los permisos de datos. Omitir cualquiera de estos tres tipos de evidencia sesga las conclusiones hacia visiones parciales.

Las pruebas deben utilizar candidatos a lanzamiento únicos y versiones explícitas de modelos, documentando sistemas objetivo, capacidades del dispositivo, backends de tiempo de ejecución, fuentes del modelo y estados de actualización. El rendimiento de inferencia on-device, el uso de memoria y la compatibilidad dependen de la estructura del modelo, la cuantización, el hardware y el tiempo de ejecución; no se pueden citar cifras de otros modelos o dispositivos.

Las rutas de excepción son críticas: archivos de modelo faltantes o corruptos, actualizaciones interrumpidas, tiempos de ejecución no compatibles, tokens de servidor expirados, señales de integridad no disponibles, cargas de registros fallidas y permisos de usuario revocados. El sistema debe degradarse de forma segura, proporcionando estados recuperables tanto para los usuarios como para los equipos de operaciones.

Conclusiones de diseño y limitaciones de alcance

El cifrado del modelo es valioso, pero representa solo un punto de control dentro del ciclo de vida del modelo. Las aplicaciones de IA comerciales también deben proteger la lógica de pre/postprocesamiento, evitar que claves de alto privilegio de larga duración lleguen al cliente, garantizar que el servidor realice la autorización final, implementar tolerancia a fallos para las señales de integridad de la plataforma y gobernar los datos y registros de usuario.

Sin candidatos a lanzamiento reales, versiones de modelos, dispositivos objetivo e interfaces del lado del servidor, solo podemos revisar la arquitectura y los elementos pendientes de validación. No podemos afirmar que los modelos sean a prueba de extracción, que las interfaces sean a prueba de abuso, que se bloquee la inyección en tiempo de ejecución o que se cumplan los objetivos de rendimiento. Cualquier conclusión de este tipo requiere paquetes de evidencia actuales.

El punto de entrada de acción de Yudun en esta página sirve para solicitar el endurecimiento de aplicaciones y la evaluación de compatibilidad; no representa la validación de ningún framework de modelo específico ni capacidad exclusiva de IA. El alcance del proyecto debe confirmarse por separado tras enviar la pila tecnológica, el método de entrega del modelo y las rutas críticas del negocio.

• Mantener registros separados para modelos, entornos de ejecución, credenciales y datos
• Garantizar que las invocaciones de alto riesgo sean autorizadas finalmente por el servidor
• Proporcionar rutas de indisponibilidad y degradación para las señales de plataforma
• Habilitar actualizaciones de modelos que admitan verificación, conmutación atómica y reversión
• Vincular todas las conclusiones a candidatos a lanzamiento y versiones de modelo específicos