 Der Weg unseres nächsten Sprechers ist von gebrochenen Trustzone gepflastert. Alles, was er anfasst, löst sich in seinen Fingern auf. Er ist einer von Forbes 30 unter 30 in Technologie. Gibt einen herzlichen Applaus für Thomas Roth. Willkommen zu meinem Talk Trustzone M Hardware Angriffe auf Sicherheitsfeatures. Ich bin Thomas Roth, ihr findet mich auf Twitter als X-Tag Smashing. Ich bin Sicherheitsforscher, Berater und Trainer bei verschiedenen Sicherheitsfirmen. Bevor wir anfangen, ich möchte ein paar Leuten bedanken. Josh Stadka und Dimitri Nitzost-Passoff, die sehr hilfreich waren, wenn ich immer nicht weiterkam und Hilfe brauchen. Colin Of Lin gab mir konstant Feedback und Tipps und hat mir viel geholfen. Und diese Leute und viele Leute, die den Weg für diesen Forschung frei gemacht hat, wäre nicht vier. Auch viele danken für NXP und MicroShift, mit denen ich für diesen Talk zusammenarbeiten musste. Und es war großartig. Ich hatte einfach sehr schlechte Herstellerfahrungen. Diese hier waren sehr gut. Außerdem, früher arbeiten Colin Flin und Alexi Dua haben dieses Jahr ein Papers-Release, über das auch auf per differenzielle Leistungsanalyse auf Trustzone geguckt haben. Abgesehen davon ist Trustzone M relativ neu. Aber viel Arbeit hat über die große Trustzone gemacht worden. Und es gibt auch sehr viel Arbeit über Fault-Injection, Fehler-Injektion, ganz im Allgemeinen. Also, was ist Trustzone M? Trustzone M ist die kleine Trustzone. Es ist eine kleinere Version der Trustzone, die man auf Cortex-A-Prozessoren findet. Also, wenn ihr ein iPhone habt, dann seid der hohe Wahrscheinlichkeit, dann sind zum Beispiel eure Schlüssel oder Passwörter in der Trustzone auf dem Cortex-A-Prozessor gespeichert. Trustzone erlaubt sichere Abteilungen auf einem ansonsten unsicheren Prozessor. Also, wenn bestimmte Dinge nur im sicheren Kontext zugegriffen werden, dann speichert man das in der Trustzone. Und was auch ist, ist, dass solche Prozesse kommen mit zwei MPUs. Letztes Jahr hatten wir ein Talk über Bitcoin-Vollets. Wir haben das Problem, wir haben den Betriebssystem, das ist sehr komplex, das muss die Grafik anzeigen, User-Interface, und es gibt relativ hohe Wahrscheinlichkeit, dass es irgendwie kompromissiert werden und dann in all deine Geheimnisse und all deine Bitcoins weg. Mit Trustzone gibt es die Möglichkeit, ein zweites, kleineres Betriebssystem laufen zu lassen, dass diese Speicherwürde, Schlüsselmaterial hat und das dann sicher sein soll. Warum ich auf Trustzone M geguckt habe, ist, dass wir viele Anfragen gekriegt haben für Beratungen zu Trustzone M. Viele haben gefragt, wir möchten solche Dinge machen, aber wir möchten es sicherer machen, und Trustzone N war relativ neu. Soweit ich weiß, gibt es relativ wenig offentliche Forschung über Trustzone M, und es gibt wenig Unterlusten. Es gibt viele Leute, die fangen an, sie als sichere Chips zu benutzen. Also es gibt Leute, die überlegen, die einen Autoschlüssel einbauen wollen, oder hat wir Wollets für Bezahldienstleistungen. Und ein Begriff, der immer wieder aufkommt, dies ist ein sicherer Chip. Aber was ist ein sicherer Chip? Ohne ein Bedrohungsmodell gibt es nichts wie ein sicheren Chip. Und weil es so viele mögliche Angriffe gibt, muss man einfach wissen, wogegen möchte ich mich verteidigen. Man kann es bei einem Chip könnte Hardware-Feature haben, die das Software sicherer machen, zum Beispiel das NX-Bit, das man speichelbar nicht ausfüllen kann. Oder es gibt Chips, die gegen Hardware-Attacks vergleichen sind, keine Debugsport dagegen, Seitenkanal-Attacken verteidigt. Und die Informationen von den Herstellern sind häufig sehr unklar oder sogar verwirrend, dass sie einfach nicht sagen, okay, ja, dies ist ein sicherer Chip, aber sie sagen nicht, wogegen sie schützen, zum Beispiel man weiß nicht, ob der Chip sicher ist, aber gegen Fault-Injection-Angriffe sicher ist, oder ob das außerhalb des untersuchten Bereichs ist. So, und was wir jetzt machen worden, sind lokale Device-Only-Attacken. Also es gibt Geräte, alle Angriffe, die wir haben, dafür muss man das Gerät in der Hand haben. Und ja, das ist unser Plan für heute. Wir fangen mit einer kurzen Einführung in Trustzone M an, mit viel Theorie, für Speicher-Layout und so was. Wir reden ein bisschen davon, wie man Fehler injiziert, und dann werden wir reale Chips eingreifen, die drei hier aus der Liste eben. In einem Cortex-M-Prozessor hat man einen flachen Speicher-Layout. Man hat keine MMO, alle Bereiche sind in dem gleichen Speicherbereich, in dem gleichen Bereich. Und was ein Trustzone M erlaubt, man kann den Speicherbereich partitionieren für sichere und nicht sichere. Man kann zum Beispiel den Flash in einen kleinen sicheren und einen größeren, nicht sicheren Bereich auftauchen. Das Gleiche für den Arbeitsspeicher, für das RAM, oder auch für Peripherie. Man kann entscheiden, ob bestimmte Peripheriebausteine sicher oder nicht sicher betrachtet werden sollen. Also lassen wir uns die Zustände angucken. Sicher oder nicht sicher. Also wenn wir einen sicheren Code haben, dann werden wir in welchem Code in der nicht sicheren Welt erhufen. Also das ist im Prinzip der höchste Privileg, das man haben kann. Aber die andere Sache, wenn man aus der nicht sicheren Welt in die sichere Welt guckt, das ist nicht sicher. Wenn man zum Beispiel in den Code springen will, der hinter irgendwelchen Schutzmechanismen ist, dann geht das nicht. Deshalb, wenn man versucht, aus einem nicht sicheren Code und sicheren Code zu springen, dann wird das eine Ausnahmelbedingung generiert. Deshalb gibt es diese Zwischending, dieses non-secure-callable diesen Code. Und der nicht-sicheren Code kann diesen nicht-sichereaufrufbaren Code oder NSC-Code rufen. Und der muss Adressen aufrufen, die einen SG Instruktion haben, so eine secure Gateway, also sicheres Tor. Die Idee ist, wenn man einen nicht-sicheren Kern laufen hat, dann hat man vermutlich auch irgendwo einen sicheren Kern laufen und der wird bestimmte Systemaufrufe veröffentlicht. Und wir wollen irgendwie aus dem nicht-sicheren Code diese Systemaufrufe machen. Und wie ich gerade gesagt habe, das können wir nicht, weil das eine Ausnahmelbedingung erzeugen wird. Und der wiegt wie das unter Trust on Amles. Man macht solche sehr einfache Anpassungsfunktionen-hacken, diese Veneer. Und dann würde er diese Load-Key-Veneer-Funktion haben, die ruft dann die Load-Key-Funktion ab. Und diese Funktionen sind sehr kurz, zum Beispiel, sind sehr kurz. Es sind drei Instruktionen. Also es gibt diese secure gate Instruktion und dann einfach eine brand Instruktion in die eigentliche Funktion. Deshalb beenden wir mit diesen Diagramm sicher-kann, nicht-sicher-rufen, nicht-sicher-kann, diesen nicht-sicher-aufrufbaren NSC-Bereichaufrufen und NSC-kann, den sicheren Bereich aufrufen. Aber woher wissen, welchen Sicherheitszustand eine Adresse hat? Dafür benutzen wir im Cortex-M die Attribution-Units, dafür gibt es vier Units in der Cortex-M. Es gibt die Security-Attribution-Unit. Die erste, die wird von Arm selbst definiert, ist praktisch bei allen Prozessoren die gleiche. Dann gibt es die ID-AiU, die implementationsdefinierte Zuschreibungseinheit, die wird halt von dem Hersteller im Prinzip was gemacht und um den Sicherheitszustand eine Adresse wissen will, dann muss man diese beiden Zuschreibungseinheiten kombinieren. Und wer immer die höher ist, deren Wert gilt. Also, wenn immer die SRU sagt, dann ist es sicher und die ID, die implementationsdefinierte ID-AiU, sagt, es ist nicht sicher, dann gewinnt der restriktivste Zustand. Also, es wird als sicher betrachtet. Also, das ist hier die Tabelle. Also, wenn beide sagen, nicht sicher, es ist nicht sicher. Wenn beide sagen, es ist sicher, es ist auch sicher. Wenn sie sich nicht einig sind, ist es sicher und nicht sicher. Dann ist es trotzdem sicher, weil sicherer oder höhere Privileg ist. Die andere Richtung ist auch gleich. Und auch hier wird nicht sicher aufrufbar. Also, sicher ist mehr Privileg, als nicht sicher, nicht sicher callable. Und halt, wenn wir nicht sicher callable und nicht sicher mürchen, kriegen wir ein nicht sicher callable. Meine Hypothese war, wenn wir irgendwie diese Zuschreibungseinheiten, diese attribution units kaputt machen, dann machen wir die gesamte Sicherheit kaputt. Also, lasst uns zuerst auf die Security attribution unit, die Standard-Unit von ARM gucken. Die ist standardisiert, ist nicht auf allen Chips vorhanden, und man kann sie auch tun. Und wenn sie halt ausgeschaltet ist, dann wird alles Sicherheit. Und wenn man sie einschaltet, es sind keine Regionen definiert, wird immer noch alles als sicher angenommen. Dann kann man hingehen und sie einschalten und bestimmte Regionen als nicht sicher oder als NSC machen. Und das ist relativ einfach. Man hat im Prinzip diese fünf Register, das SRU Control Register, wo man die SRU ein- und ausschalten kann. Es hat den SRU-Typ, der ihm die Zahl der unterstützten Regionen angibt. Dann haben wir das Regionsnummerregister. Damit kann man die Region auswählen, die man stellen will. Und dann kann man die Anfang- und Endadresse einstellen. Also, wenn wir die Region 0 missen, dann setzen wir das Nummerregister zu 0, die Basisadresse zu 0, Hex 1000, und dann setzen wir die Limitadresse, die Grenzadresse zu 1fe0, was das Gleiche ist wie 1fff. Da sind bestimmte Bits noch dahinter. Und wir schalten die SRU an, dann setzen wir das Controlregister aus. Wenn wir eine andere Region konfigurieren wollen, dann machen wir, setzen wir zum Beispiel das Nummerregister auf 1 und die Adress-Register auf andere Werte. Um zusammenfassen, wir haben drei Sicherheitszustände für den Speicher. Wir haben S-sicher, NSC nicht sicher aufrufbar und NS nicht sicherbar. Und wir haben diese beiden Zuschreibungseinheiten, die SAU, die Standardisierte von ARM und die IDAU, die möglicherweise herstellerspezifisch ist. Wir benutzen diese beiden SAU und IDAU sehr viel, deshalb war das jetzt sehr wichtig. Lass uns über Talk, Fault Injection sprechen. Die Idee hinter Fault Injection ist, wie man es auch nen Glitching, was wir machen wollen, ist, wir wollen Fehler in den Chip einfügen. Zum Beispiel, dass wir am Power-Level umdrehen, also am Energie-Level, ich füge ihm weniger Strom zu und füge es dann wieder zu. Wenn wir einen Laser draufhauen, wir können am Signal der Hardware-Uhr herumdrehen. Elektromagnetische Schock, alles, was ihr euch vorstellen könnt. Und was wir jetzt ganz speziell angucken wollen, ist Spannungs-Glitching. Das heißt, wir schreiten die Elektrizität an den Chip für eine sehr, sehr kurze Zeit ab und haben dabei sehr präzise Getimtes, also getimtes Verhalten. Und wir schauen auf dem Oszilloskop. Wir sehen hier stabile Spannung und dann auf einmal einen Sprung nach unten und kommt sofort wieder hoch. Und dieser Abfall in der Spannung ist nur ein paar Nanosekunden lang. 10, 15 Nanosekunden kommt auf den Chip an. Und was das erlaubt ist, wir können zum Beispiel Instruktionen auslassen. Wir können Speichervorgänge beim Flash damit kaputt machen. Wir können auch Register lesen und schreiben behindern. Aber für mich ist das interessant, dass ich Anweisungen auslassen kann. Das kann zum Beispiel mir erlauben, dass ich über Anweisungen hinwegspringe, die interessant werden. Das ist ziemlich einfacher Boot-Up-Code. Das ist eine Initialisierung. Dann sehen wir, dass die Firma verifiziert wird. Und dann sehen wir, hier ist das ein Check, der prüft, ob das funktioniert hat. Und wenn wir jetzt glitchen könnten über diesen Check hinweg, dann hätten wir in Prinzip eine Möglichkeit, auch zum Beispiel, die Filme, die wir verändert haben zu buden, obwohl es eigentlich nicht erlaubt sein soll. Also was müssen wir jetzt machen? Wie wäre es denn, wenn wir zum Beispiel über Enabled Trust Zone drüber springen könnten? So was machen wir jetzt in der Praxis? Wir müssen auf jeden Fall für eine Weile warten und müssen dann einen Puls, also einen Strompuls, genau im richtigen Zeitpunkt absenden mit einer sehr feinen Präzision von 10 Nanosekunden. Also was an der Stelle sehr funktioniert, wenn man so eine hohe Präzision braucht, ist ein FPGA. Wir haben zum Beispiel den Lattice-Ice-Stick verwendet und man braucht noch einen billigen Mosfet. Das heißt, das ist ungefähr 30 Dollar. Auf der Setup-Site haben wir ein FPGA, der hat einen Trigger-Eingang. Das heißt zum Beispiel die V-Set-Line und dann haben wir einen Output für den Glitch. Das heißt, wir löten das jetzt alles zusammen, bzw. stecken das alles zusammen. Wenn der Glitch-Puls hochgeht, dann setzen wir den V-Set und dadurch wird die Spannung unterbrochen beim Chip und wir können über eine Anweisung drüber entspringen. Wie funktioniert das jetzt? Ein Mikrocontroller hat heutzutage viele Chips in sich drin. Zum Beispiel den CPU-Core, wir haben das Wi-Fi, wir haben auch GPIO. Und oft ist es so, dass diese Peripheriegeräte auf unterschiedlichen Spannungen laufen. Also zum Beispiel, Wi-Fi kann 1,3 Volt haben, auch wenn der Eingang des Mikrocontrollers 3,3 ist. Das heißt, man braucht einen Regulator im Mikrocontroller selber, der dafür sorgt, dass die Spannungen erzeugt werden, die die internen Chips brauchen. Was interessant ist, dass hinter den Core-Regulierern, also den Spannungswandern, sind externe Kondensatoren und was die machen ist, dass sie die Spannung glätten als Output des Kernregulierers. Was es aber auch erlaubt ist, dass es direkt einen Zugriff auf die die CPU-Kern-Spannungsversorgung ist. Das heißt, wenn wir jetzt den Kondensator abbasteln, können wir direkt Zugriff auf die interne Spannungsversorgung des CPU-Kerns. Das Problem ist, dass es diese Kondensatoren braucht. Es funktioniert halt nicht wirklich stabil. Was du machen kannst, ist, du kannst auch eine externe Spannungsversorgung und die auf die richtige Spannung setzen, damit du die Spannung stabil hältst und gleichzeitig kannst du damit glitschen. Also was wir machen ist, wir haben den Lattice-Stick, um auch die Spannung für das Gesamtgerät zurückzusetzen, damit wir auch neu buten können. Wir haben das MOSFET und wir haben natürlich noch die Spannungsversorgung. Wenn wir das jetzt alles zusammen basteln, dann funktioniert es beim ersten Mal, beim zweiten Mal auch noch. Und beim dritten Mal ist es scheiße. Und in dem Moment, wo irgendwas mit 100 Jumperkabeln auf deinem schraptisch kaputt geht, ist es eigentlich nur ganz von vorne anfangen. Deswegen haben wir jetzt den Mark 11 verwendet. Es hat ein FPGA drauf, es hat ein Glitch-Support. Wenn ihr im Gipsen gelesen habt, dann wisst ihr, wo es herkommt. Und es enthält ein Lattice-Ice-40, was eine komplett offene Toolchain ist. Das erlaubt uns, dass wir super schnell neue Glitch-Codes und Trigger verwenden können. Und das macht die Entwicklung total schnell. Es hat auch 3 interne Spannungsversorgungen. Es versorgt mit 3,35 und 1,2 Volt. Und das ist gebaut rund um schon bereits existierende Geräte. Also zum Beispiel der FPGA basiert auf dem 1-Bit-Squared Icebreaker und der Eingang ist der Nano-Analog Chip-Lister. Wie immer mit der Hardware in dem Moment, wo wir machen die gleichen Erfahrungen wie immer, dass die Produktion der Hardware länger dauert als man angenommen hat. Aber ihr könnt nicht bei Twitter ansprechen. Und ich kann euch damit versorgen, die Version von uns kostet ungefähr 40 Dollar. Den ersten Chip, den ich gesehen habe, der Trust on M verwendet, ist der Microchip Sam LF. Der wurde im Juni 2018 rausgegeben. Ziemlich langsam das Ding, hat nur 32 Mhz, 64 KB Flasche und nur 16 KB SRAM. Aber es ist sowas von billig. Er kostet nur knapp unter 2 Dollar. Er hat immer nur einen bestellt. Wir hatten Leute, die zu uns kamen, die gesagt haben, sie wollen einen Trusted Platform Module bauen oder ein Hardware Wallet oder andere Geräte. Und wenn wir uns jetzt die Webseite von dem Chip anschauen, dann sehen wir, dass es ein Haufen Security drin hat. Es war ein Award-Gewinner 2018. Und jetzt ist Secure jetzt Secure sucht auf der Webseite und dann habt ihr 57 Ergebnisse und das ist deshalb auch 57fach sicher. Also ihr habt hier Chip-Level Security. Es hat ein Active Shield. Es hat Mikroprobing-Attack-Sicherheit. Es hat Mikroprobing-Attack-Sicherheit. Es hat sogar ein Erkennungssensor für einen Stromabfall am VDD Core. Also im Prinzip, was wir uns auch interessieren. Sie wollen damit was sie damit sagen, ist es mit diesem Absatz, dass es nicht sicher ist gegen Hardware-Attacken. Aber das könnte man auch anders verstehen. So, jetzt wollen wir uns mal über die Trustzone in dem Chip unterhalten. Dieses Gerät hat nicht diese SAU, die wir vorhin besprochen haben. Es hat nur eine EDAU und die Konfiguration dafür steckt in der Userzeile, was im Konfigurationsflash hängt. Es ist, soweit ich weiß, Flash basiert. Es können natürlich auch Sicherungen sein, aber es ist nicht Flash. Und wenn es vom Konfiguriert wurde, vom Bootraum, beim Start des Chips, die Idee hinter dem EDAU ist, dass alles in zwei Teile geteilt wird in unsicherer Teil, z.B. den Bootloader, nur ist immer ein Sicherer und ein Unsicherer und ihr könnt auch noch die Anwendungen aufteilen. Und die Größe dieser Bereiche ist durch diese fünf Register festgelegt. Das heißt, wenn ihr jetzt einen Teil kleiner und einen größer machten müsst, müsst ihr einfach nur mit diesen Registern spielen und dann ändert sich der. Jetzt ist die Frage, wie können wir das angreifen? Mein Ziel war am Anfang, dass ich ein Daten auslesen kann aus der nicht-sicheren Welt. Das heißt, ich will die Sicherheitslücke überspringen und schauen, dass ich sichere Daten aus der nicht-sicheren Welt abgreife. Mein Idee war jetzt, dass ich den Bootraumcode glitchen kann, der die EDAU-Konfiguration liest. Dazu müssen wir aber überhaupt erst mal verstehen, ob dieser Chip glitchbar ist. Ist der dafür anfällig oder fliegen wir dann sofort raus? Das heißt, ich habe ein sehr einfaches Setup aufgebaut, wo ich aus einem Loop raus glitchen wollte und eine Lampe zum Leuchen bringen. Und ich habe es in fünf Minuten geschafft. Es ist superstabil. Es ist irgendwie was nicht stimmt. Das ist mein Tester, der falsch ist und der Loop raus ist. Es ging noch nie so schnell wie hier. Das heißt, es war super einfach. Es war total simpel. Ich hatte sofort Erfolg. Dann habe ich 2 Stunden damit zugebracht, rauszufinden, ob das richtig ist, was ich gemacht habe oder ob ich einen Fehler gemacht hatte. Jetzt ist die Frage, was glitchen wir am Ende? Wir werden in dem Bootvorgang diese Register aus dem Flasch gelesen und dann wird irgendwie Hardware konfiguriert. Aber wir wissen nicht so genau wie, weil wir können das Bootraum nicht ausgeben und das Manual ist mir viel zu lang. Ich lese keine Handbücher als Millenium und ich lese nur, was ich muss. Das heißt, die Grundidee ist, wenn ich jetzt den richtigen Moment abpaste, dann würde das gelesen werden. Wenn wir es wahrscheinlich auf 0 setzen, das heißt, weil die meisten Initialieren sowieso mit 0 und wenn wir jetzt den richtigen Moment abgreifen, wo das gelesen wird, dann würde es einfach 0 bleiben und dadurch würde dann alles nicht sicher gesetzt werden und könnte dann ausgelesen werden. Das Problem dabei ist, das Bootraum kann man einfach nicht ausgeben. Das heißt, wir können nicht wissen, wann das macht und das Zweite ist. Wir wissen nicht, wann der Lesenzugriff auf die IDIU passiert und wann es konfiguriert wird. Wir brauchen aber genau die ganz präzise Stelle, an der das passiert, sonst passiert nichts. Also, Blutforcen will das, weil wir haben ja keine Zeit für so umgebasteln. Wir sind jetzt natürlich schon ein relativ großer Adressraum, das sind wir Zeitraum. Also haben wir Stromanalysen betrieben. Das wurde schon vorher gedacht, gemacht von Wiskio. Das können wir durch Analyse der Stromversorgung sehen, wenn wir ein JTEC Log setzen müssen. Was wir machen ist, wir setzen 0 auf das AS Register und suchen dann die Stromspannung raus und dasselbe mit einem anderen Wert. So sieht mein Setup aus. Wir haben hier den Chip Whisperer Lite und wir haben dann noch einen Programmierer. Wir haben einfach nur ein paar Mitschnitte davon gemacht. Das dauert vielleicht eine halbe Sekunde für ein Mitschnitt. Du brauchst halt 20 Mitschnitte aus dem sicheren und 20 aus dem unsicheren Modus und dann sieht man klare Unterschiede zwischen den beiden und ich habe mir noch ein bisschen mit der Statistik gefasst davon. Mein bester Kandidat dafür ist bei 2,185 Millisekunden und wir sind ja hier in der Nanosekundenwelt. Da müssen wir echt explizit den richtigen Moment treffen, damit es passt. Und jetzt ist die Frage, wie baut man so ein Glitch-Test-Setup um ein Rückmeldung zu kriegen, dass man das kaputt gemacht hat, wenn man Erfolg hatte. Das heißt, was wir machen ist, wir versuchen, sichere Daten zu lesen aus der nicht sicheren Firmware. Wenn es erfolgreich ist, das ist ein GPIO Pin und ansonsten resettert es einfach. Das heißt, ich versuche jetzt einfach verschiedene Längen des Pulses und auch verschiedene Offsets, also verschiedene Zeitpunkte, an denen ich das mache und irgendwann hatte ich dann einfach Erfolg. Wenn ihr das Firmware anschaut, das wir mal veröffentlicht haben, dann seht ihr, wie einfach das geht und im Prinzip sind das hier einfach nur 20 Zeilen. Das heißt, ihr geht hier über verschiedene Zeitpunkte und verschiedene Pulsenlängen und dann musst du nur noch checken, ist der GPIO hoch oder tief und wenn ihr das mal stabil laufen habt, dann ist es krass, wie schnell das eigentlich geht. Das hier ist eine Aufnahme von einem echten Glitch und ihr seht hier, wir haben ungefähr 20 Versuche pro Sekunde und nach einigen Sekunden haben wir auch schon den Erfolgsmeldung. Wir haben gerade einen Chip kaputt gemacht. Viel Erfolg. Also jetzt bin ich in den Süden von Deutschland gezogen und wir sind ja echt geizig mit Schwaben, deswegen sind wir fast sechs Bier auf dem Oktoberfest um das jetzt mal in die lokale Währung umzusetzen. Das sind 60-mal Arteflaschen. Das geht überhaupt nicht. Wir müssen echt billiger werden. Was wenn wir einen Chip nehmen, der 57 sicher ist und wir versuchen es mit einem 3-Dollar-Chip zu brechen? Das hier ist ein IT-Tiny, der kostet irgendwie 2 oder 3 Euro. Wir kombinieren es mit einem MOSFET, um die vergleich zu halten. Das sind ungefähr drei Club-Marte und wir packen das auf ein Breadboard und wir stellen fest, okay, wir haben einen stabilen Glitch mit ungefähr 120 Zeilen Assembler-Code auf dem IT-Tiny und wir können damit einen Chip zuverlässig glitschen. Und Chips sind, sind schwierig und ist immer einfallen, selbst konfiguriert, dass man einen Chip zu glitschen, weil es kann sein, man hat vielleicht irgendein Security-Bit zu, dass man etwas Einstellungen vergessen hat oder sowas. Wirklicherweise gibt es hier ein, diesen Sammelf KPH, der wird mit einem eingestellten Key-Beschlüssel geliefert und die Trust Zone ist fertig, komplett abgesichert und der, der Benutzer kann nur unsicheren Code schreiben und auch nur den eigenen, nicht, nicht sicheren Code debacken. Aber ich kann die leider nicht benutzen, weil den Kaufen benutzt halt Zugriff zu deren Code. Aber wir konnten unseren Attacke damit testen. Man kann diesen Chip auf Dickey-Key kaufen und man kann gucken, ob der, die Attacke funktioniert, weil diese Chips sind völlig fertig konfiguriert und sollten sicher sein und wir haben unser Setup gemacht. Wir haben einen, irgendwie haben wir einen J-Tag, wir haben keine Kondensatoren, dass man direkt Zugriff auf die Kernspannung hat und man hat den FPGA in der Ecke und ein Programmierer und dann haben wir eine einfache Funktion geschrieben, die einfach Open OCD benutzt, um versucht, eine Adresse zu lesen, die wir normalerweise nicht lesen durften. Also wir machen, wir glitschen, dann starten wir Open OPCD, um über den Deback die Adresse zu lesen und dann haben wir das alles zusammengesteckt, haben ein nettes Skript geschrieben und haben es dann laufen lassen und nach einer Weile, nach einer paar Sekunden waren wir successful. Wir hatten immer mehr, immer mehr, wir sehen, wie stabil man diese Glitches kriegt und wie einfach man den glitschen kann. Also ja, okay, gehackt. Wir können diesen Chip einfach glitschen und die Sicherheiten mit ... Das ist super für Supply Chain Attacks, weil man halt Dinge machen kann, wenn der Adresser den Chip kauft und er glaubt, er kommt nicht ran, dann wird er dich nicht findet. Nun, Supply Chain Attacks sind natürlich schwierig, weil man ist nur für sehr fortgeschrittene Akteure machen und es ist relativ schwierig. Außer man kann irgendwie den Vertreiber des Systems unterwandern kann. Und hier kann man zum Beispiel über DigiKey ein Bug, die Idee ist, wenn man eine Rechnung abfragt, dann checkt man sie nicht, ob man wirklich berechtigt war, diese Adresse, diese Rechnung zu sehen und wenn man es macht, dann konnte man halt die Adresse und die Rechnungsnummer und das ist alles, was man brauchte, um DigiKey zum Beispiel die Lieferadresse zu machen, aber das hat DigiKey inzwischen gefixt. Insofern geht das heute nicht mehr, aber wir lassen uns mal kurz angucken, wie man das hätte funktionieren können. Wir haben Eve und wir haben DigiKey und Eve, die braucht für ihre Cyber Toilette diesen hoch sicheren Chip. Also sie zu DigiKey und bestellt diesen Chip und Mallory überwacht alle ihre Rechnungen auf DigiKey und sobald sie feststellt, sie kauft einen Sam-11, dann sagt sie DigiKey, dass er die Lieferadresse ändern soll und dann werden diese Chips statt zu Eve ein Mallory übergeschickt und Mallory hat die Chips, kann sie Backdoor ins Rallieren und kann dann die Chips einfach an Eve weiter schicken und Eve merkt nichts, weil wir jetzt die gleichen Unternehmen um die Sieger zuzustellen und kann wenig sehen und selbst wenn sie die Dinge aufmachen und alles scammed, was sie offiziell scannen kann, finden sie nicht, weil die ganze Backdoor in einem Teil des Chips installiert ist, den sie ja nicht sehen kann. Das ganze von uns wird damit einfach den passenden UPS-Umschlag zu benutzen. Ein interessanter Angriffsbisteln. Also ich hab mit Microchip geredet, der Kontakt war sehr gut, sehr nett, sie waren sehr offen und sie sagen, dass dieser Chip nur gegen Software-Angriffe verteidigt. Es hat ein paar Hardware-Eigenschaften wie Manipulation, sicheres Rahmen, aber es ist nicht so gut designed, dass es Fehler in die Aktion Angriffen widerstehen kann. Ohne man sich's an die Dataship guckt, wenn die Älteren, die erwähnen noch ein bisschen Far-Feature gegen hardware hat, aber die Neueren erwähnen das nicht mehr und sie fragen jetzt auch sehr viel nach Feedback, um es klarer zu machen, wogegen der Chip tatsächlich Protekt. Also erste Chip kaputt, lass uns den nächsten angucken. Der nächste Chip war der Nuva-Ton NuMicro M2351, das ist einfach auszusprechen, das ist ein Cortex-M23-Prozessor. Es ist Trustzone-M und es heißt sowohl eine SIU als auch eine IDIU und ich hab mit deren Marketing gesprochen, es schützt explizit gegen Fehler in die Aktion. Ich war sehr erfreut darüber und sehr aufgeregt, also sehen wie es geht. Lass uns kurz über Trustzone oder in dem Nuva-Tons Chip reden. Wie vorher, wenn die SIU, wenn sie ausgeschaltet ist oder ohne Region eingeschaltet ist, wird sie völlig sicher zurückgeben. Und wie gesagt, egal was die IDIU da sagt, in diesem Fall wird immer sicher gewinnen. Also der endliche Zustand ist alles sicher. Wenn wir jetzt ein paar nicht-sichere Bereiche hinzufügen, dann ist auch der endgültige Zustand so, dass die es endlich nicht sicher gibt. Und ich guckte, wie man den Code, und hier sieht man das hier, die SIU-Control wird eins gesetzt und wenn wir über die SI darüber klitschen können, dann ist die komplette sichere Mechanismus ausgehebelt. Also, ja, der sichere Bootloader startet mit nicht-sicherem Code, dann klitschen wir über die SIU-Enabled, dann ist plötzlich alles sicher und dann läuft unser gesamter Code im sicheren Bereich außer, also ganz einfach, außer liest das blöde Handbuch und diese tausende Seiten von Dokumentation enthalten tatsächlich sinnvolle Informationen. Man braucht eine spezielle Instruktion um vom sicheren, im unsicheren Start zu springen. Und das ist diese BLXNS-Branche, Linked and Exchange Non-Secure, die hilft dagegen ausversehen, den nicht-sicheren Code zu springen. Und was auch interessant ist, wenn man diese Transition hat, es wird nicht immer die Übergang machen, es hängt an dem letzten Bit in der Zieladresse und der Weg, wie der Bootloader seine Adressen gekriegt, der Jump von dem Reset-Tabelle, das ist einfach die Tabelle, wo der Reset-Handler ist und der Rapp-Handler und der Stat-Pointer und ihr seht, der letzte Bit ist immer eins. Und wenn das eins ist, wird er immer in sicheren Code springen. Also irgendwie haben sie es geschafft, aus diesem sicheren ist und dann in den nicht-sicheren zu spielen. Und wie machen sie das nun? Sie benutzen eine explizite Bit-Clear Instruktion. Was wissen wir bei der Instruktion? Wir können drüber glitchen. Das heißt, wenn wir mit zwei Glitches können wir jetzt über die SIU gehen, dann glitchen wir erst über das Enable von der SIU, dann glitchen wir über diese Bit-Lush-Instruktion und dann der Resultat ist, einfach normaler Code wird als sicher laufen. Also ganz normaler Code. Problem ist, das funktioniert, aber es ist relativ schwer, stabil hinzukriegen. Also irgendwie geht es, aber nicht gut. Es war echt schwierig, das tatsächlich zu benutzen. Also wollte ich eine andere Schwachstelle hanken. Also habe ich mich über die Implementation, die implementationsdefinierte IDIU, geguckt. Und was sie schreibt, stellt jedes Stück Flasche oder Rahmen ist zweimal in den Speicher gemappt. Einmal als sicher und einmal als nicht sicher. Einmal als sicher zum Beispiel, als 0x2 und als nicht sicher 0x2. Das ist der gleiche Speicher. Und ich habe dann eine Attacke gefunden, die ich CRO, CRO-Bresch-Branden genannt habe, oder CRO-Aber, because ohne Namen ist eine Vulnerability nichts. Und wir benutzen das hier, dieses Mirror Ring. Also die IDIU spiegelt den Speicher einmal als sicher und einmal nicht als schwächer. Und wir nehmen an, am Boden des Flasches haben wir diesen sicheren. Das wird auch in dem Spiegelbild dieses Speicher ist. Aber da ist die IDIU-Konfiguration sicher ist, würde ich nicht zugänglich meinen. Aber dieser Anfang hier von diesem Bereich wird von dem Arbarregister gesetzt. Und vielleicht können wir, wenn wir den Wert dieses Arbarregisters ändern, dann können wir diesen nicht sicheren Bereich verändern. Und wenn man an die Dokumentation ist, dann stellt man fest, okay, ist der Wert beim Start ist andauend, aber ich habe es getestet, und bei allen Chips ist der tatsächlich 0. Und wenn wir jetzt über diese Instaktionen glitschen, dann dehnt sich dieser nicht sichere Bereich aus. Und das funktioniert tatsächlich. Wir kriegen einen total stabilen Glitch. Es dauert ungefähr 30 Sekunden für eine erfolgreiche Abbildung. Ich kann euch nicht genau sagen, was es ist. Ich weiß nur, ich laufe den Glitch und ich kann den sicheren Bereich lesen. Ich weiß nicht genau, was da passiert. Also, wuhu, der nächste Trip ist gefallen. Also, gucken wir den nächsten Trip an. Der LXP, NXP, LXP 55S69. Der zwei Cortex-Course, ein M33-Course, einer davon hat Cortland-Trustzone. Das Layout ist ähnlich zu dem New Micro. Ich habe den Doppelglitch-Angriff zum Laufen gekriegt und auch den Crow Aber. Und die Reaktion des Herstellers war großartig. Sie wollten sofort wissen, was ich gemacht habe. Ich habe sie am Telefon mitgesucht. Allerdings, was ich herausstellt, der Beispielcode hat ein Sicherheitsfeature nicht eingeschaltet. Dieser Sicherheitsfeature heißt Vermischtes Control Register. Das steht dafür, sicheres Kontrollregister hoffensichtlich. Und dieses Register hat ein Bit. Und wenn man das setzt, dann schaltet es SecureTracken ein. Und wenn ich ein paar Sätze weiter gelesen hätte, ja, Millennial, Entschuldigung, dann hätte ich gewusst, dass es das gibt. Und wenn ich dieses Bit setze, dann gibt es einen zusätzlichen Speichersicherheitschecker. Aktiviert er ein kleinere Kontrolle über die Speicherregionen. Und der Check mit den Zuschreibungseinheiten, ob der Sicherheitszustand ist, dergleiche ist wieder mit dem NPC Sicherheitsdate. Und wenn man das nicht ist, dann stoppt er den Angreif. Auch das kann man Glitches, aber das ist sehr viel schwieriger. Es braucht wenigstens zwei Glitches. Die Antworten des Herstellers waren auch großartig. Und die Dokumentation wird verbessert. Aber es gibt einem schon ein gewisser Sicherheit, aber es ist keine volle Sicherung. Bevor wir ändern, diese Chips sind nicht unsicher. Sie sind nur gegen ein sehr, sehr spezifisches Angriffsszenario nicht geschützt. Und alles, was du machen musst, ist dein Chip gegen dein spezielles Angreifermodell richtig auswählen. Das heißt, ihr müsst euch überlegen, was ihr machen wollt. Also zum Beispiel, wenn ihr jetzt irgendwie ein Chip, der ein Auto sichern soll, der den Zugriff erlaubt oder nicht, dann müsst ihr euch darüber Gedanken machen, vielleicht bei einem Hardware-Wallet definitiv, ja. Also es hängt sehr vom Anwendungsfall ab. Okay, vielen Dank. Das war die Übersetzung des Talks. Überbrechendes Arm verocht sichert. Jetzt kommen die Fragen. Wir haben den Talk übersetzt. Florian und Kaste, wir würden uns über Feedback bei dritter Freund benutzen auf den Hashtag C3T. Und jetzt geht es los mit den Fragen. Seid ihr auf... Kennt ihr die ST Cortex Firewall Research? Ja, ich habe mich da mit sehr viel beschäftigt. Ihr könnt euch den Vortrag vom letzten C3 angucken über Wallet Fail. Da geht es genau darum. Da gibt es eine merkwürdige Firewall-Feature. Ich kann leider noch keine Forschung dazu veröffentlichen. Sorry. Habt ihr versucht, diesen... der Angriffe auf Mehrkern-CPUs zu reproduzieren? Und wenn nicht, wie würdet ihr dafür vorgehen? Habe ich noch nicht. Es gibt leider keine Chips mit der Frequenz, die dieses Trust-On-Feature unterschützen. Es gibt von anderen Leuten Forschung dazu. Es gibt auch veröffentlichte Materialien zu Hochfrequenz-Glitching. Das Problem ist, es wird sehr, sehr schnell, sehr teuer, als wenn es aus Diskop halt immer mehr können muss. Sind das Standard-Funktionalitäten, um von sicheren zu gehen? Oder ist das, wenn die Hersteller abhängig? Das Viniere-Zeug ist relativ standard, und ihr könnt euch von Arm die Handbücher holen. Es gibt Toolchains, die diese Viniere-Funktionen generieren. Ich habe mir nicht genau angeguckt, wie sie generiert werden, aber ich habe ein bisschen Trust geschrieben, um darum umzukommen. Und es ist relativ einfach. Ich möchte wissen, wie wichtig ist die Hardware-Sicherheit zu vergleichen mit der Software-Sicherheit? Kann diese Geräte nicht hacken, ohne das Zugriff auf das Gerät zu haben? Das hängt halt von deinem Angriffsmodell ab. Wenn ihr jetzt zum Beispiel ein Hardware-Wallet-Baus, dann musst du dir sehr viel über Gedanken machen, über die Sicherheit, weil jemand es einfach mitnehmen kann. Bei deinem Telefon willst du vielleicht auch nicht, dass jemand beim Zoll sich bei deinem Telefon bemächtigen kann. Deswegen ist das ein relativ relevantes Szenario. Beim Autoschüssel ist es ähnlich, weil du willst nicht, dass sie jemanden ein Kopie davon machen können. Es ist ähnlich mit den Druckerkartuschen, weil die Hersteller verwenden viel Energie darauf, sicherzustellen, dass man die nicht einfach kopieren kann. Hier geht es nicht so sehr darum, dass der Benutzer sich schützen will, dass er kopiert wird, aber der andere Hersteller. Ihr habt mehrfach attackenhöhere Ordnung erwähnt. Beim letzten Trip erwähntet ihr, das ist mit zwei Glitches gebrochen hat. Das habt ihr gemacht, um den Suchbereich zu verkleinern. Wenn ihr eine Sicherheitsverteilungsunit habt, könnt ihr euch entscheiden, ob ihr das andere abschalten könnt. Ich konnte meine SU ausschalten. So hatte ich einen sehr kleinen Suchraum. So konnte ich relativ genau einen Engen, wo ich den Glitch machen musste. Ich konnte ja den Glitch machen. Ich hatte einen kleinen Suchraum, wo ich den Glitch machen musste. Ich habe den Code selber geschrieben, konnte dann auf dem Oszilloskop nachverfolgen, wie meine Instruktionen ausgeführt wurden. Ich frage mich nur, wenn der Hersteller diesen Kondensator auf dem Dai machen würde, wie viel schwieriger würde das die Angriffe machen? Bei Volchisch-Glitching kann das helfen. Bei UFI-Glitching ist es schwieriger, weil dann muss man einfach nur eine Spule drauf machen und kann es dann direkt injecten. Es hilft schon, aber man macht es weniger wegen Sicherheitsgründen. Was habt ihr geteilt, um dein eigenes custom Hardware zu helfen? Ja, teilweise. Die Teile, die funktioniert haben, ja, das ist so die. Hi, thanks for the interesting talk. All these vendors pretty much said, this is not a scope. All these vendors pretty much said, this is not a scope. All these vendors pretty much said, this is not a scope. All these vendors pretty much said, this is not a scope. All these vendors pretty much said, this is not a scope. All these vendors pretty much said, this is not a scope. Im Bereich, in dem wir schützen wollen, es ist Out of scope. Gibt es Chips, ich weiß nur, dass niemand darüber reden darf. Und ich weiß, es gibt einige Chips, die sehr gut gegen Glitching ist. Und ich glaube, das, wo man nachher suchen muss, ist Glitch-Monitor. Wenn ihr einen Datasheet seht, dass ihr das drin habt, dann wisst ihr, dass ihr eingefunden habt. Was ist das mit Brown-Out-Detection, dass Michael Schipzack hart ist? Warum hat es ihn Angriff nicht gefunden? Es ist nicht dafür da, dass man Glitching verhindert. Es geht nur darum, dass man den Chip stabil hält. Also wenn man zum Beispiel die Spannungsversorgung runtergeht, dann möchte man das feststellen, um sich nicht selber zu glitschen. Weil wenn zum Beispiel die Batterie leer ist, dann will man, dass der Chip stabil läuft und dann einfach ausgeht. Das ist somit mein Verständnis von dem Brown-Out-Detektor. Aber die sind nicht schnell genug, um Glitch-Attacken zu festzustellen. Ihr habt gezeigt, dass es sehr schnell, schwierig ist, wenn man zwei nachfolgende Glitches hat. Das ist nicht einfacher. Man macht das zweimal oder dreimal. Es ist dann nicht so schwierig, dass man nicht mehr glitschen kann. Es hilft, wenn die Spannung an und aus geschildert wird. Aber wenn man das zweimal macht, könnte man auch einfach bei der Spannungsversorgung monitoren. Und wenn jemand das von Hand macht, dann kann er das immer noch machen. Ist das was ich dagegen auf dem PCB-Level machen, auf dem Platinen-Level machen kann oder geht das nur auf dem Chip-Level? Wenn du, es geht nur auf dem Chip-Level, weil wenn du einfach eine Klebepistole nimmst oder eine Hitze, eine Wärmepistole, dann kannst du einfach den Chip runter machen und in den Socket basteln. Du musst immer den ganzen Chip dagegen sitzen. Also, wenn nicht, dann musst du zumindest so ein Case drum rum bauen, was verhindert, dass man daran kommt. Ich frage mich, ob ihr irgendwas über die SDM32L5-Serie gehört habt. Ich habe viel davon gehört, aber ich habe noch nichts davon gesehen. Wir warten immer noch sehr gespannt darauf. Würdest du die Hardware-Design von dem Board veröffentlichen oder ist da irgendwas, was nicht gibt oder so? Es gibt Chip.Fail.Fail.Domains, wo es bei uns schief gegangen ist. Ich habe die auch in das Gitter, in das letztes Hochgeladen. Ich werde es noch raus veröffentlichen und es ist alles auf Open Source Hardware basiert. Insofern werde ich, ich will nur mal das Leben für alle einfacher machen. Du sagst, du weißt nicht genau, was in dem Moment des Glitches passiert und du warst glücklich, dass du eine Instruktion übersprungen hast. Hast du eine Idee, was in dem Moment des Glitches passiert? Ich habe genau die gleiche Frage gestellt. Was da passiert, habe ich verschiedene Leuten gestellt und ich habe verschiedene Antworten bekommen und im Prinzip ist mein Verständnis, dass man die Spannung runterzieht, die man braucht, um einen Register zu sitzen. Aber es ist wirklich komplett außerhalb meiner Expertise, um das wirklich zu verstehen und eine gute Antwort zu geben. Ich kann nur Dinge kaputt machen. Du hast viel über Chip-Attacken erzählt. Kannst du was über J-Tag-Attacken erzählen? Ja klar, zum Beispiel die KTH Version von dem Chip. Da habe ich J-Tag verwendet, um das aus dem Chip auszulesen. Aber es ist möglich, auf vielen Chips J-Tag wieder anzumachen, selbst wenn Chip J-Tag eigentlich hinterher verplombt wurde und da gab es auch ein Talk auf dem letzten Kongress, wo das erklärt wurde. Ich würde vermuten, das geht bei dem hier auch, aber ich habe es noch nicht probiert.