 Ich bin sehr froh, dass ihr jetzt alle hier seid und dass ich Johanna Rudkowska euch vorstellen kann, wie über halbwegs vertrauenswürdige x86 Systeme reden wird. Sie ist die Gründerin und Führer von Invisible Things Lab. Das ist also auch etwas, was ihr wahrscheinlich alle benutzt, das CubesOS Betriebssystem. Und sie wird jetzt hier bei Intel basierte Systeme und Virtualisierung sprechen. Aber heute nicht nur über die Probleme dieser Maschinen, sondern auch einige Lösungen, um darstellen, um das sicherer zu machen. Also, herzlichen Applaus. Lass uns mit etwas offensichtlichem anfangen. TCS sind Erweiterungen unserer Gehirne. Die meisten von euch werden da wahrscheinlich zustimmen. Aber die sind unsicher und unvertrauenswürdig, was mich persönlich sehr beunruhigt. Und ich will kurz einen Ausflug machen und über die Worte sprechen, die ich hier benutzen will. Es sind drei Eigenschaften, die mit Vertrauen zu tun haben und die werden häufig verwechselt. Also, wenn wir über Vertrusted reden, dann bedeutet das, dass einzelne Dinge, die dann die Vertrauenswürdigkeit des gesamten Systems zerstören können. Das heißt, wir wollen keine Trusted-Systeme, keine Systeme, in denen wir vertrauen müssen. Das bedeutet nicht, dass das sicher ist. Was bedeutet also sicher? Sicher bedeutet, dass es widerstandsfähig gegenüberattacken. Zum Beispiel dieser Laptop, der kann zum Beispiel, wenn man einen E-Mail-Anhang empfängt, dann ist möglicherweise mein Laptop dagegen geschützt. Und wenn ich jetzt hier einen USB-Stick einstecke, mit dem ich dann die Slides umschalten kann, dann hoffe ich auch, dass das nicht die Sicherheit meines PCs kompromittiert. Aber es gibt Dinge, die können sicher sein, aber nicht vertrauenswürdig. Und ein Beispiel dafür könnte zum Beispiel die Intel-Management-Engine sein, über die ich später noch mal sprechen werde. Das heißt, man könnte möglicherweise einem Angriff widerstehen, aber es könnte auch eine Backdoor eingebaut sein. Das heißt, es kann sich möglicherweise Angriffen widersetzen, aber es handelt nicht im Sinne des Besitzers. Also nicht gut in deinem moralischen Referenzrahmen, nicht die richtige Entscheidung. Und es gibt eine ganze Menge an Arbeit, die in den letzten 20 Jahren oder auch mehr passiert ist, um Lösungen zu bauen, die Sicherheit und Vertrauenswürdigkeit sicherstellen sollen. Die meisten dieser Arbeiten, da ging es um die Programme, also die Applikationen, PGB, Tor, alle diese sicheren Kommunikationsprotokolle und Anwendungen. Aber natürlich ist es auch klar, dass ein Aufwand, den wir auf dem Applikationslevel treiben, bedeutungslos ist, wenn wir nicht sicher sind, wenn wir eben nicht vertrauen können, dem Betriebssystem. Denn das Betriebssystem ist der Teil, dem wir vertrauen, das ist trusted. Und wenn das Betriebssystem kompromittiert ist, dann ist alles verloren. Und es gibt einigen Aufwand, der getrieben wurde. Und das gibt jetzt etwa zwölf Leute, die an Cubes arbeiten. Und wir versuchen dieses Problem, dass Betriebssysteme leicht kompromittiert werden können. Wir wollen die Menge des Codes, dem wir vertrauen müssen, minimieren. Und da gibt es eine Menge an Aufwand, der da getrieben wird aktuell. Aber ich werde über Betriebssysteme heute nicht reden. Was ich will heute über den letzten, die letzte Schicht, die Hardware reden. Denn genauso wie das Betriebssystem sich zu Applikationen verhält, so verhält sich eben auch die Hardware zum Betriebssystem. Und den meisten Aufwand, der bislang getrieben wurde, um sichere und vertrauenswürdige Betriebssysteme zu bauen, hat vorausgesetzt, dass die Hardware vertrauenswürdig ist. Und das bedeutet für die meisten, ob Betriebssysteme, dass ein einzelnes angeschlossenes Gerät, das bösartig ist an dem Laptop, zum Beispiel das WLAN-Modul oder ein eingebauter Controller, kann den gesamten Computer kompromitieren, mein gesamtes digitales Leben kompromitieren. Also was machen wir da jetzt? Und bevor wir darüber reden, was wir jetzt tun sollten, sollten wir schnell uns dann erinnern, was für Probleme die aktuellen PCs eben haben. Und ich werde mich jetzt hier speziell auf die x86-Plattform und speziell auf die Intel x86-Plattform konzentrieren. Und auf diesem Bild sieht man, wie ein typischer moderner Laptop aussieht. Ihr könnt sehen, es besteht aus einem Prozessor, das in der Mitte, und dann gibt es Speicher und angeschlossene Geräte, Tastatur, Monitor, es ist ganz einfach. Es kann sehr einfach sein, weil wenn wir uns bestehende Prozessoren anschauen, dann ist tatsächlich alles eingebaut in dieses Gerät. Und vor zehn Jahren gab es ein Prozessor, eine Northbridge, eine Southbridge und auch möglicherweise einzelne Teile, die im Motherboard eingebaut sind. Aber heute sind alle oder fast alle diese Elemente in ein Prozessor-Paket eingebaut worden. Das ist jetzt ein Broadwell-Chip. Und das längliche Element ist die CPU und die GPU, also die Grafikprozessor und die Prozessor. Bislang hätte man das eben Southbridge und Northbridge genannt, dieses andere Teil, und das ist jetzt dieses andere Teil, was wir hier sehen. Und es gibt nur eine Firma, die die herstellt, amerikanische Firma, die Intel heißt. Das ist eine komplett undurchsichtige Konstruktion. Wir haben überhaupt keine Ahnung, wir haben keine Möglichkeit, da reinzuschauen. Aber der Vorteil ist, dass die Herstellung, der Zusammenbau von Computern sehr, sehr einfach ist. Und viele Hersteller können eben kleine sexy Laptops wie den, den ich hier habe herstellen. Und auf dem Bild sehen wir auch noch zusätzliche Elemente, die in dem Prozessor integriert sind. Also wenn man Prozessor sagt heute, dann ist es nicht mehr nur noch die CPU, sondern es ist eben auch die GPU, die Speicherkontroller, der Hub, die PCI Express, Southbridge Teile. Also zum Beispiel SATA Controller und so weiter. Und auch etwas, das Management Engine heißt und da werden wir gleich noch mal drauf zurückkommen. Es gibt noch ein paar weitere Elemente, die wichtig sind. Und der Wichtigste davon ist die SPI Flash. Denn was interessant ist, ist mit dieser ganzen Integration, die beim Prozessor und bei den anderen angeschlossenen Geräten passiert ist, die Firmware wird nach wie vor, ist nach wie vor ein einzelnes Element, also wo das BIOS und die andere Firmware draufgespeichert wird, dass es immer noch ein einzelnes Element. Wir werden das auch gleich auf einem der nächsten Slides nochmal sehen. Also schauen wir uns zuerst mal das Problem an. Was ist die Sicherheit beim Booten? Jedem ist klar, dass die Sicherheit beim Booten, also es geht darum, wie starten wir die kette, die vertrauenswürdige Kette, um sicherzustellen, dass das Betriebssystem, das nachher läuft, auch vertrauenswürdig ist. Das ist sehr, sehr wichtig. Jetzt bin ich hier auf der falschen Slide. Und mit der Boots Security, also mit der Sicherheit beim Booten, hängt eben auch die bösartigen Geräte, die man möglicherweise anschließt zusammen. Also können wir sicherstellen, dass nur guter Code gestartet wird und wie die angeschlossenen Geräte hier dazwischenfunken können. Also wenn wir uns dieses SPI Flash-Modul angucken, also jetzt geht es um die Sicherheit beim Booten. Und wir wollen verstehen, welcher Code geladen wird beim Booten. Und wenn wir uns jetzt überlegen, wo das gespeichert wird, dann ist er auf diesem SPI Flash-Controller und möglicherweise auf einzelnen von den einzelnen Elementen, die hier markiert sind. Also ich möchte nochmal wiederholen, dieser gesamte Prozessor hat alles eingebaut, nur den Flash nicht. Also mit Ausnahme von dem Speicherort der Firmware. Hier haben wir eins von diesen SPI Flash Chips. Das ist tatsächlich von meinem Laptop, den ihr hier seht. Es ist ein kleiner Micro-Controller und das speichert üblicherweise die Firmware, für die Geräte, die da auf der linken Seite mit notiert sind. Und die Frage ist, sagen wir mal, ich habe den Laptop von einem Laden geholt. Wie kann ich sicherstellen, welche Firmware wirklich auf diesem Chip gespeichert ist? Naja, ich kann zum Beispiel hochfahren in ein Linux-System und nachfragen. Aber natürlich, wenn da ein bösartiges Element ist, zum Beispiel auf dem Motherboard, nicht notwendigerweise auf diesem Chip, dann kriege ich vielleicht nicht die wahre Antwort. Und eine andere Frage, behaupten wir mal, ich weiß, dass etwas vertrauenswürdig auf diesem Chip gespeichert ist. Können wir auf irgendeine Art und Weise sicherstellen, dass die nur gelesen werden können, also nicht geschrieben werden können. Und das gibt einigen Aufwand, der getrieben wurde. Zum Beispiel ein Projekt von Peter Stoke, der hat mit einem Lötkolben hier einen Pin verbunden. Und es gibt einen Pin, wenn man den erdet, dann sagt ihr den Chip, dass alle Schreibkommandos weggeworfen werden sollen, also ignoriert werden. Aber der Chip ist immer noch ein kleiner Microcontroller. Es ist immer noch ein kleiner Computer. Das heißt, er könnte möglicherweise diese Anfragen alle ignorieren. Es ist nicht so, als ob wir da ein Signal abschneiden, sondern wir fragen nur den, also wir bitten den Prozessor, ignoriere bitte das, bitte. Aber wenn wir dem Chip ohnehin schon nicht vertrauen, dann ist das kein verlässlicher Weg, um diese nur lesen Eigenschaft herzustellen. Also wie kann ich jetzt vielleicht zum Beispiel mein eigenes Bios drauf spielen? Und das sieht so aus, als hätten wir da kein Glück wieder. Also wie ich das gerade schon erwähnt habe, das ist nur einer von den Orten, wo diese Dinge gespeichert werden. Ein Embedded Controller wäre ein anderer Microcontroller, der auf einem internen Flash oder möglicherweise einen anderen SPI Chip benutzt, um Flash zu bekommen. Und das wäre also ein komplett eigener Microcontroller, also ein eigener Computer, der eigenen Flash-Speicher hat für die eigene Firmware. Und das ist möglicherweise auch für das WLAN-Modul wahr. Viel jahrelang habe ich selber und auch viele andere Leute immer geglaubt, dass diese Technologien wie TPM oder Trusted Execution Technology haben also geglaubt, dass wir damit irgendwie dieses Sicherheitsproblem lösen könnten. Aber wie sich gezeigt hat, helfen uns alle diese Technologien eigentlich nichts weiter und versagen also ganz grauenvoll. Das waren also eigentlich nur die Spitze des Icebacks der Probleme, wenn wir über die Sicherheit nachdenken. Und lange Rede, kurz das Sinn, wir können eigentlich heute nicht sicherstellen, dass wir den Bootvorgang auf eine sicherer Art und Weise durchführen. Bevor wir jetzt vielleicht zu Intel ME weitergehen, werfen wir noch kurz einen Blick auf Intel TXT Trust Execution Technology. Das ist was, was Intel eingeführt hat und was Intel damit machen wollte. Sie wollten, dass BIOS außerhalb der Trusted Base also unterbringen. Die Idee war also, wenn man TXT verwendet, man kann sich das vorstellen wie eine spezielle Instruktion für den Prozessor. Dann ist das sozusagen die Wurzeln alles vertrauens. Also wenn man Intel TXT benutzt, hätte man also in der Lage sein sollen, diese Kette des Vertrauens zu starten, ohne dem BIOS selbst zu trauen. Und dasselbe galt auch für Peripheriegeräte, wie zum Beispiel Wi-Fi-Karten. Und das war eigentlich eine tolle Idee. Und ich fand diese Technologie auch gar nicht schlecht. Und wir haben auch jede Menge Forschung betrieben an TXT. Aber eine der ersten Angriffsmöglichkeiten auf TXT, die wir ungefähr 2009 vorgestellt haben, bestand darin, dass wir TXT einfach umgehen konnten, indem wir ein bösartiges SMM hatten. Und wie sich herausstellte, konnte man das BIOS also gar nicht aus dieser Gleichung herausnehmen. Denn SMM war in der Lage, diese ganze TXT Technologie einfach zu umgehen. Die Antwort von Intel war okay, aber macht euch keine Sorgen. Denn wir haben eine Technologie, die nennt sich STM, Secure Transfer Monitor. Und das ist im Grunde ein kleiner Hyperweise, in der das SMM wie in einer Sandbox ausgeführt wird. Und wenn das also bösartig sein konnte, konnte es aus dieser Sandbox nicht ausbrechen. Was sie also machen wollten, sie wollten eine kleine spezielle Umgebung hochfahren, um dieses SMM in einer Sandbox auszuführen. Und wie sich herausstellte, war auch das nicht so einfach. Denn wie üblich liegt der Teufel im Detail versteckt? Ungefähr sechs Jahre sind es seit dem Vergangen. Und wir haben immer noch kein echtes System mit einem SMM gesehen, was man kaufen könnte. Und das ist also nur ein Beispiel, wie hoffnungslos dieser ganze Ansatz einen sicheren Bootvorgang zu gewährleisten, für die x86-Plattform eigentlich ist. Ein weiteres Problem mit der x86-Plattform, die in den letzten Jahren deutlich geworden ist, ist die Intel Management Engine. Eine dieser zusätzlichen Dinge, die Intel in seine Prozessoren eingebaut hat, nennt sich Management Engine. Und diese Management Engine ist ein kleiner Mikrocontroller. Der hier in dem Prozessor sitzt und er hat seinen eigenen eingebauten Speicher. Er hat sein eigenes Engine für Speicherzugriff. Das heißt, er hat also zum Beispiel Zugriff auf das RAM, was in dem PC eingebaut ist. Und natürlich erlaubt er nur Firmware, die von Intel signiert wurde. Und er hat auch ein kleines bisschen ROM innerhalb des Prozessors, wo man nicht wirklich reinschauen kann und wo also auch dem zufolge keiner weiß, was der Code in diesem ROM macht. Natürlich wäre es denkbar, dass dort proprietäre Programme ausgeführt werden und ein kleines proprietäres Betriebssystem von Intel. Und all das passiert immer sobald ihr bei eurem Laptop den Strom einschaltet und der Prozessor Strom bekommt, selbst wenn er der Prozessor eigentlich im Sleep Mode sich befindet, dann läuft dieses Modul weiter und kann im Grunde alles machen, was es möchte. Wenn ich sowas sage, dann ist natürlich der erste Gedanke, zumindest für Leute, die sich mit Security befassen, dass es eigentlich ein idealer Angriffsvektor um Backdoors oder RootKits in das System zu bringen. Aber es gibt noch ein weiteres Problem und das ist, dass euer PC dadurch zu einem Zombie gemacht werden kann. Ich finde, das sind zwei Probleme, die im Grunde unabhängig voneinander sind. Ungefähr zehn Jahre oder vielleicht sogar ein bisschen mehr habe ich sehr viel Forschung betrieben im Bereich Malware und auch was RootKits angeht. Und damals, wenn ich mir damals eine perfekte Infrastruktur zum Schreiben von RootKits hätte vorstellen müssen, hätte ich mir wahrscheinlich nichts Besseres als die Intel Management Engine vorstellen können. Denn die Management Engine hat im Grunde Zugriff auf alles, was wichtig ist in dem System. Wie ich erwähnt habe, hat es uneingeschränkten Zugriff auf das RAM, auf die CPU selbst, auf den Grafikprozessor. Es kann genauso gut auch zu den Netzwerk-Controllern sprechen und insbesondere auch zu der Ethernet-Card, der ja normalerweise in der Southbridge oder heutzutage sogar ein Prozessor eingebaut ist. Und zu dem SPI-Flesch-Module kann das eben auch reden und kann, hat auch da eine eigene Partition, die für die Management Engine reserviert ist, wo es also alles ablegen kann, was es dauerhaft aufheben möchte. Und das ist wirklich problematisch und wir wissen eigentlich gar nicht, was das Ganze macht. Aber das andere Problem, was vielleicht nicht ganz so offensichtlich ist, das ist das, was ich Zombifikation nennen möchte. Ungefähr vor einem Jahr wurde ein Buch herausgegeben von einem der Architekten von Intel, einer der Architekten, der die Management Engine designt hat. Ich kann das Buch nur empfehlen. Es ist sozusagen die einzige offizielle Informationsquelle über diese Intel Management Engine. Und was mir dieses Buch vor Augen geführt hat, ist dieses Modell, was sich Intel für die Zukunft vorstellt, ist im Grunde das Modell, was wir heute haben, was also folgendermaßen aussieht. Die Größe der Kästchen hier soll so ein kleines bisschen darstellen, wie die Menge an Logik, die in jedem dieser Schichten verbaut ist. Und wenn es um das Prozessieren von Benutzerdaten geht, passiert also das allermeiste in der Applikationsebene. Aber ein Teil der Verarbeitung muss eben auch vom Betriebssystem übernommen werden und ein noch kleinerer Teil eben direkt auf der Hardware. Wenn wir also beispielsweise eine Zufallszahl generieren möchten, dann würden wir normalerweise das Betriebssystem fragen. Wir würden normalerweise das Betriebssystem uns bitten, eine Zufallszahl zurückzuliefern, denn das ist eine Funktion, die das Betriebssystem beherrscht, wie auch immer es das macht, basierend auf der aktuellen Zeit. Aber der weiße Code steckt in dem Applikationslehrer und das ist eigentlich eine gute Sache, denn dadurch, dass unsere Computer ja allgemein gültig Computers sind, kann jeder von uns Applikationen schreiben. Man könnte jetzt darüber streiten, was der beste Weg vielleicht ist, zum Beispiel eine kryptografische Routine zu implementieren und der eine schreibt es vielleicht auf diese Weise, der andere auf jene Weise, aber das ist gut. Und das hier ist das Modell, auf das Intel zuläuft. Im Grunde wollen Sie einen Großteil der Logik, die unsere Daten anfasst, wollen Sie aus den Applikations- und Betriebssystemebene eliminieren und in die Management Engine verschieben. Und denkt daran, dass die Intel Management Engine ein komplett eigenes Betriebssystem ist. Allerdings ist es ein Betriebssystem, von dem keiner so genau weiß, wie es funktioniert. Es ist ein Betriebssystem, wo niemand die Möglichkeit hat, den Quelltext einzusehen oder Reverse-Engineering zu betreiben, denn wir können ja nicht mal den Bineerkode analysieren. Es steht unter der vollen Kontrolle von Intel und alle jegliche Dienste, die die MA zur Verfügung stellt, wird ebenfalls von Intel kontrolliert. Und nur die können im Grunde verifizieren, was die Management Engine tut und das mag kein bösartiger Code sein, der dort drin abläuft. Aber vielleicht haben Sie einfach einen Fehler bei einer Implementierung gemacht. Vielleicht sind dort Bugs drin, vielleicht sind dort Sicherheitslücken versteckt. Und Intel glaubt natürlich, dass alles, was Intel baut, auch sicher sein muss. Und aus irgendeinem Grund haben Sie anscheinend einige Papers nicht gelesen, die mein Team und auch andere Teams in den letzten zehn Jahren veröffentlicht haben. Die offensichtlichen Fragen sind natürlich, können wir die Intel Management Engine abschalten, können wir kontrollieren, was dort abläuft oder können wir zumindest sehen, welcher Code dort abläuft. Und meines Wissens nach können wir das nicht. Wie ich erwähnt habe, habe ich hier diesen coolen Laptop, der unter CubesOS läuft. Aber natürlich läuft dort nicht nur CubesOS, sondern auch die Intel Management Engine. Und das ist ein properitäres Betriebssystem. Und es gibt nichts, was ich dagegen tun kann. Ebenfalls vor ungefähr sechs oder sieben Jahren habe ich mit meinem Team zusammen an Intel VT gearbeitet. Und das war eine der ersten Arbeiten, soweit ich das weiß, wo wir in der Lage waren, Code zu injizieren. Und das war zu dem Zeit, als Intel ME noch nicht im Prozessor verankert war, sondern sich in der Northbridge befunden hat. Es war, glaube ich, der Q45-Schipsatz. Und wir konnten demonstrieren, dass es möglich war, ein Rootkit in diese Management Engine einzubringen. Intel hat das natürlich dann gepatched. Und jetzt glauben Sie wieder, dass alles, was Sie schreiben, natürlich hoch sicher ist. Aber das eigentliche Problem ist, einige Jahre nach dieser Präsentation habe ich immer noch geglaubt, dass wir VTD benutzen können. Das ist ebenfalls eine Technologie von Intel, oder vielleicht auch TXT, um im Grunde die Management Engine in einer Sandbox ablaufen zu lassen. Denn die Spezifikationen haben im Grunde besagt, dass es möglich sein sollte, die Management Engine und die Zugriffe zum Beispiel auf den Speicher in einer Sandbox laufen zu lassen. Weil wir auf Cubes auch das VTD sehr stark benutzen, hat mich das natürlich besorgt. Wie sich dann leider herausstellte, kann die Management Engine einfach VTD umgehen und dieses Feature einfach ausschalten. Das brachte uns dann zu dieser traurigen Erkenntnis oder zu diesem traurigen Schluss, dass wenn wir jetzt auf diese Intel-Plattform schauen, dann ist der Krieg hier an dieser Stelle eigentlich verloren. Und er wäre wahrscheinlich selbst ohne die Management Engine verloren. Selbst wenn wir es irgendwie schaffen würden, Intel davon zu überzeugen, wenigstens die Möglichkeit für Laptop-Hersteller die Möglichkeit zu eröffnen, die Management Engine abzuschalten, wäre der Krieg wahrscheinlich dann auch verloren. Das Problem mit Secure Boot, also einem sicheren Bootvorgang, was ich auch in sehr detailliert in einem Paper analysiert habe, ist tatsächlich hoffnungslos, denn die Komplexität dieser ganzen Architektur, wo wir Ring 3 und Ring 0 haben, dann haben wir SMM, dann haben wir Virtualisierung, dann haben wir STM, um eine Sandbox für SMM zu bauen und die Art und Weise, wie diese ganzen Komponenten interagieren, sieht nicht so aus, als ob wir dieses Problem auf eine effektive Art und Weise lösen könnten. Und das bereitet mir noch ganz gewaltig Sorgen. Und sei es nur aus egoistischen Gründen, denn ich habe ja die letzten fünf Jahre meines Lebens mit diesem Cube's Project zugebracht. Und wenn die Dinge so sind, wie sie scheinen, dann macht das mein ganzes Cube's Project eigentlich bedeutungslos. Aber manchmal, wenn die Situation so schlecht ist, dann ist vielleicht der einzige Weg, das Problem zu lösen, indem wir einfach die Regeln des Spiels ändern. Also wir können das unter den alten Regeln das Spiel nicht gewinnen, aber vielleicht können wir es mit den neuen regeln. Und deswegen wollte ich diesen Ansatz heute vorstellen. Und es geht eben darum, zu erkennen, dass das Problem, oder die meisten Probleme, was damit zu tun haben, dass ein Zustand gespeichert wird auf allen Ebenen der Plattform. Und zum Beispiel die Firmware, aber nicht nur. Also stellen wir uns mal vor, wir könnten Zustand und Hardware sauber trennen. Das ist das aktuelle Bild, das ist euer Laptop. Und die roten Boxen, das ist eben der Zustand, der permanent gespeicherte Zustand. Das heißt, das sind die Orte, wo Mailware, wo bösartige Software dauerhaft gespeichert werden kann. Und das sind auch Orte, wo Mailware, also wo bösartige Software Geheimnisse speichern kann, zum Beispiel die, die sie von euch geklaut haben. Also ich habe zum Beispiel, es kann zum Beispiel bösartige Software geben, die nur mein Verschlüsselungskiefe für meine Festplattenverschlüsselung klaut. Und das speichert's zum Beispiel irgendwo auf der Festplatte, oder im SPI Flash, oder im WLAN-Modul, oder möglicherweise im Embedded Controller. Irgendwo wird in diesen roten Bereichen dieses Geheimnis abgespeichert. Wenn die Böse Software das tut, dann ist das natürlich eine ziemlich problematische Situation. Wenn zum Beispiel mein Laptop geklaut wird oder beschlagnahmt, dann kann die Person, die die den Zugang zu dieser Mailware hat, also zu dieser bösartigen Software, der kann dann einfach den Schlüssel auslesen und hat dann den Schlüssel zu meiner Festplattenverschlüsselung. Ein weiteres Problem mit dem Zustand ist auch, dass es etwas offenlegen kann über zum Beispiel über persönliche Informationen offenlegen kann. Also zum Beispiel MAC-Adressen, oder möglicherweise CPU-Seriennummern, oder von der Management Engine Seriennummer, was auch immer, oder es sind SSIDs von WLAN-Netzwerken, die die Management Engine gesehen hat. Woher wissen wir, dass die nicht irgendwo abgespeichert werden? Also auch wenn ich meinen SPI Flash ausschalten kann, oder möglicherweise ein Programm anschließen kann, dass das auslesen kann, aber all das ist ja verschlüsselt. Das heißt, wir erkennen jetzt, dass Zustand ein Problem sein könnte. Und jetzt stellen wir uns ein Bild vor, wo wir ein Laptop haben, der jetzt keine permanente Speichermöglichkeit mehr bietet. Also nennen wir das mal zustandslosen Laptop. Und dann haben wir ein anderes Element, das nennen wir jetzt zum Beispiel mal den vertrauenswürdigen Stick, und darauf wird jetzt die gesamte Firmware, die Konfigurationen, die Systempartitionen, also Boot-Partitionen, oder die Wurzelpartitionen und die Benutzepartitionen. Jetzt ist natürlich klar, dass die Firmware und die Systempartitionen nur gelesen werden können. Das heißt, selbst wenn bösartige Software, zum Beispiel traditionelle Software, die auf meinem System gelandet ist, auf zum Beispiel durch eine bösartigen E-Mail-Anhang, dass selbst wenn diese Mail-Wire eine Schwäche gefunden hat, dann kann in dem Fall die bösartige Software das BIOS nicht mehr überschreiben. Und solche Angriffe davon haben wir sehr viele gesehen in der letzten Zeit. Aber in dem Modell wäre das eben nicht erfolgreich, denn der vertrauenswürdige Stick, der einfach nur ein SPI-Gerät ist, stellt es eben nur als Lesezugriff zur Verfügung. Und so können wir eben Firmware-Infektionen vorbeugen. Außerdem gibt es keinen Ort, um gestohlene Geheimnisse abzuspeichern, denn die selbe bösartige Software, die läuft, könnte jetzt immer noch meinen PGB-Key oder meinen Festplattenverschlüsselung-Skey auslesen. Aber es kann es eben nirgendwo speichern. Das heißt, jemand, der meinen Laptop mitnimmt, hat dann keine Chance, dieses Geheimnis irgendwo zu finden. Also möglicherweise könnte dir jetzt sagen, man kann es ja vielleicht auf dem Stick speichern, aber die Partitionen für System und Firmware sind ja nur lesend und die Benutzepartitionen sind ja verschlüsselt. Klar, MI kann immer noch Informationen da hinschicken, aber außerdem benutzer selbst kann niemand diese Informationen wieder auslesen. Außerdem haben wir jetzt einen zuverlässigen Weg, um rauszufinden, welche Firmware wir benutzen oder eben auch einen Weg, um auszusuchen, welche Firmware wir benutzen wollen, wenn wir könnten einfach den Stick... Wir könnten es in einem 15 Jahre alten Laptop stecken mit Coaboot und dann könnten wir da die verschiedenen Elemente eben analysieren. Das heißt, wir haben jetzt endlich eine Möglichkeit, weil der aktuelle Laptop, also weil der tatsächliche Laptop jetzt eben keinen Zustand mehr hat, haben wir jetzt endlich eine Möglichkeit, sicherzustellen, dass er tut, was er behauptet, dass er tut. Ich kann es benutzen, ich kann es runterfahren und es gibt keinerlei Spuren von dem, was ich da getan habe. Ich kann den Laptop jemand anders geben oder ich kann eben einen anderen Umgebung buten. Also möglicherweise ein Windows, um Spiele zu spielen, oder? Also was müssten wir tun, um so einen zustandslosen Laptop zu kriegen? Das ist die einfachste Version, wo wir sehen können, dass die einzige Modifikation, die jetzt hier gemacht wurde, ist, dass wir den SPI Flash Chip ausgebaut haben und außerhalb des Laptops jetzt quasi haben auf so einem vertrauenswürdigen Stick einfach nur diese vier Kabel werden jetzt auf den Trusted Stick weitergeleitet und das ist im Wesentlichen alles, das ist die einfachste Möglichkeit. Ach so, und ich habe außerdem, ich musste jetzt hier noch sicherstellen, dass diese grauen Kasten, dass die jetzt keinen Flash-Speicher haben, also, sondern dass die sowas wie OTP-Speicher benutzen. Also wir können den WLAN-Chip zum Beispiel entfernen und einen externen benutzen, wenn das nicht möglich ist. Denn das ist der Embedded Controller, das ist immer irgendwas, das der Hersteller aussucht für uns, das können wir nicht selbst entscheiden. Aber wir können die Hersteller fragen oder bitten, ob wir einen Controller, der im Wesentlichen RAM benutzt, statt Flash-Speicher. Und das ist die einfachste Möglichkeit, die sehr, sehr einfach ist. Das ist jetzt eine etwas kompliziertere Variante. Da haben wir sowas, das nenne ich hier SPI-Multiplexer, das haben wir hier mit doch mit eingebaut und das erlaubt uns, die Firmware nicht nur an den Prozessor weiterzugeben, sondern auch an den Embedded Controller und möglicherweise auch an die Festplatte. Dann möglicherweise hätten wir ja gerne eine interne Festplatte, denn die ist zum Beispiel immer schneller und immer größer, als was auch immer wir jetzt als Festplatte in unseren Trusted Stick eingebaut haben. Aber ihr könntet jetzt widersprechen, eine Festplatte in einem zustandlosen Laptop, das ist ja kein zustandloses Ding, so eine Festplatte. Und die Festplatte ist auf eine spezielle Art und Weise hier gemacht. Da werde ich in wenigen Momenten drüber reden. Das ist eine spezielle Festplatte, die vertrauenswürdige Firmware ausführt und mit Verschlüsselung arbeitet. Und jetzt gehen wir auf den Trusted Stick ein, also den vertrauenswürdigen Stick. Also wie ich schon erwähnt habe, da ist die Vorstellung und die Hoffnung für den vertrauenswürdigen Stick. Das ist eine nur lesbare und nur verschlüsselte Partitionen anbietet. Und die nur lesbaren sind eben für die Firmware und für den Systemcode. Also der erste Teil da oben ist etwas, das wir zum Beispiel bei SPI exportieren wollen und die Systempartition ist, die wir dann dem Betriebssystem anbieten. Zum Beispiel über, indem man zum Beispiel so tut, als wäre man ein USB-Massenspeicher über das USB-Massenspeicher-Protokoll. Und die verschlüsselte Partition, also das Wichtige daran ist, dass die Verschlüsselung so implementiert werden soll, dass der Stick die selbst durchführt. Das heißt, wir haben einen Schlüssel und die Frage ist, wie, welchen Input sollen wir benutzen, um diesen, diesen Key herzustellen, abzuleiten? Also es könnte irgendwas sein, was bei diesem Stick sich nie ändert oder es könnte eine Passphrase sein, die der Benutzer zum Beispiel über ein ganz klassisches Tastatur eingibt. Und es könnte möglicherweise noch ein Geheimnis sein, was das TPM, also das Trusted-Plattform-Modul, in diesem Prozessor eingebaut ist, auf diesem Stick. Und jetzt sehen wir über diese interne Festplatte, die natürlich optional ist. Und es sollte im Wesentlichen dasselbe tun wie dieser Stick, aber weil das vertrauenswürdige Firmware ausführt, die er sich von dem Trusted Stick besorgt, ist die Festplatte selbst auch komplett ohne Flash-Speicher. Und weil wir der Hardware von dieser Festplatte vertrauen und der Firmware vertrauen und insbesondere der Firmware vertrauen, dass sie eben nur lesbare Partitionen oder verschlüsselte Partitionen anbietet, muss der Stick eben nicht mehr Massenspeicher sein. Das hat positive Effekte. Und das ist so ein Bild mit der internen vertrauenswürdigen Festplatte, die hier markiert ist. Wie man sehen kann, holt sich die Firmware eben auch von dem vertrauenswürdigen Stick. Und das gibt ein Projekt, das heißt Open SSD. Und das sieht so aus, als hätten Leute schon eine Open Hardware, Open Firmware SSD, die sehr, sehr schnell ist, gebaut. Also das ist hier nicht nur Science Fiction, zumindest für den Teil der SSD. Also das sieht alles ganz nett aus, aber es gibt ein Problem. Obwohl die Mellware möglicherweise, also die bösartige Software möglicherweise, keinen Ort hat, um die Geheimnisse aufzuschreiben, könnte es aber trotzdem zum Beispiel die Geheimnisse über das Netzwerk rausschicken. Und jetzt unterscheiden wir zwischen klassischer bösartiger Software und hochentwickelter bösartiger Software. Und klassische Mellware ist eben so etwas, was man über ein E-Mail-Anhang bekommt oder über ein Browser beim Surfen sich einfängt. Aber jetzt reden wir über die spezielle bösartige Software. Zum Beispiel ein Rootkit in der Management Engine. Und bevor wir jetzt weitermachen, offensichtlicherweise ist ja so eine spezielle Mellware nicht daran interessiert, also die ist daran interessiert, dass man sie nicht leicht finden kann. Also man kann die nicht einfach, man kann nicht einfach eine TCP-Verbindung zu diesem Server herstellen oder so was Ähnliches. Und wenn wir uns daran erinnern, dann schauen wir uns jetzt mal ein paar Szenarien an. Also das Szenario ist, wir haben ein System, das nicht ans Netzwerk angeschlossen ist. Und obwohl das nicht ans Netzwerk angeschlossen ist, läuft trotzdem diese Management Engine auf dem System. Wenn der Computer jetzt nicht in einem faradaischen Käfig ist, dann gibt es immer noch alle möglichen Netzwerke, Geräte, die um es herum sind. Und das kann bedeutet, dass die Management Engine zum Beispiel über den Lautsprecher oder die Netzwerkkarte zum Beispiel eine Verbindung zum Telefon herstellen kann, was spezielle Software ausführt. Und um so ein System also tatsächlich vom Netzwerk zu trennen, immer unter der Voraussetzung, dass wir die Management Engine nicht entfernen können, müssen wir für alle Geräte die Signale übermitteln, inklusive den Lautsprechern Kill-Switches einbauen. Also müssen wir ausschalten können. Aber selbst das könnte zu wenig sein. Denn das umfasst immer noch nicht so Geräte wie Temperaturflugtuationen oder Stromflugtuationen. Aber lassen wir die mal fürs erste Beiseite. Und ein weiteres interessantes Szenario ist ein geschlossenes Netzwerk, in dem nur vertrauenswürdige Knoten vorhanden sind. Und in diesem Szenario vermuten wir jetzt, dass alle Geräte, die in diesem Netzwerk sind, vertrauenswürdig sind. Das heißt, die Definition ist, jede von diesen Leuten kann jetzt unser System komprimitieren. Das ist die Definition davon. Deswegen mögen wir vertrauenswürdige Dinge nicht. Aber obwohl jeder von diesen vertrauenswürdigen Knoten, obwohl die jetzt alle dieses bösartige ME-Management-Engine eingebaut haben, bauen wir einen kleinen Proxy, also einen Zwischenhändler dazwischen, eine Modifikation, die wir also zusätzlich noch machen müssen. Das heißt, statt unser WLAN-Modul direkt an den CPU, an den Prozessor anzuschließen, was nicht gut ist, weil es bedeutet, dass der Prozessor komplett dieses WLAN-Modul kontrollieren kann. Stattdessen möchten wir es über ein Zwischenmodul anschließen, so einen Proxy, und das führt so eine Art Tunneling, wie so ein VPN oder zum Beispiel über Toa leiten. Mit dem gesamten Traffic, der da durchgeht. Und wenn das die Management-Engine jetzt möglicherweise traffic in irgendeiner Art und Weise zum Beispiel nicht explizit verschickt, sondern möglicherweise an andere Daten ran hängt, also zum Beispiel über die Sequenznummern von TCP-Paketen, dann haben wir es immer noch innerhalb von diesem Tunnel. Aber jetzt werden Leute sagen schon, aber möglicherweise wird das Timing von der generierten Paketen angepasst. Das kann man auch von außen beobachten. Und so kann man natürlich auch Informationen nach außen übertragen. Aber da können wir nicht viel machen. Aber andererseits wäre es eben auch sehr, sehr schwierig für das die Management-Engine so eine entsprechende Lösung zu implementieren. Und dann haben wir natürlich noch das Szenario, dass wir uns mit jedem anderen Rechner verbinden möchten, nicht nur mit den Rechnern, die wir vertrauen. Das heißt, den Rechner, den wir hier sehen, vielleicht vertrauen wir eben vielleicht nicht, aber dadurch, dass wir eben diesen Proxy hier haben, der ja möglicherweise auch innerhalb dieses embedded controllers implementiert ist, er läuft also unter einer Firmware, die wir vertrauen, denn die bekommt er ja von unserem, von diesem Stick, den wir haben. Dieser Proxy, den wir eingebaut haben, tunnelt also unsere Daten und verhindert somit, dass die Management-Engine Daten über uns preisgibt. Das heißt zum Beispiel, unser Service Provider, über den wir uns mit dem Internet verbinden, kann diese Informationen nicht sehen. Aber natürlich muss dieser Tunnel auch irgendwo ein Endpunkt haben, also zum Beispiel ein VPN-Server oder eine Tor-Exit-Note oder vielleicht ein Onion-Server, der ein Onion-Website hostet. Dann kann hier an dieser Stelle immer noch möglicherweise jemand die geheimen Informationen abgreifen, die die Management-Engine initiiert hat. Und leider ist das etwas, wo wir nichts dagegen tun können, außer wir könnten vielleicht, wenn wir Tor benutzen für diesen ersten Teil hier dieser Verbindung, dann ist zumindest ein bösartiger Server-Administrator nicht mehr in der Lage zuzuordnen, zu wem diese Verschlüsselungskie oder zu wem diese geheimen Informationen gehören. Unter der Voraussetzung natürlich, dass es sich dabei um einen allgemeinen Computer handelt, wenn man einen sehr speziellen Computer zum Beispiel mit Cubes benutzt und da nur eine Partition unserer Geheimnis beinhaltet, dann würde das nicht funktionieren, denn die Management-Engine wäre immer noch in der Lage, von jeder x-beliebigen Partition abzugreifen, denn es hat ja Zugriff auf alle Informationen des Rechners und das schließt auch den Arbeitsspeicher beispielsweise ein. Aber wenn dieser Proxy unseren hypothetischen Angreifer, wenn er ihm sehr starke Schwierigkeiten bereitet, unsere Daten einfach an irgendeiner High-Level-Protokoll anzuhängen oder über irgendwelche geheimen Kanäle zu versenden, dann ist das Verglichen mit dem, was heute möglich ist, dann können Sie den Schlüssel immer noch entwenden, auf der SPI Flash-Partition speichern, aber es ist immer noch um einige Größenordnungen schwieriger für Sie an diese Geheimnisse heranzukommen. Wir haben jetzt über diese spezialisierte Malware gesprochen. Die klassische Malware, damit es verhält sich ein bisschen anders, diese klassische Malware muss nicht aufpassen, dass es nicht sichtbar wird, dass die Daten raus senden. Die kann also zum Beispiel auch E-Mails versenden und muss das also nicht geheimhalten. Aber um dieses Problem also zu lösen, können wir das eigentlich relativ gut auf Betriebssystemebene in den Griff bekommen, indem wir zum Beispiel die Anwendungen voneinander trennen. Aber das Problem, was sich dabei ergibt, ist, dass zum Beispiel ein BIOS, das Schadcode enthält. Okay, ich muss vielleicht ein bisschen weiter ausholen. Also bisher haben wir immer unterstellt, dass wir dem BIOS nicht wirklich vertrauen müssen, denn wir haben ja diesen zustandslosen Laptop und unseren speziellen Stick, sodass also wenn Schadcode sich im BIOS befinde, wäre also nicht in der Lage, auf die Filmwebpartition zuzugreifen und irgendwelche Geheimnisse dauerhaft abzulegen. Also es ist vielleicht ganz bequem, sich zuvorzustellen, dass wir diesen BIOS nicht unbedingt vertrauen müssen, aber ein Kompromittier des BIOS könnte genauso gut auch askellen. Backdoors bereitstellen, über die sich Angreife eine zum Beispiel erhöhte Rechte beschaffen können und klassische Malware, die sich auf dem normalen Betriebssystem ausführen lässt. Für die ist es relativ trivial so etwas zu implementieren und natürlich wollen wir solche klassischen Malware ebenfalls nicht haben. Das heißt, also auch hier müssen wir sicherstellen, wie es diese Möglichkeiten also nicht bietet und keine Backdoors enthält. Um es kurz zu machen, wir müssen einfach ein Open Source BIOS entwickeln, wie zum Beispiel Coreboot. Es ist toll, dass wir Coreboot haben und wir sollten also alles daran setzen, dass wir Coreboot zu einem BIOS weiterentwickeln, sodass es ein Laptop BIOS werden kann. Coreboot ist nicht vollständig Open Source, es sind also zum Beispiel immer noch, es sind immer noch Binairecodes von Intel enthalten, die zum Beispiel einige der Chips initialisieren auf deinem Mainboard. Aber es sollte nicht allzu schwer sein, sicherzustellen, dass sich auf diese Art und Weise keine Backdoors einschleusen lassen. Also es ist in meinen Augen ein lösbares Problem. Und schlussendlich haben wir hier noch die Frage, also gehen wir mal davon aus, vielleicht in einem halben Jahr oder in einem Jahr, kommt jemand und sagt, hier haben wir einen zustandslosen Laptop. Du kannst ihn kaufen, der kostet 2000 Dollar. Und jetzt kauft ihr also diesen Laptop, aber woher wisst ihr, dass es wirklich ein zustandsloser Laptop ist? Vielleicht ist der Laptop ja voller Elemente, die trotzdem noch zustande speichern. Vielleicht sind jede Menge Geräte und Peripheriegeräte eingebaut, die Radiowellen emittieren und auf diese Art und Weise Informationen nach außen schicken können. Das heißt, die Frage stellt sich jetzt, wie können wir zwei verschiedene Platinen miteinander vergleichen? Bisher ist es so, dass wir keine wirkliche Möglichkeit haben, zwei verschiedene Platinen zu vergleichen und zu sagen, ja, die sind gleich. Denn wenn wir das hätten, dann könnten wir den Laptop-Hersteller, der ganz offensichtlich sich auch der Open Hardware verschreiben müsste und die Platinen-Layouts veröffentlichen müsste von den Mainboards. Und jeder, der sich dann einen dieser Laptops kauft, hätte die Möglichkeit, das Mainboard beispielsweise zu fotografieren und dann mit einer Art Diff-Tool zu vergleichen, ob es wirklich so aussieht, wie vom Hersteller vorgesehen. Natürlich könnten wir auf diese Art und Weise nicht schauen, was in dem Inneren der Chips vor sich geht, aber wir könnten zum Beispiel sehen, dass niemand an den Leiterbahnen modifiziert hat. Und das wäre schon mal ein ganz gewaltiger Schritt, solche bösartigen Modifikationen durch die Laptop-Hersteller zu verhindern. Das ist eine, ein Problem, Fotos zu vergleichen. Man nimmt also ein Foto eines bekannten Platinen, hält seine eigene daneben und ich glaube, vor ungefähr einem Jahr hat Jack Applebaum schon mal erwähnt, dass das ein ganz interessantes Forschungsprojekt ist für all die Akademiker unter euch. Hier ist ein Weihspiel. Ich habe dieses Laptop also bekommen. Ich habe den Laptop aufgemacht. Ja, ein paar Sachen kann ich vielleicht identifizieren. Ich kann die ECs erkennen, wie zum Beispiel diesen Embedded Controller hier drüben. Aber vielleicht ist er ja etwas anders angeschlossen als normal. Vielleicht ist da ein Chip drauf, der nicht drauf gehört. Das weiß ich eben nicht. Ich hätte gerne die Möglichkeit, das zu vergleichen mit einem Referenzbild. Der vielleicht von Experten detailliert analysiert wurde. Viele Leute sagen, dass wir uns vielleicht gleich von der Intel X86-Architektur verabschieden sollten. Aber es ist so eine richtig tolle Idee, ist das eben auch nicht. Oder vielleicht ist es nicht die Lösung für alles, sollte ich vielleicht besser sagen. Zum einen haben wir natürlich Arm. Alle sagen, warum nicht auf Arm umsteigen? Zum einen gibt es nicht den Armprozessor. Arm verkauft nur Spezifikationen, Intellectual Property. Und dann gibt es die Hersteller wie zum Beispiel Samsung oder Texas Instruments und so weiter. Die nehmen eben dieses Design und bauen damit ihr System on a Chip. Im Grunde handelt es sich da also trotzdem immer noch um einen proprietären Prozessor. Und sie können da auch mit dazu bauen, was sie möchten. Die Trust Zone in dem Armprozessor-Architektur ist nicht so verschlossen wie die Management Engine, aber natürlich können die Hersteller das Nehmen und das Modifizieren und etwas ME ähnliches daraus bauen. Es ist also nur, wenn der Hersteller sich dazu entscheidet, das zu machen, dann kann er das gerne tun. Die vielen unterschiedlichen Arten von Armprozessoren machen das außerdem noch schwierig für Betriebssysteme wie Cubes, die fortschrittlichen Technologien zu benutzen, weil sie eben nur von einigen und nicht von allen Armprozessoren unterstützt werden. Ein anderer Prozessor hat vielleicht eine völlig andere Implementierung, eine andere Version, eine bestimmte Technologie, so dass man sich da eben nicht darauf verlassen kann. Eine viel bessere Alternative wäre natürlich Open Source Prozessoren zu benutzen. Im Grunde könnte man die auf FPGAs implementieren. In der Zukunft haben wir vielleicht die Möglichkeit, dass jeder sich seinen eigenen Prozessor ausdrucken kann. Das ist aber jetzt natürlich nichts, was in den nächsten 10 Jahren passieren wird. Das heißt also, in der Zwischenzeit stecken wir mit Prozessoren fest, die uns nicht die gewünschte Performance geben und auch nicht die Sicherheitstechnologien. Das bedeutet, dass das eben in den nächsten Jahren noch keine brauchbare Lösung sein wird. Und selbst wenn wir das hätten, wenn wir einen Open Source Prozessor hätten, dann können wir den Zustand komplett trennen von restlichen Logik. Dann haben wir immer noch das... Dann können wir vielleicht Firmware-Infektionen verhindern, denn Potenziale Malware hat keine Möglichkeit mehr, die abgegriffenen Informationen irgendwo zu speichern. Und es würde uns auch erlauben, schnell unterschiedliche Umgebungen hochzufahren und Laptops zu teilen mit anderen. Viele von euch sagen jetzt vielleicht, naja, das sieht wie eine ziemlich coole Idee aus, aber am Markt wird sich sowas nie durchsetzen. Stimmt's? Aber zu verstehen, dass PCs, wie ich eingangs sagte, wirklich eine Erweiterung unseres Gehirns sind, sollten wir mal aufhören nur über die Kräfte des Marktes, als die absolute Macht zu denken, die bestimmt, wie sich unsere Computer entwickeln. Stattdessen sollten wir uns darauf konzentrieren, wie wir Menschenrechte schützen könnten. Wir sollten es nicht den Kräften des Marktes überlassen, uns vertrauenswürdige Computer zu bringen, denn das wird wahrscheinlich nicht funktionieren. Denn es liegt nicht im Interesse der Kräfte des Marktes. Und hoffentlich bekommen wir da einige gesetzliche Regelungen, vielleicht innerhalb der EU, vielleicht könnte die EU hier was tun. Es ist schon irgendwie lustig. Wir wissen alle, dass unsere Welt so abhängig ist von Computern. Und trotzdem sagt offensichtlich jeder Ingenieur, mit dem ich gesprochen habe, ja, die Leute würden sowas nie machen, die Leute würden sowas nicht kaufen, die Hersteller, die Firmen würden das nicht in Ordnung finden. Aber wenn die ganze Welt doch so abhängig ist von Computern, sollten wir dann nicht die Ingenieure dazu anhalten, die ja letztendlich das letzte Wort haben, wie die Computertechnologie aussieht. Naja, ich lasse diesen Gedanken mal so im Raum stehen. Vielen Dank.