 Eure Controtor mit Geheimnissen, die Sie selber nicht erzählen wollen. Unserem nächsten Vortragenden, den wir Ihnen da zu Ihre Geheimnisse zu veröffentlichen, versucht gar nicht, euer Enthusiasmus zurückzuhalten für Johannes und Marc. So, ein wunderschönen guten Abend und willkommen zu unserem Vortrag zur Zeltgebung vom Hardware-Sicherheit. Wir werden nun drei Sachen näher beleuchten. Die erste Frage ist, warum? Dann werden wir darüber reden, wie wir das machen mit zwei Beispielen und ich werde dann über die Konsequenzen reden. Zu allererst die Frage, warum? Mein Name ist Johannes Obermeier. Ich bin Forschern über die Sicherheit der Sicherheit und arbeite gegen Ende meiner Doktorarbeit. Hallo, ich bin Marc Schink und ich arbeite als Sicherheits-Reach-Searcher. Ich mache alles, das irgendwie mild Hardware-Sicherheit zu tun hat. Von der Analyse von Konzepten bis hin zur Seitenkanal-Angriffen auf Microcontrollern mache ich alles. Wir beide arbeiten mit Microcontrollern zusammen und arbeiten sehr viel mit Ihnen und wir lesen Ihre Datenblätter und manchmal haben Sie sehr starke Sicherheitsbehauptungen in den Datenblättern. Und häufig fragen wir uns, funktionieren die überhaupt? Aber warum sollten wir uns überhaupt Gedanken machen über die Sicherheit von Microcontrollern? Normalerweise möchten wir uns eine Firma sichern, wenn man ein Impeded Gerät herstellt. Aber selbst wenn es nicht darum geht, die Software zu sichern, dann möchte man mindestens die beinhalteten Credentials wie zum Beispiel kryptografische Schlüssel oder aber sichern. Außerdem möchte man auch sicherstellen, dass keine andere Firmware darauf installiert wird, dass es nur mit der richtigen Firmware läuft und keine manipulierten Daten analysiert. Warum wollen wir sie angreifen? Es gibt mehrere, zum Beispiel Forschungsprojekte, wo wir Microcontroller benutzen und die Sicherheitskonzepte davon benutzen. Manchmal merken wir, dass es dort Sicherheitslücken gibt. Eine andere Möglichkeit ist, dass wir Kunden haben können, die eine Sicherheitsanalyse von einem Konzept erstellen wollen, weil sie diese Features und diese Komponenten benutzen wollen. Wir analysieren dieses Konzept und zeigen in die Ergebnisse. Das Letzte ist wissenschaftliche Curiosität. Manchmal sehen wir ein neues Sicherheitsfeature und wollen uns anschauen, ob es wirklich sicher ist und wie es funktioniert. Aber die Frage ist immer noch, würde jemand wirklich die Sicherheit von einem Microcontroller brechen wollen? Leider ist die Antwort, dass es nicht nur jeder, der es machen möchte, sondern es gibt einen ganzen Markt, der darum geht, wie man Embedded Geräte klont. Wir haben Firmen, die anbieten, ein Gerät zu klonen. Es sind für eine geklonte Platine und sie ziehen auch die Firmware von den Microcontrollern und installieren es auf dem klonenden Gerät. Man vermutet jetzt, dass das relativ teuer ist. Darum haben wir für unsere Kunden nachgefragt. Nein, es ist relativ günstig. Es hat nur 6.000 US-Dollar gekostet pro Chip und für einen ganz aktuellen Microcontroller und es hätte sogar in 30 Tagen geliefert werden sollen. Das ist überraschend günstig und es ist ein wirkliches Anriff-Szenario. Leider haben vermuten, dass die Hersteller von Microcontrollern meistens, dass wir negativer angreifert sind. Manchmal sieht es so aus, als ob ich ein Produkt auswähle und ich versuche diesen spezifischen Hersteller, weil das Ding, das ich so nicht mag. Darum hole ich meinen Cyberhammer aus meinem Schrank und bis die Sicherheit kaputt ist. Wir suchen nicht einen spezifischen Produkt aus oder einen spezifischen Hersteller heraus. Bitte erinnert euch, greift nicht den Überbringer der Nachricht an. Wir zeigen nur, dass vorhandene Sicherheitslücken da sind und bringen keine Neue hinzu. Wir machen eine wissenschaftliche Analyse von Sicherheitskonzepten. Die Wissenschaft ist der Kern unserer Forschung hier. Zuallererst versuchen wir einen theoretischen Analyse. Wir lesen das Datenblatt, überlegen, wie funktioniert das Sicherheitskonzept und wenn wir eine Idee haben, dass es dort ein Sicherheitsproblem gibt, versuchen wir es praktisch aus. Wenn es wirklich erfolgreich ist, entwickeln wir ein Proof of Concept, also ein Versuchsangriff, damit der Verkäufer oder der Hersteller unsere Sicherheitslücken analysieren kann, damit es dann gefixt wird. Und dann veröffentlichen wir das darüber und dann schließt es den Kreislauf. Und es wird reproduzierbar. Ein zukünftiger Forscher, ein zukünftiger Implementator, kann vielleicht davon unseren Ergebnissen lernen. Jetzt, wo ich erklärt habe, warum wir diese Angriff überhaupt machen, reden wir darüber wie und ein Beispiel, die wir vor Kurzem gemacht haben. Normalerweise, wenn wir anfangen wollen, ist die Frage, wie fangen wir überhaupt an? Riechen wir wirklich Sicherheitslücken? In der Regel ist das nicht sehr weit entfernt, von wer es wirklich passiert ist. Manchmal hat man so das Gefühl, dass die Sicherheitskonzepte so ein bisschen interessant sind. Und dann schauen wir es uns tiefer an. Ich hatte zum Beispiel diesen STM32F0 Microcontroller Board und darum habe ich viel damit entwickelt und ich habe es relativ gut kennengelernt. Und dann habe ich ein paar Sicherheitsfeatures gesehen, wo ich dachte, sie sind wirklich so stark, wie ich es hier versprochen wird. Und das war der Grund, weshalb ich gesagt habe, das ist uns mal näher anschauen. Also, um die Firmware zu sichern, hat der Microcontroller drei Sicherheitslevel. Wir haben RDP Level 2, 0 bis 2. Bei 0 hat man überhaupt keine Schutz, das ist was Entwickler benutzen, wenn man den Microcontroller kauft, dann können wir damit alles machen. Dann haben wir die schwache Protektion von Level 1 und wir haben keinen Debug-Axis in RDP Level 2. Und ich kann diesen Wert konfigurieren, damit wir einen speziellen Wert in den Speicher schreiben. Damit ist ein fester Wert. Also, wenn ich jetzt 3 CC dorthin schreibe, dann sieht das der Microcontroller und erschaltet seinen Debug-Interface aus. Man kann die Sicherheitslevel immer nur erhöhen. Wenn man sie reduzieren möchte, dann muss man es komplett löschen. Die gesamte Firmware löschen. Dieses Sicherheitskonzept zieht mit einem ersten Blick relativ gut aus. Aber wenn wir den Entsattenplatt näher anschauen, dann ist diese ganze Erklärung in einer Unterkategorie der Flash Firmware Protektion steht. Wie ist die das mit S-Ramen aus? Also, habe ich es ausprobiert. Ich habe einen Microcontroller genommen, habe die Firmware draufgeschrieben, habe das ADP Level 1 eingeschaltet und habe versucht, den S-Ramen auszulesen. Oh, Überraschung, es ist immer noch lesbar. Die ganzen Daten, die vielleicht in S-Ramen gespeichert sind, sind immer noch da. Stüssel, die aktuell benutzt werden, können immer noch aufgerufen werden. Und man kann sogar einen Angriff darauf fahren, mit dem man Teile der Firmware auslesen kann. Also, das ist etwas, was man immer im Kopf behalten muss, wenn man ADP Level 1 benutzt. Man denkt so, hey, dann nutzen wir ADP Level 2. Ist das eine gute Idee? Das ist uns mal näher anschauen. Wir haben diese Dateneinstellungen gespeichert. Die zwei Unterschiede sind ADP Level 2 und 0. Wir sehen hier die Binäranalyse der Einstellungen. Die ganzen anderen Konfigurationen werden zu ADP Level 1 gemappt. Vielleicht ist es möglich, ADP Level 2 zu ADP Level 1 zu reduzieren, wenn wir nur ein einziges Bitfledge ändern. Es ist vielleicht irgendwie möglich, dieses ein Bett zu ändern. Die Daten werden in Flash-Memory gespeichert. In Flash-Speichern sind die Daten in der Regel mit Floating Gates gespeichert. Wenn da Elektronen sind, dann wird das als 0 gelesen, und wenn die Elektronen nicht da sind, dann ist es einer 1. Und dann brauche ich einen Weg, diese Elektronen zu entfernen aus dem Flash-Speicher da. Und das kann z.B. mit UV-Licht erreicht werden. Das heißt, wenn ich diese Zelle lösche mit UV-Licht und dann löscht das UV-Licht diese Elektronen weg und reduziert es zu RTP Level 1. Okay, wie können wir da vorgehen? Wir brauchen als erstes eine starke UV-Lichtquelle. Ich habe mine aus dem Müll der Uni geholt, und du kriegst sie aber auch in Online-Händen, also ziemlich einfach. Okay, jetzt brauchst du natürlich noch Zugriff auf den Chip und auf den Flash-Memory, also Flash-Speicher. Also man muss ein Teil der Daffa des Gehäuses entfernen. Das kann man natürlich etwas kompliziert machen, aber z.B. mit starken Säuren oder du gehst zu einer Firma oder zu Chemikern, die Möglichkeiten dafür haben. Also es ist auf jeden Fall machbar, die Verpackung etwas zu öffnen. Wenn man genauer reinguckt und ein bisschen Erfahrung hat, dann kann man die Flash-Speicher-Region erkennen und mit mehr Experimenten. Das kann man übrigens alles in den Papieren für die Veröffentlichung finden. Und nur die untere Rechte Gegend hat die LDP-Bytes, die die Sicherheit bestimmen. Wir haben also eine Maske da drauf gelegt, um den Rest des Flash-Speicher zu schützen. Wir wollen nur diesen Teil belichten mit UV-Licht, und zwar für mehrere Stunden. Und dann kriegen wir ein komplettes Security-Runderschrauben von Level 2 auf 1 hin. Auf diese Art und Weise ist Level 2 kaputt, weil mit diesem einfachen Mechanismus kommt man immer auf Level 1 zurück. Aber im LDP Level 1 kann ich immer noch nicht den Flash-Speicher auslesen. Das ist auch etwas, was ich nicht so richtig geglaubt habe. Ich habe irgendwie alles außer den Flash. Das scheint irgendwie sehr kompliziert zu sein, wie es implementiert sein kann. Ich habe also da ein bisschen zugehört, wie der Standard-Debagger mit dem Mikro-Kontrollerspricht in Level 1. In LDP Level 1 am Anfang fängt der Debugger an, die Debugger Funktionalität zu aktivieren. Der Mikro-Kontroller bestätigt das. Und dann gibt es 80 Transaktionen zwischen dem Debugger und dem Mikro-Kontroller. Der Debugger z.B. liest den CPU-ID aus und Konfigurationen, Breakpoints, Watchpoints usw. Dann habe ich versucht mit dem Debugger den Flash auszulesen versucht und das hat natürlich nicht funktioniert, weil das in LDP Level 1 gesperrt ist. Also ich hatte nicht wirklich die Möglichkeit, den Standard-Debagger zu nehmen. Okay, dann habe ich gedacht, dann mache ich eben meinen eigenen Debugger auf einem anderen Evaluierungsboard und dann versuche ich, ob ich da ein bisschen mit der Kommunikation rumspielen kann. Ich bin nicht interessiert in Breakpoints und Watchpoints. Habe ich einfach diesen ganzen Readout, das Auslesen einfach komplett übersprungen. Ich weiß, welchen Mikro-Kohler ich spreche, also brauche ich die CPU-ID nicht rausfinden. Ich habe die ganze Konfigurationsausleserei gelassen und nur, um herauszufinden, ob mein System richtig funktioniert, habe ich einen Teil der Flash-Adressen versucht auszulesen und wir haben natürlich alle erwartet, dass das nicht klappt, weil LDP Level 1 aktiv ist und es schützt ja den Flash vor Aussicht auslesen, aber überraschenderweise lag da Datum. Okay, ich dachte als erstes, ich habe irgendwie Implementierungsfehler gemacht, ich habe es nochmal gecheckt und nein, das war tatsächlich ein Datum, das ich vorher in den Mikro-Kotroller geschrieben habe. Also habe ich es nochmal versucht, das nächste beizulesen und das schlug dann fehl. Ich habe dann mehr damit rumgespielt und rausgefunden, wenn ich gar keine Konfigurationen mache am Anfang, wenn die erste Transaktion einfach direkt entflöscht geht, dann kann ich ein einfaches Wort aus dem geschützten Flash-Memory auslesen. Das war sehr überraschend. Da scheint es eine Laufzeitbedingung zu geben, dass es noch nicht schnell genug ist und ich hier ein bisschen Datum rauslesen kann. Wir haben auch das schon veröffentlicht. Diese Problematik besteht bei diesem Mikro-Kontroller und ich kann das euch auch in einem kleinen Demo zeigen. Auf der linken Seite sehen wir das Gerät, das wir getestet haben, der Mikro-Kontroller in dem LDP Level 2 und auf der rechten Seite haben wir den Fimbe-Extractor, der diesen Angriff durchführt. Er setzt den Mikro-Kontroller immer zurück und liest dann immer ein Wort aus nach dem anderen. So, ich habe das mal vorbereitet, wie im Vorhinein. Ich kann also nicht den Flash-Memory auslesen. Es gibt immer nur 9 zurück. Jetzt werde ich den Fimbe-Extractor starten, der hier auf dem Tisch liegt und der Laptop verbindet sich jetzt mit dem Fimbe-Extractor. Er macht seine Arbeit, er macht das ganze experimentelle Debugging und versucht den Speicher auszulesen von dem Gerät, das wir testen wollen. Und wie ihr hier sehen könnt, die ersten Bytes werden direkt schon gelesen, um nur zu verifizieren, dass es ist. Ich habe da menschenlesbare Strings in den Speicher geschrieben, die jetzt hier langsam auftauchen. Ich werde den Angriff jetzt absprechen und wie ihr hier sehen könnt, da ist tatsächlich der geschützte Flash-Speicher-Inhalt zu sehen. Das kann also in ein paar Minuten oder Stunden gemacht werden. Also das ist komplett möglich und wir konnten also auch ADP Level 1 kaputt machen. Danke. Vielen lieben Dank. Und warum war das möglich? Weil wir unzugeichend Management haben. Okay, und jetzt wird Marc euch noch einen anderen Angriff zeigen. Ich werde über einen Angriff sprechen, die wir letzte Woche auf einer Konferenz gezeigt haben. Dieses Projekt hat gestartet, weil ich ein Datenblatt gelesen habe von einer Micro-Kontrolle und dann habe ich über ein Feature PC-Rob gelesen und dachte, was zum Teufel ist PC-Rob? Darüber habe ich noch nie was gehört. Ich dachte, es ist irgendwie ein Encontre, eine Gegenmaßnahme zu Rob, aber es stellt sich raus, es ist ein proprietärer Kot-Ausleseschutz. Das soll da so ein Feature sein, die der eine Firma auf dem Micro-Kohler schützen gegen Entwickler, die auf dem selben System arbeiten. Also du überlegst ja, du entwickelst eine Bibliothek und dann deployst du sie auf dem Micro-Kontroller und der Micro-Kontrolle geht an jemand anderen und der andere Developer entwickelt die Hauptapplikation und am Ende wird sozusagen das Gerät gesperrt und die Firma ist gesperrt und du hast dein Produkt zum Beispiel einen Roboter, der ziemlich mit sein sollte. Während des Entwicklungsprozesses ist deine Firma natürlich nicht geschützt, wie wir jetzt gerade gehört haben. Wenn du den Micro-Kontroller zum Beispiel über dem Debug im Modus angucken kannst, dann kommst du natürlich an die Sachen ran und da kommt PC-Rob ins Spiel, die versuchen, die erlauben den Firma auf dem Micro-Kontroller zu platzieren und dann kannst du es schützen, bevor du es an einen anderen Entwickler weitergibst. Der andere Entwickler kann immer noch die Bibliothek nutzen, aber sie kann sie nicht auslesen und manipulieren. Während unserer Forschung haben wir herausgefunden, das ist nicht nur STM Micro-Kontrollern implementiert, sondern auch bei einigen Geräten von NXP und Texas Instruments. Hier sind die Devices, die Details könnt ihr im Paper lesen. Wir haben außerdem herausgefunden, dass es ein paar interessante Hardware-Fehler in diesen Geräten gibt. Wie funktioniert das? Es ist eine einfache schematische Darstellung des Micro-Kontrollers. Auf der rechten Seite haben wir den Flash-Speicher, der durch ein Busmatrix an SRAM und Peripherie und CPU verbunden ist. Und auf der anderen Seite haben wir den Speicher. Man schrappt quasi seine Sachen da rein, in den geschützten Bereich des Speichers und dann schützt man diesen Bereich. Man sollte es nicht mehr möglich sein, diesen Code zu manipulieren, nur noch Instruction-Fetch, also Instruktionsbefehle einholen, sollte möglich sein, damit man, das muss man natürlich um die Befehle ausführen zu können. Diese Art, Firmware zu schützen, sollte Firmware für Entwickler auf den Micro-Kontrollers schützen. Das Problem als Entwickler kann ich quasi überall zukaufen, außer auf den geschützten Bereich. Ein Angreifer kann also die Instruction im geschützten Bereich ausführen und die Effekte beobachten, die dabei passieren. Lass uns sagen, ich führe eine Ad-Instruction aus und dann kann ich sehen, wie sich die CPU verändert. Und wenn man das macht und all diese Unterschiede im SRAM und der CPU anguckt, dann kann man den Code wiederherstellen, der im geschützten Bereich steht. Dann kann man ihn wiederherstellen. Und das ist, was ich euch jetzt zeigen werde. Letzte Woche haben wir eine Demonstration auf dem SRAM gezeigt und jetzt wollen wir heute einen anderen Micro-Kontroller benutzen für diese Präsentation. Wir benutzen ein Gerät von Texas Instrument, dem TM4-C123. Was ich jetzt tue ist, ich verbinde den Micro-Kontroller, den Micro-Kontroller mit meinem Computer. Und das erste, was ich mache, ich stelle eine Debugverbindung her. Okay, lass uns mal schauen. Mir fehlt ein Terminal, okay. Lass uns einen Micro-Kontroller verbinden und da gibt es eine Bibliothek auf dem Micro-Kontroller, dass die LED blinken lässt. Das ist also unsere Library, die wir gerade schützen wollen, vor Auslesen. Und die Bibliothek ist an dieser Speicheradresse platziert. Das sind 44 Instruktionen. Das ist die Bibliothek, die wir schützen wollen. Ohne Execute Only Speicher können wir diesen Code einfach ausführen. Das ist also sehr einfach. Okay, jetzt schalten wir Execute Only für diesen Teil des Speichers ein. Ja, okay, so ist es. Jetzt ist es nur ein ausführbarer Speicherbereich. Wir können es eigentlich nicht mehr lesen. Wir versuchen es nochmal, diesen Bereich zu disassemblieren. Aber das klappt jetzt nicht mehr. Okay, jetzt gibt es einen Bus-Wähler. Wenn wir jetzt unser Werkzeug benutzen, lassen wir uns das nochmal machen. Wir sagen, dass unser Werkzeug Instruktionen in dieser Memory-Adresse und zwar 44 Instruktionen herausfinden soll. Und dann können wir sehen, dass wir den Code tatsächlich herstellen können. Wenn man die link und die rechte Seite vergleicht, dann kann man sehen, wir können den gesamten Code wieder herstellen. Also links siehst du den wiederhergestellten Code und rechts den tatsächlich hin. Wenn du die vergleichtest, dann wirst du herausfinden, das ist genau der gleiche Code. Also von wegen nicht lesen, nur ausführen, der in Schutz können wir brechen. Okay, so, okay. Wir haben die Sicherheitslücken in mehrere Kontrollern gefunden. Was machen wir jetzt damit? Also natürlich machen wir einen ordentlichen Veröffentlichungsprozess und normalerweise sollte das so aussehen. Das ist die Theorie. Das heißt, wir machen die Forschung, wir finden die Sicherheitslücke, wir informieren den Hersteller mit der technischen Information darüber, dann beprüft der Hersteller, dass man diesen Sicherheitslücken gefunden hat und dann schreibt man seinen Paper, schickt es zu einer Konferenz und am Ende wird das Paper veröffentlicht. So sollte das in Theorie funktionieren. Aber leider ist die Realität manchmal ein bisschen anders. Oh ja. Das für Hardware-Sicherheitssachen, Hardware-Sicherheitsbugs, wird in der Regel diese Information 120 Tage vor der Veröffentlichung informiert, um damit die Hersteller auch eine gewisse Zeit haben, entsprechende Gegenmaßnahmen zu ergreifen. Okay, lass uns zum ersten Beispiel uns anschauen, der Hersteller A. Kurz nachdem wir unsere Sicherforschung, die wir von unserer Forschung angefangen haben, haben wir die Sicherheitslücke gefunden. Das dauerte ein bisschen länger. In Hardware-Bereich sind ein paar Hersteller, kein Zert, von man ganz einfach die Menschen weiß, die die ganzen Sicherheitslücken sucht. Und es war ein bisschen schwierig, die richtige E-Mail-Adresse zu finden. Aber dann haben wir uns mit ihnen diskutiert, aber irgendwie wurde es langsamer nach ein paar Tagen und Wochen, weil wir Telefonkonferenzen haben wollen. Sie haben nicht reingewählt oder jetzt keine Zeit dafür und irgendwann haben sie uns doch nicht mehr geantwortet. Und sie haben uns hier ganz einfach ignoriert. Leider können wir hier nichts wirklich machen, also vielleicht kriegen sie unsere E-Mails nicht, aber ich habe es mir näher angeschaut und habe erkannt, wir haben ein paar Out-of-Office-Bereichen. Das heißt, der Mails, der war funktioniert, bekam unsere E-Mail und sie wollten einfach nur nicht antworten. Also, da wir wissenschaftlich weiterarbeiten wollen, wollen wir unsere Sachen immer noch veröffentlichen. Also haben wir ein bisschen gewartet und dann kam eine Forschungs-Konferenz und wir haben es da zugefügt und dann begann die Zeit, wo wir auf die Reviews warten mussten. Unser Paper, ob unser Paper überhaupt akzeptiert wurde und in diesem Fall wandt und wird Glück. Wir wurden akzeptiert und das Konferenzprogramm wurde veröffentlicht. Dann passiert etwas sehr Interessantes. Sie haben uns auf einmal wieder kontaktiert und haben eine NDA gesendet. Also, wir mögen diese Idee nicht aus ein paar Gründen. Zuerst brauche ich keinen Disclosure-Agrimit. Ich möchte sie veröffentlichen. Ich möchte eine offene Diskussion darüber haben. Aus meiner Seite heraus möchte ich nichts mit einem NDA absichern und auch aus der Seite des Herstellers. Sie müssen uns nichts mehr erzählen. Wir möchten Ihnen nur sagen, was wir gefunden haben und vielleicht ein paar Fragen beantworten. Das ist es. Wir brauchen keinen NDA für einen technischen Grund. Außerdem gibt es noch eine weitere Sache, wo ich an unserer Rechtsanwälte für unserem Institut gelesen habe. Ich habe gesagt, hey, vielleicht ist es eine richtig schlechte Idee, einen NDA zu unterschreiben, wenn wir zwei Wochen später auf einer Konferenz darüber reden wollen. Also, wir haben das ignoriert und gesagt, hey, wir können immer noch darüber reden. Wir brauchen dieses NDA nicht. Und dann wurden sie wieder leise. Der Paper wurde veröffentlicht. Wir haben das CVE-Nummer bekommen und das war es für den Hersteller A. Im Endeffekt hat es funktioniert. Das hat ein bisschen länger gedauert als die 120 Tage. Aber generell war es relativ erfolgreich im Endeffekt. Okay. Lass uns mal schauen, wie das mit dem Hersteller B passiert ist. Wir fangen mit unserer Forschung an. Und dieses Mal gibt es guten Kontakt mit dem Hersteller, weil sie eine Produkt-Sicherheitsgruppe haben. Wir haben eine E-Mail-Adresse auf ihrer Webseite. In manchen Fällen sogar PGP-Schlüssel. Das heißt, wir können mit ihnen kommunizieren. Alles ist gut. Und dann fangen sie an, die Sicherheitssache zu sagen, hey, das ist keine Sicherheitslücke. Lest auch bei das Datenblatt. Es ist keine Sicherheitslücke. Wir senden noch mal eine E-Mail. Wir sagten wieder, wir sind immer noch der Meinung, dass wir immer noch keine Sicherheitslücke haben. Wir haben das Datenblatt noch einmal gelesen. Und dann haben wir ihnen noch eine E-Mail gesendet, schickt und sagt, hey, wir denken immer noch, dass das eine Sicherheitslücke ist. Wir versuchten es ihnen noch weiter zu erklären, warum wir denken, dass das eine Sicherheitslücke ist. Und wir sagten wieder, das ist keine Sicherheitslücke. Lest das Datenblatt noch einmal. Und dann passierte das hier. Wir haben einen großen Schritt im Veröffentlichungsprozess zu machen. Wisst ihr, was hier passiert ist? Wir haben ihnen ein Proof of Concept zugesendet. Und damit konnten wir ihnen den gesamten Code innerhalb von einer Sekunde auslesen. Und das interessante Sache dabei ist, natürlich hatten wir das Datenblatt. Natürlich, wieder und wieder haben wir das Datenblatt gelesen. Dann haben wir einen weiteren Bug gefunden. So, wir haben die Hatch-Wersicherheitsbereich. Es ist auch die Möglichkeit, die Execute Only-Bereich zu umgehen. Dann haben wir eine Telefonkonferenz bekommen. Dann haben sie das alles bestätigt. Es ist alles relativ gut. Sie sieht jetzt wieder ganz normal aus. Aber leider haben wir in unser Paper zugesendet. Und haben sie uns darum gebeten, ein paar Sätze daraus zu entfernen, ein paar Sätze umzuschreiben mit spezifischen Sachen. Außerdem haben sie uns auch gebeten, ein paar Referenzen zu ihrem Datenblatt hinzuzufügen. Was haben wir gemacht? Und außerdem haben sie uns gebeten, eine ganze Sektion aus unserem Paper zu entfernen, weil es zu einfach zu verstehen war. Das war ein Bereich darüber, wie wir die Hatch-Wersicherheitslücke ausnutzen können. Dann haben wir gesagt, es ist ein wichtiger Bestandteil für den Leser, dass der verstehen kann, wie es funktioniert. Dann können der Leser und andere Kunden selber verstehen, wie stark die Sicherheitslücke ist. Wir haben es trotzdem versucht zu veröffentlichen. Es wurde nicht angenommen. Jetzt hat aber der Hersteller vielleicht ein bisschen mehr Zeit, das zu machen. Wir haben es wieder veröffentlicht. Bei einem anderen Projekt. Dann wurde es veröffentlicht. Ich habe gesagt, dass es für uns wichtig ist, die Sachen so zu beschreiben in unseren Veröffentlichungen, dass jeder es verstehen kann. Das Problem ist, dass Hardware häufig nicht reparierbar ist. Wenn man ein Microcontroller-Bug hat, dann kann man das nicht reparieren. Wir haben kein Microcontroller-Code. Wir haben keine Software, wo man damit herumarbeiten kann, über die Sicherheitslücke herumarbeiten kann. Wenn wir dort eine Sicherheitslücke haben, ist das sehr schwimm. Es kann auch das potenziellen Pfarr für andere Produzenten, die diesen Chip benutzen haben. Aber wir wollen es nicht veröffentlichen, sodass es reproduzierbar ist, sodass andere unsere Sicherheitslücke auch finden können. Vielleicht ist es sogar möglich, diese Sicherheitslücke zu umgehen. Jetzt, wo wir diese Informationen haben, können wir bei anderen Produkten eine Sicherheitslücke finden. Oder vielleicht dieselben Sicherheitslücken bei anderen Produzenten. Im letzten Projekt haben wir uns entschieden, alle Informationen in unserem Documentation zu haben. Aber wir haben den Code, den ich gerade gezeigt habe, nicht veröffentlicht. Auch den anderen Code, um die Hardware-Sicherheitslücke nicht zu veröffentlicht. Wir haben die Informationen, aber der Quellcode ist nicht veröffentlicht. Wir hatten vier Fälle. Das erste war, den Johannes erklärt hat, und das ist das Ergebnis von dem Prozess. Das Datenblatt wurde nicht veröffentlicht. Es wurde kein Rata-Datei-Schicht hinzugefügt. Das ist dort immer noch nicht vorhanden. Der Hersteller hat auch keine CVE angefordert, also haben wir es für Sie gemacht. Mit einem anderen Hersteller hatten wir bessere Kommunikation. Sie haben sogar das CVE angefordert. Jetzt ist es im Datenblatt hinzugefügt worden. Da steht jetzt drin, benutzt das nicht mehr. Im dritten Fall ist es komplett schief gelaufen, weil überhaupt keine Kommunikation passiert, weil wir haben die Kontakte, die wir schon vorher mit Ihnen hatten. Aber auch in diesem Fall haben wir keine Ergebnisse von Ihnen bekommen. Wir haben auch keine CVE angefordert. Und was noch viel schlimmer ist, ist gar kein Update im Datenblatt oder im Rata. Das ist keine Dokumentation von denen. Sie sagten, dass das Feature, was in unserem Datenblatt drinsteht, funktioniert nicht so, wie es erklärt wird. Und im letzten Fall war die Kommunikation relativ gut. Leider hat der Hersteller die CVE nicht angefordert. CVE ist eine Identifikation für einen Sicherheitsblock. Sie wollten selber mit Ihren Kunden darüber kommunizieren, also wurde das Datenblatt noch nicht geupdatet, so viel mit der Kommunikation. Aber es haben eine Errater veröffentlicht und das wird in der Regel überlässt, überignoriert, wenn der Chip benutzt wird. Und hier in diesem Hardware-Sicherheitsbereich funktioniert diese Veröffentlichungsfall. In unserer Erfahrung nur einem von vier Fällen gut. In einem Fall ist es so, meh, gelaufen. Das, was noch viel schlimmer ist, ist, dass wir diese Datenblatt haben. Nur einer von vier Fällen hat der Hersteller diese Informationen, dass dort ein Sicherheitslücke ist, veröffentlicht oder die Feature entfernt. Das heißt, es gibt keine Dokumentation, die für den Kunden einfach zu bekommen ist, dass das Feature nicht so funktioniert, wie es versprochen wird. Das ist in unserer Meinung ungefähr so, es ist in drei von vier Fällen richtig schlecht gelaufen, weil es keine einfache Dokumentation dafür gibt. Wenn es die Frage ist, ist es wirklich sehr schlimm. Nee, es ist noch schlimmer. Ja. Okay, thank you. Das Problem ist, nachdem wir unser Paper veröffentlicht haben, habe ich ein paar E-Mails von anderen Forschern bekommen, die auch für Sicherheitssicherheit sehr interessant finden. Sie haben mir auch gesagt, das Chip ist relativ interessant. Ich glaube, ich habe hier auch etwas gefunden, aber wie kann ich das denn veröffentlichen? Wie kann ich das veröffentlichen, ohne mich selbst in Gefahr zu bringen? Ich fand das sehr spannend, dass andere Leute auch sehr, sehr interessante Probleme in Mikro-Kontrollern entdeckt haben, aber die wussten nicht, wie man das richtig berichtet. Wir haben herausgefunden, da gibt es viel Angst vor irgendwelchen rechtlichen Schritten, die die Hersteller potenziell nehmen können. Und dann gibt es quasi einen von zwei Möglichkeiten, die können natürlich irgendwie anonym ein full disclosure machen, irgendwas auf Pay-Spin packen, und dann gibt es keine Warnung für den Hersteller und auch nicht für die User. Und das ist, was nicht besonders gut ist, das wollen wir nicht, das ist nicht gut für den Hersteller, das ist für niemanden gut. Und die zweite Option scheint irgendwie genauso schlecht zu sein. Keine Veröffentlichung, keine Geradestellung. Aber wenn das der Fall ist, dann es wurde ja von Leuten gefunden und das wird vermutlich dann auch in der nächsten Serie der Mikro-Kontrolle gefunden. Und wenn es dann erstmal irgendwann veröffentlicht wird, dann werden mehrere Mikro-Kontrolle auf einmal plötzlich ein Problem ausgesetzt. Da muss es noch einen anderen Weg geben. Und das ist das koordinierte Disclosure, das koordinierte Veröffentlichen. Das ist immer noch nicht so gut zu erreichen, weil man immer noch den Angst vor der gesetzlichen Schritten hat. Wir brauchen auf der einen Seite, dass die Hersteller mehr mit uns kooperieren mit den wissenschaftlichen Forschern, dass wir unsere Unterstützung bekommen, dass sie unsere E-Mails lesen und ernst nehmen. Und auf der anderen Seite brauchen wir internationale rechtliche Sicherheit, dass wir nicht irgendwie vor Klagen Angst haben müssen. Das ist etwas, was sehr gefährlich ist und es gibt Fälle, zum Beispiel in der Software-Sicherheit, da gibt es irgendwie Klagen gegen Forscher, die versucht haben, Schwachstellen zu veröffentlichen. Wenn wir diese legale Sicherheit hinbekommen, dann gibt es die Möglichkeit, dass wir Sicherheit verbessern, wenn Forscher und Hersteller zusammenarbeiten, zum Beispiel, dass Firmware nicht ausgelesen werden kann oder deinen geheimen Schlüssel in Mikro-Kontrolle können dann vielleicht nicht ausgelesen werden. Und es geht ja nicht nur um die wissenschaftlichen Forscher, es geht hier um jeden, der eigentlich nur interessiert ist an Sicherheit von Mikro-Kontrollern. Man kann einfach einen Mikro-Kontroller kaufen, einen Evaluationsbord kaufen und draufgucken. Und wenn man dann irgendwie Sachen rausfindet, welche Sicherheitsversprechen gehalten werden und welche nicht, das wäre gut, wenn wir diese Art von Zukunft gestalten, wo so ein offenes Kurs darüber haben können. Und ich hoffe, dass wir auf einem guten Weg dorthin sind. Wir wollen alle auch das nach vorne bringen, zum Beispiel auch mit diesem Vortrag, und sagen ganz klar, wir brauchen die Hersteller dafür. Wir sind nicht gegen sie, wir sind auf ihrer Seite. Wir wollen auch die Sicherheit dieser Produkte verbessern. Und wir brauchen auf der anderen Seite natürlich auch mehr rechtliche Sicherheit. Und das könnte ein Weg sein, wie bessere Sicherheit für den Mikro-Kontroller hier realisiert werden kann. Vielen lieben Dank fürs Zuhören. Johannes Mark, thank you so much. Okay, ja, vielen lieben Dank. Wir haben Zeit für Fragen. Das gibt Mikrophoneangel auf der einen und auf der anderen Seite. Falls ihr Fragen habt, geht zu den Mikrofonen oder vielleicht gibt es ja endlich eine Frage aus dem Internet. Ja, es gibt eine Frage aus dem Internet. Als Sicherheitsforscher, was würdet ihr empfehlen? Mikro-Kontrollerhersteller, um die Sicherheit, ihre Sicherheitsfeature zu verbessern. Das ist eine sehr generelle Frage. Ich denke, Sicherheit muss von Anfang an gemacht werden. Wenn da ein Produkt schon auf dem Markt ist, dann ist es quasi zu spät. Da muss Analyse von einem initialen Konzept passieren. Wenn wir über Sachen stolpen, wie z.B. das, was Mark erzählt hat, nachdem wir das Datenblatt gelesen haben, haben wir gedacht, moment mal, das kann nicht wirklich funktionieren. Wenn man das Datenblatt schon vor der Produktion gelesen hätte oder ganz am Anfang der Entwicklung, dann hätten Sie den Hersteller schon kontaktieren können. Also Sicherheit musst du ganz am Anfang bei des Produktes schon mit bedenken. Das ist ein essentieller Teil des Produktes heutzutage. Außerdem einige Hardware-Schwachstellen sind sehr, sehr einfach. Eine Sicherheit, z.B. wenn man benutzt einen anderen Bus, um den geschützten Code anzugucken und zuzukaufen. Also wenn du da ein Pentes in deiner Firma habt, dann hätte das wahrscheinlich sehr, sehr einfach gefunden. Es gibt weitere Fragen da drüben. Mikrofon? Jetzt. Eine kurze Sache. Die Farbe auf den Disclosure-Time-Crafts, also wie lange ihr gebrochen habt, bis ihr die Sachen veröffentlichen konntet, haben die Farben eine Bedeutung, Hersteller A und Hersteller B? Haben die besondere Bedeutung? Nein. Okay, danke. Danke für den Vortrag. Gibt es irgendwelche Hersteller, Hardware-Hersteller, welche Security-Backbound die Programme haben? Eine Frage. Okay, nur eine bitte. Hat jemand irgendwo ein Backbound-Programm? Ich weiß es nicht. Ich glaube nicht. Ich kenne auch niemand, zumindest im üblichen kommerziellen Mikrocontroller im Feld. Aber diese Sicherheitsbound, die Backbound-Programme können auch das Gegenteil bewirken. Eine offene Diskussion über Schwachstellen entgegenwirken. Ich habe manche dieser Guidelines gelesen. Das war oft so, wie wenn du ein Fehler berichtest und wenn du dieses Backbound-Programm benutzt, dann möchtest du deine Ergebnisse irgendwo anders publizieren. Das wäre nicht gut für die Mikrocontroller-Community-Gemeinschaft. Okay, ich glaube, wir haben nur noch eine Zeit für eine sehr, sehr kurze Frage. Ist ja eine kurze Frage vom Internet? Nein, okay, dann hast du die glückliche letzte Frage. Sehr interessante Präsentation. Ich habe mich gefragt, ob jemand der Hersteller die Hardware aktualisiert hat, um die Probleme anzugehen. Nein, bisher nicht. Aber ich glaube, das ist zu früh, um es zu sagen, weil das Paper letzte Woche quasi veröffentlicht wurde und die anderen Hersteller, über die wir geredet haben, sind eher so, die neue Serie wird bald rauskommen. Also ich weiß es nicht, ich habe da kein aktuellen Info, aber es würde sehr, sehr interessant sein, wenn sie auf uns zukommen würden und sagen würden, wir haben da was verändert. Aber soweit ich das weiß, ist es noch nicht der Fall. Johannes, Marc, vielen lieben Dank für diesen tollen Vortrag.