 Du hast gleich den Talk Micro-Architektural Attacks on Trusted Execution Environments, also Attacken auf Mikroarchitektur, Ebenen auf Trusted Execution Environments. Wir werden den letzten Begriff nicht übersetzen im Weiterhang darauf. Es übersetzen Christian und Pharma-Firma und damit warten wir jetzt noch darauf, dass der Talk losgeht. Er wurde von der CCC vorhin inspiriert. Er war 2019 C3 und seine Recherche auf Smartphones und Chips, Systeme auf den Chips in Smartphones, werden die Fragen antworten, ob man die Trusted Execution Environments trusten kann. Bitte geben ein warmes Rund of applause zu Kiegen und genügend Spaß! Ich arbeite bei NTC Group und das ist mein Vortrag. Um zu verstehen, was ein Trusted Execution Environments ist, müssen wir uns pro Zessour Sicherheit etwas genauer anschauen, und zwar genauer gesagt auf Exetix. Wie sicher viele von euch wissen, gibt es verschiedene Modi, unter denen Code ausgeführt werden kann. Es beinhaltet Ring 3, das ist der Usercode, also die ganzen Anwendung und Ring 0, das ist der Kernelcode. Es gibt auch Ring 1 und Ring 2, die zum Beispiel für Treiber und Gasbefehlungen nutzen können, aber tatsächlich wirklich wichtig sind nur Ring 0 und Ring 3. In diesem Diagramm, das hier auf der Folge ist, sehen wir, dass das Privilegienlevel sich erhöht, wenn wir auf einem Diagramm Ring nimmer sind. Und tatsächlich die ganzen wichtigen Ziele der Angreifers in den Ring 0 und die Angreifer versuchen aus Ring 3 heraus an diese Information zu kommen. Was ist jetzt, wenn ich einen Prozessor Feature hinzufügen möchte, dass für Hypervisor gab es ein neues Feature, die können verschiedene Gastbetriebssysteme managen, und die sind natürlich alle in Ring 0, darum gibt es einen neuen Ring Minus 1, der ist für den Hypervisor. Also alle Geheimnisse vom Hypervisor gehören sind auf dem Ring Minus 1. Genau, es ist prinzipiell völlig völlig aus einem weniger privilegierten Ring darauf zu greifen. Also, du add Ring Minus 2, das ist Systemmanagement-Mode. Wenn man noch höheren Aktress haben will, dann geht es Ring Minus 2, das Systemmanagement-Modus, kann z.B. der Kippen chip auf das Management-Sport, und der kann alles wirklich her, was auch der Hakenweise nicht kann. Falls Ring Minus 2 nicht reicht, dann haben wir noch einen Ring Minus 3. Ihr seht, worauf es hinaufläuft, es gibt immer mehr Ringe, und das Ziel des Attackers ist dann immer höheren Ring. Aber was ist, wenn wir jetzt unsere Geheimnisse eigentlich gar nicht behaupten möchten, sondern in den User Space, ganz unten, ohne hohe Privilegien. Das ist die IG von SGX, die SGX Extensions, Software Gold Extensions, das waren z.B. Keys und Schlüssel usw. in User Space, wie man kann. Wir schauen jetzt mal weiter, dass mal nur Ring 0 bis Ring 3 an, Kernel bis uns made SGX in Klave. Wenn man Code in der SGX in Klave ausführen will, dann lädt man den Test da hinein, dann vertraut man der Ausführung, der Codeausführung innerhalb von dieser Klave, und man vertraut darauf, dass Kernel die anderen Ringe und so weiter da nicht darauf zugreifen kann. Man muss den SGX eigentlich vertraut. Dieses Modell ist ein bisschen komisch, weil der Angreifer ist in einem Ring oben im Kernel, und ausnahmsweise versucht der Attacker jetzt sich natürlich nach unten vorzuarbeiten, anstatt nach oben wirst. Wie ist das denn z.B. aus der Memory Management? Das ist etwas in Ring 0 dafür zuständig, und das muss jetzt da auf Ring 3 zugreifen können. Aber was wir natürlich auch nicht wollen, ist, dass der bösartige Ring 0 im Ring 3 etwas zufügen kann. SGX erlaubt dann tatsächlich, dass Ring 0 pagevoll zählen kann, aber gleichzeitig wird es sicher, dass weiterhin keine Speicherzukussverletzungen passieren können. Also, es ist tatsächlich ein etwas verstrickter Lösung, es ist nicht mehr sich so klar, dass er dann hält, aber es funktioniert. Und das letzte ganz grobe Überblick war die Idee in der SGX. Wir können jetzt in 86 anschauen und das dann mit Arm vor Ort vergleichen. Es ist im Prinzip in einem ähnlichen Rezept gebaut, aber es ist angefangen mit so die SGX. Also, es hat auf jeden Fall verschiedene Privilege, und bei Arm heißt es eine Privileg-Level, sondern Exception-Level. Und im Vergleich zu X86 startet Arm bei Level 0 und geht dann weiter nach oben. Jetzt müssen wir das merken. So, dann gibt es noch den Hypervisor-Modus, das ist in Exception-Level 2 und dann gibt es noch dem Monitor des Exception-Level 3. An diesem Punkt wollen wir jetzt noch immer die Möglichkeit haben, dass wir Code, den wir vertrauen möchten, im niedrigsten Privilege-Level ausführen, nämlich Exception-Level 0. Und das heißt, wir teilen das Diagramm in zwei verschiedene Abschnitte auf. Einmal die Secure-Welt und die non-secure-Welt, die sichere-Welt und die unsicher-Welt. Wir haben die nicht-sicher-Welt, die un-secure-Welt auf der linken Seite mit dem User-Dent-Könne-Hypervisor und dann haben wir die sichere-Welt, die trusted-Welt mit einem vertrauenswürdigen Anwendung, vertrauenswürdigen Betriebsystem. Und die Idee ist im Prinzip, dass man, wenn man irgendwas in der Secure-Welt ausführt, dass es dann nicht modifizierbar ist aus der non-secure-Welt. Und ja, das wäre dann hier ein Beispiel. Der Angreifahrt zum Beispiel, Zugriff auf den nicht-sicheren Könne, zum Beispiel Linux, und der versucht dann auf die trusted Anwendung in Exception-Level 0 zu zu greifen. Also, die Frage, die sich dabei stellt, wenn man sich SGX oder trust uns anschaut, können wir diese Ausführungsmodi nutzen, um die trusted execution environments anzugreifen. Es gab da schon verschiedene Ansätze, z.B. bei trust-zone und einem Glock-Screw-Angriff. Überall im Prinzip gehe ich jetzt in den nächsten Folien über verschiedene Paper durch. Einige davon sind schon etwas älter, aber ich sage das immer, sodass ihr rausfindet, was alter, was neu war. Und das Glock-Screw-Paper ist tatsächlich ziemlich neu. Es ist aus dem Jahr 2017. Und Glock-Screw funktioniert so, dass es von den Energiemanagement-Funktionärität-Messprozessors nutzt und die braucht man, weil der Prozessor die Energieverbrauch den verschiedenen Prozessoren-Energen nutzt. Und das heißt, man hat schon viel schon normalerweise damit, dass man den Energieverbrauch von Prozessoren, die gerade nicht benutzt werden, herunter skalieren kann. Das heißt, man hat z.B. höhere Batterielaufzeit, bessere Performance, Heldlänger und so weiter. Die Frage ist jetzt, wenn wir zwei verschiedene Kerne haben und einer läuft gerade im Nicht-Trusted-Operating-System und der andere führt gerade Code in der Secure-World aus. Das heißt, Code, den wir vertrauen. Also kann dieses nicht-sichere Betriebssystem trotzdem noch die Energiemanagement-Features für den anderen Kern bearbeiten. Und was die Glock-Screw-Attack an der Stelle tut, ist, dass der Kern in der nicht-sichere Welt den Zielkern übertaktet, um Holz zu induzieren. Und das heißt, diese Berechnung auf den angegriffenen Kern schlägt dann fehl und man kann damit dann irgendwelche geheimen Schlüssel oder Code-Signing oder so was funktionieren. Das ist also eine relativ mächtige Attacke, die ermöglicht wird dadurch, dass das nicht-privilegierte Betriebssystem mächtig genug ist, einige Features von dem Kern, wo gerade das sichere Betriebssystem läuft, zum Unifizieren. Das war eine aktive Attacke. Der Attacke muss aktiv etwas machen. Ich stelle jetzt eine passive Attacke vor. Also, was genau der Rest der Präsentation ist, ist eine passive Attacke. In vielen Askeks und Trastzoneimplementationen teilen sich vertrautensürdiger und nicht-vertraunsürdiger Code dasselbe Hardware, zum Beispiel, Register, so weiter. Also, die Andere, die der sichere Code gemacht hat, kann man also auch irgendwie in der Unsicherheitszone sehen. Zum Beispiel, ein Cache, der unsichere Code kann herausfinden, was der sichere Code im Cache gemacht hat. Das ist so wie eine Side-Channel Attacke, ja, seine Kanalattacke funktioniert. Wir haben darüber gesprochen, wie Memory Management funktioniert und wie es eigentlich verantwortet wird, dass das nicht funktioniert, zurückgeattacken. Und wie ist es denn jetzt mit Side-Channel Attacke? Wie wird darüber, wie wird dagegen geschützt? Insofern sagt gar nicht, wir haben diesen, diese Art von Angriff, wenn nicht abgedeckt. Das ist Aufgabe, das nicht abzudecken. Das ist eine gute Neuigkeit für uns, weil solche Side-Channel Attacke uns sehr machtvoll und es hilft uns, dass wir vorwärts kommen und es ist wahrscheinlich wert, dass wir das erreichen können. Schauen wir noch mal Cache-Attacken allgemein an, damit wir alle das erste Verständnis davon entwickeln, wie das funktioniert. Fangen wir an und schauen uns noch mal kurz an, wie Caches funktionieren. Also, wir brauchen Caches in Prozessoren, weil Hauptspeicher zu Prozessoren langsam sind. Wenn wir normalen Hauptspeicher anfassen, dann dauert es eine Zeit, bis das tatsächlich zum Prozessor kommt. Der Cache existiert als eine Schicht zwischen Hauptspeicher und Kern, um sich zu merken, was diese Informationen waren. Das heißt, wenn der Prozessor noch mal was von dieser Adresse braucht, dann lädt er es einfach nur noch vom Cache. Und dieser Zugriff geht dann deutlich schneller. Das heißt, der Cache beschleunigt den Speichertzugreif transparent. Und wenn wir dann eine für andere Adresse zugreifen wollen, dann wird er auch in den Cache gebracht und dann auf den zweiten Mal schnell gelesen. Und das geht immer so weiter. Und wie ihr euch denken könnt, für diese ganzen Beispiele haben sich diese Speicherboxen horizontal bewegt. Die waren immer in derselben Welt. Und das steht in Caches durch sogenannte Sets. Das heißt, es gibt vier verschiedene Set IDs. Und jede Adresse im Speicher mapt auf eine verschiedene Set ID. Und das heißt, in ein Set kommen immer nur Adressen aus mit der jeweiligen Set ID. Das heißt, wenn wir Adressen haben, die auf verschiedene Set IDs mapen, dann überlappen sie sich nicht in Cache und nehmen sich nicht gegenseitig den Platz weg. Aber was haben wir jetzt mit Speicherboxen? Die tatsächlich dieselbe Cache ID haben und der Cache voll ist. Wenn der Cache nicht voll ist, dann wird der Cache einfach weiter gefüllt. Aber die Anzahl an möglichen Einträgen in einer Set ID ist die sogenannte Assoziativität des Caches. Und das sehen wir hier in diesem Cache an der Anzahl, an Spalten in dem Cache. Das heißt, was wir hier sehen, ist ein zwei-Weg-Satz, also ein zertiver Cache. Und, ja, das heißt, was passiert jetzt, wenn wir jetzt einen Konflikt in dem Cache induzieren. Das heißt, zum Beispiel in die oberste Cache da in jetzt was reinlesen. Dann müssen wir eine alte Speicherbox aus dem Cache verdrängen und dafür die neue Adresse oder Box reinladen. Und wie wehrt man dann die Cache Box aus, die entfernt werden soll? Das ist ein Portice-Detail. Und für diesen Vortrag denken wir uns einfach das zufällig. Aber das heißt, wenn wir jetzt wieder die andere Adresse lesen wollen, dann müssen wir das wieder verdrängen und die alten Daten wieder in den Cache reinbringen. Das ist quasi wie ein Satz aus Zertiver Caches funktionieren. Es gibt zum Beispiel die Flash and Reload Attacke und wir haben zwei verschiedene Angriffsprozesse, den Angriffsprozess A und den Weg dem Prozess, also Opferprozess V. Und, ja, da gibt es eine ganze Reihe von Szenarien, wie zum Beispiel Page-Deduplikationen mit den Maschinen oder Copy and Write Libraries. Das Wichtige ist, dass sie sich ein Teil vom Code teilen. Das heißt, Code wird sowohl von dem Prozess A als auch von dem Prozess B referenziert. Wir starten jetzt beim leeren Cache und das heißt, der Angreifer lässt erstmal das Opfer ein bisschen ausführen und das heißt, Daten aus dem Hauptspeicher werden in den Cache gebracht. Und die zweite Phase von der Attacke ist dann die sogenannte Reload, also Wiederladephase, wo der Angreifer wieder ein Speicherzugriff macht und der Speicher den auch das Weg zum Leid und schaut, ob die Daten aus dem Cache geladen wurden oder aus dem Speicher in dem Fall, wurden die Daten aus dem Speicher geladen. Es hat lange gedauert und der Angreifer kann dadurch herausfinden, dass die Adresse, die er gerade geladen hat, nicht im Cache war. So, wenn er aber die Adresse eins lädt, sieht er, dass der Lade davor schnell passiert. Das heißt, der Angreifer sieht, dass die Daten im Cache waren. Weil der Angreifer vor der Ausführung vom Victim-Prozess alle Daten aus dem Cache geflasht hat, also verdreumt hat. Das heißt, so kann der Angreifer herausfinden, welche Speicheradressen der Opfer-Prozess tatsächlich zugreift. Das heißt, wir spielen das jetzt immer so weiter. Das heißt, der Angreifer flasht den Cache, lässt das Victim ausführen und guckt dann wieder, welchen Speicherbereich das Victim angefasst hat. Wir gehen ja jetzt nicht zu sehr ins Detail, aber es gibt noch andere Angriffe. Statt dass man Load Instruktion benutzt, kann man einfach auch zweimal flaschen. Denn Flaschinstruktionen dauern länger und die brauchen länger, also dauern genau dann länger, wenn Daten in dem Cache waren. Wieso? Zeitunterschied kann man nutzen. Das heißt, diese ganzen Attacken basieren darauf, dass Angreifer und Opfer einen Code bereichteilen. Jetzt gibt es aber auch den Fall, wenn Sie sich Code-Bereiche nicht teilen. Und da gibt es die sogenannte Prime-and-Probe-Attack, die auch wieder in zwei Stufen funktioniert. Das heißt, im ersten Schritt primt der Angreifer den Cache. Das heißt, der lässt Speicher den Cache voll mit Daten, die ihm gehören. Und dann, wenn der Opfer-Prozess einen Speicherzug aufmacht und Speicher zugreift, der dem gehört, muss er in einer Vertragung stattfinden. Und in dieser zweiten, und jetzt kommt die zweite Phase, in der der Angreifer die verschiedenen Cache-Anträge mit den Anzett-ID-Svergleich und checkt, ob das noch die gleichen Daten sind, die er mal reingeladen hat. Und in dem Beispiel checkt der Attacker zum Beispiel erst Adresse 3, Zugriff ist schnell, sieht das und Cache ist. Und wenn der Angreifer aber Adresse 7 zugreift und das lange dauert, weil wir erst die Verdrängung haben, wissen wir, dass der Victim-Prozess dieser Adresse angefasst hat. Das heißt, der Angreifer kann herausfinden, dass das Opfer irgendetwas in dieser letzten, in diesem letzten Set angefasst hat. Und kann jetzt noch nicht sagen, was die Inhalte waren, aber er kann sagen, welche Set-ID das waren. Also, das Wichtigste in Kürze, Caches sind sehr wichtig für die Performance auf Prozession. Sie machen einen sehr hohen, ja, es ist, es gibt einen riesen Speed-Unterschied, Geschwindigkeitsunterschied, ob man einen Cache hat oder nicht. Aber der Nachteil ist, dass dieser große Zeitunterschied es auch erlaubt an einem Angreifer herauszufinden, was ein Opferprozess im Cache gerade benutzt hat. Bei den vorgestellten Attacken, ja. Und das Wichtigste, was man im Kopf halten muss, ist, diese Cache-Attacken, wir wissen, was der Opferprozess angeschaut hat, aber nicht was, wo, aber nicht was. Also, wie sieht so ein, wie sieht jetzt so etwas aus, wenn wir das als Bild darstellen? In diesem Bild sind wir eine horizontale Achse, das ist die Zeit, also jede Spalte ist eine, eine zeitliche Iteration, eine zeitliche Messung von der Fraubattacke, und die vertikale Achse sind die Set-IDs aus dem Cache, die verschiedenen Orte im Cache. Und ein Pixel ist weiß, wenn das Opfer darauf zugegriffen hat, in dieser Zeit, Spanne. Man sieht also in dem Muster quasi wieder, wie das Opfer auf den Speicher zugereicht. In diesem Beispiel geht es um eine AIS-Verschlüsselung, welche ca. 20 Mal ausgeführt wurde, und man sieht, dass sich das Ganze immer wieder wiederholt, weil man sieht wiederholende Zugriffs-Muster im Cache. Wir wissen, können jetzt also herausfinden, was das war, aber was hat das jetzt mit AIS selber zu tun, wenn wir jetzt dasselbe AIS nehmen, aber einen anderen Schlüssel mit AIS, dann gibt es ein anderes Muster. Also nur dadurch, dass sich der Schlüssel geändert hat, hat sich das Zugriffs-Muster verändert. Wir wissen also, dass im Key ein Teil, wenn wir genug solche Änderungen haben, dann können wir etwas auf den Schlüssel, auf den Key schließen. Wir wollen halt jetzt möglichst nahe herausfinden, was dieses Geheimnis dieses Schlüssel ist. Wie können wir diese Attacke klassifizieren? Wir brauchen eine Metrik. Wir definieren die als röhrliche Auflösung, zeitliche Auflösung und Neust. Wirkliche Auflösung, wie genau wissen wir im Speicherbereich, z.B. wir wissen es auf tausend Bereich genau, oder wir sind auf zwölf Beiz genau, wo das Opfer zugegriffen hat. Zeitliche Auflösung, sehr ordentlich, wie genau können wir das in der Zeit sagen, haben wir das auf die millisekunde genau, oder dann wissen wir viel mehr, als wenn wir das nur alle eine Sekunde wissen. Also je kürzer die Zeit ist, desto besser wird die zeitliche Auflösung. Und so gibt es quasi ein besseres Bild von den Cash-Zugriffen. Das Letzte ist Neuse oder Larm, wie genau sind denn unsere Werte innerhalb dieses Cashes? Wir können false positives oder false negatives haben, mit diesen Attacken, die ich vorgestellt habe, das brauchen wir, und sind in der Kopf gehalten. Das waren Cash-Attacken ganz kurz gefasst, das war für uns jetzt die Attacke. Die erste Attacke, die wir uns anschauen, ist eine sogenannte Control-Channel-Attacke, aber wir können sie tatsächlich analysieren, das lohnt sich trotzdem. Wenn ich erinnere, dann auch die Memory-Management bei SGX, das heißt, wenn ein Page-Fold in der Enclave passiert, dann wird dieser Page-Fold ja vom Kernel in der Regel geredet. Das heißt, der Kernel muss wissen, welche Page jetzt reingepage braucht, damit die Enclave weiter ausführen kann. In der Control-Channel-Attacke gibt es im nicht vertreten System jeder andere Page von der Enclave aussah. Das heißt, das Betriebsteam kann ausführen. Das Betriebsteam bekommt eine Liste von sequenziellen Speicherzugreifen. Das ist eine sehr generelle Attacke. Man muss überhaupt nicht verstehen, was in der Enclave passiert, sondern wir laden einfach irgendeine Enclave und können als Attica-Körner sehen, welche Pages von dieser Enclave die Enclave zugereift. Wir wollen nicht aufhören, wo das Betrieb schlecht war und was der offene Page, denn es zeigt beim Page-Fold nicht, welche Aufsette der Enclave war. Die zeitliche Auflösung ist gut, aber nicht besonders gut, denn wir sehen zwar verschiedene Seiten, aber wir sehen nicht die Sequenzienzengrüffe auf der einen Seite, denn wenn es dir reingepaged lassen, so lange die Page-Fold arbeitet. Aber es gibt überhaupt keine Noise dabei. Dann gibt es ein Page-Fold, aber overall still a powerful Attacke. Aber wir still want to improve on that spatial resolution, want to be able to see what the Enclave is doing at greater than a resolution und what it does. Wenn anstatt der Ausführung in der Enclave zu unterbrechenden, in dem man Page-Fold generiert, dann sind wir Time Interrupts, um ein Ausfluss aus der Enclave zu forcieren, den den können rein und können die Time Interrupts sehr häufig auftreten lassen, sodass wir eine sehr hohe zeitliche Auflösung bekommen. Das betrifft dem, wenn der Time Interrupt feuert die Prime in Pope Attacke fährt auf den L1 Cache und diese Attacke lässt den Angreifer dann sehen, welche Daten die Enclave gerade zubegriffen hat. Das kann man auch auf den Instruction Cache erweitern, das heißt man erfährt nicht nur welchen Daten die Enclave zu begriffen hat, sondern tatsächlich auch welche Instructions und das ist dann doch etwas der Gemeinde und auf jeden Fall auch deutlich mächtiger. Hinsichtlich der Metriken sehen wir, dass die räumliche Auflösung deutlich besser ist, nur noch die größere einer Cache-Line, also 64-byte, und die zeitliche Auflösung ist nach dem Paper fast unlimitiert, denn der bösartige Kernel kann die Time Interrupts sehr sehr nah beieinander platzieren und so sehr sehr kleine Zeitabschlüsse von der Anwendung vermessen. Und die Neues ist tatsächlich immer noch relativ niedrig, denn die Chancen von einem false positive oder negativ sind gering. Wir können noch auf Truson-Tex betrachten, die ganzen Attacke, die wir bisher betrachten, waren ja alle gegen GX, und ja, da ist ja interessant, was die öffentlichen Attacke auf Truson sind. Eine heißt True Spy, die ist konzentrationell relativ endizoll Prime-Prop-Attacke, also Cache-Zone-Attacke, die auch auf den einen Startencache abzielt und anstatt dem Opferprozess die ganze Zeit zu unterbrechen, verführt die True Spy-Attacke und dann den Prime-Step, dann eine volle IS-Verschlüsselung, und dann ein einmaliges Traum. Warum machen sie das? Die Secure-Welt ist geschützt und ist nicht unterblechbar und das heißt, die Autoren können trotzdem Statistik verwenden, um trotz relativ großer Neues den Schlüssel zu extrahieren. Sie müssen nicht mehr im Kernel laufen, um diese Attacke zu fahren. Wieder die Metriken, die räumliche Auflösung ist auf dem Prozessor, auf dem das gemacht wurde. Die zeitliche Auflösung ist relativ schlecht, weil wir nur eine einzige Messung pro Aushöhung bekommen, weil sie nicht interruptible ist, und die Leitung ist relativ hoher Neues, weil sie vom User-Land aus geführt wird. Aber selbst wenn wir das vom Kernel aus machen, hätten wir immer noch mögliche Vorheitspositives oder Negatives. Also, wir würden das gerne ein bisschen verbessern. Also, wie können wir diese zeitliche Auflösung verbessern? Wir möchten da ein bisschen mehr an SGX herankommen, die zeitliche Auflösung soll verbessert werden. Die sichere Welt ist geschützt und nicht unterbrechbar. Dazu gehen wir jetzt zurück auf dieses Diagramm. Es ist wahr, dass, wenn ein Interrupt auftritt, dann geht das zum Monitor. Der Monitor ist in der sicheren Wert. Das ist auf Exception Level 0 und geht zur Exception Level 3. Das hilft uns nicht notwendigerweise weiter. Aber wenn wir ein Interrupt setzen, dann können wir unseren Programmfluss in den nicht vertrauenswürdigen Code umleiten. Theoretisch. Praktisch hat das Linux ein EL1 in der sicheren Wert. Und so können wir sichere iOS schreiben. Wir können die Taston-Attack verbessern in dem, ja mit von der AD, ein Core führt den sicheren Code aus, der andere den unsicheren. Der nicht sichere schickt ein Interrupt an der sicheren. Das gibt uns eine Überlappung von Attacker und Victim. Und wir haben jetzt diese beiden Cores, Attack und Victim Core. Der Interrupt wird aufgenommen vom Monitor. Das gibt ihn weitere ansichtlichere OS mit Tricksystem. Und da geht es dann weiter an den Angriffskode. Und in der sicheren Welt wird dann irgendwann weitergemacht. Und wir wiederholen das, bis wir genug Daten haben. Wir haben jetzt eine bessere Auflösung von eigentlichermaßen gute oder fast unlimitierte zeitliche Auflösung anstatt nur eine Proausführung. Wir sitzen mit dem Neues aus, dass wir ihn auch noch verbessern. Dann kriegen wir quasi ein klareres Bild und sehen unsere Geheimnisse besser und klarer. Wir können in Kernel die Messungen ausführen. Aber alternativ können wir auch anderen Zyklus-Counter benutzen. Es gibt Performance-Counter für verschiedene Events wie Cash Misses und Typischen Cash-Szenario haben wir keinen Zugriff. Darum wurde es auch noch nicht so im Detail angeschaut bis jetzt. Wir in einer präligierten und unpräligierten Welt haben wir aber Zugriff auf diese. Wir können also eine sehr genaue Counter darüber, ob es ein Cash Miss oder Cash Hit war. Etwas, das noch mehr tun sollte, vielleicht wollte diese Armveracht-Counter benutzen. Wenn wir die Staaten aus der unsicheren Welt und die sicheren Welt einsetzt und wieder aussetzt, dann wollen wir eigentlich wissen, wie viele Kut-Instruktionen von der sicheren Welt ausgeführt wurden. Leider hat Arm daran gedacht und hat es schon. Also unter Arm ist es nicht möglich, diese Event-Counter aus der unsicheren Welt heraus zu programmieren und dann in der sicheren Welt weiterlaufen zu lassen. Unter Arm V7 geht das aber noch. Wir können jedenfalls dann mit der Performance-Counter weiter die Performance-Counter benutzen, um herausfinden, was tatsächlich im Cash so abgeht an der Stelle und dadurch, dass wir die Welt direkt aus den Performance-Countern heraus bekommen, also direkt vom Prozessor gesagt bekommen, was da passiert, haben wir minimales Neues und haben uns noch sehr gute Methodiken. Wie implementiert man an diesen ganzen Attacken? Wir müssen hier tatsächlich auch mal bauen. Das heißt, das Ziel ist, diese Attacken-Auftrassen zu implementieren und normalerweise ist das Betriebssystem in den nicht-sicheren Gebogen genutzt basiert und das ist, wenn wir nutzen, wenn also ein keine Modul schreiben, das Performance-Counter benutzt und Inter-Processor interrupts, also interrupts sich einen Prozessor an den anderen checken, um diese Attacken durchzuführen. Das heißt, und wir betrachten hier erstmal das Nexus 5X, aber dadurch, dass wir hier diese Situation haben, mit dem uns das System, und genau auf das Garnemodul, können wir das leicht auffahren und das System fortieren und so können wir dann eben die Cash-Attacken auf vielen verschiedenen Plattformen tatsächlich zahlen. Wir limitieren dadurch, dass wir irgendwas im Kernel haben. Die Sammlung von diesen Messwerten auf die Zeit während die sichere Welt läuft, das heißt, wir haben etwas mehr Neues in der Aufteilung und können tatsächlich auch mehrere Attacken auf verschiedene Cash-Teile also z.B. eine Attacke, die Parallel sowohl den Data-Cache als auch den Instruction-Cache anschauen. Man kann sich die nebeneinander anschauen, z.B. in dem Tool, das ich geschrieben habe, dass eben diese beiden Sachen dann auch nebeneinander anzeigen kann. Und diese School-Tool kann dann eben mit dem Kernelmodul interagieren und zeigen. Welcher Code oder welches Speicherbild aussieht, das vom Secure-World-Code angefasst war. Die Idee ist, dass man eben diese Methode leicht wiederverwendbar macht und so möglichst viele Plattformen angreifen kann und überprüfen kann, ob ihr Code auch anfertig ist für diese Art von Attacken. Die Frage ist auch noch, können wir noch bessere räumliche Auflösung erreichen? Wir sind im Moment limitiert durch die Größe der Cashlines also 64-byte, aber bei SGX können wir tatsächlich noch genauer werden als 64-byte. Das geht mit sogenannten Branch-Shadow-Attacken bei SGX. Es gibt im Prozessor einen sogenannten Branch-Target-Buffer, der für die Verzweigungsverhersage also wo er spekuliert, wo die Ausführung weitergeht, wird er dafür benutzt. Dieser Buffer ist ähnlich zu einem Cash, aber vergleicht nicht die volle Adresse. Die selbe Adresse wird für eine eigentlich inkorrekte Adresse ausgelesen. Das ist eh nur für Branch-Prediction, also Vorhersagen, in dem Fall okay, und die Branch-Shadow-Attacke nutzt diese Überlappung, um eine geteilte Codezelle auf dem Branch-Target-Buffer auszuführen. Also wenn der Angriffer im SGX in der Enklave etwas ausführt, dann hoffen wir, dass die Ausführungsverhersagen sich überlappen mit etwas, das nicht in den SGX drin ist. Der Angriffercode könnte also so ja, möglicherweise, dass ja, quasi die Codeausführung vom Opfer vorhersagen, in dem er diese diese Attacke anwendet. Die Räumliche Aufrüstung ist fantastisch. Wir können individuelle Branches detektieren. Wir wissen, welche ausgeführt wurde, was nicht. Die zeitliche Auflösung fast unlimitiert, weil wir auch die Timer Interrupt verwenden können. Und das Noise ist sehr tief, weil wir halt diese Branches Miss-Prediction ausverminden können. Also wie sieht das jetzt mit Trashzone-Attacks aus? Kann man das übernehmen? Hier wird der BTB nicht geteilt, der Branch-Target-Buffer und aber es ist eigentlich wie die früheren Cash-Tax wenn die Attacke und Angriffer und Opfer-Memberiteile teilen, dann funktioniert. Wie sieht das jetzt mit dem BTB-Cache aus? Was wir eigentlich machen ist, wir füllen quasi den BTB-Cache mit Voraussage-Daten dann lassen wir das Opfer etwas ausführen und was halt den BTB füllt und der Attacker verfüllt dann nochmal sein Code aus und dann sieht man ob es falsche Vorhersagen gegeben hat. So, das ist jetzt exakter als aus dem Cash anstatt der BTB hat 2048 Sets und der Cash hat nur um die 200 irgendwas und so kann man das halt viel genauer vorhersagen. Im Nexus 5S, wo ich damit arbeite, ist die Granularität nicht mehr 64 Bytes, sondern 16 Bytes. So sehen wir welcher Ast aus dem Vertrauen zu den Code ausgeführt wurde auf 16 Bytes, genau. Was heißt das jetzt? Mit der ersten Attacke haben wir quasi eine Messung gemacht von diesen 256 Sets und mit Interups können wir die zeitliche Auflösung vergrößen, dann sieht das ca. so aus. Ihr seht, oben hat es kleine weiße Punkte und das heißt, das ist dann die gleiche Cash-Zeile, aber die hat immer wieder aufgerufen wird. Und so kann man halt sagen, was der Prozess gemacht hat. Die BTB-Attacke sieht jetzt so aus, ich hoffe ihr könnt's sehen. Also, wir schauen uns diesen kleinen Teil da an. Der sieht so aus. Das weiße Pixel ist ein Ausführungssprung, der quasi genommen wurde. Eigentlich quasi die verschiedenen Funktionen, wie sie aufgerufen wurden. Und das gibt uns halt sehr viele Informationen darüber, was die sichere Welt macht. Das ist sehr machtvoll, mächtig und wird in den neuen Tools verwendet. Was kann man dagegen tun? Also, die einzig gute Lösung ist, dass man Hardware nicht teilt. Man muss für sensitive Operationen separate Hardware benutzen. Da sieht das schon in verschiedenen Smartphones, z.B. in Apple SOCs, Systemchip oder das hat seinen eigenen Cash, die ist sicher ein Klave darin, hat einen eigenen Cash und so weiter. Das schließt eine ganze Klasse von Side-Channel-Attacken aus, in der man separate Hardware hat. Das Pixel 2 geht in eine ehrliche Richtung, hat Hardware-Schutzmodelle und hat auch eigene Cashes für einen sicheren Bereich. Und ja, ist das halt immer schwieriger herauszufinden, was in diesem Hardware-Modul vor sich geht. Wenn wir das nicht haben, dann können wir trotzdem wir machen mehr Code-Indexen in Hardware auslagern, aber andererseits machen wir halt, je mehr ex ausgelagert wird, desto größer ist auch die Wahrscheinlichkeit, dass ein Angriffskode ausgelagert wird. Also das ist auch immer die Frage, was hinterher zeitlich alles darin ausgeführt wird, in der Ausführung der Code-Kontografischen Code und so weiter. Kurzfristig müssen wir aber einfach Side-Channel-freie Software schreiben. Also Software, die nicht anfällig ist für Side-Channel-Attacken müssen sehr vorsichtig sein, was unser Software tut, also ob sie abhängig von dem Geheimnis, dass wir versuchen zu schützen, ihr Ausführungsverhalten ändert, also bestimmte Branches nimmt oder nicht nimmt, oder bestimmte Speicherbereiche anfasst oder nicht anfasst. Hierbei gibt es ein paar offensichtliche Limiterungen, zum Beispiel das Performance in den allermeisten Fällen abgebogen werden muss gegenüber der Sicherheit vor Side-Channel-Angriffen, die man bekommt. Die Trusted Executioner-Environments schützen auch nicht vor allem, es gibt immer noch Mikroarchitekturattacken, die attacken auf Mikroarchitektur-Ebene, die machbar sind. Die Attacken, die wir hier gezeigt haben, sind auch sehr mächtig und auch relativ einfach aufzusetzen und zu fahren. Das heißt, ihr könnt das auch leicht auf euren eigenen Code anwenden und das überprüfen. Zuletzt ist das Problem, dass nur einen einzigen kleinen Fehler benötigt, in einem Code, der auf irgendeine Art und Weise von dem zu schützenen Geheimnis abhängt, deswegen dann nicht mehr Side-Channel frei ist, um das Ganze zu weit zu bringen. Das heißt, wo daraus man ankommt, ist klar zu machen, dass ihr als Entwickler dazu verpflichtet seid, euch um diese Side-Channel-Attacken zu kümmern, sonst wird es keiner tun. Danke. Wenn ihr ausgehen wollt, tut das doch bitte ruhig. Wir haben jetzt 17 Minuten für Fragen und Antworten. Geht doch bitte zu dem Mikrofon. Es gibt noch keine Fragen von den Signallängeln. Also, starr mit dem Mikrofon 6. Es gab ein Symbol von Secure oder ASAS in der Trastung. Wenn die, wenn die sichere, ah, sorry. Bei AMV 8 gibt es verschiedene Arten von Interrupts. Wenn ich mich rede an die Thermologierende, dann gibt es ein IR-Code, ein IFU-Interrupt und die Secure-Mode handelt die FIU-Interrupt und senkt dann halt von dem Interrupt über ab, welcher der beiden Kölner entsprechend wählt, den Interrupt erhält. Hat jemand, ah, ich seh nicht, ich hab mir AMV noch nicht so genau angeguckt, soweit ich sagen kann, es ist einfach nicht so häufig verwendet, aber es gibt zwar viele verschiedene Trusted Executionen und Gebungen und wir haben uns hauptsächlich auf SJX und Trust Zone beschränkt, denn das sind einfach die weitest verbreiteten Technologien. Wenn Trust Zone verschoben werden, auf eine dedizierte Hardware verschoben werden, könnte man die Userspace-Attacken replizieren, indem man eigenen vertrauenswürdigen Userspace-Code ausführt darin. Ja, wenn man tatsächlich seinen eigenen Code da draufladen kann, dann könnte man das tun, aber auf den meisten Modellen, die es heute gibt, wird da z.B. Code-Signing als Medi-Guide-Stream eingesetzt, sodass nicht einfach jeder da Code ausführen kann und eben die eigene Onklaves nicht als Rake benutzen kann. Einige dieser Attacken sind mehr oder weniger machtig, gegen SJX oder ja. Heißt das jetzt, dass die Trusted Executionen-Environments ein attraktives Ziel sind? Es gibt tatsächlich schon einen Vorteil, das man will, zu nutzen, aber den Punkt, den ich von mitten wollte, war, obwohl sie die Trusted Executionen-Environment eine ganze Reihe an interessanten Features bereitstellen, schützen das jetzt eben nicht vor den Attacken, die ich präsentiert habe. Das heißt, man muss sich bei der Entwicklung dessen bewusst sein. AMD macht etwas mit verschlüsseltem Speichern und ich bin nicht sicher, ob sie auch die Adressen verschlüsseln, aber wäre das eine Verteidigungsmöglichkeit? Noch mal, ich kenne mich bei AMD nicht so genau aus, aber SJX verschlüsselt tatsächlich auch Speichern, nämlich bevor es den CPU verletzt, also nach dem Lasten-Cache, aber als der Angreifer interessiert uns eigentlich gar nicht so genau, welche Daten da drin liegen, sondern eben nur, welche Cache-Line es war. Wenn man Adressen verschlüsselt, würde das helfen. Ja, ich wüsste jetzt nicht, wie man die Adressen selber verschlüsselt, denn solange die Adressen auf dasselbe Set fallen, wie das Opfer, kann das wirklich dann halt dir, also könnte man diese mal Tacken fahren. Hat die Sicher-Enklave in Samsung auch keine ... Also kann man wissen, was die Sicher-Enklave als Wert zurückgeliefert hat. Also es geht um die Truth-By-Attacke. Also ich glaube, dass wäre implementationsabhängig, solange es noch eine Produziere an bestimmten Schlüssel verwendet, dann wäre das attack dafür geeignet. Kannst du eine Referenz empfehlen, um diese Cache-Branchen und so weiter besser zu verstehen? Ja, ich kann immer noch kurz über die Referenzen gehen. Also ich habe zahlreiche Referenzen dran gehangen, zu den Verstehenden Attacken. Könnt ihr im Video direkt sehen? Ansonsten wartet euch die Folien runter. Und viele von denen beinhalten sehr gute Ausgangspunkte. Das Truth-By-Paper erklärt das jetzt auch nicht direkt, aber es gibt auch wieder sehr gute Ausgangspunkte, um sich da weiter zu informieren. Meine Frage ist sehr ähnlich. Wie hart ist es, effektiv sein Schlüssel herauszufinden? Ist das ein diesen Machine-Learning-Problem oder kann das auf einem kleinen normalen Maschine gemacht werden? Es ist auch wieder sehr implementationsabhängig. Es ist letztendlich immer auch abhängig von der Software, die man da angreift. Und wie stark die Daten liegt. Und wie leicht das dann über die Neues und Weg zu sein ist. Die STX-Fold-Injection Attack zum Beispiel braucht relativ viel Brutforce und relativ viele rechte Ressourcen, um das zu machen, aber generell je vor allem die Auflösung ist, desto leichter ist die Attacke. Ich hoffe es ist nicht so naiv meine Frage. Ich frage mich, all diese Attacke sind auf Cache-Misses basierend. Ist es möglich, den Cache zu flaschen oder da Neues quasi hineinzufügen, um quasi, ah, kann das Offer quasi etwas machen, Neues und so weiter, um den Attacke auszutricksen? Ja, das ist tatsächlich möglich und das ist auch komplett richtig. Also die Attacke wird dadurch schlechter. Das heißt, wenn wir in der Anwendung jedes Mal den Cache flaschen oder Neues einfügen, dann macht das die Attacke sehr viel schwerer. Er fordert mehr Anforderungen, er fordert mehr Rechneressourcen, aber letztendlich hat man dann die Trade-off zwischen Performance und Sicherheit. Wie gut sind wir jetzt wirklich geschützt für so eine Ring-Null-Corporation? Weil wenn wir sehen, wie schlechter schon Browser geschützt sind, dann wie sehr können wir dann also empoweren? Die Frage ist warum, ob das ein realistisches Angangsmodell ist, dass wir immer Kooperation vom Kernel brauchen, weil nur dann geht die Neues ja soweit runter. Aber es gibt tatsächlich Szenarien, z.B. bei DRM oder so was, wenn der Angreifer tatsächlich einfach der User ist und gerotetes Telefon hat, um die DRM-Key aus der Stimtrusted Executioner-Environment zu extrahieren, dann ist tatsächlich unser Angangsmodell, dass der Kernel bösartig ist. In anderen Fällen nicht. Danke für den guten Tag, kurze Frage. Hast du Erfolgs-Stories, Quasi, oder Angriff dieser Trustzone? Keine, die ich zu diesem Zeitpunkt jetzt veröffentlichen möchte. Danke schön, wieder einen großen Applaus an Kiegen. Damit verabschieden Sie sich aus der Übersicht.