Pourquoi le chiffrement des modèles sur l'appareil ne peut pas remplacer l'autorisation API

Déconstruction des applications mobiles d'IA en sept classes d'actifs

La sécurité des applications mobiles d'IA est souvent simplifiée à outrance en se demandant si le modèle est chiffré. En réalité, la surface d'attaque inclut au moins les fichiers de modèle, les environnements d'exécution d'inférence, le prétraitement des entrées, le post-traitement des sorties, les prompts ou règles métier, les identifiants API distants, les données utilisateur et les journaux. Chaque classe d'actifs entraîne des conséquences différentes en cas de fuite, dispose de mécanismes de mise à jour distincts et relève de responsabilités de propriété séparées.

La copie des poids du modèle peut entraîner un vol de propriété intellectuelle et une perte de capacité métier ; la modification des modèles de prompt ou de la logique de post-traitement peut altérer le comportement métier ; la fuite de clés API de longue durée peut directement provoquer des pertes financières, un accès non autorisé aux données ou un abus de ressources ; les journaux d'entrée/sortie peuvent contenir des données privées utilisateurs. Protéger uniquement le fichier de modèle ne couvre pas ces risques restants.

Un registre d'actifs doit documenter l'emplacement de stockage, la source de génération, le chemin de transmission, les modèles d'utilisation en exécution, les mécanismes de mise à jour et de retour arrière, les principes du moindre privilège, la portée de la journalisation et les périodes de rétention. Les actifs sans cycle de vie défini ne doivent pas être considérés comme protégés par la simple activation d'un interrupteur de chiffrement.

Les fichiers de modèle doivent devenir du matériel utilisable durant l'exécution

Qu'il s'agisse de Core ML, LiteRT ou d'autres moteurs d'exécution sur l'appareil, les modèles doivent être chargés, analysés et utilisés pour le calcul. Le chiffrement au niveau fichier réduit la facilité de copie directe depuis les packages d'installation ou les répertoires de l'application, mais il ne peut empêcher l'application en cours d'exécution d'accéder aux ressources du modèle. Si un attaquant contrôle le processus ou observe le moteur d'exécution, le risque se déplace des fichiers statiques vers le chargement, la mémoire, les invocations de fonctions et les sorties.

Cela n'implique pas que le chiffrement des modèles soit inutile. Il augmente le coût des copies à faible effort, empêche la substitution directe et constitue une composante d'une stratégie de défense en profondeur, aux côtés de la protection du package, des vérifications d'intégrité, de la détection de l'environnement d'exécution et de l'appariement des versions. L'essentiel est de présenter l'avantage comme une augmentation du coût pour l'attaquant et une réduction de la surface d'exposition, plutôt que de prétendre que l'extraction est impossible.

Les mises à jour de modèles introduisent également des défis de compatibilité. Les versions de modèles doivent être appariées avec la logique de prétraitement, les formes des fonctionnalités, les versions du moteur d'exécution, les capacités matérielles et les règles de post-traitement. Les échecs de mise à jour nécessitent des retours arrière sécurisés pour éviter les combinaisons aléatoires d'anciens modèles et de nouvelle logique.

Les clés API à longue durée de vie et à privilèges élevés ne doivent pas être des secrets côté client

La documentation de sécurité Android indique explicitement que les clés API intégrées dans le code source peuvent être découvertes via la décompilation après la compilation de l'application. L'obfuscation et le durcissement d'application (application hardening) peuvent augmenter le coût de leur localisation, mais ils ne changent pas le fait que le client doit détenir et utiliser ces identifiants. Tant qu'une clé reste à longue durée de vie et hautement privilégiée au sein d'un client générique, l'impact d'une fuite est difficile à limiter.

Android Keystore peut rendre certains matériaux de clés non exportables, mais la documentation officielle précise que si le processus de l'application est compromis, les attaquants peuvent toujours utiliser les clés de l'application pour effectuer des opérations. Il convient à la protection des clés privées liées à l'appareil et au chiffrement local, mais ne doit pas être interprété à tort comme un coffre-fort sécurisé pour des secrets partagés arbitraires à longue durée de vie destinés à des services distants.

Une architecture plus robuste exige que le client demande à son propre service des jetons à courte durée de vie, restreints et révocables, basés sur l'identité de l'utilisateur et le contexte de l'appareil, ou que le serveur mandataire gère les invocations de modèles à haut risque. Le serveur doit appliquer l'autorisation de compte, les quotas, la limitation de débit, la portée du modèle, la portée des données et la surveillance des comportements anormaux.

• Isoler les identifiants par environnements de développement, de test et de production
• S'assurer que les jetons possèdent des permissions minimales sur le modèle et les données
• Activer la révocation côté serveur et appliquer les quotas et les limites de débit
• Empêcher les clients de stocker des clés partagées à longue durée de vie et à privilèges élevés

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
)

Les signaux d'intégrité doivent uniquement éclairer les décisions côté serveur

Play Integrity fournit aux backends Android des signaux concernant l'identification de l'application, l'intégrité de l'appareil, la licence du compte et les risques environnementaux partiels. Apple App Attest aide le serveur à déterminer si une requête provient d'une instance d'application valide en générant des clés d'appareil, en émettant des défis uniques, en vérifiant l'attestation côté serveur et en traitant les assertions ultérieures. Le point commun est que la preuve est finalement validée par le serveur.

Ces mécanismes ont des limites claires. Les signaux liés à Play sont influencés par les sources de distribution, l'état de l'appareil et les conditions de service ; la documentation d'Apple indique qu'App Attest n'est pas pris en charge sur tous les types d'appareils et qu'aucune politique unique n'élimine toute fraude. Le serveur doit distinguer les états de réussite, d'échec, d'indisponibilité, d'erreurs transitoires et de non-configuration. Il ne doit pas assimiler directement « indisponible » à une attaque, ni effectuer de jugements finaux localement sur le client.

Les signaux d'intégrité et le chiffrement des modèles répondent à des problèmes différents. Les premiers aident à vérifier les instances d'application et les environnements d'exécution, tandis que le second réduit l'exposition statique des modèles. Une autorisation réelle nécessite toujours un contexte de compte, des vérifications des ressources métier, une validation de version, une analyse du contenu de la requête, une application des quotas et un contexte comportemental.

La validation des applications IA mobiles nécessite des vues statiques, d'exécution et côté serveur

Les contrôles statiques déterminent quels modèles, configurations, chaînes, identifiants et ressources de débogage existent dans le paquet d'installation ; les contrôles d'exécution déterminent comment les modèles sont chargés, comment les échecs sont gérés, si les journaux fuient des données et si les mises à jour peuvent être annulées ; les contrôles côté serveur déterminent si le compte, la version, l'intégrité, les quotas et les permissions de données sont réellement appliqués. L'absence de l'un de ces trois types de preuves biaise les conclusions vers des vues partielles.

Les tests doivent utiliser des release candidates uniques et des versions de modèles explicites, en documentant les systèmes cibles, les capacités des appareils, les backends d'exécution, les sources de modèles et les états de mise à jour. Les performances d'inférence on-device, l'utilisation de la mémoire et la compatibilité dépendent de la structure du modèle, de la quantification, du matériel et de l'exécution ; les chiffres provenant d'autres modèles ou appareils ne peuvent être cités.

Les chemins d'exception sont critiques : fichiers de modèles manquants ou corrompus, mises à jour interrompues, exécutifs non pris en charge, jetons serveur expirés, signaux d'intégrité indisponibles, échecs de téléchargement des journaux et permissions utilisateur révoquées. Le système doit se dégrader en toute sécurité, fournissant des états récupérables tant pour les utilisateurs que pour les équipes opérationnelles.

Conclusions de conception et limites du périmètre

Le chiffrement du modèle est pertinent, mais il ne représente qu'un point de contrôle dans le cycle de vie du modèle. Les applications IA commerciales doivent également protéger la logique de pré/post-traitement, empêcher l'introduction de clés à privilèges élevés et de longue durée dans le client, garantir que le serveur effectue l'autorisation finale, mettre en œuvre une tolérance aux pannes pour les signaux d'intégrité de la plateforme et gouverner les données utilisateur et les journaux.

En l'absence de release candidates réels, de versions de modèles, de dispositifs cibles et d'interfaces côté serveur, nous ne pouvons examiner que l'architecture et les éléments en attente de validation. Nous ne pouvons affirmer que les modèles sont résistants à l'extraction, que les interfaces sont protégées contre les abus, que l'injection au moment de l'exécution est bloquée ou que les objectifs de performance sont atteints. Toute conclusion de ce type nécessite des dossiers de preuves actuels.

Le point d'entrée de l'action Yudun sur cette page sert à demander un durcissement d'application et une évaluation de compatibilité ; il ne constitue pas une validation d'un framework de modèle spécifique ou d'une capacité exclusive à l'IA. Le périmètre du projet doit être confirmé séparément après soumission de la pile technologique, de la méthode de livraison du modèle et des parcours métier critiques.

• Maintenir des registres distincts pour les modèles, les environnements d'exécution, les identifiants et les données
• Garantir que les invocations à haut risque sont autorisées en dernier lieu par le serveur
• Prévoir des chemins d'indisponibilité et de dégradation pour les signaux de plateforme
• Permettre aux mises à jour de modèles de prendre en charge la vérification, la commutation atomique et le retour arrière
• Lier toutes les conclusions à des release candidates et des versions de modèles spécifiques