 Willkommen zu unserem ersten Vortrag auf dem Kongress. Die Vortrag ist, Open Source ist nicht ausreichend, um Vertrauensprobleme in Hardware zu lösen. Obwohl wir viel Gutes über Open Source Software sagen können, ist es nicht inherent sicherer. Und genau das Gleiche ist die Version für Hardware. Wir reden jetzt darüber, wie man vertrauenswürdige Hardware bauen kann und wie sie mit der Software zusammengebracht werden kann, damit es sicher ist. Wir haben einen Vortragenden hier, Bunny. Er heckt Hardware und Firmware. Aber der Vortrag wurde von drei Leuten vorbereitet, nicht nur Bunny, but auch Sean, Sam Cross. Die anderen sind leider heute nicht da, aber ein großer Runde Applaus für unseren Vortragenden Bunny. Ja, schön. Guten Morgen. Danke, dass ich hier sein kann und dass ich hier sein kann und über dieses Problem sprechen kann. Ja, es ist ziemlich aufregend, dass es so der erste Talk, der heute gibt, die Präsentation ist jetzt von PDF-Backup. Mal gucken, wie es funktioniert. Also, heute geht es darum, dass Open Source nicht ausreicht, um Hardware-Probleme zu lösen. Und wir schauen uns mal an, was wir dagegen tun können. Also, mein Hintergrund ist, ich bin ein großer Evangelist für Open Source Hardware. Ich habe eine ganze Menge in Open Source gebaut und da gibt es so eine Frage, die an mir nagert und sagt, okay, weißt du, man baut diese Open Source Hardware, man kann ja mehr vertrauen. Und da ist so diese Lücke in meinem Kopf gewesen, wo ich gedacht habe, ah, was ist das? Und in diesem Talk versuche ich mal, das rauszudestillieren, wo das Problem liegt. Also, ich denke, Leute haben Meinungen, welche Browser sicherer sind und welchen man mehr vertrauen kann. Aber die Frage ist, warum tut ihr das? Warum würdet ihr vertrauen, der eine ist besser oder sicherer als der andere? Und irgendwas sicherer ist als zum Beispiel der Samsung Browser, der in deinem Telefon drin ist oder warum man vielleicht einen anderen verwendet. Und ich bin ziemlich sicher, dass die Leute da so verschiedene Meinungen haben und die Leute sagen, dass Open Source halt immer vertrauenswürdiger ist. Aber warum ist das? Weil wir tatsächlich durchlesen, was da passiert ist, weil wir das sozusagen selber kompilieren, bevor wir sie verwenden. Nee, wir haben eigentlich nicht die Zeit, um das zu tun. Also schauen wir uns das mal ein bisschen genauer an, warum Open Source Software als sicherer gilt. Also, hier sind Diagramm für den Lebenszyklus von so einem Softwareprojekt. Man sieht also einen Haufen Developer-Power auf der linken Seite. Die Code-Committments in so einem Source-Management-System. LiveGit zum Beispiel. Dann bauen die das Ganze und dann geht das Ganze in eine Cloud, die nicht vertrauen. Das wird runtergeladen auf die Festplatte in Ram geladen und läuft dann ab. Und der Grund, warum wir glauben, das könnte vertrauenswürdiger sein. Ist, dass wir daran glauben, dass die also wissen, dass jeder im Grunde diesen Source-Code lesen kann, dass selber bauen kann und dann bestätigen kann, dass auch der tatsächlich dasselbe exekutable am Schluss rauskommt per Hash. Und die User können auch sozusagen rausbekommen, dass das auf diese Weise für sie funktioniert. Und dass das also vertrauenswürdiger ist. Wenn wir also Leute haben, die bestimmte Sachen angreifen wollen, zum Beispiel den Bild-Server oder den Cloud-Server, können wir das umgehen. Das hat damit zu tun, dass wir Werkzeuge haben, die Vertrauen in Software übersetzen können. Also zum Beispiel Hashing, Publinkies, Mercurys und so weiter und so fort. Und wir haben natürlich noch die sozialen Netzwerke, die wir haben, um die Community-Standards für Codequalität und ähnliches aufrechtzuerhalten. Nun, es lohnt sich mal anzuschauen, weil, wie Hashing für uns funktioniert. Denn da kann man so eine Kette des Vertrauens, eine Chain of Trusts aufbauen. Das ist ein Hashing für Leute, die es nicht wissen. Ein Hash nimmt einen großen Haufen Bits und berechnet daraus eine Zahlenfolge. Und das oder Symbole generiert ja. Und wie wir in dem Bild sehen, eine kleine Änderung, ein einziges Bits, generiert eine völlig andere Symbolfolge. Wir sehen also hier die Date auf der linken Seite, die hat ein Hash, der besteht aus Katzmaus, Panda und ne Beer. Und ein Bit geändert und schon Hash das Ganze auf 40 Cookie und ein Stück Pizza, glaube ich. Und da ist diese Änderung, wie gesagt, eine Änderung reicht daraus für eine dramatisch andere Hash daraus kommt. Und diese Hash-Funktion ist also so ein Sicherungsmechanismus, der sagen kann, ob irgendetwas sich geändert hat. Und bei Signierung geht es darum, dass man also einen öffentlichen und ein Stück privaten Schlüssel hat und damit diese Hashings noch mal signiert und damit also sicherstellen kann, dass diese Hashes tatsächlich von dem bestimmten Auto kommen. Die Herausforderung dabei ist, dass wir da eine Verifikations- und Benutzungszeitpunkt-Probleme haben. Wenn wir es zu einer anderen Zeit überprüfen, als es benutzen, kann man sich das mit einem Man-in-the-Bid-Angriff hereingehen. Das ist eine Angriffsklasse, die es ermöglicht, Informationsverkehr in der Wett-Übertragung anzugreifen. Wir verhalten uns auch so ein bisschen warm in diese Hoodies in kalten Plätzen. Ein Beispiel für eine Benutzerzeitpunkt- und Überprüfungszeitpunktunterschied ist, wir laden ein Datei herunter, schreiben sie auf die Festpärte, prüfen sie und jetzt könnte ein Angreifer die Datei auf der Festpärte verändern, bevor sie in Arbeitsspeicher übertragen würden. Obwohl die richtige Version heruntergeladen wurde, ist die falsche Version, die in Arbeitsspeicher geladen wird. Die Idee, wie die Sicherheit bei Open-Source-Projekten ist, ist, dass wir eine Möglichkeit haben, das zu überprüfen. Wir versuchen die Überprüfung möglichst nah an den Kunden zu machen. Kurz bevor die Software ausgeführt wird, wird überprüft, ob die Software immer noch die richtige ist. Die Frage ist eher so, der Ort der Überprüfung und nicht die Zeit der Überprüfung. Es ist wichtig, dass man die Kopie der Software überprüft so nah wie möglich dran. Wir nennen es nicht so, weil es hört sich so ein bisschen komisch an. Warum ich jetzt sage so, dass der Ort der Überprüfung ist? Der Ort der Überprüfung ist nicht der Ort der Überprüfung. Das Problem ist, wie haben wir unser Vertrauen und wir müssen die ganze Lieferkette vertrauen. Wir haben zum Beispiel eine Firma, da ist ein bisschen Code, der da drin ist. Das kann verändert werden, aber es kann auch ein zusätzliches Hardware-Modul in deiner Hardware eingebaut werden. Vom Firma-Situation ist die Technologie ein Problem. Es ist wirklich ein Software-Problem. Die gute Idee ist, wir haben Open-Firmware-Implementation, die diese Fragen angeht. Wenn man eine ausreichend große Firma ist, kann man die Firma Blob sich anschauen und das Problem eventuell lösen. Aber das Problem ist, dass man immer noch der Hardware vertrauen muss, dass die Verifikation richtig läuft. Das heißt, wenn die Hardware das nicht richtig verifiziert, ist es egal, dass man eine vertrauenswertige Firma hat. Und dann sind wir jetzt bei der Frage von Hardware-Implants. Trage ist, wie schlimm kann es werden? Wie ist das Feld, wo haben wir da wirklich unsere Vertrauensprobleme? Ich habe in viele Jahre mit Lieferketten angeschaut, das ist kein nettes Umgebung. Viele wollen, die Chips in der Lieferkette verändern. Das ist ein kleiner Microcontroller, ST, behauptet sicher zu sein. Und jemand hat gesagt, das ist nicht sicher, das funktioniert nicht richtig. Und wir haben uns das angeschaut und das ist ein komplett anderer Microcontroller drin. Das wurde nicht gemacht, weil jemand die Sicherheitschip angriffen wollte, sondern jemand wollte schneller ein bisschen Geld bekommen. Das, was drauf steht, ist das, worauf man schaut, was drin ist, ist egal. Oder man sieht es nicht. Ich habe ein Roboter-Controller-Gerät gebaut mit einem FPGA. Wir haben tausend davon hergestellt und ungefähr drei waren kaputt. Und ich habe später angeschaut, was passiert ist, dass sie nicht durch die Tests durchlaufen. Und ich habe gemerkt, dass alle, die nicht funktionieren waren, hatten diesen weißen Vier-Eck da unten, in dem der Zoom-Inversion hat. Und was wir festgestellt haben, war, unter der drin war IS für Engineering Sample. Und das wurde dann einfach weggeläsert. Und das ist gesagt, dass es noch nicht ein normales Produktionsgerät ist. Und hat es einfach in die Lieferung verkauft. Und es hat viel Geld damit gemacht. Verkäufer machen relativ wenig Geld. Das heißt, selbst wenn 97% der Hardware in Ordnung, das bedeutet immer noch nicht, dass alles in Ordnung ist. Es hilft nicht, ein Beispiel aus der gesamten Hardware herauszunehmen und sagen, hey, das ist richtig. Und darum müssten alle richtig sein. Das ist einfach eine falsche Herangehensweise. 100% Hardwareverifikation ist notwendig, wenn wir über Vertrauenswürdigkeit sprechen. Jetzt gehen wir noch ein bisschen tiefer. Das ist ein Diagramm, eine Analyse von Supply Chain angegriffen. Wir haben hier oben, wie einfach ist es, das festzustellen. Unten braucht man einen Mikroskop, in der Mitte ist ein X-Ray. Das ist ein bisschen spezialisiert. Und oben ist einfach visuell mit dem J-Tag und einem Programmiergerät. Und links und rechts ist die Implementationsspezifikation. Sachen, die mehrere Millionen im Monat kosten oder ein paar Dollar pro Sekunden. Hier sind viele unterschiedliche Klassen. Es gibt Sachen, die sind sehr einfach. Komponenten austauschen ist sehr einfach. Komponenten hinzufügen ist relativ einfach. Aber die gefährlichere ist eine neuen Chip, in den Chip, den man sieht, hinzufügen. Das ist noch ein Chip, in eine Paket hinzufügen. Das ist ein Teil von den Snowden Dateien, die wir gefunden haben, wo sie einen Chip, zusätzlich ein Chip in Verbkonektoren einbauen, in USB Stecker und andere Chips, die normalerweise draußen sind. Ein Chip in eine Paket hinzufügen ist relativ einfach. Das passiert jeden Tag, wenn man irgendeine SD-Karte, Micro SD-Karte, die man hart aufmacht, dann sieht man, dass da zwei Chips drin sind, mindestens ein Speicher-Chip und ein Controller-Chip. Und sie können 16, 17 Chips in diese Pakete rein spasten, ohne dass es ein Problem ist. Und wenn wir diese Tricks finden müssen, ist die einfache Weg, alles durch ein X-Ray-Gerät durchzuschieben. Und so sieht eine Platine aus. Ein paar Sachen sind sehr offensichtlich. Hier links haben wir unseren Ethernet-Gerät, das sind viele Sachen. Und das ist alles, was da reingehören, das ist normal. Und hier rechts haben wir unsere Chips. Wenn man sich das anschaut und sagt, hier ist dieses große, vier-Eck-Ding da unten, das muss der Chip sein. Aber tatsächlich ist es nicht der Chip, sondern das ist die Lüttsstelle, die die Disziplatine hält. Weil man kann den echten Chip gar nicht sehen. Wenn wir einen echten Chip in einer X-Ray anschauen, dann muss das ungefähr so aussehen. Links sieht man es in 3D aus und rechts ist, wie es ungefähr im X-Ray aussieht. Man hat diese dünnen Drähte, die rausgehen. Wenn man ein Chip in Chip anschaut, das ist ein Bild von einem Chip. Man sieht verschiedene Silikonenschichten, die aufeinander gebaut sind. Und wenn man das von der Seite sich anschauen würde oder können würde, muss man leider den Chip vom Platine ablösen. Das heißt, wir sehen immer nur von oben drauf. Wir sehen einfach nur ein paar gerade Drähte. Es ist nicht offensichtlich, ob wir mehrere Chips sehen, acht Chips, ein Chip. Wie viele Chips sind da überhaupt? Weil die ganzen Drähte über den Chip gehen und gut aussehen. Hier so sieht ein Chip im Chip-Szenario ein Chip. Und die Drähte gehen einfach nur so ein bisschen weiter. Und im X-Ray kann man das nicht sonderlich gut sehen. Wir sehen ein paar längere Drähte in ein paar Fällen. Das heißt, man kann die finden, aber es ist nicht offensichtlich, dass man einen Implantart gefunden hat. Silikon finden ist schwer. Silikon ist relativ durchsichtig für X-rays. Wenn man Kupferschichten darunter hat, dann sieht man die einfach nur schwer. Es gibt ein paar Sachen, die man dagegen machen kann. Man kann Computerphomografie machen. Man kann X-Ray, Röntgen diffragmentieren. Es gibt alles keine sicheren Methodiken. Und der Angriff ist gut verstanden. Es ist relativ günstig. Ich habe hier mal selber ein paar Chips zusammengebaut. Es kostet 10.000 Euro pro Woche. 7000 Euro, wenn man einen selber kaufen möchte. Man programmiert die Maschinen einmal, dann läuft es. Wenn man einen Chip modifizieren möchte, dann ist es nicht so obskur, wie man sich denkt. Dann gehen wir noch ein Stückchen weiter nach unten. Hier ist ein Querschnitt von einem Chip, da unten sieht man den Basis-Chip. Und oben sieht man ein Chip, der nur 0,1 bis 0,2 mm stark ist. Und tatsächlich haben die dort durchgebot, durch diese Chips, sodass man oben und unten Schaltkreise hat. Das sieht man dann tatsächlich auch. So sieht man also, wie diese Chips übereinander geschichtet oder gestapelt sind. Und das zweite Konzept ist, dass man auf dem Wafer, also auf den einzelnen Platinenschichten rausgeht. Und da sieht man also, dass diese überall drin sind. Also wenn man ein iPhone z.B. reinschaut, dann sieht man eigentlich, dass sämtliche Chips in dieser WLCSP-Technik gemacht sind. Und was da passiert ist, wenn man sich das Ganze anschaut, dann sieht es aus wie ein normaler Schaltkreis, den man dort hat. Und der dann darauf formuliert ist, wenn man das Ganze aber kombiniert mit diesem Silikon durchbrüchen oder diese Implantat, der da drin ist, dann bekommt man eine Angriffsmöglichkeit, die dann so hier aussieht. Man hat also ein Stück Silikon und das ist originale Pad drauf und das maskiert oder verdeckt sozusagen das, was da drunter ist. Und das ist im Grunde nicht aufwendbar. Also wenn man sich das Ganze anschaut, an der Kante dort sieht man dort so eine Naht, wo man das möglicherweise daran noch erkennen könnte, weil da verschiedene Geschichten oder so was drinnen kombiniert sind. Und wenn man wirklich überlegen will, okay, wie gut kann man so ein Implantat verbergen, so würde ich das machen, wenn ich es machen müsste. Also man muss die Chips sozusagen nicht in einer Form bekommen, die man tatsächlich verlöten kann sozusagen, sondern man kann die eigentlich direkt kaufen, wie es ist. Man kann eine Vorlage bauen aus Silikon. Das kann einige 100.000 Dollar kosten, bis man das hat. Aber wenn man das hat, dann hat man einfach Chips, die ziemlich verbreitet sind. Dann baut man da so eine Vorlage für, wo man diese Schicht hat und dann kann man damit arbeiten und das Ganze vertreiben. Also das ist hier gut. Reden wir noch ein bisschen über die Modifizierung des Chips selber. Also wie schwierig ist das so ein Chips, um sich selbst zu modifizieren? Also wenn wir ausschließen, dass jemand den Chip hinzugefügt hat, wie hart ist es, den eigentlichen Chip zu modifizieren? Also schauen wir mal. Gucken wir uns das Ganze mal bei einem Open Source Prozessor an. Wo ist die Angriffsfläche für diese Modifizierung? Auf der linken Seite sieht man so eine Flussdiagramm, wie so eine Schaltpreisherstellung aussieht. Es geht im Grunde los mit diesem High Level Chip Design mit RTL Plus oder Python. Dann geht man, na, mal was in Entscheidungen treffen. Macht man Backend Tooling oder macht man es nicht? So, wenn man also der Fabrik vertraut und ansonsten baut man den Chip dann selbst zusammen mit ein paar Lücken drin und zu sagen, macht diese Massen den dafür brauchen, geht in die Massenproduktion von dem Ding. Und die Frage ist, wo man sozusagen dort angreift, ob man also einzeln oder in großen Mengen mit herum spielt. Also wenn man den RTL selber geschrieben hat, dann macht man den Chip selber, aber das ist eigentlich nur ein Fall, denn Minderheit passiert. Denn normalerweise macht der Kunde sozusagen diesen Ablauf und das dauert normalerweise einige, kostet einige Millionen Dollar, bis das funktioniert. Das macht man vielleicht für ein Flagship Protobot, für so ein richtig Flagship CPU, die eine Firma herstellt. Die meisten Chips, die hergestellt werden, würde man sagen, das ist eine ASIC Seite, Applikation Specific Integrated Circuit. Also man macht so RTL Diagramma, macht vielleicht noch so diesen Floorplan und dann macht die eigentliche Fabrik, von der man das herstellen lässt, das ganze Detail, also wo das Ganze sich auf dem Chip befindet, die IP Integration und so weiter und so fort. Und das macht man für billigere Chips, das braucht, also Support Chips, Diskontrollers. Ja, genau. Und das sind also Chips, wo also zum Beispiel Daten durchtransportiert werden. Ich gebe euch mal eine Idee, wie verbreitet das ist. Da gibt es diese Firma, die so die, das ist eine dieser multimillionär Milliarden-Dollar-Firmen, von denen du niemals gehört hast. Hier sieht man das Design davon und da sieht man, wie sich das aufteilt, wo das Design gemacht hat und in der Technik stattfindet. So, das heißt, wenn ich COT mache, das heißt, wenn ich es nicht über Essig mache und sehr, sehr viel Geld in die Hand nehme, dann sollte ich eigentlich das sein, oder? Ja, da ist auch eine Schwäche drinnen, ist das sogenannte Hard-IP-Problem. Auf der rechten Seite sieht man sozusagen den Plot von diesem SRAM Scan, sieht es so aus. Das Bild sieht nicht so toll aus auf dem Projektor jetzt, aber was man hier sehen kann, ist der SRAM Block, der da drinnen ist. Und diese ganzen bunten Blöcke, die da drinnen sind, sind Zellen, die repräsentieren, die tatsächlichen Nandgates und so was, die da drauf montiert sind. Und wenn man dort drauf schaut und diesen SRAM in diesen Punkt, dort kurz vor der Produktion reinbringt, das macht man deshalb, weil der SRAM selber eigentlich ein großes Geschäftsgeheimnis immer ist. Das möchte man also für sich behalten. Da geht eine Riesenmenge noch hau rein. Und deswegen kann man, man kann seinen eigenen SRAM bauen, das geht tatsächlich, aber das wird niemals so gut sein, wie das, was die großen Firmen aufgrund ihrer Geschäftsgeheimnisse herstellen. Also, bei Hard-IP, worum geht es da? Das heißt, wenn man sich diese F-Bank-Gaps und so was anschaut, RAM, ROM, E-Fuses und Pad-Rings, das sind die Dinge, die dort angreifbar sind. Das ist das Ding, was sozusagen dein Chip in den PSD schützt, die Pad-Rings, all diese ganzen Dinge, die man braucht, sozusagen, um eine Backdoor in den Chip einzubauen. Gut, also sagen wir mal, okay, wir bauen sozusagen unsere ganzen IP-Blocks selber, unsere ganzen RAM, wir machen das alles alleine, dann sollten wir eigentlich komplett sicher sein. Na, Mensch, man kann diese Masken, aus denen das Ganze hergestellt wird, diese Belichtungsmasken, kann man auch noch dramatisch verändern. Und nämlich, bevor sie tatsächlich in der Produktionskette drinnen landen, und die gehen immer durch so eine Bearbeitungsphase, ne? So, das heißt, diese Masken, wo aus denen ein Chip dann geätzt wird, die sind nicht perfekt, sie müssen immer bearbeitet werden. Und deswegen muss man, wenn da ein Problem drin ist, von Hand, sozusagen, reingehen, einzelne Elemente einfach nochmal nach bearbeiten oder reparieren. Und man macht das hoffentlich besser, als es dann vorher war. Was kann man damit machen? Ja, da gibt es eine ganze Menge Veröffentlichungen drüber, die das beschreiben. Das hier zum Beispiel, da passiert jetzt keine dramatische Änderung in der Logik. Das heißt, was hier passiert ist, man muss also wirklich mit spektro- grafischen Verfahren da reingucken, um das Ganze heranschauen. Aber man kann dann direkt auf der Schaltkreis-Ebene Elemente verändern. Und das sorgt dann auch dafür, dass man tatsächlich Veränderung in der Logik des Chips herbeiführen kann. Und, ja, das passiert, wenn man ACI nimmt, ja, mein Gott, da gibt es auch immer wieder Probleme, die seiner Machenfehler, das geht überall. Das heißt, man muss das ja auch reparieren können und damit ist hier dieser Angriffspunkt gegeben. So, das heißt, selbst auf diesem Maskenlevel kann was passieren. Das ist nur ein ganz schneller Überblick, wo man sozusagen dieses Vertrauensproblem ansetzen muss. Und um das mal schnell zusammenzufessen, also das Problem ist, es gibt eine Menge Orte, wo man implatate Drinnen verstecken kann. Nicht alle davon sind entweder schwer oder teuer. Die sind eigentlich eher leicht zu machen, dieses sogenannte Wirebonding. Und es ist nicht so leicht herauszufinden, dass das passiert ist oder dass das jemand gemacht hat. Wenn man das ziemlich gut plant, sind sie wirklich, wirklich schwer zu finden. Also, man kann implatate, man kann einbauten machen. Also, was machen wir? Ja, na gut. Dann müssen wir also unsere eigene Fabrik brauen, nicht wahr? Also, machen wir das, wir bauen unsere eigene Fabrik. Egal, wie es funktioniert. Wir sorgen dafür, dass wir ordentliche Fabrikarbeiter dort haben. Gut, also, gucken wir uns das an. So, also, es geht los, mit dir selbst, da bist du. Und dann könnte man sagen, okay, da gibt es diese Evil Maid, also jemand, der zuarbeitet und dabei heimlich etwas verändert. Denken wir mal nach, wie die Sachen, die du kaufst und brauchst, wie die eigentlich zu dir kommen. Es gibt in Vertreibung, da gibt es den Kurier oder der Fahrer, der es zu dir fährt. Und es gibt tatsächlich Fälle, wo auf dem Transportweg des Materials zur Fabrik das Ganze sozusagen unterbrochen wurde, verändert wurde. Und dann wieder zurück, wieder verändert wurde. So, wie funktioniert das? Insgesamt schauen wir uns mal an. Es können auch andere Leute einfach dieses Produkt kaufen. Sie können es verändern und das dann als Reklamation einfach zurück schicken. Und das heißt, du kaufst Hardware von dem Distributor und tatsächlich kann durch Zufall dann so ein veränderter Ausgangsmaterial bei dir landen. Also, das ist doch so was, was passieren kann. Dann gibt es hier ein Paper, der nochmal ein bisschen genauer drüber erklärt, wie solche Sachen funktionieren, dass man also Sticker und Zertifikate darauf entfernen kann. Na gut. Nehmen wir das zurück. Schauen wir uns mal noch auf den Zoll an und so was da, wo müssen wir uns ja auch Sorgen machen. Und es heißt, es gibt eine riesige Angriffsoberfläche, wo selbst mit einer eigenen Fabrik sozusagen von der Distribution bis zur Box und also diese ganzen Sachen, wo etwas passieren kann, um Sachen ein bisschen profitabel zu machen, werden Leute Sachen immer ein bisschen billiger machen oder einfach eine Angriffsoberfläche damit, unfreiwillig vielleicht zu geöffnen. Das heißt, es gibt immer so einen Punkt, wo irgendjemand an die Hardware eben rankommt, bevor sie bei dir landen. Tja, kann Open Source uns jetzt retten oder kann Open Hardware dieses Problem jetzt lösen? Also, denken wir mal drüber nach. Wir haben diese Developer auf der linken Seite. Wie weit kommen wir damit? Wir können es machen. Wir können gucken, dass die Hardware korrekt ist. Wir bekommen diese offenen Entwürfe, diese offenen Schaltkreise. Wir können sozusagen an einer Stelle nochmal so ein Test machen und schauen, dass da noch irgendwelche Probleme entdeckt werden. Aber man sieht schon, wenn man sich das Ganze anschaut, es gibt ein Haufen Orte, wo wir es nicht kontrollieren gucken. So, das heißt einfach nur, da hat wir dann selber zu lösen, dass das funktioniert nicht, weil wir können letztlich Hardware nicht haschen. Es gibt keine Haschfunktion, die mir beruft auf meine Hardware, wirklich korrekt ist. So, das heißt, es gibt einfach keinen bequemen Weg, um das zu prüfen. Naja, ich sage Leute, Banni, aber es gibt immer noch das größere Mikroskop, mit dem man nachgucken kann. Ja, das stimmt tatsächlich. Es gibt eine herrliche Technik, die als ptyographische Röntgen-Bildgebung. Damit kann man es wirklich bis auf den Gate-Level, also auf den einzelnen Transistor runter sich das Ganze anschauen und Design-Vertifications machen. Aber das Problem ist, das Mikroskop ist so groß wie ein Gebäude. Ja, also dieses komische, scheibenförmige Ding, das ist das Mikroskop. Das braucht man, um diese Verifizierung zu machen. Und man kann vielleicht dahin gehen und so sagen, ja gut, okay, ich prüfe es dort. Aber wiederum, die Zeit, wo ich es prüfe, ist nicht die Ablaufzeit, wo ich es benutze. Und das ist ein großer Problem. Und ich kann halt auch immer nur einen einzigen Chip dann prüfen. Nur wenn 99 Prozent meiner Hardware okay sind, heißt es überhaupt nicht, dass ich sicher bin. Es gibt da einfach ein paar sehr fundamentale Probleme, die noch drin sind. Wenn ich Zufallstichproben mache, reicht auch nicht. Das ist einfach nicht gut genug, um Sachen rauszufinden. Würde man sozusagen die Software auch nur zufällig überprüfen, die man runterläten? Nein, man möchte sie immer prüfen. Also, wie kann noch Open Source jetzt aussehen bei HardwareTV Vertrauen wollen? Also, was man machen kann, Peer Review. Also, man kann es, das viele Augenprinzip kann, also Sachen eliminieren, das kann man tun. Und wir wären sehr, sehr gerne in der Lage, dass man sagen, gut, okay, wir ranlassen den Code zu sagen. Und sicher drauf laufen wir, prüfen das jeweils. Aber ohne diese Art von Transparenz funktioniert das für uns leider nicht. Sachen, die aus der Community kommen, das ist immer auch etwas sehr, sehr starkes, was geht. Designs in der Community gehören, das sind so Standards, wo wir eigentlich durchaus hinwollen. Das ist eine Notwendigkeit, tatsächlich. Aber es reicht eben nicht, um der Hardware zu vertrauen. Also, die Frage ist, können wir dieses Point of Use, dort wird es wirklich angewandt, dieses Verifizierungsproblem? Können wir das lösen? Ist das überhaupt lössbar? Ich habe darüber nachgedacht, und ich habe drei Prinzipien mir eingefahren dafür. Also, das erste ist Komplexität ist der Feind der Verifizierung. Also, man muss die Leute empowern, um sozusagen diese Sachen verifizieren zu können. Und das Problem ist, Komplexität ist eine komplizierte Sache. Also, wenn ich sozusagen nicht nur robustes Hashing habe, dann muss ich es einfach Stück für Stück verifizieren. Hier ist ein modernes Telefon. Das hat so viele Komponenten. Selbst wenn ich dir den voll, den kompletten Sourcecode dafür gebe, was machst du damit? Woher weißt du, dass das insgesamt dann photo funktioniert und nicht modifiziert ist? Also, mehr Komplexität, mehr Schwierigkeiten. Also, müssen wir es einfach machen. Wir machen es einfach aus ganz simplen Transistoren. Sehr, sehr leicht zu verifizieren, während diese Projekte dann. Und das Problem ist, das heißt, wenn man hier bis 500 Nanometer Produktionstrecker runtergeht und sowas, dann bekommt man, so zu sagen, hoch bis nach 100 MHz Clockrate, so zu sagen. Aber das ist halt wirklich limitierend. Also, man hat immer diesen Trade-off. Es ist leicht herzustellen, es ist leicht zu verifizieren. Es ist überhaupt benutzbar und kann man es gut nutzen und was für Fähigkeiten hat das. Also, Airpods zum Beispiel haben Millionen von Transistoren da drauf. Man kann sich sozusagen die Gleichung anschauen, schauen, wie das Backend dafür funktioniert. Und während so ein normales Headset hat, eine erhältliche Membran, die kann man sehr, sehr schnell verifizieren. Das heißt, man hat dann einfach ein Headset. Das ist wahr, aber man kann zu diesem Headset nicht sagen, Hey Siri, und es funktioniert. Das funktioniert sozusagen nicht. So, um ein Dialog zu starten, um das Gespräch zu kommen zu User-Ferrification, wir haben also auf jeden Fall erst mal Kontakt aufzustellen. Ich habe ein Projekt gestartet, das heißt Beat Trusted. Da ist die Frage, was wäre so ein minimal viable Product, so das minimale Produkt, an dem man das mal ausprobieren kann, wie das funktioniert. Und ich habe mir belegt, es müsste was sein, was tatsächlich darauf angelegt ist, modifiziert zu werden. Und das ist ein Bild davon. Das ist ein Prototyp, den ich tatsächlich hier habe. Den könnt ihr euch auf dem Kongress hier auch anschauen. Das ist ein Mobilfunkgerät, das sozusagen für textbasierte Kommunikation gedacht ist. Und man kann das auch für Authentifizierung nehmen und ein Wallet ist noch drin. Und ich denke, Leute, die es nutzen könnten, werden so High Value-Targets, also Leute, die Geld verwalten oder Leute, die aus anderer Sicht als ein Angriff sehr interessant sein konnten. Und natürlich Open Source-Enthusiasten. Und am liebsten hätte ich das auf der ganzen Welt verwendet. Das ist wirklich eine ganze Menge von Leuten und verschiedenen Leuten auch verwendet wird. Und die Frage ist, das bringt mich dann an einen Punkt, wo ich sage, okay, ich kann die wirklich schwierigen Probleme lösen. Das heißt, das Ganze muss man selbstverständlich mit Unicode funktionieren. Das wäre eine Möglichkeit. Das führt mich zum zweiten Punkt, dass ich sage, okay, wir müssen das komplette System verifizieren und nicht einzelnen Komponenten. Also, warum denke ich über dieses komplette Gerät nach? Ja, das Problem ist, diese ganzen privaten Sachen, die bleiben nicht wirklich privat. Also, man kann auf dem Screen-Inhalte kopieren, man kann Sachen abhören. Und selbst wenn man diese Schlüssel sicher halten möchte, müssen diese Schlüssel trotzdem einmal die Passphrases über das Keyboard, über die CPU wandern. Und das heißt, sobald man sozusagen das Keyboard benutzt, kann so eine Message aufgehen und sagen, übrigens, dieses Keyboard kann lesen, was du gerade tippst. Also, von daher hat man so ein Ding auf der Seite, wo ich sage, wollen Sie das tatsächlich wirklich haben? So könnten nämlich auch Daten modifiziert werden. Also, schauen wir uns mal an, wenn einiges komplettes Gerät verifizierbar sein soll, wie sieht das Ganze aus oder wie führt man das Ganze zu einem tatsächlichen Projekt zusammen. Also, das ist die Idee, diese drei Sachen zu nehmen und diese fünf Features zu haben. Also, ein echtes Keyboard, ein black-and-white LCD Bildschirm, ein FGA-basierter Risk-Tip. Ja, gehen wir mal so ein Stück einzeln durch. Also, erstens, warum gibt es ein physisches und kein virtuelles Keyboard? Ja, das Problem ist, dass diese guten Wurte ein Keyboard halt einen eigenen Firmware-Block drin haben müssen, also ein Microcontroller. Und es ist gar nicht so leicht, diese Dinge zu bauen. Und wenn man das wirklich gut und mit Open Source machen möchte, das wäre toll, wenn man das hätte, aber das ist wahnsinnig aufwendig. Und deswegen habe ich gesagt, okay, wir nehmen einfach hier ein physikalisches Keyboard. So sieht das Ganze aus, wenn man das Ganze auseinander nimmt. Man hat einfach das Overlay da drüber. Man kann auch diese Abdeckung mit verschiedenen Sprachen, eine Beschriftung unternehmen. Und wenn man es gegen das Licht sieht, sieht man, okay, da sind die Drähte, da sind die Schalter, da ist nicht viel drauf. Und das lässt sich also vergleichsweise simpel verifizieren. Schwarz-Weiß LCD, ein bisschen schwieriger. Ja, warum nicht Farbe nehmen? Wenn man jemals wirklich ein LCD-Display auseinandergenommen hat, dann schaut man nach diesen kleinen, dünnen Rechteck, was sich dort befindet, dass sich in der Nähe des Displays befindet. Das ist tatsächlich ein Silikonchip, der da drauf montiert ist. So sieht er aus in der Vergrößerung. Und da ist ja FrameBuffer drinnen und das Command Interface. Das heißt, wieder Millionen Transistoren da drinnen. Und man weiß nicht, was da drinnen ist, also was wir eigentlich tun. Und das heißt, das ist wieder so ein Angriffspunkt, über dem man sich Sorgen machen könnte. Ich habe tatsächlich ein Screen gefunden. Der heißt Memory von Sharp Electronics. Und das alles ist, die gesamte Electronics sind auf Glas. Da ist alles montiert. Und das heißt, ich kann sie tatsächlich sehen, mit einem erbilligen optischen Mikroskop. Und das ist die Komponente, die wirklich alles auf dem Display macht. Da ist nichts Verstecktes da. Das lässt sich also gut verifizieren. Und es gibt so, so wenige Orte, wo man hier was verstecken kann, dass man muss es eigentlich gar nicht unbedingt prüfen. Das heißt, wenn man diese Glas sich anschaut, oder einen Chip ran will. Also am Schluss sieht es so aus weniger Orte, wo man was verstecken kann. Und das wäre gut, wenn man dort was verstecken kann. Die gute Nachricht ist, dass dieses eine große Pixel-Dichte hat. Es ist näher an das IP. Wenn wir jetzt zu diesem schwierigen Teil des Prozessors kommen, der High-Bleiter-Teil, jedes Chip, das von heutzutage gebaut wird, ist nicht mehr komplett überprüft. Alles, was man überprüfen muss, für Schicht überprüft werden. Jede moderne Chip besteht aus vielen verschiedenen Schichten. Alles müsste überprüft werden. Dieser Prozess ist sehr schwierig umzusetzen. Man musste die Hardware einen Prozess bauen, um diese zu überprüfen. Ich habe sehr viel Zeit damit verbracht, zu über Optionen für diese Überprüfung aufzusetzen. Wir müssen Chip-Design-Techniken mit Schwierigkeiten verprügen. Wo kann man die Gates, die damit zusammenhängen, überprüfen? Das Problem ist, dass es keine richtige Strategie gibt, die wirklich einfach umzusetzen ist und wenig Geld umzusetzbar ist. Es gibt keine wirklich gute Möglichkeit, für alltägliche Menschen diese Überprüfung zugänglich zu machen. Es gibt keine platonische Möglichkeit, diese Überprüfbarkeit umzusetzen. Das FPGA steht für Feldprogrammierbare, Schalt-Array. Das ist ein Bild eines FPGAs. Auf der oberen rechten Seite ist eine große Cluster von Chips. Viele Schalte. Dieses Bild zeigt eine Koalition von Designs, wo man Code korrespondieren kann für dieses Netz. Der Gedanke dahinter ist, dass jeder sich diese CPU aus dem Quercode selber herstellen kann. Damit haben wir ein bisschen mehr von diesem Vertrauensransfer, wie wir sie in der Software haben. Aber das Problem ist, dass diese Toolchains nicht immer gut funktioniert. Es gibt sozusagen ein paar falsche Freunde. Es gibt mehrere Probleme in dieser Implementierung. Aber wenn man FPGA nimmt, das ist ganz gut. Da gibt es immer diese Frage dieser Trade-off zwischen Usability und kann man es verifizieren oder nicht. Bei einem mobilen Gerät, das möchte man den gesamten Tag über verwenden und möchte nicht, dass das sozusagen leer ist. Das heißt, es ist ein Akku-Dauer, eine Frage. Wenn man bestimmte Sachen nimmt, dann geht das also sozusagen dead by noon. Mittags ist das Gerät leer. Das wäre natürlich nicht so richtig gut. Das wirkt sich dann wieder auf diversiver Fall. Schauen wir uns ein bisschen mal diese FPGA-Features an. Das eine, was sie ans Anbieten ist, ich bekomme so ein paar Randomisierungsmöglichkeiten. Aber eben auf der Hardware. Es gibt so eine pseudo-zufällige Verteilung von Elementen auf der Hardware. Man sieht diesen Source-Code hier mit einer sehr, sehr kleinen Modifizierung. Man kann aber sehen, dass sich damit der Ort, wo das Ganze implementiert wird, in der Hardware verschiebt. Das bedeutet, damit werden ein paar Angriffe auf der Silikonebene tatsächlich wirklich schwierig. Wenn man einfach nur sagt, dass man so ein paar Drähte oder so was verändern will, dann wird es wahrscheinlicher, dass man es auffinden kann. Das heißt, wenn man wirklich eine Backdoor in so ein FPGA reinbauen möchte, dann muss man wirklich, wirklich drinnen auf der Source-Code-Ebene sehr, sehr sorgfältig arbeiten. Das heißt, wir suchen dann nicht mehr, ob bei der Referenzierung die Nade im Neuhaufen, sondern wir messen einfach, wie hoch der Heuhaufen ist. Das ist sehr, sehr viel einfacher zu implementieren, als zu sagen, diese Nade drin zu suchen. Noch ein paar mögliche Attacken, mögliche Angriffsmöglichkeiten auf dem FPGA sieht so aus. Also, der FPGA selber hat natürlich noch ein Close-Source-Chip. Was ist da drinnen? Weiß man nicht. Man kann das sozusagen in bestimmten Blog reinhauen und versuchen, okay, zu erkunden, was passiert da drinnen, wie funktioniert das Ganze. Aber es gibt, dort gibt es sozusagen zumindest eine Umgehungsmöglichkeit, die relativ einfach ist. Wenn man die Input-Output sozusagen angreifen will, wo ich gesagt habe, okay, man versucht also einen Chip dazwischenzulöten vor das FPGA, es gibt so ein paar Tricks, die man haben kann. Man kann den Bus zum Beispiel einfach verschlüsseln. Das wäre eine Möglichkeit, die man hat. Und man macht das Ganze auf der Implementierung. Zum Beispiel, man kann auf jeden Gerät die Drähte sozusagen anders beläden, also permutieren, wie diese Pins gemapped sind. Und das, damit würde eine bestimmte Implementierung, die müsste oder an Angriffen müsste tatsächlich jeden dieser Fälle dann handhaben, was wir hoffen, dass es schwerer möglich ist. Und natürlich kann man es nochmal gründlich durchleuchten. Das geht immer noch. Die Schwierigkeit bei diesen Close-Silicon, also bei diesen Teilen, wo man nicht rankommt, wir nehmen an, diese Firma hat so ein Toolchain-Patch und der sozusagen schaut, okay, wo gibt es ein betrusted Build und dann genau in diesen Builds, da möchte ich eine Backdoor drin haben. Und ja, das heißt, oder vielleicht sind sogar die ganze Toolchain selber, die ich verwende, um meinen FPGA, also meine Schaltung auf den Chip zu bekommen, meine Backdoor. Aber das coole da drin ist, es gibt ein Projekt, das heißt PRG X-Ray, Project X-Ray und die haben diesen kompletten Bitstream dokumentiert und das heißt, wir wissen nicht genau, was diese machen, aber das Verhalten dieses Bitstreams ist deterministisch und das bedeutet, wenn da eine Backdoor drin ist und so zu sagen, dann würde man sehen, dass sich etwas geändert hat in diesem Bitstream. Das heißt, wir können hoffentlich irgendwann so ein Bitstream Checker bauen, der tatsächlich in der Lage ist, sozusagen diese Bit zu prüfen, zu gucken, hat das, funktioniert das alles? Ist das so, wie erwartet, wenn ich mein Gerät benutze? Und damit kann ein Benutzer tatsächlich von seinem Gerät bestätigen, ja, das funktioniert so, wie es die sein wollte. Also, Zusammenfassung, schauen wir mal. Also, die, was dafür spricht, der einzige eigenes Chip, sozusagen, machen, ist, man bekommt sozusagen Custom Silicon und man hat eine sehr, sehr gute Performance bei 40 Nanometern und das ist aber wirklich, wirklich schwer zu verifizieren. Das heißt, Open Source hilft da nicht und diese Hard-IP-Blocks sind wirklich ein schwieriges Problem. FPG-As, die haben einige ganz, ganz offensichtliche Fahne, wo wir die Angriffe abwehren können. Das heißt, wir haben dieses Randomizite-Mapping, wir können diese Bitstreams anschauen und wir können pro Device ein eigenes Pin-Mapping machen. Das ist nicht perfekt, aber es ist schon sehr, sehr viel besser, als man es gar nicht machen könnte. Und das Problem ist, die sind gerade gut, gerade gut genug für die Anwaltung. Das heißt, man hat immer noch den externen Ramm, den man verwenden muss. Man hat eben nur 100 Megaspeed und man hat 5-10-fachen Energieverbrauch, den man mit dem Custom Silicon erhielt. Und das ist natürlich für ein mobiles Gerät eine ganze Menge. Und wie man gesagt, also wenn ich das Gerät hier zeige, warum das so dick ist, das ist die Batterie. Das ist einfach der Hauptteil da drin. Ja, schwierig. Also, jetzt schauen wir mal die letzten Punkte uns noch an. Also User's Healable Keys. Und das geht da jetzt um diesen dritten Punkt. Also die End-Users sozusagen, ihre Hardware zu überprüfen und zu versiegeln. Super, ich kann es verifizieren. Aber kann ich da drin ein Geheimnis für mich behalten? Man kann nicht da drin ein Geheimnis speichern, sozusagen. Schauen wir uns das Ganze mal an. Wir wollen ein FBGA zu bekommen, sozusagen. Wir wollen User- erzeugte Schlüssel, die schwer aus diesem Gerät rauszuholen sind. Und wenn es passiert, sozusagen, dann sollte man das bekommen können. Ja, also rausbekommen können, dass das hier in Angriff stattgefunden hat. Und die Lösung ist sozusagen, dieses Self-Provisioning und versiegelt tatsächlich der Kryptograph Schlüssel. Also schauen wir uns das Ganze mal an. Ich, wenn wir uns die Serie 7 von den FBGA anschauen, dann haben wir diesen verschlüsselten Age-Mag verifizierten Bitstream, von dem gebutet wird. Auslesen ist, wird verhindert davon. Und es braucht ungefähr einen Tag und 1,6 Millionen Cypher-Tax-Races, um diese Schlüssel dort rauszubekommen. Und das wäre tatsächlich immer noch ein Problem, aber es gibt ein paar leichte Möglichkeiten dem zu begegnen, dass eine ist tatsächlich es wirklich physisch zu versiegeln oder die Power-Filterung zu verbessern. Also jemand aber beim Zoll oder dieses Evil-Mate-Angriffs-Muster könnte, da versuche ich immer noch da zu sagen, rankommen. Was bedeutet das für uns? Wenn wir eine Region im Chap-Kinn, die wir sichern wollen, dann wäre das, wenn man genau weiß, wo man angreifen will, braucht man ungefähr eine Stunde, um die Schlichten abzutragen, eine weitere Stunde, um das Layer freizulegen. Das heißt, man könnte das in einem Nachmittag versuchen, auf der Hardware-Ebene anzugreifen. Aber das passiert nicht bei einer Zollstation und das wird auch nicht bei jemanden, bei den Mitarbeitern, und Vertrauenswürdigen Mitarbeiter passieren. Das ist also so nicht möglich. Gut. Das heißt, wie bekommen wir diese Schlüssel in das FPGA rein und wie bekommen sie wieder raus? Wie gesagt, sie sollten usergeneriert sein, sie sollten niemals das Gerät verlassen. Die CPU sollte gar nicht rankommen und man sollte sich nicht wahnsinnig auskennen müssen. So, wie machen wir das? Wir haben diese zwei Rechtecke, die dazu sehen sind. Das eine ist der ROM, da ist ein Bitstream drin und auf der anderen Seite das FPGA. Wenn man sich ganz anschaut, da ist der ROM drin, da ist der nicht verschlüsselte Bitstream im ROM drin. Dann haben wir eine Crypto-Engine, die aber wiederum keine Schlüssel hat, die das prüfen kann. Und die Schlüssel werden generiert, werden erzeugt, auf einem Teil, wo das FPGA nicht rankommt. Dann kann diese Crypto sozusagen dort rangehen und während sie diesen Stream verschlüsselt, kann sie diese Schlüssel dort sozusagen rein injizieren. Und da wir wissen, wo das Ganze sich befinden muss in dem Bitstream, dann haben wir einen versiegelten Bitstream in dem ROM drin. Und an diesem Punkt sozusagen, sollte tatsächlich der Strom nicht ausfallen, aber dann haben wir diesen Schlüssel und können tatsächlich in den FPGA mit reinnehmen, weil wir sozusagen diesen Strom dort über die Crypto-Engine entschlüsseln können. So, es gibt jetzt kein Weg sozusagen in diesen Bitstream reinzugehen und zu sagen, okay, sag mir jetzt deinen Schlüssel, das ist jetzt an dieser Stelle nicht mehr möglich. Man kann sozusagen diesen Hardware-Upgrade-Pass immer noch wieder ermöglichen da drin. Wenn man das aber macht, dann hat man öffnet mal wieder so eine Angriffsüberfläche, weil man dann natürlich wieder Zugriff auf diesen Schlüssel bekommen würde. Das heißt, wenn man wirklich paranoid ist, macht man das Ganze nur ein einziges Mal und dann muss man wirklich tatsächlich Bootforce diesen Schlüssel zu knacken. Also, es ist möglich mit FPGA und jetzt noch der letzte Punkt, ist es leicht zu verifizieren. Also, wenn man eine inspiziere, eine gutachbare Barriere machen muss, das Problem ist, diese Glitzersiegel sind einfach wahnsinnig hart zu verifizieren. Ich selber habe manchmal ein Siegel drauf gemacht und weiß dann nicht mehr, ist das Siegel, was ich da eigentlich vor drauf gemacht habe. Das heißt, wir haben dieses Gerät, die wir nicht haben. Die Frage ist, wie kriegt man jetzt raus, okay, dass man das selber bauen kann und so einen Wasserzeichen anlegen kann. Also, was man machen kann, ist so ein, diese Idee ist, dass ich dieses Epoxytmischung nehme und das Ganze auf den Tisch mache und dann diese Bewegung mache und dann mischt es das Epoxyt in dieser Tüte und dann male ich ein Wasserzeichen darauf und Menschen sind sehr, sehr gut, ihre eigene Handschrift wiederzuerkennen. Das ist tatsächlich so. Man kann das versuchen, aber das zu verifizieren ist zumindest viel, viel einfacher als auf so einem Glitzercode zu gucken und das heißt, was man macht, braucht einfach noch ein bisschen Küchenpapier und dann kann man das auf dieses Gerät drauf applizieren und wenn jemand das versucht, also abzutragen oder so tauschen, dann kann man persönlich meistens selber sehr gut sagen, Moment, das ist nicht das, was ich gezeichnet habe, das ist nicht das, was von mir kommt und das ist das, was man macht. Also, es ist so eine Art Hack, aber ich denke, es ist ein bisschen näher daran, dass man nicht noch ein extra Hardware oder irgendwas kaufen muss, um eine Verifizierung durchzuführen. Also ich habe über verschiedene Implementierungen hier gesprochen, wie man diese drei Prinzipien für vertrauenswürdige Hardware anwenden kann. Die Idee ist, man versucht, ein System zu bauen, das nicht zu komplex ist, so dass man die einzelnen Teile und alle zusammen möglichst verifizieren kann. Dass man auf das Keyboard, dass das Player anschaut und den FPGA direkt von der Source kompalieren kann. Und am Schluss möchte man sozusagen diesen, die Geheimnisse haben. Es sollte mit dem User anfangen und mit dem User aufhören. Das ist der Punkt, wo man hinkommen möchte. Ja. Okay, und man möchte sicherstellen, dass diese Geheimnisse in dieser Hardware also sicher bleiben. Das Ding ist also diese Lücke zwischen Time of Check und Time of Use, wo wir das angewandt waren, wird es geprüft zu schließen und das weiterzubringen zu diesem Point of Use, also zum User. Wir sehen diese riesige Landschaft an Problemen und die Idee ist, einfach so viel wie möglich den Usern beizubringen, ihr eigenes Zeug zu verifizieren. Es sollte im Design mit drinnen sein. Und das ist etwas, wo wir hoffentlich bald drüber sprechen können, mit welchen Werkzeugen wir das machen können. Aber ich würde gerne sehen, ob ihr in euren sozialen Netzwerken so ein paar Bemerkungen hinterlassen könnt, ob man jemanden findet, der das kann oder so. Und diese, erst gemusst, umgehen diese Konnen, diese Selbstbewusstsein aufzubauen, dass man sowas tun kann. Und dass man irgendwann mal Leute fragen kann, die sagen, ja, arbeite mit jenna klar, ich hasche das und so weiter und so fort. Und dass Leute irgendwann sagen, oh je, ich habe ein paar Leute vergessen, von denen ich das eigentlich haben möchte, dass sie dazu in der Lage sind. So, hier geht es also drum, dass man auch selber überprüft, ob das eigentlich wirklich nutzlich ist, was ich da versuche. Das heißt, ich möchte es eigentlich rausgeben zu Leuten und sagen, hier prüft es mal, der Entwicklungsstand sieht es im Moment so aus, dass die Hardware gerade in diesem EBT-Stage von Prototyp ist. Und wir wollen eigentlich im Moment noch viel mehr Ideen dafür sammeln, wie das Ganze funktioniert. Die Software fängt gerade an. Wir schreiben unser eigenes Betriebssystem dafür und wir schauen gerade noch, wie die User Experience dafür aussieht und wie das Ganze mit Anwendung funktionieren könnten. Und ich möchte noch mal einen riesen, dank einer Netgame, die uns dafür die Finanzierung und die Förderung zur Verfügung gestellt haben. Und jetzt können wir tatsächlich über die schweren Probleme nachdenken und müssen nicht noch einen riesen Crowdfunding aufmachen, was ja auch ein Problem ist. Und die Leute sagen, hey, das sieht aus wie so ein Product Making. Können wir das bereverkaufen? Und ich sage in dem Moment, das ist noch nicht fertig. Und ich will mir für so etwas wirklich die Zeit nehmen, drüber zu sprechen, Leuten zuzuhören, gucken, wie es funktioniert und einfach die richtige Dinge zu tun. Okay, vielen, vielen Dank fürs Zuhören und da ist Zeit für Fragen und Antworten. Ja, wir sind aus der Besetzerkabine Franz Tee und Eiffel Berger und Apila E. Vielen Dank fürs Zuhören. Ihr könnt uns Feedback geben bei Twitter mit dem Hashtag C3lingo. Vielen Dank. Jetzt gibt es noch ein paar Fragen und Antworten. Wenn ihr Fragen habt, bitte geht auf Twitter oder IRC und sendet es mit dem Hashtag C3lingo, das ist das Hashtag Clark. Weitere Informationen dazu findet man auf den üblichen Seiten unter events.ccc.de. Frage vom Mikrofon 1. Du hast erwähnt, dass es mit dem Beginn, mit dem Hard Apply Logs, mit den eingebauten Blockraums oder mit einigen anderen Funktionen, die verwendet werden. Ja, wir müssen darüber nachdenken, wie Implantate, die im FPGA existieren, sind, umzugehen ist. Die vielleicht auch schon vor diesem Projekt in den FPGAs exportieren. Vielleicht gibt es da ein paar Fragen, die wir noch nicht wissen. Aber das US-Militär benutzt viele von diesen FPGAs in ihren Geräten. Das heißt, sie haben selber in den Interesse daran, dass dort keine Sicherheitsangriffe vorhanden sind. Ich glaube, das wichtigste Antwort ist, dass es möglich ist. Der positive Sache ist, dass dadurch das FPGAs sehr legulär ist, dass es nicht möglich ist, dass das FPGAs sehr legulär, sehr gleichmäßig sind. Es ist einfacher, die initiale Konstruktion zu überprüfen, eine machbares Problem ist. Das bedeutet noch lange nicht, dass wir heute haben dasselbe etwas, was wir auch überprüft haben. Aber wenn jetzt ein Block verändert wurde, dann können wir dadurch, dass wir einfach Zufall da reinbringen, wie das genau implementiert ist, dann müssen sie deutlich größere, zusätzliche Strukturen hinzuführen. Und dann könnte man das viel einfacher erkennen. Aber das ist eine gute Frage, vielen Dank. Mikrofon Nr. 3, bitte. Yeah, move close to the microphone, thanks. Hallo. Meine Frage ist, in deiner Vorschlage, in der Lösung, wie kann man den Angreifer unabhängig davon, ob ein Nutzer bevor ein Nutzer selbst diese Überprüfung vor der Hardware vornehmen kann? Die Idee von dem selbst einfügen von den kryptografischen Schlüsseln ist, dass wir verkaufen dir das Gerät, du kannst die Platine dir anschauen, du kannst dir das Gerät anschauen und dann kompilierst du dein eigenes FPGA Software. Und der ist diese, es sind die Sachen drin. Und du kannst das verifizieren. Und wenn du jetzt diesen Komponenten, dieses kompilierte Gerät überprüfen, angreifen möchtest, dann musst du entweder den Bitstream verändern oder den Code verändern und damit wäre ein Hash anders. Das heißt, irgendjemand müsste einen Hardware implantat hinzufügen. Zum Beispiel zum Arbeitsspeicher, aber das hilft nicht, bevor es zum Arbeitsspeicher kommt, ist es verschlüsselt. Ich glaube, dass seit der Angriffsschichtstelle relativ gering ist. Du hast über die Corea geredet. In diesem Fall dieser Corea, der Corea würde die Hardware API nicht verändern, aber die Hardware FPGA wäre anders provisional. Also, die Frage ist, wie er sich an den Bitstream überprüfen würde. Du baust deinen eigenen Bitstream. Ich liefere nicht den Bitstream aus. Die Frage ist jetzt, wenn man jetzt den Bitstream, wie überprüfen wir, dass der ROM keine Hintertür hat? Ja, das ist möglich, aber da kann man auch sich gegenschützen. Die Idee, wie wir dort eine Zufälligkeit in der Compilat haben, wir kompilieren da einfach eine 64-Bit-Nummer da rein. Dann können wir im Bitstream die Nummer herauslesen. Das heißt, wenn jemand den Bitstream vorher schon reinimplementiert hat und einen anderen Bitstream drinnen hat, dann ist diese Zufallszahl da nicht drin. Ich glaube, es gibt Methoden, herauszufinden, ob der ROM verändert wurde, oder ob es eine böse Kopie von dem Source Code drin ist. Da können wir uns gegen verteidigen. Lässt die Frage vom Mikrofon 5. Eine der Optionen, die du erwähnt hast, war die Idee, selbst Highlighter herzustellen, die man optisch überprüfen könnte. Ist das eine komplett verrückte Idee? Würdest du das in Zukunft dir vorstellen können? Oder hast du das angeschaut? Ich habe darüber nachgedacht, ich habe ein paar Probleme dabei. Das Erste ist, wenn wir eine optische Verifikation benutzen, dann müssen unsere Benutzer diese optische Verifikation durchführen. Das heißt, eine gute Sache vom FPGA ist, dass wir alles, was wir da überprüfen und so weiter. Das bedeutet, dass wir da keine spezielles Equipment beim Endbenutzer haben müssen. Das heißt, wenn wir unseren eigenen Chip, den 500 Nanometer Zylinkon herstellen, dann würde er wahrscheinlich 100 Mhz laufen, weil er hätte nicht so viel Arbeitsspeichel, vielleicht 100 Tilo Beiz, also nicht so viel. Es würde viel Strom verbrauchen, aber dann müsste jeder Einzelner von diesen Chips sobald wir ihnen ein schwarzes Blob von Epoxy reinmachen, dann sieht man es nicht. Ich habe über transparente Verpackungen. Ja, das kann man machen, dann müsste jeder Endkunde ein Mikroskop benutzen, um nachzuschauen. Aber ich glaube, ich versuche mir zu überlegen, wie meine Mutter das benutzt. Ich kann mir nicht vorstellen, dass sie irgendjemanden kennt, dass sie ein Mikroskop hat, außer jetzt vielleicht mich. Und ich glaube nicht, dass das eine faire Herangehensweise ist, wie ein Benutzer das Ganze verifizieren kann. Das heißt, vielleicht für einige Szenarien ist das eine Herangehensweise, weil eine komplette optische Verifikation ist die einzige, das der einzige Abstand zwischen dir und dem Chip. Das ist das Problem, wenn so ein harter Chip, wenn man einen wirklichen Chip hat. Selbst wenn es klar ist, dann muss man es immer noch irgendwie mit einem überprüfen. Die Idee bei dem Display ist, dass man es nicht überprüfen muss, sondern dass es so einfach ist, dass man das nicht mit einem Mikroskop überprüfen muss. Weil es ist sehr schwer, da überhaupt irgendwas zu verstecken. Ja, vielen Dank für alle, die Fragen gestellt haben. Und auch eine große Runde Applaus für unseren vortragenden Bunny.