- Der Data Memory-Dependent Prefetcher (DMP) kann geheime Schlüssel selbst aus Constant-Time-Implementierungen preisgeben, indem er Datenwerte in Kryptocode wie Adressen behandelt
- Auf Apple-m-series-CPUs versucht der DMP, aus dem Speicher geladene Werte zu dereferenzieren, wenn sie wie Pointer aussehen, wodurch die Constant-Time-Annahme einer Trennung von Daten und Adressen ins Wanken gerät
- Die Forschenden demonstrierten auf Apple m1 eine End-to-End-Schlüsselextraktion für OpenSSL Diffie-Hellman, Go-RSA-Entschlüsselung, CRYSTALS-Kyber und CRYSTALS-Dilithium und bestätigten ähnliches DMP-Verhalten auch auf m2 und m3
- Auf m3 deaktiviert das DIT-Bit den DMP wirksam, gilt jedoch nicht für m1 und m2; ein im April 2024 entdecktes HID-Konfigurationsbit ist ohne macOS-Kernel-Unterstützung nicht direkt nutzbar
- Zu den Gegenmaßnahmen zählen aktuelle Software, die Nutzung von DIT-/DOIT-Bits auf unterstützten CPUs, Input Blinding und das Vermeiden gemeinsam genutzter Hardware; die Bewertung der Anfälligkeit erfordert Kryptoanalyse und Codeprüfung
Das Wesentliche am GoFetch-Angriff
- GoFetch ist ein mikroarchitektonischer Side-Channel-Angriff, der den Data Memory-Dependent Prefetcher (DMP) ausnutzt
- Selbst aus kryptografischen Implementierungen, die in Constant Time geschrieben wurden, lassen sich geheime Schlüssel extrahieren
- Die von den Forschenden demonstrierten Ziele sind:
- OpenSSL Diffie-Hellman Key Exchange
- Go RSA decryption
- CRYSTALS-Kyber
- CRYSTALS-Dilithium
- Paper und Tools sind hier verfügbar: Paper, Tools
Wie DMP die Constant-Time-Annahme bricht
- Der DMP in Apple-m-series-CPUs wird aktiv, wenn aus dem Speicher geladene Daten wie ein Pointer-artiger Wert aussehen, und versucht, diesen zu dereferenzieren
- Constant-Time-Programmierung verlangt die Trennung von Daten und Adressen, damit sich Verzweigungen, Schleifen, Speicherzugriffe und Array-Indizes nicht abhängig von geheimen Werten ändern
- Selbst wenn der betroffene Code diese Regel einhält, kann der DMP auf Hardware-Ebene stattdessen geheimnisabhängige Speicherzugriffe erzeugen
- Dadurch entstehen in eigentlich constant-time ausgelegtem Code beobachtbare Zeitunterschiede, die Angriffe zur Schlüsselextraktion ermöglichen
Ablauf des Angriffs
- Der Angreifer konstruiert gewählte Eingaben für die Kryptooperation so, dass nur bei einer richtigen Teilvermutung des geheimen Schlüssels im Zwischenzustand ein pointer-artiger Wert erscheint
- Anschließend wird per Cache-Timing-Analyse geprüft, ob der DMP eine Dereferenzierung durchgeführt hat, um die Vermutung zu bestätigen
- Wird eine korrekte Vermutung bestätigt, wird auf dieselbe Weise der nächste Schlüsselbit-Block geraten
- Mit diesem Verfahren ist eine End-to-End-Schlüsselextraktion aus Implementierungen klassischer und Post-Quanten-Kryptografie möglich
Betroffene Prozessoren und Beobachtungen
- Der End-to-End-GoFetch-Angriff wurde auf Hardware mit Apple-m1-Prozessor durchgeführt
- Auch m2- und m3-CPUs zeigen ähnlich ausnutzbare Aktivierungsmuster des DMP
- Andere m-series-Varianten wie m2 Pro wurden zwar nicht getestet, verwenden aber dieselbe Mikroarchitektur wie die einfachen Modelle, sodass ein ausnutzbarer DMP wahrscheinlich ist
- Auch die Intel-Mikroarchitektur Raptor Lake der 13. Generation besitzt einen DMP
- Die Aktivierungskriterien sind dort jedoch stärker eingeschränkt, wodurch sie gegenüber dem GoFetch-Angriff robust ist
Unterschied zu Augury
- Der DMP der Apple-m-series wurde zuerst von Augury entdeckt
- Augury ging davon aus, dass der DMP unter bestimmten Bedingungen Daten und Adressen vermischen kann
- Die GoFetch-Forschenden halten die von Augury beschriebenen Aktivierungskriterien des DMP jedoch für zu restriktiv
- Im realen Verhalten kann jeder aus dem Speicher geladene Wert ein Kandidat für die Dereferenzierung sein, was End-to-End-Angriffe auf echte Constant-Time-Kryptocodepfade ermöglicht
Hintergrund zu Cache und Prefetchern
- Moderne Prozessoren verwenden Caches, um die Latenz von Speicherzugriffen zu verringern
- Bereits zuvor genutzte Daten verbleiben im Cache, wodurch spätere Zugriffe schneller werden
- Ein Angreifer, der auf derselben Maschine mitläuft, kann den gemeinsam genutzten Cache-Zustand beobachten und daraus auf die Zugriffsmuster des Opfers schließen
- Gewöhnliche Prefetcher sagen künftige Speicheradressen anhand zuvor beobachteter Speicherzugriffe voraus
- Der DMP berücksichtigt zusätzlich Speicherinhalte, um bei unregelmäßigen Zugriffsmustern wie dem Traversieren verketteter Listen zu entscheiden, welche Daten vorab geladen werden sollen
- Dieses Verhalten vermischt auf Hardware-Ebene Daten und Speicheradressen und kann dadurch den gesamten Rechen-Stack wie nicht constant-time erscheinen lassen
Bewertung der Anfälligkeit und Gegenmaßnahmen
- Um zu beurteilen, ob eine Implementierung anfällig ist, muss man wissen, wann und wie sich geheimnisabhängige Zwischenwerte pointer-artig darstellen lassen
- Diese Bewertung erfordert Kryptoanalyse und Codeprüfung; sie ist manuell und langsam und kann andere Angriffswege nicht ausschließen
- Auf einigen Prozessoren lässt sich der DMP deaktivieren
- Im April 2024 entdeckte Hector Martin (marcan) auf m1- und m2-CPUs das HID-Konfigurationsbit
SYS_APL_HID11_EL1[30], das den DMP deaktiviert- Für dieses chicken bit ist Kernel-Unterstützung erforderlich
- macOS unterstützt dies derzeit nicht
- Weitere Informationen finden sich in @marcans Beitrag
- Nutzerinnen und Nutzern wird empfohlen, aktuelle Software einzusetzen und regelmäßig zu aktualisieren
- Entwickler von Kryptobibliotheken können auf unterstützten CPUs nach Möglichkeit DIT-/DOIT-Bits setzen
- Input Blinding kann bei einigen Kryptoschemata helfen, vom Angreifer kontrollierte Zwischenwerte zu vermeiden
- Wenn gemeinsam genutzte Hardware vermieden wird, sodass Angreifer die DMP-Aktivierung nicht messen können, lässt sich die Sicherheit kryptografischer Protokolle weiter erhöhen
Offenlegung und spätere Updates
- Die Forschenden meldeten ihre Ergebnisse am 5. Dezember 2023 an Apple, also 107 Tage vor der öffentlichen Veröffentlichung
- Im August 2024 gewann GoFetch den Pwnie Award 2024 Best Cryptographic Attack
- In einer Folgestudie vom Dezember 2024 wurden die Semantiken des Intel-DMP per Reverse Engineering untersucht; zudem wurde gezeigt, dass DMP auch dann Informationen preisgeben kann, wenn ungültige Pointer dereferenziert werden
- Das Folgepaper ist Peek-a-Walk: Leaking Secrets via Page Walk Side Channels
- Der Code liegt im Peek-a-Walk GitHub-Repository
1 Kommentare
Hacker-News-Kommentare
In einer Zeit, in der es so etwas wie Effizienzkerne gibt, könnte man in modernen Architekturen auch Krypto-Kerne brauchen
Solche Kerne müssten explizit Garantien im Zusammenhang mit Constant-Time-Algorithmen bieten und Dinge wie Prefetching oder Branch Prediction nicht verwenden
Etwas Ähnliches wie Itanium, aber auf einen „Krypto-Prozessor“ beschränkt, hätte deutlich weniger Funktionen, daher dürfte die Siliziumfläche des Kerns an sich prinzipiell auch nicht groß sein
Wenn man Kryptocode implementiert, wirken solche Probleme wohl so zermürbend, dass man zum Alkohol greifen möchte. Selbst im besten Fall ist es ein harter Kampf, und selbst wenn man alles korrekt implementiert, können unzählige heutige und zukünftige Prozessorfunktionen den Code jederzeit kaputtmachen
Aber ein Krypto-Koprozessor ist eine viel zu disruptive Lösung. Man müsste einen Berg an Infrastruktur schaffen, um auf diesen Kern umzuschalten, zurückzukehren, Speicher zu teilen usw.
Noch gravierender ist, dass man nicht einfach nur die RSA-Multiplikation auf diesen Kern verschieben und es dabei belassen kann. Der Schlüssel wurde ja irgendwo geparst — muss dann auch der Parser auf dem Krypto-Kern laufen? Was passiert, wenn er über das Netzwerk hereinkommt? Ist es okay, wenn man den gesamten Schlüssel schützt, aber ein CPU-Seitenkanal die verschlüsselte Nachricht preisgibt? Kann man sagen, das sei in Ordnung, weil es kein Schlüssel ist?
Dass man solche Angriffe in Nicht-Krypto-Code seltener sieht, liegt daran, dass die Zielsuche je nach Anwendung zu unterschiedlich ist, während sich bei Kryptobibliotheken alle einig sind, dass das Leaken von Schlüsseln schlecht ist
Letztlich dürfen Prozessorentwickler unsere Annahmen nicht brechen — oder sollten zumindest mit uns reden, bevor sie es tun
Die Abstraktionseinheit wäre dabei vermutlich eher auf Thread-Ebene
https://support.apple.com/guide/security/secure-enclave-sec5...
Aber kostenoptimierte Cloud-Architekturen haben den CPU-Markt mit Consumer-Hardware dominiert, und inzwischen sind selbst für große Anwendungen praktisch nur noch Consumer-CPUs realistische Optionen
Um neue Algorithmen zu ermöglichen, könnte es auch sinnvoll sein, ein paar elementare Krypto-Operationen als Instruktionen hinzuzufügen
Laut dem Paper „geht OpenSSL davon aus, dass lokale Seitenkanalangriffe außerhalb des Threat Models liegen, und das Go-Crypto-Team stuft die Schwere dieses Angriffs als niedrig ein“
Das Endergebnis solcher Seitenkanalangriffe wäre eine CPU ohne jede Optimierung, bei der jede Instruktion unter allen Umständen in gleich vielen Zyklen ausgeführt wird
Aber dazu wird es nie kommen. Niemand will eine langsame CPU
Wenn es nicht aus der Ferne ausnutzbar ist, sehe ich darin kein Problem, über das man sich Sorgen machen müsste. Natürlich fällt Multi-Tenant-Cloud-Virtualisierung damit aus
Ohne spekulative Ausführung, ohne Prefetching, also ein Kern mit einer 5-stufigen Pipeline wie im Kurs Rechnerarchitektur 101
Es gibt zwar ein paar Cloud-Anbieter, die Rechenzeit auf rackmontierten Mac Minis vermieten, aber das sind nicht viele, und selbst dort ist es eher für sehr spezifische Workloads oder Build-Jobs gedacht
Für Leute, die viel Geld für solche Dienste bezahlen, könnte es ein Problem sein, aber die überwältigende Mehrheit der Apple-Silicon-Geräte wird ganz sicher niemals Cloud-Dienste hosten
Wenn man Code auf einen bestimmten Kern isoliert, kann ein Exploit — vorausgesetzt, alles funktioniert wie beabsichtigt — keine anderen Tenants kompromittieren
Auf die Frage „Kann man DMP deaktivieren?“ heißt es: „Ja, aber nur auf einigen Prozessoren. Auf M3-CPUs deaktiviert das Setzen des DIT-Bits DMP effektiv, auf M1 und M2 jedoch nicht“
Irgendwo muss es doch bestimmt ein Chicken Bit geben, um das abzuschalten?
Geht das in Swift oder braucht man dafür Assembler?
Nach dem Lesen wirkt es so, als könnten Bibliotheken wie libsodium auf M3 und neuer vor sensiblen kryptografischen Operationen einfach das Deaktivierungs-Bit setzen
Außerdem scheint man einige Aspekte des Schlüssels im Voraus kennen zu müssen
Sehr cool, aber nicht wirklich praktikabel
Das erinnerte mich an den Augury-Angriff von 2022. Auch der missbrauchte DMP-Prefetching auf Apple-Silicon-CPUs
[1]: https://www.prefetchers.info
Warum hat Apple nur so viele Hardware-Hintertü... äh, reine Bugs?
Um auf diese unsinnige Hintertür-Verschwörungstheorie zu antworten: Menschen wollen schnelle CPUs, deshalb haben Prozessoren Caches und Zeitunterschiede. Constant Time und hohe Geschwindigkeit kann man nicht gleichzeitig haben, und Apple ist nicht das einzige Unternehmen mit Prefetching
Hier ist eine Dokumentation, in der Apple beschreibt, wie man Constant-Time-Operationen für Kryptografie aktiviert. Fast so, als wäre das absichtlich in die Hardware eingebaut worden. Seltsam, nicht wahr: https://developer.apple.com/documentation/xcode/writing-arm6...
Wenn man Krypto-Routinen schreibt, sollte man die Krypto-Bibliothek der Plattform verwenden oder der Dokumentation folgen
https://developer.apple.com/documentation/xcode/writing-arm6...
Jetzt sind auch auf Mac und iPad Malware-Prüfungen und Virenscanner sinnvoll geworden
Der Angreifer muss auf derselben Hardware laufen