Une nouvelle attaque contre Recall suggère que Microsoft a sécurisé le coffre-fort, mais pas la remise

L’histoire de la sécurité de Recall vient de se compliquer à nouveau

La fonctionnalité Recall de Microsoft était déjà l’une des idées les plus controversées du début de l’ère des PC Copilot+. Elle promettait une couche de mémoire assistée par IA capable de suivre l’activité d’un utilisateur via des captures d’écran et un historique consultable, mais sa première implémentation stockait des éléments très sensibles dans des fichiers locaux non chiffrés. Après de vives critiques de journalistes et de chercheurs en sécurité, Microsoft a retardé le déploiement, reconstruit des protections clés, chiffré les données stockées, amélioré le filtrage du contenu sensible et rendu la fonctionnalité facultative plutôt que systématiquement activée.

Cette refonte semblait répondre à la critique la plus immédiate. Mais un outil récemment mis à jour, TotalRecall Reloaded, pointe désormais vers une autre catégorie de risque. Selon le texte source fourni, le problème ne vient pas d’une compromission directe de la base de données protégée de Recall elle-même. Le problème apparaît plutôt après qu’un utilisateur s’authentifie avec Windows Hello et que les données Recall sont transmises à un autre processus système, AIXHost.exe, qui ne bénéficie pas des mêmes protections. Le chercheur derrière l’outil, Alexander Hagenah, a résumé le problème par une métaphore : le coffre-fort est peut-être solide, mais le chemin de livraison ne l’est pas.

La faiblesse est dans le flux de travail, pas dans la couche de stockage

Cette distinction est importante, car elle change le débat. La réponse de Microsoft à la première vague de critiques contre Recall s’est fortement concentrée sur la sécurité du stockage : chiffrement, authentification, meilleure exclusion du contenu sensible et comportement désactivé par défaut. Ces mesures comptent. Mais la nouvelle découverte suggère que sécuriser une fonction IA ne peut pas s’arrêter à la façon dont les données sont stockées au repos. Il faut aussi couvrir la manière dont elles circulent dans le système pendant l’usage normal.

Autrement dit, Recall peut être plus difficile à piller sur le disque qu’auparavant, tout en restant vulnérable au moment où les données protégées deviennent utilisables. C’est un problème bien connu en ingénierie de la sécurité. Les systèmes paraissent souvent les plus solides sur les schémas d’architecture statique et les plus faibles dans les transitions opérationnelles : authentification, déchiffrement, communication interprocessus et états d’accès temporaires. Pour une fonctionnalité conçue pour enregistrer de vastes pans de l’activité informatique personnelle, ces points de transition sont précisément l’endroit où le risque devient le plus sensible.

Le texte source montre aussi clairement pourquoi Recall reste particulièrement controversé même après les améliorations de Microsoft. Ce n’est pas simplement un autre cache d’application ou un historique de navigateur. C’est un système conçu pour enregistrer de larges pans de l’activité du PC afin qu’ils puissent être retrouvés plus tard. Par conséquent, même une compromission partielle peut exposer bien plus de contexte que les utilisateurs ne s’attendraient à voir fuiter via un seul maillon faible.

Pourquoi cela compte au-delà de Recall

L’épisode Recall devient une étude de cas pour un problème plus large de l’industrie : les fonctions IA qui paraissent pratiques au niveau du produit accumulent souvent des risques au niveau du système. La promesse est simple. L’IA locale, soutenue par des NPU, devrait permettre de conserver les fonctions sensibles sur l’appareil plutôt que dans le cloud distant. Mais le traitement local ne signifie pas automatiquement sécurité locale. Cela signifie que le modèle de menace change. Les attaquants n’ont plus besoin d’intercepter le trafic cloud s’ils peuvent viser le point terminal, la session utilisateur ou le chemin logiciel qui transporte les informations déchiffrées après authentification.

Cette dynamique est susceptible de se reproduire à mesure que les systèmes d’exploitation intègrent davantage de fonctions fondées sur des modèles. La recherche, la synthèse, l’historique d’activité, l’assistance prédictive et les outils agentiques exigent tous une combinaison de collecte, d’interprétation et de récupération des données. Si ces systèmes doivent être dignes de confiance, les éditeurs devront sécuriser tout le cycle de vie de l’accès, et pas seulement la base de données au repos.

La critique actualisée de Recall n’efface pas les améliorations précédentes de Microsoft. Selon le cadrage même de la source, les protections de la base de données sont bien plus robustes qu’avant. Mais elle confirme une vérité plus dure : lorsqu’une fonctionnalité est conçue pour se souvenir de presque tout, la tolérance aux écarts d’implémentation est extrêmement faible. Chaque nouveau contournement ou point faible de processus ravive la même inquiétude sous un angle différent.

• Microsoft avait déjà revu Recall après que son approche initiale du stockage a été jugée peu sûre.
• Le nouvel outil viserait le moment après l’authentification Windows Hello, lorsque les données Recall sont transmises à AIXHost.exe.
• L’incident souligne qu’une fonction IA peut rester risquée même après l’ajout d’un chiffrement renforcé et de contrôles d’opt-in.

Recall pourrait encore devenir une composante stable de Windows. Mais si cela arrive, ce sera parce que Microsoft aura démontré non seulement que la mémoire est protégée, mais aussi que chaque étape nécessaire pour y accéder l’est également.

Cet article s’appuie sur un reportage d’Ars Technica. Lire l’article original.