Wenn Machine Learning die falsche Geschichte erzählt

• Ein MIT-Projekt zur Hardware-Sicherheit rekonstruierte einen im Webbrowser möglichen Machine-Learning-gestützten Seitenkanalangriff und zeigte dabei die Falle auf, dass eine hohe Modellgenauigkeit nicht die tatsächliche Ursache beweist
• Frühere Forschung zu Website-Fingerprinting sah CPU-Cache-Konkurrenz als Ursache, doch ein Ansatz, der Cache-Zugriffe entfernte und nur einen einfachen Zähler erhöhte, erzielte in mehreren Umgebungen eine höhere Genauigkeit
• Das Forschungsteam schloss nacheinander CPU-Frequenzskalierung, CPU-Core-Konkurrenz und die Cache-Hypothese aus und bestätigte mit eBPF-Instrumentierung, dass über 99 % der Pausen von mehr als 100 ns auf Interrupt-Verarbeitung entfielen
• Schon Signale von System-Interrupts legten Aktivitäten beim Laden von Websites offen; unter Chrome/Linux erreichte die Identifikation der Ziel-Website unter 100 Websites eine Genauigkeit von bis zu 96,6 %
• Für die Entwicklung von Gegenmaßnahmen muss zuerst der tatsächliche Mechanismus des Seitenkanals analysiert werden, statt nur festzustellen, dass das Modell richtig lag

---

Wie die Forschung begann

• 2020 startete in MITs Kurs Secure Hardware Design ein Projekt zur Reimplementierung eines Website-Fingerprinting-Angriffs, gestützt auf Erfahrung in Webentwicklung und Machine Learning
• Mengjia Yan sah in der aktuellen Forschung zu Website-Fingerprinting, die Hardware-Schwächen mit Machine Learning angreift, etwas Unstimmiges und schlug eine Reimplementierung vor
• Aus dem Projekt entstand später das Paper There’s Always a Bigger Fish: A Clarifying Analysis of a Machine-Learning-Assisted Side-Channel Attack
  • Das Paper gewann den 1. Platz bei Intels 2024 Hardware Security Academic Award und wurde in die IEEE Micro Top Picks 2023 aufgenommen
  • Die Forschung behandelt drei Achsen: Browser-Angriffe, Lecks durch System-Interrupts und Fehlinterpretationen von Machine Learning

Seitenkanäle und Website-Fingerprinting

• Prozessisolation trennt Speicher und Ressourcen von Anwendungen, doch in realen Computern werden Ressourcen wie Netzwerkkarte, GPU und CPU weiterhin gemeinsam genutzt
• Gemeinsam genutzte Ressourcen können unbeabsichtigt Informationen über Nutzeraktivitäten preisgeben
  • Wenn jemand am selben WLAN-Router ein großes Video ansieht, kann sich die Download-Zeit anderer Nutzer verlängern
  • Auch Änderungen im Stromverbrauch oder elektromagnetische Abstrahlung können zu Seitenkanälen werden, über die sich kryptografische Schlüssel oder Nutzeraktivitäten ableiten lassen
• Website-Fingerprinting ist ein Angriff, bei dem eine Angreifer-Website in einem Tab versucht, die in einem anderen Tab geöffnete Opfer-Website zu identifizieren
• Die frühere Arbeit von Shusterman et al. stellte einen Angriff vor, der mithilfe des CPU-Caches die geöffnete Website unter 100 Kandidaten erkennt
  • Der Angreifer erstellt ein Array in der Größe des CPU-Caches und füllt es mit 1
  • Während die Opfer-Website lädt, misst er alle 2 ms die Zugriffszeit auf das Array
  • Über 15 Sekunden werden insgesamt 7.500 Messwerte gesammelt
  • Da sich Skripte, Bilder, Stylesheets und Rendering-Muster je nach Website ähnlich wiederholen, dient der Mess-Trace wie ein Fingerabdruck
  • Von 100 Websites werden jeweils 100 Traces gesammelt, um einen gelabelten Datensatz mit insgesamt 10.000 Einträgen zu erstellen und ein Machine-Learning-Modell zu trainieren
  • Über mehrere Browser und Betriebssysteme hinweg wurde eine maximale Genauigkeit von 91,4 % erreicht

Der Zählerangriff ohne Cache

• In der ersten Reimplementierung war die Klassifikation von 4 Websites einfach; schon ein einfacher Random-Forest-Klassifikator erreichte 98 % Genauigkeit
• Als das Experiment auf 10 Websites erweitert wurde, lag die Genauigkeit zunächst bei 75 %, verbesserte sich später aber bis zur Klassifikation von 10, 50 und 100 Websites
• Die entscheidende Änderung bestand darin, den Zugriff auf das Cache-Array zu entfernen und den Angreifer so schnell wie möglich value++ wiederholen zu lassen
  • Wenn der Zählerwert in festen Abständen gespeichert wird, bleibt als Trace erhalten, wie viel der Computer in diesem Zeitraum ausgeführt hat
  • Auch andere Aktivitäten wie das Ändern der Browserfenstergröße oder das Öffnen eines neuen Tabs spiegeln sich im Zähler-Trace wider
  • Im Paper wurden die Werte alle 5 ms gespeichert, um innerhalb einer festen Zeit mehr Informationen zu gewinnen
• Ein mit Zähler-Traces trainiertes Modell zeigte eine höhere Genauigkeit bei der Website-Identifikation als die bisherigen Cache-Latenz-Traces
• Dieses Ergebnis stellte infrage, ob der frühere Angriff tatsächlich Cache-Konkurrenz ausnutzte, und führte zu einer Analyse der Ursache

Die Lücke zwischen Modellgenauigkeit und Ursachenanalyse

• Bei Machine-Learning-gestützten Seitenkanalangriffen zeigt die Tatsache, dass ein Modell Nutzeraktivitäten zuverlässig vorhersagt, nur die Existenz eines Signals
• Hohe Genauigkeit beweist nicht, aus welchem Seitenkanal dieses Signal stammt
  • Selbst wenn das Modell von Shusterman et al. die Opfer-Website mit 91,4 % Genauigkeit erkannte, bedeutet das nicht, dass es CPU-Cache-Konkurrenz erfasst hat
  • Was das Modell findet, sind Korrelationen; es erklärt nicht die Ursache des Signals
• Eine falsche Ursachenanalyse kann die Entwicklung von Gegenmaßnahmen in die Irre führen
  • Forschende entwerfen auf Basis von Angriffspapern Gegenmaßnahmen, um Computer sicherer zu machen
  • Wird die Ursache des Angriffs falsch verstanden, können Zeit und Aufwand verschwendet werden

Hypothesentest: Frequenz, Core, Interrupts

• Das Forschungsteam verglich den früheren Cache-basierten Angriff und den neuen Zähler-basierten Angriff in verschiedenen Umgebungen
  • Bei der Aufgabe, 100 Websites zu identifizieren, erzielte der Zähler-basierte Angriff in fast allen experimentellen Konfigurationen eine höhere Genauigkeit
  • Unter Safari auf macOS erreichte der Cache-Angriff 72,6 %, der Zählerangriff 96,6 % Genauigkeit
  • In der Standardkonfiguration wurde die richtige Website unter 100 Websites mit 95,2 % Genauigkeit identifiziert

• Hypothese zur CPU-Frequenzskalierung

  • Moderne CPUs erhöhen oder senken ihre Frequenz je nach Last, um Energie zu sparen
  • Die Hypothese lautete, dass sich beim Laden der Opfer-Website die CPU-Frequenz ändert und dadurch der Zählerwert variiert
  • Nach dem Deaktivieren der Frequenzskalierung im BIOS wurden neue Daten gesammelt und das Modell trainiert
  • Die Genauigkeit sank nur um 1 Prozentpunkt von 95,2 % auf 94,2 %, sodass die Änderungen des Zählerwerts schwer durch CPU-Frequenzänderungen zu erklären waren

• Hypothese zur CPU-Core-Konkurrenz

  • Wenn Angreifer- und Opfer-Tab auf demselben CPU-Core laufen, könnte das Laden des Opfer-Tabs die Ausführungszeit des Angreifer-Zählers verringern
  • Mit taskset unter Linux wurden Angreifer- und Opfer-Tab fest auf unterschiedliche Cores gelegt
  • Auch bei deaktivierter CPU-Frequenzskalierung blieb die Genauigkeit bei 94,0 %
  • Auch CPU-Core-Konkurrenz war damit schwer als Hauptursache anzusehen

• Hypothese zu System-Interrupts

  • Die nächste Hypothese war, dass System-Interrupts das Signal des Zähler-basierten Angriffs liefern
  • Betriebssysteme verwenden Interrupts, um mit Hardwaregeräten wie Tastatur, Maus, Display und Netzwerkkarte zu kommunizieren
  • Wenn ein Interrupt auf einem CPU-Core eintrifft, wird das dort laufende Programm sofort angehalten und der Interrupt-Handler ausgeführt
  • Während die Opfer-Website lädt, erzeugen verschiedene Geräte wie Netzwerk und Grafik Interrupts; werden sie auf demselben Core wie der Angreifer verarbeitet, kann dessen Zählerwert sinken
  • Unter Linux lässt sich die Interrupt-Verarbeitung mit cat /proc/interrupts prüfen

Verschiebbare und nicht verschiebbare Interrupts

• Linux kann einige verschiebbare Interrupts auf bestimmte Cores routen
  • Dazu gehören Interrupts mit numerischer ID
  • Sie stammen häufig von externen Hardwaregeräten wie Tastaturen oder Netzwerkkarten
• Viele nicht verschiebbare Interrupts lassen sich nicht auf bestimmte Cores isolieren
  • Dazu gehören Interrupts mit dreibuchstabiger ID
  • Da sie zur Synchronisierung von Aktivitäten zwischen CPU-Cores genutzt werden, müssen sie auf allen Cores verarbeitet werden
  • In der Experimentumgebung machten sie den Großteil der Interrupt-Aktivität aus
• Mit irqbalance wurden verschiebbare Interrupts auf Core 1 geleitet, während taskset Angreifer und Opfer auf Core 2 und 3 ausführte
• Bei ebenfalls fixierter CPU-Frequenz fiel die Genauigkeit um fast 6 Prozentpunkte, was die Interrupt-Hypothese plausibler machte

Mit eBPF bestätigte tatsächliche Ursache

• Da ein Experiment zur vollständigen Isolation auch nicht verschiebbarer Interrupts aufgrund der Betriebssystemarchitektur unmöglich war, wurde die Ausführung mit eBPF instrumentiert
• Über eBPF wurden zwei Zeitpunkte aufgezeichnet
  • Wann das Angreiferprogramm startet und stoppt
  • Wann ein Interrupt-Handler startet und stoppt
• Da die CPU-Frequenz fixiert war, sollte der Angreifer, wenn er nicht gestört wird, innerhalb einer festen Zeit nahezu die gleiche Anzahl an Instruktionen ausführen
• Mit dem von Jonathan Behrens geschriebenen eBPF-Code wurden die Pausen in der Angreiferausführung mit den Zeiträumen der Interrupt-Verarbeitung verglichen
• Über 99 % der Unterbrechungen der Angreiferausführung, die länger als 100 ns dauerten, wurden als Interrupt-Verarbeitungszeit bestätigt
• Der CPU-Core des Angreifers führte praktisch entweder den Zählcode aus oder verarbeitete Interrupts; wenn die Interrupt-Verarbeitungszeit sank, stieg der Zählerwert, und wenn sie zunahm, fiel er

Die zwei wichtigsten Ergebnisse des Papers

• Das erste Ergebnis ist, dass System-Interrupts Nutzeraktivitäten leaken
  • Die Sicherheitseigenschaften von System-Interrupts waren in der bisherigen Literatur nicht untersucht worden
  • Das Forschungsteam analysierte erstmals einen Seitenkanal auf Basis von System-Interrupts
• Das zweite Ergebnis ist, dass Machine-Learning-gestützte Seitenkanalangriffe sorgfältig analysiert werden müssen
  • Machine-Learning-Modelle können starke Angriffe ermöglichen, auch ohne den Seitenkanal zu verstehen
  • Ohne Instrumentierung des Betriebssystems hätte man nicht schließen können, welcher Seitenkanal genutzt wird
• Frühere Gegenmaßnahmen gegen Cache-basierte Angriffe bestanden darin, den CPU-Cache wiederholt zu verdrängen, um Rauschen einzubringen
• Eine Gegenmaßnahme, die viele Interrupts erzeugt, etwa durch Netzwerk-Requests an eine lokale IP-Adresse, funktioniert sowohl gegen den Cache-basierten als auch gegen den Zähler-basierten Angriff besser
• Dieser Vergleich stärkt die Evidenz, dass der Angriff von Shusterman et al. vor allem Interrupt-Signale statt Cache-Signale nutzt

Weitere Experimente und Verteidigungsmöglichkeiten

• Das Paper enthält auch weitere Ergebnisse
  • Es schlägt eine Methode vor, den Angriff vollständig abzumildern, indem die JavaScript bereitgestellte Browser-Uhr verändert wird
  • Es führt Experimente durch, bei denen Angreifer und Opfer zur Isolation in separate virtuelle Maschinen gelegt werden
  • Es analysiert Häufigkeit und Verarbeitungszeit verschiedener nicht verschiebbarer Interrupts
• Browser verringern die Präzision der JavaScript bereitgestellten Uhren, um Angriffe auf Basis hochpräzisen Timings zu erschweren
  • Chrome rundet auf 0,1-ms-Schritte und fügt zufälliges Rauschen hinzu
  • Firefox und Safari runden auf 1-ms-Schritte
  • Der Tor Browser rundet auf 100-ms-Schritte und senkt die Angriffsgenauigkeit von 96,6 % in Chrome auf 49,8 %
• Die Verringerung der Uhrpräzision bringt Trade-offs mit sich
  • Browserbasierte Game-Engines benötigen hochpräzise Timer für Rendering und Animationen
  • Nutzer des Tor Browser können die meisten Spiele nur schwer spielen, doch für sicherheitsorientierte Nutzer ist das möglicherweise kein Problem

Offene Forschungsfragen

• System-Interrupts sind mit Hardwaremechanismen tief im Inneren moderner Computer verbunden, ähnlich wie Spectre und Meltdown
• Eine Verteidigung, die nicht verschiebbare Interrupts vom Angreifer isoliert, ist derzeit nicht implementierbar; unklar ist, wie Computer neu entworfen werden müssten, um dies zu ermöglichen
• Auch die Beziehung zwischen Website-Aktivität und Interrupts ist noch nicht ausreichend verstanden
  • weather.com verursachte viele Rescheduling-Interrupts, nytimes.com und amazon.com hingegen nicht
  • Nicht analysiert wurde, wie zusätzliche Bilder, Werbung und Skripte den Zähler-Trace beeinflussen
• Der Angriff könnte noch stärker werden
  • Das Paper ist eher ein „Analyse-Paper“ als ein „Angriffs-Paper“
  • Die unter Chrome/Linux erzielten 96,6 % Genauigkeit könnten keine Ober-, sondern eine Untergrenze sein
  • Mit besseren Modellen oder anderen Methoden bleibt die Möglichkeit, ihn auf Aufgaben wie die Klassifikation von 1.000 Websites, die Erkennung, ob ein Film angesehen wird, ob ein VPN genutzt wird, oder wie oft Robinhood geprüft wird, anzuwenden
• Browserbasierte Gegenmaßnahmen müssen ebenfalls in reale Browser implementiert und auf ihre Praxistauglichkeit für normale Nutzer geprüft werden

Einfluss der Forschung auf den persönlichen Werdegang

• Vor diesem Projekt war ein Graduiertenstudium keine ernsthafte Option; nach einem Deep-Learning-Forschungspraktikum bei NVIDIA lag eher ein Job bei einem großen Technologieunternehmen oder einem AI-Startup nahe
• Nach dem Projekt entstand die Erfahrung, dass Forschung Spaß machen und schön sein kann
• Nach dem MIT-Abschluss folgte ein weiteres Jahr im Computer-Science-MEng-Programm, anschließend zwei Jahre Studium an der University of Oxford mit einem Rhodes scholarship
• Im nächsten Jahr ist der Beginn eines sechsjährigen PhD in Computer Science am MIT geplant

[GN⁺]

Hacker-News-Kommentare

• Guter Artikel, und auch die zugrunde liegende Forschung ist sauber.
  Der Beitrag des Papers hat meiner Ansicht nach eigentlich wenig mit Machine Learning zu tun, sondern damit, mithilfe von Interrupts einen neuen Seitenkanal gefunden zu haben.
  Machine Learning dient hier eher dazu, mehr Leser anzuziehen; ähnlich hätte man wohl auch „Statistik“ sagen können, ohne dass sich viel geändert hätte.
  Ich erinnere mich daran, wie mein Doktorvater früher sagte: „Wenn du verstanden hast, worum es in deinem Paper wirklich geht, schreibe es neu und nimm die Teile heraus, die du vorher für das Thema gehalten hast.“
  Der Titel dieses Papers hätte meiner Meinung nach den neuen Seitenkanal stärker in den Mittelpunkt stellen sollen als die Machine-Learning-Geschichte. Aber das ist eine Kleinigkeit; es ist hervorragende Arbeit.

  • Die beiden Geschichten sind eng miteinander verwoben. Ohne das Warnbeispiel zu Machine Learning wäre der neue Seitenkanal nicht gefunden worden.
    Besonders wichtig ist die Erkenntnis über das Missverständnis beim Machine Learning, weil sie einen beträchtlichen Teil der bisherigen Computerarchitektur-Forschung infrage stellt.
    Früher musste man für solche Angriffe den ausgenutzten Seitenkanal sehr genau verstehen; Machine-Learning-Modelle, hier ein LSTM, ermöglichen jedoch weit höhere Genauigkeit als bloße „Statistik“ und machen es einfacher, starke Angriffe zu bauen, die schlecht verstandene Seitenkanäle ausnutzen.
    Es gibt heute ziemlich viele auf diese Weise konstruierte, Machine-Learning-gestützte Angriffe, und allein das Paper von Shusterman et al. wurde fast 200-mal zitiert, was für ein Computerarchitektur-Paper eine enorme Zahl ist.
    Ziel der Veröffentlichung solcher Forschung ist es, Systeme besser zu verstehen und dadurch stärkere Abwehrmaßnahmen zu entwickeln; die Kosten, die Community durch ein falsches Verständnis in die Irre zu führen, sind hoch.
    Das gilt weiterhin, selbst wenn sich herausgestellt hätte, dass die Ursache des früheren Angriffs letztlich der Cache war; dass dabei ein neuer Seitenkanal entdeckt wurde, hat die Botschaft aber deutlich klarer gemacht. Der Blogpost hätte diesen Punkt wohl noch stärker betonen können.
  • Ich sehe darin weniger eine starke neue Erkenntnis über Machine Learning, sondern eher eine Grundregel, die alle Machine-Learning-Praktiker kennen sollten: Wenn die erhobenen und modellierten Daten es nicht hergeben, darf man Korrelation nicht als kausale Erklärung interpretieren.
    In der Praxis kann diese Grundregel in einem Meer aus Daten und Korrelationen untergehen, aber gutes experimentelles Design und Peer Review sollten eigentlich schwache Schlussfolgerungen und Interpretationen herausfiltern.
    In dieser Hinsicht hat diese Reproduktionsstudie genau das hervorragend geleistet.

• Hervorragender Artikel. Ich hätte nicht gedacht, dass man Seitenkanalangriffe so leicht verständlich erklären kann.
  Es las sich wie ein Krimi, bei dem man von Anfang an weiß, wer der Täter ist, aber herausfinden muss, „wie es gemacht wurde“.
  Habe ihn in die Lesezeichen gelegt.

  • Wegen der Länge und der Einleitung hätte ich ihn fast nicht gelesen. Normalerweise möchte man eher direkt zum Kern kommen als erst Hintergrund lesen.
    Aber wegen dieser Reaktion habe ich ihn gelesen, und er war tatsächlich wirklich gut.

• Die Stelle „Nächstes Jahr kehre ich ans MIT zurück, um ein sechsjähriges PhD-Programm in Informatik zu beginnen. Ich könnte nicht aufgeregter sein!“ ist erstaunlich.
  Beeindruckend ist, dass alles mit der glücklichen Idee der Autorin begann, statt des viel ausgefeilteren Cache-Eviction-Angriffs des ursprünglichen Seitenkanalangriffs einfach einmal zufällig Counter auszuprobieren – und dass das dank Konzepten funktionierte, die sie damals noch gar nicht kannte.
  Jemand wie ich, vermutlich einer von Tausenden, hatte dieses Glück nicht, gab den Gedanken an eine akademische Laufbahn schnell auf, ging in die Industrie und machte eine gewöhnliche Karriere.
  Ich begann ein australisches, etwa masterähnliches Informatik-Honours-Degree und wollte um 2010, also lange vor dem heutigen AI-Hype, auf Basis der Anwendungen aus einem regulären AI-Kurs ein Paper über künstliche Intelligenz schreiben.
  Ausgehend davon, wie Weingüter AI einsetzen, um Weinqualität und Produktion zu verbessern, wollte ich das auf „allgemeinere“ Anwendungen übertragen; der mir zugeteilte Betreuer hatte jedoch keinerlei Interesse zu helfen, und ohne weitere Unterstützung war es schwer weiterzumachen.
  Zumal ich ein Vollzeitangebot mit recht gutem Gehalt hatte, und selbst wenn ich weitergemacht hätte, hätte ich vermutlich nicht viel erreicht.
  Wie die Autorin selbst sagt, lief es dank ihres Betreuers und der Hilfe in ihrem Umfeld gut; allein braucht man enormen Antrieb und Talent, und mir fehlte wohl beides.

  • Ob man am richtigen Ort mit den richtigen Menschen ist, ist ein sehr wichtiger Erfolgsfaktor.
    Während meines ersten Promotionsversuchs in Japan haben mein Professor und die Leute um mich herum drei Jahre lang alles, was ich vorschlug, nur kritisiert, ohne umsetzbare Ideen zu liefern.
    Der Professor im Labor nebenan mochte meine Forschung, aber als ich das merkte, war es zu spät, um das Labor zu wechseln.
    Jetzt bin ich an einem Ort, an dem ich mit der Hälfte der Menschen im ganzen Land zusammenarbeiten kann, die mein anderes Projekt vollständig verstehen und sich dafür interessieren – insgesamt also zwei Personen –, und schon ihre Daten haben das Projekt verbessert.
    Auch der Institutsleiter sieht mich positiv und bezieht mich in Laboraktivitäten ein, obwohl ich dort nicht offiziell zugehörig bin.
    In so einer Umgebung kann man Erfolg haben. Die passende Umgebung und die passenden Menschen zu finden ist schwer, aber entscheidend; sonst kann selbst sehr gute Arbeit vergeblich sein.

• Der Artikel war gut.
  Als sehr kleine Kritik zur Seite: Der Trennlinien-Stil mit den großen Punkten wirkte wie die Positionsanzeige eines Bilderkarussells und war dadurch verwirrend.

• Der Artikel ist hervorragend, die Erklärung sehr zugänglich, und die interaktive Demo ist wirklich cool.
  Mir gefiel auch, dass erzählt wurde, wie es überhaupt zu dieser Arbeit kam.

• Sehr interessant und gut erklärt. Wenn die Forschung schon zwei Jahre alt ist, haben interessierte Datensammler sie vermutlich bereits berücksichtigt.
  Hacker kann man vergessen. Das ist ein Exploit für Unternehmen und Regierungen.
  Könnte eine Website, die großen Wert auf Datenschutz legt, ein Paket ausliefern, das zufällig Interrupts auslöst? Könnte eine Browser-Erweiterung das für alle Websites tun?

  • Eine Website müsste dabei vorsichtig sein. Wenn sie die einzige Website ist, die zufällig viele Interrupts auslöst, könnte sie dadurch erst recht leicht identifizierbar werden.
    Unsere Gegenmaßnahme, die zufällig Interrupts auslöst, ist als Browser-Erweiterung implementiert, und der Quellcode ist hier: https://github.com/jackcook/bigger-fish
    Allerdings würde ich sie nicht für den Alltag empfehlen. In unseren Tests waren die Seitenladezeiten, soweit ich mich erinnere, etwa 10 % langsamer.
  • Ich nutze Safari/macOS, und viele der Counting-Demos haben sich nicht so stark verändert wie behauptet.
    Einige änderten sich ziemlich stark, wenn der Computer stark ausgelastet war, aber es wirkt so, als könnte Safari bereits einige Mitigations enthalten.
    Trotzdem ist das Paper wirklich großartig.