Neue Recall-Attacke legt nahe, dass Microsoft den Tresor gesichert hat, aber nicht die Übergabe

Die Sicherheitsgeschichte von Recall ist wieder komplizierter geworden

Microsofts Recall-Funktion war bereits eine der umstrittensten Ideen in der frühen Copilot+-PC-Ära. Sie versprach eine KI-gestützte Gedächtnisschicht, die Aktivitäten eines Nutzers über Screenshots und durchsuchbare Verläufe nachverfolgen kann, doch die erste Umsetzung speicherte hochsensible Inhalte in unverschlüsselten lokalen Dateien. Nach heftiger Kritik von Journalisten und Sicherheitsforschern verzögerte Microsoft die Einführung, überarbeitete zentrale Schutzmechanismen, verschlüsselte die gespeicherten Daten, verbesserte die Filterung sensibler Inhalte und machte die Funktion zu einer Opt-in-Lösung statt einer universellen Voreinstellung.

Diese Überarbeitung schien die unmittelbarste Kritik zu beantworten. Doch ein neu aktualisiertes Tool, TotalRecall Reloaded, weist nun auf eine andere Risikoklasse hin. Laut dem bereitgestellten Quelltext geht es nicht um einen direkten Bruch der geschützten Recall-Datenbank selbst. Das Problem entsteht vielmehr, nachdem ein Nutzer sich mit Windows Hello authentifiziert hat und Recall-Daten an einen anderen Systemprozess, AIXHost.exe, übergeben werden, der nicht von denselben Schutzmaßnahmen profitiert. Der Forscher hinter dem Tool, Alexander Hagenah, brachte das Problem mit einer Metapher auf den Punkt: Der Tresor mag stark sein, aber der Lieferweg ist es nicht.

Die Schwachstelle liegt im Workflow, nicht in der Speicherstufe

Diese Unterscheidung ist wichtig, weil sie die Debatte verändert. Microsofts Reaktion auf die erste Kritik an Recall konzentrierte sich stark auf Speichersicherheit: Verschlüsselung, Authentifizierung, bessere Ausfilterung sensibler Inhalte und ein standardmäßig deaktiviertes Verhalten. Diese Maßnahmen sind relevant. Doch der neue Befund legt nahe, dass die Absicherung einer KI-Funktion nicht bei der Ablage der Daten enden kann. Sie muss auch abdecken, wie Daten im normalen Betrieb durch das System fließen.

Mit anderen Worten: Recall ist möglicherweise schwieriger als früher direkt von der Festplatte zu plündern, bleibt aber an dem Punkt verwundbar, an dem geschützte Daten nutzbar werden. Das ist ein vertrautes Problem der Sicherheitsentwicklung. Systeme wirken auf statischen Architekturdiagrammen oft am stärksten und in betrieblichen Übergängen am schwächsten: Authentifizierung, Entschlüsselung, Interprozesskommunikation und temporäre Zugriffsphasen. Für eine Funktion, die große Mengen persönlicher Computerhistorie erfassen soll, sind genau diese Übergänge die sensibelsten Risikopunkte.

Der Quelltext macht auch klar, warum Recall trotz Microsofts Verbesserungen weiterhin einzigartig umstritten ist. Das ist nicht nur ein weiterer Anwendungs-Cache oder Browserverlauf. Es handelt sich um ein System, das breite Teile der PC-Aktivität aufzeichnen soll, damit diese später wieder abrufbar sind. Schon eine partielle Kompromittierung kann daher deutlich mehr Kontext offenlegen, als Nutzer durch eine einzelne Schwachstelle erwarten würden.

Warum das über Recall hinaus wichtig ist

Der Recall-Fall entwickelt sich zu einer Fallstudie für ein breiteres Branchenproblem: KI-Funktionen, die auf Produktebene bequem wirken, sammeln auf Systemebene oft Risiken an. Das Versprechen ist schlicht genug. Lokale KI, unterstützt durch NPUs, soll sensible Funktionen auf dem Gerät halten statt in der entfernten Cloud. Aber lokale Verarbeitung bedeutet nicht automatisch lokale Sicherheit. Es verschiebt das Bedrohungsmodell. Angreifer müssen keinen Cloud-Verkehr mehr abfangen, wenn sie den Endpunkt, die Benutzersitzung oder den Softwarepfad angreifen können, der nach der Authentifizierung entschlüsselte Informationen transportiert.

Diese Dynamik wird sich wahrscheinlich wiederholen, wenn Betriebssysteme mehr modellgestützte Funktionen aufnehmen. Suche, Zusammenfassung, Aktivitätsverlauf, prädiktive Unterstützung und agentische Werkzeuge benötigen jeweils eine Kombination aus Datenerfassung, Interpretation und Abruf. Wenn solche Systeme vertrauenswürdig sein sollen, müssen Anbieter den gesamten Lebenszyklus des Zugriffs absichern, nicht nur die ruhende Datenbank.

Die aktualisierte Kritik an Recall macht Microsofts frühere Verbesserungen nicht zunichte. Nach der Formulierung der Quelle sind die Datenbank-Schutzmechanismen deutlich stärker als zuvor. Aber sie unterstreicht eine härtere Wahrheit: Wenn eine Funktion so konzipiert ist, dass sie fast alles erinnert, ist die Toleranz für Implementierungslücken extrem gering. Jeder neue Workaround oder Prozessfehler belebt dieselbe Grundsorge aus einem anderen Blickwinkel.

• Microsoft hatte Recall bereits überarbeitet, nachdem der ursprüngliche Speicheransatz als unsicher eingestuft worden war.
• Das neue Tool zielt Berichten zufolge auf den Punkt nach der Windows-Hello-Authentifizierung, wenn Recall-Daten an AIXHost.exe übergeben werden.
• Der Fall zeigt, wie KI-Funktionen auch nach stärkerer Verschlüsselung und Opt-in-Steuerung riskant bleiben können.

Recall könnte sich dennoch zu einem stabilen Bestandteil von Windows entwickeln. Wenn das passiert, dann nur, weil Microsoft nicht nur beweist, dass das Gedächtnis geschützt ist, sondern auch, dass jeder Schritt zum Zugriff darauf geschützt ist.

Dieser Artikel basiert auf einer Berichterstattung von Ars Technica. Zum Originalartikel.