Windows Recall : la mémoire longue de Microsoft reste une épine dans le pied de la sécurité
Deux ans. C’est le temps qu’il aura fallu à Windows Recall pour ne pas réussir à quitter l’actualité sécurité. La fonctionnalité phare des PC Copilot+, conçue pour capturer en continu l’activité de l’utilisateur sous forme de captures d’écran indexées et interrogeables par IA, revient dans le collimateur des chercheurs en cybersécurité avec une nouvelle démonstration d’exploitation signée Alexander Hagenah, créateur de l’outil TotalRecall Reloaded. Microsoft, de son côté, maintient que tout fonctionne exactement comme prévu. Le débat tourne donc en rond, mais pas pour les mêmes raisons qu’en 2024.
Un peu de contexte pour ceux qui auraient réussi à oublier
Annoncée en fanfare en mai 2024 comme la fonctionnalité qui allait transformer Windows en « mémoire photographique numérique », Recall avait rapidement provoqué un tollé dans les milieux de la sécurité. La fonctionnalité prenait des instantanés de toute l’activité du PC, exposant potentiellement des données personnelles à d’éventuels acteurs malveillants. Microsoft avait alors retiré la fonctionnalité de la distribution publique et était retourné à sa table à dessin.
Les utilisateurs de PC Copilot+ ont finalement commencé à recevoir Recall sous forme de fonctionnalité optionnelle à partir d’avril 2025, soit un an après l’annonce initiale. Pour sa réintroduction, Microsoft avait cette fois fait ses devoirs : la fonctionnalité nécessite désormais Windows Hello Enhanced Sign-In Security (ESS), avec authentification biométrique (empreinte digitale ou reconnaissance faciale) pour autoriser temporairement l’accès aux données protégées. Microsoft affirmait que cette architecture visait à restreindre les tentatives de logiciels malveillants dormants cherchant à profiter de l’authentification d’un utilisateur pour dérober des données. Ambition louable.
TotalRecall Reloaded : la même chanson avec de nouvelles paroles
C’est ici qu’entre en scène Alexander Hagenah. Ce chercheur, qui avait déjà en 2024 extrait des données de Recall depuis des builds préliminaires en supprimant manuellement les protections de sécurité (une approche que d’aucuns qualifieraient davantage de chirurgie invasive que de vrai pentest), a cette fois publié un outil baptisé TotalRecall Reloaded sur GitHub. Sa thèse : il est possible, depuis un processus non privilégié, de forcer l’affichage d’une invite d’authentification Windows Hello et, une fois l’utilisateur authentifié, de récupérer l’intégralité des données de la timeline Recall.
La métaphore qu’il emploie lui-même est parlante et mérite d’être citée intégralement tant elle résume le débat technique :
« Le VBS enclave qui protège les données Recall est en acier. Le problème fondamental n’est pas la cryptographie, l’enclave, l’authentification ou le PPL. C’est l’envoi du contenu déchiffré vers un processus non protégé (l’application Recall timeline) pour le rendu. La porte du coffre est en titane. Le mur à côté est en placo. »
En d’autres termes : la zone sécurisée Virtualization-Based Security (VBS) dans laquelle résident les données chiffrées de Recall est, de l’aveu même du chercheur, imperméable. Le talon d’Achille se situe en aval, au moment où ces données doivent être déchiffrées et transmises à l’application d’affichage (la Recall timeline) pour être rendues intelligibles. Ce processus de rendu s’exécute dans un contexte non protégé, ce qui ouvre théoriquement une fenêtre d’interception pour un logiciel malveillant ayant obtenu une exécution locale.
La réponse de Microsoft : « Ce n’est pas une vulnérabilité »
Microsoft a clôturé son investigation sous la mention explicite « Not a Vulnerability ». La réponse officielle transmise au chercheur est sans ambiguïté : le comportement observé s’inscrit dans la conception de sécurité documentée de Recall et les patterns d’accès démontrés sont cohérents avec les protections et contrôles prévus.
Microsoft renvoie également vers son billet de blog de septembre 2024 dans lequel l’architecture de sécurité avait été détaillée. Le point central de la défense de Microsoft est que l’accès aux données de Recall suppose que l’attaquant dispose déjà d’une exécution locale sur la machine avec le niveau de privilege adéquat, et que l’utilisateur s’authentifie effectivement. Ce prérequis ramène le problème dans la catégorie des scénarios de compromission locale, qui relèvent d’une surface d’attaque bien plus large que Recall elle-même.
Paul Thurrott, observateur attentif de l’écosystème Microsoft depuis trois décennies, adopte une position nuancée mais globalement favorable à Microsoft : la fonctionnalité est optionnelle, les données restent sur le poste, aucune transmission vers les serveurs de Microsoft n’est effectuée, et quiconque s’inquiète réellement de Recall ne l’activera tout simplement pas.
Ce que cela signifie pour un environnement professionnel
Pour les DSI, le débat technique ne doit pas masquer les enjeux de gouvernance. Recall n’est aujourd’hui déployable que sur les PC Copilot+ (NPU requis, processeurs Snapdragon, Intel Core Ultra ou AMD Ryzen AI), représentant moins de 10 % du parc Windows 11 mondial. La surface de risque réelle dans un parc d’entreprise est donc encore limitée, mais la question mérite d’être posée dans les politiques de sécurité des postes de travail.
Les points à retenir sont les suivants. Premièrement, la protection VBS enclave de Recall est solide, et le chercheur le reconnaît lui-même. Deuxièmement, le vecteur d’attaque identifié nécessite une exécution locale préalable, ce qui présuppose un poste déjà compromis ; à ce stade, les données Recall ne seraient qu’une cible parmi d’autres. Troisièmement, Recall est une fonctionnalité opt-in : dans un contexte d’entreprise, elle doit faire l’objet d’une politique explicite via Intune, avec désactivation par défaut jusqu’à évaluation formelle du risque. Quatrièmement, les données de Recall, qui peuvent inclure des captures d’écran de mots de passe, de données bancaires ou de documents confidentiels affichés à l’écran, constituent un actif de haute valeur pour un attaquant, ce qui justifie une vigilance proportionnelle même si l’architecture de base est correcte.
Le vrai sujet n’est peut-être pas tant la robustesse cryptographique de l’implémentation que la question fondamentale de principe : est-il raisonnable de constituer, sur un poste de travail professionnel, une base de données indexée et interrogeable de tout ce que l’utilisateur a vu et fait sur son poste ? La réponse dépend autant de la politique de sécurité de l’organisation que de la confiance accordée à Microsoft sur la durée…