 Ja, herzlich willkommen zu meinem Vortrag. Der Titel ist vielleicht nicht so attraktiv, vielmehr geht es schneller ein. Also es soll um Kryptobeschleuniger gehen und wie man das mit Open Source Technik machen kann und ob das überhaupt gehen kann. Das heißt, dass ich will heute ein bisschen darüber erzählen, was im Moment so ein bisschen meine Mission ist. Ich versuche nämlich wirklich kryptografische Hardware zu bauen. Also wirklich Chips, die Kryptooperationen unterstützen und ermöglichen. Und ich will mal erklären, warum ich das tun will und ob das überhaupt möglich ist und ich will euch einfach mal zeigen, was heute schon möglich ist und was die Community eigentlich noch tun müsste, um das wirklich richtig zu machen. Wirklich in dem Sinne von, wie viel müsste man tun, um auch wirklich Chips zu bauen, die mit kommerziellen mithalten zu können. Das wäre nämlich extrem viel Arbeit, aber es ist nicht hoffnungslos. Warum will ich das tun? Kennen wir alle. Ich habe jetzt hier mal sozusagen aus meiner Datenbanken der Fails. Also ich habe zu Hause so eine Datenbank, wo ich mir so schlimme Sachen aufschreibe, was so in der wirklichen Welt passiert. Und immer wenn ich einen Vortrag hochhalte, dann suche ich mir sozusagen aus dieser Datenbank raus, was für lustige Beispiele so existieren eigentlich nur, um entweder Leute betroffen zu machen oder zu sagen, ja wir müssen endlich mal was tun. Also schön ist zum Beispiel hier letztes Jahr gab es mal das Sturmwarnsystem von Dallas, das einfach mal lustigerweise losgeheult hat. Das war mal gehackt. Das hier finde ich auch sehr spannend. Ich komme ursprünglich aus der Automobilindustrie. Den Airbag vom Audi DT, den kann man manipulieren. Den kann man ein- und ausschalten, ohne dass man das merkt als Besitzer. Naja, das ist dann ganz lustig auf der Autobahn. Ganz spannend sind auch irgendwelche so diverse Lücken in der Medizintechnik, in Krankenhäusern. Da steht US-Krankenhäuser. Ich vermute mal, das kann man eins zu eins auf deutsche Krankenhäuser auch übertragen. Das heißt also, wenn jemand von euch irgendwie einen lustigen Roman, kriminal Roman schreiben wollte, dann würde ich empfehlen, nicht irgendwie dumme Agentenstorys zu erzählen oder irgendwelche Leute mit Knarren rumlaufen zu lassen, sondern Hacker die Infusionsbumpen manipulieren. Das finde ich viel spannender, um Leute endgültig über den Jörg anzuschicken. Es gibt ja immer so mal so missliebige Leute, die man dummerweise mit Nerven, Giften und Kampfstoffen platt macht. Also das wäre ich, glaube ich, viel, viel ergiebiger. Das ist auch mal ganz interessant. Das hat man weit mitgekriegt. Fiat Kreisler hat mal 1,4 Millionen Autos zurückgeholt, wo man die Remote-Hacken konnte auf der Autobahn. Das ist vielleicht auch nicht so ganz lustig, ja, also zumindest nicht für den, der drinsitzt. Das hier finde, das ist mein Favorit. Der Hacker, der Finne an sich ist ja hart. Also der friert nicht so schnell. Das heißt, wenn man im finnischen Winter mal so eine Heizung ausschaltet, dann naja, dann ist das in Finnland vielleicht nicht so schlimm, aber in Deutschland wird das absolute Katastrophe, gibt es Tote vermutlich. Man kann jetzt auch Autos hacken über Digitalradio. Das liegt daran, dass die Radios in einem Auto in dem Autobahnnetz drinnen hängen und man hat da Lücken gefunden, wie man aus dem Radio in das Autobahnnetz reinkommt. Das ist vielleicht auch nicht so gut. Dann lustige Routschelz mit Telnet-Zugriff auf Infusionspumpen in der Intensivstation. Ah, der ist auch ganz gut. Das war ein Sicherheitsloch in einem Herzschrittmacher. Also so ein Herzschrittmacher hat inzwischen eine Fernwartungsschnittstelle und die sind abgesichert mit, also da gab es Gerüchte, dass die Firma, die das gebaut hat, die hatten RSA-Verfahren mit 16-Bit genommen, weil der RSA ist ja ganz sicher und 16-Bit klingt gut. Hat man halt mal gemacht. Im Endeffekt sind sie dann zu einem Rückruf gezwungen worden, weil dann konnte man nämlich auch Fernwartungsschnittstelle den Defibrillator auslösen in dem Herzschrittmacher. Das ist auch funny. Und das kann man sich dann so vorstellen, dass man dann als Patient auf so eine Liege gelegt wird. Dann wird der Herzschrittmacher in ein Fail-Safe-Modus gesetzt. Der Arzt steht neben dran und dann wird man neu geflasht. Also jetzt elektronisch, nicht mit dem Defibrillator. Man sieht, dass es da ganz viele Beispiele gibt, dass das wirklich kritisch ist und dass das uns alle betrifft und es wird ja noch viel, viel mehr werden in Zukunft. Das sind ja jetzt sozusagen nur die Vorläufer von dem, was in der Zukunft passieren wird. Das BSI hat es schon erkannt. 2016 haben die schon gesagt, die Lage bleibt angespannt. Die Formulierung fand ich ja auch gut. Die Lage ist meiner Meinung nach nicht angespannt, die ist dramatisch. Und wenn jetzt sozusagen so was wie intelligente Gegenstände und Internet of Sync sich verbreiten wird und das wird es tun, dann werden diese Fälle quasi im Stundentakt einschlagen, wenn wir nicht langsam was unternehmen. Das ist jetzt nur mal so als Motivation, warum ich mich mit dem Thema beschäftige und warum ich das Thema wichtig finde. So, jetzt habe ich gerade schon gesagt, Internet der Dinge, das kennen wir alle. Da wird immer schvatroniert von irgendwelchen intelligenten Gegenständen der realen Welt, um neuwertige Dienste anzubieten. Alles für den Menschen natürlich nur, nichts für die Werbeindustrie. Aber wenn man sich diese Dinge anguckt, das sind immer irgendwelche kleine Mikrocontroller, irgendwelche so kleinen Käferchens und die haben alle eine gemeinsame Eigenschaft, die dürfen nichts kosten. Also, die dürfen nur fennige kosten, aber sie müssen zehn bis 15 Jahre halten. Also, wenn wir uns das mal vorstellen, stellt man sich mal so eine Haussteuerung zum Beispiel vor. Da wollen wir diese Steuergeräte von dem Haus irgendwo in die Wand einbetonieren und die will nicht alle, alle zwei Jahre, wenn wir die nicht aus der Wand rausreißen. Das heißt also, wir haben billige kleine Systeme, die nichts kosten dürfen, die sehr, sehr lange leben. Und wie wollen wir jetzt mit solchen Dingen an IT-Sicherheit generieren? Wie wollen wir erreichen, dass wir 15 Jahre lang in dem Haus sicher sein können, dass unsere Daten nicht an unberechtigte Leute fließen? Und das ist ein großes Problem, weil bei den normalen Rechnern ist das kein Problem. So ein PC tauscht man einfach alle zwei Jahre aus, dann kaufst du die Kiste und am Tisch weg, kaufst eine neue, stellst du die Kiste hin, alles ist gut. Ja, selbst bei Handys ist es kein Problem, weil wir die relativ schnell austauschen. Aber bei so kleinen unsichtbaren Systemen wird das viel, viel schlimmer werden. Gut, jetzt argumentiere ich Gloss-Source-Ansätze, die wir bisher hatten, die waren jetzt schon derlich erfolgreich. Sowohl Software-Lösung als Hardware-Lösung waren regelmäßig gehackt, das haben wir alle schon mitgekriegt. Und ich glaube, dass wir jetzt an einem Punkt sind, dass die Leute, die sich, sag ich mal grob Hacker nennen, an dem Punkt angelangt sein sollten, dass sie erkennen, wir müssen das Problem lösen, die Industrie wird das Problem nicht für uns lösen. Wir müssen es lösen. Und jetzt wollen wir mal schauen, ob wir das hinkriegen würden. Jetzt habe ich vorhin schon mal gesagt, ich komme ursprünglich aus dem Automobilsektor. Es kann also gut sein, dass einige von euch heute mit Autos hierher gefahren sind, wo meine IT-Sicherheitslösungen drin sind, die ich vor Jahren mal gebaut habe. Ob da hoffentlich nicht gehackt heute Morgen. Und deswegen war meine Idee ursprünglich, ich gucke einfach mal den Automobilsektor an. Was hat man da schon alles gemacht? Was gibt es da für Probleme? Und dann schauen wir mal, ob wir diese Ideen übertragen können und wie wir das mit Open Source Sachen nachbauen könnten oder vielleicht sogar besser machen könnten. Das war so die Idee. Und jetzt ist es vielen vielleicht nicht bekannt. So ein Auto ist heute extrem kritisch. Also da werden extrem viele kritische Daten verarbeitet. Ich habe mal ein paar zusammengestellt. Was vielen Leuten bekannt ist, ist sozusagen der Ratsensor. Der ist kritisch. Warum? Wenn man den hacken kann, dann kann man auch den Kilometerstand fälschen in seinem Auto. Man lässt ihn einfach nur halb so schnell drehen, den Kilometerzäler. Das ist gut, wenn man Lesingfahrzeuge hat. Deswegen will das die Industrie nicht so unbedingt. Das hat aber dann auch noch so lustige Nebeneffekte, wie es gibt dann Experten, die stecken solche Boxen zur Manipulation des Ratsens, was in den in den in den Autobus rein, mehrere hintereinander. Und dann geht auch auf der Autobahn die Servo-Lenkung butterweich. Da haben sie also dann schon Leute aus dem menschlichen Genpool-Final entfernt und das ist dann schlecht für die Werbung. Also deswegen versucht man das zu vermeiden. Dann gibt es natürlich Airbags, ABS und ESPs und solche Sachen. Da ist klar, dass man daran nicht rumfuschen sollte, wird aber trotzdem gemacht. Schließsysteme, das ist offensichtlich. Niemand will, dass Autos geklaut werden. Wie bitte? Ja, da könnte man jetzt auch noch in die Details gehen. So ein geklautes Auto ist ein verkauftes Auto ist gut. Aber wenn es zu viel werden, dann steigen die Versicherungsprämien. Das will man dann auch nicht. Also ein paar geklaute sind gut, zu viele geklaute sind nicht so gut. Abstandsensoren, da könnte man drüber nachdenken, wenn man mal so ein Abstandsensor wirklich von außen manipulieren kann, dann kann man lustige Verkehrsunfälle auf Autobahnen provozieren. Das wird auch kommen, wenn das passiert. Was auch ganz interessant ist der Ladezustand von E-Fahrzeugen. Da wird man irgendwann mal vielleicht Strom klauen können oder man kann zum Beispiel auch darüber nachdenken, dass man mit Strom in Autos Geldwäsche machen kann. Man kann erst uns das Auto an einem Punkt tanken und am anderen Punkt den Strom weiter verkaufen. Könnte man sich auch mal überlegen, ob sowas geht. Dann die Vehicle-to-infrastructure-Kommunikation ist ein großes Problem und was der absolute Albtraum ist, der IT-Sicherheit, ist das autonomes Fahren und intelligente Autos. Also wenn wir das haben, haben wir ein ernstes Problem. So, so sieht es in der Automobilindustrie aus. Da gibt es wahnsinnig viele Lösungen schon dafür und da wird auch ganz viel gemacht, auch wenn man das von außen vielleicht immer nicht sieht. Aber da gibt es Firmen, die sich damit beschäftigen und viele, viele Ingenieure arbeiten daran. Was können wir davon lernen? Wir sagen einfach, wir machen das genauso wie die Automobilindustrie. Wir machen das einfach mal in Software. Die Verfahren sind bekannt. Da gibt es symmetrische Verfahren, sowas wie AES, sind so Blockschiffere oder Stromverschlüsselung, wie Chacha ist relativ bekannt. Es gibt Hash-Funktionen, um digitale Fingerabdrücke auszurechnen und Key-Tash-Funktionen, also sogenannte Message-Authentication-Codes, Macs. Hier gibt es alles, kann man in den RFCs nachgucken, implementieren wir einfach sindglücklich. Problem ist, wenn man das macht, wenn man symmetrische Verfahren implementiert, dann braucht man irgendwelche sicheren, nichtflüchtigen Speicher. Man braucht irgendwelchen Speicher in einem Chip, den man von außen nicht manipulieren und einsehen kann, um sein Geheimnis zu bewahren. Wie baue ich das? Das geht in Software nicht. Da braucht man irgendwelche speziellen Speicherchips oder Speicherregionen in dem Mikroprozessor. Also sehen wir schon, so rein in Software, wenn wir nicht wegkommen. Wir müssen irgendwas selber bauen. Wir müssen Hardware bauen, um sowas zu schaffen. Jetzt kann man sagen, okay, da nehme ich halt keine symmetrische Kryptografie, wo ich irgendwelche Sachen geheim halten muss, da nehme ich halt asymmetrische Methoden. Das sind ja ganz viele Sachen bekannt. RSA, elliptische Kurven-Kryptografie oder sowas, was man die für Helmen Schlüssel austauschen nennt, gibt es ja alles. Problem ist, alle diese Verfahren, die ich da aufgezählt habe, rechnen alle mit sehr großen Zahlen von mindestens 300 Dezimalstellen. Das kann ich in Software implementieren. Das ist kein großes Problem. Wenn man weiß, wie das geht, das ist auch in der Literatur extrem gut dokumentiert. Problem ist, dann brauche ich aber relativ teure Mikrocontroller. Also so ein kleiner 8-Bit-Brösel rechnet sich halt an so einer großen Zahl tot. Ja, wie machen wir das? Und wir haben noch ein anderes Problem, was uns vielleicht nicht aufgefallen ist. Wir brauchen für alle diese Krypto-Algorithmen, brauchen wir Zufallszahlen. Wie generiert man Zufallszahlen? In reiner Software eine Zufallszahl zu generieren ist nahezu unmöglich, würde ich sagen. Das heißt, wir brauchen irgendwie ein Hardware-Zufallszahlen-Generator. Also wir brauchen offensichtlich Hardware, wir brauchen entweder irgendwelche sicheren Speicher oder wir brauchen irgendwelche Beschleuniger, um mit großen Zahlen rechnen zu können und wir brauchen zusätzlich Zufallszahlen-Generatoren. Das heißt, wir können gar nicht unser Problem mit Software lösen. Wir werden Hardware bauen müssen. Und jetzt können wir Folgendes machen. Wir können uns natürlich auf den Standpunkt stellen, da kaufen wir einfach fertige Kontrolle von einem Hersteller. Das ist das, was im Moment gemacht wird. Mit all den Folgen, die wir schon gesehen haben. Okay, also so einfach scheint es in Software nicht zu gehen. Deswegen kaufen wir uns einfach so ein Trasteplattformodul von der Stange. Die gibt es in Millionen Stückzahlen zu kaufen. Ist ja gar kein Problem, da ist alles drin. Jetzt haben wir aber so ein paar größere Probleme da. Was ist mit der Langzeit- verfügbarkeit? Das war nämlich einer der Gründe, warum die Automobileindustrie relativ lange rumgezickt hat, solche Trasteplattformodule einzusetzen im Auto. Wir haben nämlich festgestellt, wir müssen diese Produkte mindestens 15 Jahre supporten. Können wir uns davon überzeugen, dass diese Firma, die uns dieses TPM baut, auf 15 Jahre lebt? Oder wird die wegfusioniert oder gekauft? Das sieht man jetzt gerade. NXP ist mal gekauft worden. Das kriegen wir gerade mit. Von Qualcomm und dann von Broadcom. Oder schauen wir mal, ob das Trump erlaubt. Also da passiert relativ viel. Also wie ist es mit der Langzeit- verfügbarkeit? Wie ist es, wenn eine Firma mir den Hahn abdreht und sagt, dir liefern wir jetzt keine mehr? Habe ich dann noch eine Secondsauce? Habe ich einen anderen Hersteller, der mir den gleichen Chip noch nachliefert? Das war ein großes Problem. Wenn da Sachen drin sind, die ich gar nicht benutzen will, muss ich sie trotzdem mitbezahlen. Also in so einem Standard-TPM, da ist zum Beispiel ein RSA-Kig-Inerator drinnen. Vielleicht brauche ich den gar nicht, weil ich nur symmetrische arbeiten möchte. Ich müsste ihn bezahlen. Aber ich kann mir einfach keinen selber Maß schneidern, weil ich würde ihn ja einfach zukaufen. So und dann gibt es noch so andere lustige Anwendungen. Wenn ich zum Beispiel die Dinger in so ein Auto einbauen will, dann brauche ich einen erweiterten Temperaturbereich und das haben die am Anfang einfach nicht angeboten. Gabs einfach nicht Schluss. Das könnte uns auch treffen, wenn wir irgendwelche Anwendungen mal im Sinne haben, wo spezielle Features benötigt werden könnten, dass die Hersteller, die von der Stange liefern, einfach nicht liefern können. Das könnte passieren, dass wir sagen, wir brauchen dieses Feature und die sagen, sorry, das ist no business vor uns. Gibt es nicht. Deswegen kam dann die Automobilindustrie auf die Idee kommen, das bauen wir selber. Das gibt es auch. Es gibt sozusagen draste Plattformmodule für Arme, für Autos. Ist bekannt unter Ski-Modul oder das Module, die aus dem sogenannten Evita-Projekt entstanden sind. Ich habe hier mal noch mal so grob ein paar Bilder hingemalt. Also dieses Ski ist nichts anderes als eine CPU mit dem AES und ein bisschen sicherem Speicher hinten dran. Und das Evita, das ist schon ein bisschen schlauer. Das hat hier so ein Applikationsprozessor und dann hier so eine Krypto-Ecke mit so einer eigenen kleinen, internen CPU, die die Krypto-Operationen macht. So ein bisschen AES hier und ein bisschen internen Speicher und ein bisschen sicheren Speicher. Gut, das gibt es schon. Die haben das gemacht. Jetzt habe ich aber ein Problem. Eigentlich dürfte ich da drüber gar nicht erzählen. Warum? Wenn ich das wissen wollte, wie das wirklich ausschaut, müsste ich ein NDA unterschreiben. Diese Bilder, die ich jetzt dahin gemalt habe, die habe ich mir sozusagen aus dem Internet zusammen geglaubt. Also das ist eine Approximation von dem, wie es wirklich ausschaut. Und welches Problem hat das? Und das ist genau eines der Probleme, unter dem in meinen Augen diese Industrie im Moment leigelt. Wenn ich alles per NDA mache, dann kann ich das nicht unterrichten. Ich kann keine Wissensvermittlung stattfinden lassen. Ich kann mich als Lehrender, als Dozent nicht hinstellen und kann sagen, okay, ich erkläre euch mal, wie das geht. Und das bewirkt natürlich auch, dass die Industrie auf ein längerer und mittlerer Frist einfach keinen Nachwuchs bekommt. Und dann jammern sie sozusagen, dass sie niemanden einstellen können, weil sie niemanden finden, der das Know-how hat. Was passiert dann? Sie werben sich gegenseitig die alten Ingenieure ab. Ja, das ist für den alten Ingenieur gut. Und falls der Preis natürlich auch immer weiter steigt, aber irgendwann ist der Ingenieur oben mal angeschlagen und das ist der Out. Das ist dann 70 und dann geht er in Rente. Und dann haben sie niemanden mehr in der Q. Und das ist ein großes Problem. Und deswegen habe ich diese NDAs nicht unterschrieben und ich werde das auch nicht tun, weil ich dann nicht mehr drüber reden dürfte. Okay, also das ist ein Problem. Und ich glaube, das könnten wir besser machen, wenn wir einen Open Source Ansatz fahren würden, weil dann würden wir allein schon dadurch Nachwuchs erzeugen. Und selbst wenn das alles problemlos funktionieren würde, hätten wir ein ganz anderes Problem. Ich habe hier mal so eine vereinfachte, ja, ich habe hier mal so eine vereinfachte Entwicklungskette, wie heute ein Computer gebaut wird, aufgemalt. Das ist aber nur sehr, sehr stark vereinfacht. Also nehmen wir mal an, wir fangen am Anfang mit so einer Hardware-Beschreibung an, das macht man in WRLock oder VHDL im Moment, dann wirft man das in irgendwelche EDA-Tools rein, die machen da irgendwie einen Schaltplan draus und setzen die Bauteile auf so ein Silizium-Stückchen obendrauf. Dann wird es irgendwann mal in eine Fabrik geliefert, die macht so eine Belichtungsmaske, da machen die da draußen Chip und dann kriegen wir diesen Chip und dann nehmen wir irgendwelche Compiler und andere Entwicklungstools und Betriebssystemen, basteln so ein Low-Level-System draus und da drauf setzen wir dann unsere Anwendungen, entweder in einem eingebetteten System oder in so einer Workstation. Irgendwie so läuft es, ganz grob. Und jetzt haben wir natürlich ein Problem. Wir alle wissen, dass Angriffe auf Anwendungen stattfinden, also die werden gehackt, da werden Manipulationen finden, da statt, man versucht irgendwas dazu zu verändern oder Daten auszuspähen. Okay, dann haben wir erkannt, oh, wir müssen das Betriebssystem sicher machen. Machen wir also das Betriebssystem sicher. Das ist das, was wir schon immer mitkriegen. Wir kriegen jeden Tag eine Flut von Patches für unsere Betriebssysteme, um die sicher zu machen. Das klappt solala. Also was wird der richtige Entwickler und Angreifer machen? Wenn das Betriebssystem dicht ist, würde den Compiler angreifen. Der wird einfach den Compiler so manipulieren, dass er bei jedem Übersetzen einfach eine Hintertür in die Software mit einbaut. Das passiert schon. Okay, also nehmen wir mal an, die Compiler sind auch dicht. Das kriegt wir alles hin. Dann gibt es das Problem. Man kann bei der Fertigung von Chips auf der Belichtungsmaske minimale Änderungen machen, das sind sogenannte Hardware-Troyana. Und wenn ich das mache, dann passiert plötzlich Folgendes, dann wird plötzlich eine Sicherheitslösung unsicher. Und ich kann plötzlich den Schlüssel wieder rauslesen. Und du hast im Wesentlichen keine Möglichkeit zu sehen, ob so eine Maske manipuliert wurde. Wie will man das in fünf Milliarden Transistoren sehen, dass da einer manipuliert wurde? Das heißt schon bei der Fertigung, auch bei der Produktion von dieser Belichtungsmaske können irgendwelche Leute mit speziellem Know-how und sehr vielen finanziellen Ressourcen, Manipulationen einbauen, die wir gar nicht erkennen können in Software. Es geht noch weiter. Jetzt nehmen wir mal an, das hätte mal alles dicht gemacht. Jetzt gibt es ja noch die Tools, die aus der Hardware-Beschreibung den Schaltplan generieren. Dann manipulieren wir halt die. Wenn der Angreifer nur genug Geld hat, dann kann er irgendwelche bösen Leute in so eine Firma reinsetzen, die solche EDA-Tools baut und dann bauen die halt ihre Hinterlöhretürchen direkt da rein. Und das hat natürlich den großen Vorteil, dass dann plötzlich alle Chips manipuliert sind. Das hat dann noch so einen richtig schönen Skaleneffekt. Und deswegen argumentiere ich, wir brauchen für jeden Einzelnen dieser Schritte brauchen wir Opensource-Lösungen, die kontrollierbar und überprüfbar sind. Wir brauchen das in dem Sinne von, dass wir drauf gucken können und dass wir Know-how haben, sowas selber zu machen. Ich werde gleich darauf eingehen, dass in Deutschland haben wir zum Beispiel ein ganz großes Problem hier mit EDA-Tools und auch hier mit Fertigung. Es ist viel Know-how verloren gegangen. Das geht also so weit, dass wir einen High-Speed-Prozessor wie von einer großen Firma wie Intel oder sowas in Deutschland gar nicht mehr bauen, selbst wenn wir es wollten. So, okay, das heißt also, wir brauchen mehr Opensource und wir brauchen mehr Opensource-Entwickler, um jeden dieser Schritte irgendwie unter wieder unter Kontrolle zu kriegen. Dann gibt es wunderschöne Gegenbeispiele, wie man das verhindert, aktiv, dass sich Menschen dafür interessieren, sowas zu bauen. Die interessieren sich, ich sehe das immer bei jungen Leuten, die interessieren sich heute irgendwie dafür, Webseiten zu bauen und Apps zu machen für Verhandys und solche Sachen. Aber keiner von den jungen Leuten interessiert sich für diesen tiefen Low-Level-Gramen. Der ist out, braucht man auch nicht. Das kauft man einfach. Ist auch nicht so spannend. Warum legt es da, ist es so? Naja, also sagen wir mal, die Hardware-Beschreibung sprachen die heute verwendet, werden wie Verilock und Fahre der LDC nicht sonderlich attraktiv. Also gerade bei den jungen Leuten, das sieht so ein bisschen aus, wie Zähne ziehen. Und auch die Entwicklungstools, also wer schon mal mit den Xilings-Tools gearbeitet hat, die man zwar auch frei kriegt, aber klaust sind. Wenn man sich die mal anguckt, also schön ist anders. Also ich hasse die Dinger. Der aktuelle Zustand ist schlimm und der nicht so aktuelle Zustand war noch schlimmer. Also das ist ein super veraltetes Eclipse auf dem dieses Xilings-Zeugse-Berot und du kannst es nicht skriptenrichtig und das ist alles irgendwie komisch. Und dann ist wieder mal das Projekt falsch erhauen und du weißt nicht warum. Also es ist ganz komisch. Also ich habe mich zum Beispiel mal zwei Jahre mit Xilings rumgeschlagen, weil ich habe ein Retina-Display an meinem Mac und die Xilings-Tools haben diese Auflösung nicht unterstützt. Und dann wurde ich beschimpft, dass ich zu blöd werde, zu konfigurieren und dann hat sich so eine Sammlung von Leuten quasi in so einer Mellingliste zusammengetan und haben dann Screenshots verschickt, um die Firma davon zu überzeugen, dass man wirklich die Fonds nicht skalieren. Das war schwierig und ich hatte in der Zeit noch Schwierigkeiten, weil so ein Fenster ist dann echt schwierig zu benutzen. Also ein Eclipse-Fenster hinter der Auflösung ist hart. Ich habe das dann dadurch gelöst, dass ich sozusagen mein Linux dazu vergedonnert habe, einfach die Auflösung zu halbieren. Also ich habe mein Retina-Display kastriert sozusagen. Dann ging es wieder. Interessant ist auch, wenn man so richtige Asic-Tools verwendet, um Asics zu machen, von Cadence ist er der Marktführer. Also wenn man die als Privatfirma kauft kostet, habe ich mir mal sagen lassen, die werden im Monat abgerechnet, die Lizenz kostet 80.000 Euro. Damit sieht man schon mal, die kleine Firma ist ausgesperrt. Also es könnte nie sein, dass wir sowas wie ein Startup gründen von zwei Leuten, die eine coole Idee haben und versuchen, was neu ist zu machen. Die könnten sich einfach diese Preise nicht leisten. Und das Tooling ist wirklich hässlich. Also wenn man mit dem Tooling arbeiten muss, dann lächt zwar nach dem. Okay, deswegen glaube ich, es wäre toll, wenn wir kriptografischer Hardware in einem offenen Entwicklungsprozess entwickeln würden, weil das wissen wir alle. Mehr Augen sehen, mehr Fehler. Das muss nicht unbedingt sein, aber zumindest besteht die Chance. Wir haben eventuell eine bessere Langzeitverfügbarkeit und damit second source Sachen und es know how um solche Chips würde sich verbreiten. Wir hätten vielleicht die Möglichkeit, dass wir in Zukunft wieder mehr Leute haben, die wissen, wie man sowas macht. Jetzt haben aber große Probleme. Die Hardware-Fertigung, also die Chips selber, die werden meistens in Asien gefertigt. Das heißt, wenn jemand die Masken oder diesen Belichtungsprozess manipuliert, dann selbst wenn wir es rauskriegen, können wir den noch nicht mal verknacken. Wir haben überhaupt gar keine juristische Handhabe gegenüber diesen Leuten. Also wenn wir es rauskriegen. Das heißt, da kann man sich sicher sein, dass der munter Hardware-Drojaner in die Chips eingebaut werden. Die Toolchains, die man heute verwendet, um Asics zu fertigen, die werden von wesentlichen drei Firmen hergestellt. Cadence, Synopsis und Mentor Graphics. Zufälligerweise drei US-Firmen. Müssen wir alle mitarbeiten. Also wenn jetzt dort jemand entschließt, bei Cadence intern diese Tools zu manipulieren, haben wir keine Chance, da drum zu kommen, weil wir keine eigenen EDA-Tools haben für sowas. Die Chinesen haben sich dann ein bisschen schlauer aufgestellt. Die haben inzwischen sich eigene gebaut, weil sie das auch erkannt haben. Die Chinesen haben das erkannt lustigerweise die Russen auch. Wir nicht. Nein, das ist für die sozusagen eine Speziallösung. Also die rücken das natürlich auch nicht raus. Wenn man in die entsprechenden Projektanträge der Chinesen reinguckt, steht dann im Drehendeffekt das übliche Blabla drin. Wir müssen unabhängig her von den Amerikanern werden und dann steht irgendwo ganz klein unten in der schnellen Security. Also die wissen das genau, was los ist. Wir wissen das nicht. In Deutschland sind wir alles, was mit Digitalisierung zu tun hat, ist ja Neuland. Wir müssen ja jetzt schon so weit, dass wir rauskriegen, dass wir uns ganz stark anstrengen, dass wir dann vielleicht überall mal Internet hinkriegen. Aber das ist nach wie vor ein Problem und das kriegt man auch nicht so leicht weg. Und dann haben wir unabtraktive Hardware-Beschreibungssprachen. Das müssen wir wegkriegen. Und jetzt ist natürlich die Frage, kann man von Linux lernen? Kann man von Linux lernen? Ja, das glaube ich schon. Man hat mir gesehen, es gab eine Nachfrage, als hat Stelman immer kurz das Knuppprojekt gestartet. Dann gab es plötzlich mal ein C-Compiler, das hat wunderbar funktioniert. Den benutzen wir heute auch alle, auch in der Industrie. Dann hat man plötzlich festgestellt, wenn es dem Entwickler Spaß macht, dann wird es plötzlich auch erfolgreich. Ganz neue Erkenntnis. Und man sieht, plötzlich hat sich auch Unix NOHA-Einfassung und Lehre verbreitet. Ganz plötzlich. Dann hat die Industrie gelernt, man könnte Kosten teilen. Die großen Internetfirmen heute arbeiten sehr stark zusammen am Linux-Kanal und teilen sich so die Kosten. Das haben sie plötzlich als Vorteil erkannt. Das heißt, dass ich würde sagen, wir brauchen ein attraktives Portables und produktives Tooling für junge Entwickler. Weil so alte Säcke wie ich werden keine neuen, tollen Sachen machen. Das werden nur die jungen Leute machen. Also wir brauchen Tooling, dass die jungen Leute interessiert und dass die spannend findet. Wir brauchen CPU-Kerne, um sowas zu entwickeln und wir brauchen ein bisschen kryptografischen Zucker, sag ich mal. Also die Crypto Algorithmen implementiert. Okay, geht das. Können wir das schaffen? Der aktuelle Zustand sieht so aus. Das ist zumindest das, was ich verwende. Also es gibt sogenannte, ich nenne die meterharte Beschreibungssprachen, die auf einem viel höheren Level laufen, wie das, was man heute kennt, was hdl oder Veriloc ist. Jetzt gesehen, hier gab es jetzt ein paar Veriloc-Kurse. Das ist schon mal ein ganz netter Anfang. Aber Veriloc hat den großen Vorteil, wenn man wirklich große Systeme bauen will und komplexe Systeme bauen will, dann ist es relativ schwierig mit Veriloc zu arbeiten. Da gibt es jetzt ein paar neuere Entwicklungen, was relativ bekannt ist, ist MyHDL. Das mag ich persönlich nicht so sehr, weil ich Python nicht mag. Das ist Python basiert. Dann gibt es hier für die Haskell-Fans, gibt es Clash. Und dann hat die Berkeley University was auf Scala aufgesetzt. Das ist recht bekannt, das nennt man Chisel. Und ich arbeite mit etwas, das nennt man SpinalHDL. Das sitzt auch oben auf Scala drauf. Das heißt, man programmiert in einer objektorientierten, funktionalen Programmiersprache und macht damit Hardware-Beschreibungen. Und wenn man das Tool verwendet, fällt dann hinten Veriloc raus, was man halt will. Und jetzt kann man sozusagen Test-Frameworks verwenden, die es open gibt. Also, Veriloc ist vielleicht bekannt oder Icarus Veriloc und Waveform Viewer und CocoaTP. Das ist ein Testbench-Framework. Es gibt alles offen. Es gibt Veriloc-Simulatoren wie den Verilator. Das ist sehr effizientes Teil. Das ist offen. Und interessanterweise gibt es inzwischen auch vollständige FPGA-Entwicklungs-Toolchains nur open. Also, was man vielleicht schon mal gehört, ist JOSUS, Erachne, PNR und iStorm. Damit kann man lettuce FPGAs konfigurieren. Und interessanterweise gibt es ein Projekt, das heißt QFlow. Ich habe es leider selber noch nie ausprobiert und mit QFlow kann man sogar ASICs frei machen. Also, ich habe mich jetzt von jemanden davon überzeugen lassen, dass es wirklich Entwickler gibt, die mit QFlow kommerziell hunderte von ASICs schon gemacht haben. Ich habe es allerdings noch nicht ausprobiert. Also, es sieht nicht ganz so hoffnungslos aus. Das Tooling ist gar nicht mal so schlecht. Man müsste jetzt nur mal anfangen. Deswegen war die Idee, naja, jetzt brauchen wir erst mal offene CPU-Kerne. Kaufen wir einen Arm, oder? Die verkaufen IP an jeden. Das ist aber wahnsinnig teuer. Und wenn wir es nachbauen, kriegen wir von Arm sofort die Juristen zu sehen. Da gibt es gleich mal Stress. Also, nachbauen ist problematisch, kaufen ist auch problematisch. Also, das wird ausschließen, das auszuschließen. Dann, was im Moment ganz in ist, ist Risk Five. Das ist offen. Das darf jeder nachbauen, so ein Risk Five Prozessor. Das ist ganz cool. Da gibt es ein Linux für, da gibt es ein GCC dafür. Ein einfachen Risk Five Prozessor baut einen Anfänger in einem Semester nach. Das ist also nicht so schwierig. Der leistet zwar da nichts, aber für den ersten Einstieg würde das funktionieren. Oder was auch ganz interessant ist, ist das J-Core-Projekt. Die bauen eine Variante von Renesas Super-Age-Prozessor nach und da gibt es auch ein Linux für, ein GCC und Toolchains und alles. Also, es könnte man verwenden. Das Problem für mein Projekt war, eventuell sind diese beiden Varianten einfach zu teuer. Ich brauche was billigeres, was noch kleiner ist als das. Vielleicht als Kontrollprozessor. So, und deswegen habe ich einfach mal in die Vergangenen. Das Spark ist relativ groß und relativ komplex. Die haben ja diese Registerwindows und das alles zu bauen. Es gibt eine offene, es gibt von Geißler Research, gibt so eine offene. Dieser Leon Prozessor, der ist aber relativ groß. Und die Frage ist natürlich auch immer, Spark ist GPL, aber was passiert, wenn der Larry seinen nächsten Anfall hat. Also ich wäre da vorsichtig. Ist auch so ein bisschen out im Moment. Also der Risk-Five ist im Moment in, das sind ja auch immer so Möbelströmungen so ein bisschen. So, mein Blöder, mein blöder Drücker. Deswegen habe ich jetzt einfach mal in die Vergangenheit geguckt. Der Plan war einfach, ich guck einfach mal an, wie es früher war, so vor 20 Jahren. Und guck mal diese kleine alte Technik, die war extrem klein und leistungsfähig. Und dann baue ich die einfach mal mit modernen Mitteln nach und hoffe das Beste. Und dann habe ich mir gedacht, naja, ich gucke mir mal so eine ganz coole Industrie an. Das ist die Raumfahrt. Was haben die denn so verwendet? Und dann trifft man auf einem Prozessor, der bekannt ist als Norwex 4000 oder Herris RTX 2010. Der 2010, der war irgendwie strahlengehärtet für so Raumsonden. Und das ist ein Stack Prozessor. Der hat gar keine Register, sondern der hat nur Stacks. Und wenn man sich den anguckt, der ist recht erfolgreich. Ja, also der fliegt noch draußen rum. Das kann also nicht so schlecht gewesen sein. Und die Dinger werden immer noch geupdatet da draußen. Also das ist cool. Also dann habe ich mich mal umgeguckt. Kann man sowas selber bauen. Ja, kann man machen. Da gibt es eine Variante davon, die ist bekannt als J1. Die ist relativ bekannt. Die ist in VereLock geschrieben. Der VereLock-Code sieht aber nicht so sonderlich nice aus. Also man braucht relativ lange, um das zu verstehen, wie das der Kollege da zusammengebaut hat. Deswegen habe ich das einfach mal neu gemacht mit Spinal. Und wo kam ich raus? Ich habe einfach mal geschafft, diese CPU mit 120 MHz laufen zu lassen. Das sind 16-Bitternur. Aber 120 MHz ist schon mal eine Ansage. Und ich habe ein komplettes Force-System. Also Compiler, Interpreter und ein Anführungszeichen-Betriebssystem in 5 Kilo Beidramm. Und das ganze System hat 8 Kilo Beidramm im Vollausbau. Das ist klein. Und wie klein ist es? Das braucht etwa 1% von so einem klassischen Xilinx FPGA. Also es ist wirklich klein und damit hat man die Hoffnung, dass es billig wird, wenn man es vorher fertigen kann. Oder wenn man es fertigt. Das ist ja jetzt noch nicht open source. Und jetzt will ich ja beweisen, dass schon jetzt ein bisschen was gehen würde. Und dass ein bisschen was geht. Ich habe das mal auf einem Lattice nachgebaut. Auf einem Lattice FPGA mit Open Source Toolchain. Also mit diesem JOSUS Errakne und Eistorm mit Spinalis. Natürlich auch Open Source Simulation. Alles nur Open Source. Es ist kein einziges Gloss Source Tool verwendet worden. Und dann bin ich rausgekommen bei einer Implementierung, die etwa mit 40 Megahertz läuft. Und auf so einem kleinen Fuzzleteil noch laufen würde. Der Größe, den ich mir gebaut habe, läuft auf dem kleinen Lattice. Dann brauche ich einen größer. Und wenn man den kleinen kauft, den Einzelstück zahlen, dann kostet so ein Ding 6 Euro. Also das ist wirklich billig. Und darauf habe ich dann mal IES implementiert. Das geht auch. Das ist zwar nicht so sonderlich schnell des IES, aber es funktioniert. Kann man jetzt hier nicht sehen. Das ist das Bild von dem ersten Zeitpunkt, wo es mal funktioniert hat. Da war ich damals so stolz, dass ich gesagt habe, ich mache jetzt mal ein Screenshot. Also da kann man damals sehen, das ist eine voll funktionierende IES 128-Bit Verschlüsselung, die auf dieser CPU, die ich da gebaut habe, läuft. Und man sieht hier auch dieses ICO-Board. Das ist ein Open Source, ein Lattice FPGA-Board, das ich dazu verwendet habe. Das heißt, diese Berechnung lief auf diesem Chip ab. Jetzt kann man natürlich sagen, oh FPGAs, das ist doch ein bisschen doof. Wir wollen richtige ASICs machen. Das wird demnächst auch mal funktionieren. Das ist ein erster Schritt in Richtung ASIC. Also wir haben diese CPU jetzt schon mal angefangen, in ASIC zu pressen. Dann kommt nur noch die Fertigung. Also die Kohle aufzutreiben, das zu machen. Also das geht. Das heißt also, man müsste sich, wenn man Open Source-mäßig da unterwegs wäre, sich jetzt an der Stelle Gedanken machen, wie kann mich an die Fertigung dran? Das ist ein Problem. Wie kann ein einzelner ASIC fertigen lassen? Also nehmen wir mal an, wir haben alle unendlich viel Geld zur Verfügung, können wir uns so ein Ding bauen lassen. Es ist relativ schwierig, als ein Privatmann an so eine ASIC Fertigung dran zu kommen. Da müsste man dringend was tun. Das geht also so weit, dass ich mitgekriegt habe, dass Hacker-Communities in den USA's ernsthaft geplant haben, eine eigene Fab zu kaufen. Das könnte man wirklich ernsthaft überlegen. Wenn man das gemeinsam in der größeren Gruppe wirklich mal in die Hand nehmen würde, könnte man sich vielleicht so ein altes Ding kaufen, dass die anderen sonst abreißen. Und das würde für viele Zwecke, die wir hier verfolgen wollten, würde das funktionieren und erst mal ausreichen. Und hauptsächlich würde es erst mal ausreichen, um FAT aufzunehmen. Also CPU-Kerne würden funktionieren. Hochleistungswege CPU-Kerne wie so etwas wie Intel-Baud oder AMD-Baud, das ist beyond any hope. Das kriegen wir nicht hin. Das sind wahrscheinlich 20 oder 25 Jahre in der Ohau hinten dran. Aber solche kleinen Brösel kriegen wir hin. Solche kleinen Dinger kriegen wir hin. Also alles, was mit Internet of Sinks zu tun hat, das klein und billig sein muss, das würden wir hin kriegen. So, jetzt noch ein anderes Beispiel, was man mit Open Source machen kann, was man mit Close Source nicht so leicht machen kann. Ich will einfach mal ein Authentifizierungsprotokoll bauen. Ich will einfach mal so ein Schlüssel basteln. Und der Standard, den man da verwendet, ist ein Challenge Response System. Also ich würfel mir eine große Zufallzahl, schick die rüber an meinen anderen Kommunikationspartner, der nimmt des Geheimnis-Key und diesen Challenge C, hasht es, schickt es diesen Response R, den er da berechnen hat, zurück und die andere Partei akzeptiert die Antwort genau dann, wenn ihre eigene Überprüfung, die andere Partei hat natürlich diesen Geheimschlüssel auch, genau den gleichen Response wieder ergibt. So funktionieren diese elektronischen Schlüsseldrücker. Warum? Die Dinger sind, das ist leicht zu implementieren, so eine Hash Funktion, das ist sehr, sehr schnell und es braucht relativ wenig Ressourcen. Deswegen verwenden das auch alle. Wenn man das jetzt aber in Millionen Stückzahlen produziert, hat man ein Problem, wie kriege ich das Geheimnis in diese beiden Geräte hier in Alice und Bob, wie kriege ich dieses Geheimnis da rein? Das ist logistisch relativ kompliziert, man denkt da immer auch nur höher, da werfe ich halt mal ein paar Zufallszahlen da rein und dann ist schon alles gut. Das ist nicht so einfach, weil die Fertigung dann ein bisschen kompliziert wird. Also ich will das mal so nicht bauen, ich will es noch billiger haben. Die Idee ist, wir generieren uns eine Liste von Paaren, Challenge und Response, so CRPEAP, CR Paare, generiere ich mir meine Liste auf einer Seite und beim ersten Pairing wird von der einen Seite während diese Challenge Response Paare einfach übertragen zum anderen Partner und der speichert die in der Art Datenbank ab. Das kann man sich so ähnlich vorstellen, früher gab es bei den Banken doch diese Chiptan-Listen, da hat die Bank im Endeffekt auch sowas vorgeneriert, hat es übertragen, per Post an den Kunden, der hat den Brief aufgerissen, hat dann diese Chiptan-Listen verwendet. Da gibt es natürlich so gewisse Sicherheitsprobleme, man muss das sicher transportieren, so was, aber nehmen wir mal an, das könnten wir alles lösen, dann wäre das super billig, das so zu machen. Aber die Frage ist, genau ein anderes Problem, wir haben dann natürlich nur so eine endliche Anzahl von Authentifizierungsprozessen, das war bei diesen Chiptan-Listen auch so, dann musste man irgendwie mit der letzten, hat man irgendwie angeschwingelt bei der Bank und hat die letzte dazu verwendet, dass man eine neue geschickt bekommen hat. Also man kann auch so ein Prozess des Nachtankens nachbauen, das funktioniert, wenn man verschlüsselt übertragen kann. Also sowas könnte man machen. Jetzt ist aber das Problem, wie generiere ich mir diese Challenge Response Paare? Wie mache ich das? Wie mache ich es, dass es, wenn ich ein Chip produziere in der Fabrik, dass die Challenge Response Paare da schon drinnen sind? Ich will die da nicht rein lernen, ich will, dass die bei der Produktion da schon drin sind. Und da gibt es etwas, was man Physically Uncloneable Function nennt, sogenannte PUFS. Eine PUFS ist eine Abbildung von eindeutigen und einzigartigen physikalischen Materialeigenschaften auf eine Zahl. Und so eine PUFS ist leicht berechenbar, aber schwierig zu kopieren oder nahezu nicht zu kopieren. Und die nützt irgendwie aus, dass beim Herstellen von Halbleiter Fertigungstoleranzen auftauchen. Das kannst du nicht vermeiden. Normalerweise baust du dein Design so, dass die Fertigungstoleranzen keine Rolle spielen. Man kann aber, wenn man sich geschickt anstellt, das ist auch in der Literatur beschrieben, Strukturen auf so einem Halbleiter aufbauen, so dass man Fertigungstoleranzen erkennen kann. So, und sowas wollen wir bauen. Wenn wir das schaffen, dann können wir, jeder einzelne Chip hat dann automatisch eine Seriennummer, die einfach durch die Fertigung kommt. Unser System kann leicht drauf zugreifen. Es ist leicht berechenbar, steht ja hier. Aber der Böse kann sozusagen versuchen zwar den Chip aufzuschleifen, aber das ist dann immer noch so, selbst wenn der den offen hat, dann sieht der dieses Geheimnis da drin nicht und da kommt da auch nicht dran. So, können wir sowas bauen. Antwort, wie könnte man sowas machen? Naja, wir bauen eine Struktur, von dem wir wissen, dass da zwei theoretisch gleich lange Signalwege immer drin sind. Immer. Und jetzt schlägt aber die Physik zu, wenn Fertigungstoleranzen auftauchen und die Werden auftauchen, dann sind diese Signalwege plötzlich nicht mehr beliebig, also die sind nicht mehr gleich lang. Die eine Leitung ist ein bisschen dicker, die andere ist ein bisschen dünner, deswegen geht das Signal da ein bisschen schneller drüber und da ein bisschen langsamer und sowas. Das müssen wir jetzt irgendwie messen. Und das ist dann von Chip zu Chip unterschiedlich. Und eine der Klassiker sowas zu machen ist ein sogenannte Arbitrap-Huff. Das ist so eine Struktur von Multiplexern hier, so eine Kette von Multiplexern und je nachdem welches Bitmuster ich hier unten anschließe, anders wären N-Bits, dann gibt es zwei auch N-Verschiede Möglichkeiten, dann gibt es da halt so Wege durch. Und das Lustige ist, der rote und der schwarze müssten eigentlich extra so gemalt gleich lang sein. Sind es aber in der Praxis nicht. Und das kann ich messen. Irgendeiner von den beiden Pfaden wird schneller sein. Und das messe ich dann zum Schluss und durch diese Fertigungsunterschiede sind diese Längen auch bei jedem Chip ein bisschen anders oder diese Geschwindigkeit mit dem das Signal von Anfang bis zum Ende durch diese Struktur durchläuft. Und das messen wir einfach. Und jetzt haben wir das mal gebaut mit einem kommerziellen Tool auf einem Lettes FPGA. Und jetzt habe ich hier mal ein Bild rausgezogen, wie dieses kommerzielle Tool hier das Routing gemacht hat. Man sieht, dass das ein bisschen chaotisch ist. Aber das ist das was das kommerzielle Tool rauswirft. Und diese roten Linen sollten eigentlich irgendwie gleich lang sein. So ungefähr. Also nein. Was macht man dann? Man würfelt einfach so lange immer wie man synthesiert die Schaltung immer wieder neu und hofft darauf, dass eine neue Struktur sich bildet und macht es so lange, bis man so ein Abeltrap Haft rauskommt, der gut funktioniert. Und es liegt da dran, weil man keine Chance hat, bei den kommerziellen Tools auf das Routing Einfluss zu nehmen. Du kannst zwar Einfluss drauf nehmen, wo die welche Schaltkreise du auf diesem Chip verwendest. Das kann man manuell konfigurieren, aber das Routing selber hat man nicht richtig unter Kontrolle. So, was macht man jetzt? Deswegen haben wir jetzt mal beobachtet, diese Lettes FPGA sind komplett reverse engineered. Das weiß man genau, wie die aufgebaut sind. Man weiß genau, wie das Routing funktioniert. Man weiß genau, wie man welche Bits mal an und ausschalten muss und welche Leitungen zu bekommen, die man haben will oder nicht. Und jetzt ist folgende Idee. Wir fangen einfach an mal mit einer Hardware Beschreibung, platzieren unsere Multiplexer manuell, dann jagen wir das durch die Tools durch und lassen den Auto Routing machen, kriegen eine FPGA Beschreibung. Und jetzt nehmen wir mit den Open Source Tools diese FPGA Konfigurationsbeschreibung wieder auseinander. Lassen Sie uns erklären, richten die roten Linien so aus, dass sie endlich gleich lang werden. Das können wir nämlich jetzt von Hand tun, weil wir wissen, wie das aufgebaut ist. Packen wir es alles wieder zusammen und machen ein Bitstream draus. Und das können wir nur deswegen tun, weil das Open Source Tools sind. Wir können das nur deswegen tun, weil wir wissen, wie man das interne Routing beeinflusst und wie man selber von Hand machen kann. Und deswegen funktioniert dieser Trick im Moment auch nur mit diesen Lettes FPGAs. Das macht ein Studi von mir im Moment, da baut es gerade und da hat mir noch ein Foto geschickt, dass man das mal sehen kann. Das war so ein erster Versuch. Das sieht man, das sind sieben verschiedene FPGAs, Lettes Sticks. Und da kann man sehen, dass man da noch nicht so viel Unterschiede rauskriegt. Da haben wir uns noch dumm angestellt. Und hier sieht man schon, dass man sie ganz gut unterscheiden kann. Also wir können wirklich physikalisch unterscheiden. Also wenn du den reinsteckst und machst diese Berechnung, kannst du wissen, oh, das ist Stick Nummer zwei. Also die haben sowas wie Seriennummern. Und das kriegt man mit so einem Abeltrapav raus und mit den Open Source Tools kriegt man solche Sachen, kann man solche Sachen optimieren. Und das ist etwas, was ich mit kommerziellen Tools nicht tun könnte. Also wie dann in Deets, dass dieses Geunkel von vielen Leuten mit Open Source Tools kann das nicht funktionieren, das ist Blödsinn. Man muss es tun. Das ist sehr kompliziert und es wäre sehr aufwendig und eventuell müsste man viel Geld in die Hand nehmen. Aber es wäre möglich und man kann es tun und in gewissen kleinen Sachen kann man es jetzt schon tun. Und es ist nicht hoffnungslos. Das heißt also erst mal vielen Dank. Ich glaube, wir könnten es tun. Wir müssten es nur tun. Und wen das mehr interessiert, was man da tun könnte und was da passieren würde, da schaut sich bitte mal diese URL an. Da kann man Paper runterladen, wo ein Vorschlag gemacht wird, wie eine Ökonomie funktionieren könnte, die auf Open Source Hardware basiert. Und was das kryptografisch bedeuten würde. Das wird natürlich einige Marktteilnehmer, die aktuell da die Platzhörsche sind würde. So ein Vorschlag sagen wir mal nicht davor hin. Das ist ein bisschen so wie SCO und UNIX und Linux. Aber wir wissen alle, wie das ausgegangen ist. Wie bitte? Das Projekt ist noch nicht abgeschlossen. Ach so, ja okay. Die Juristen wollen ja auch von was leben. Aber im Ernst muss man wirklich so sehen, wenn man die Parallelen anguckt, wie sich dieses Close Source UNIX verdrängt worden ist durch Linux. Alle die Erfahrungen, die man gemacht hat, die wiederholen sich jetzt im Moment teilweise im Hardware Sektor ganz ähnlich. Und ich glaube, dass viele Lehren, die man aus dieser Entwicklung unter Linux gezogen haben hätte können, dass man die dahin übertragen könnte, wenn man das nur wollte. Und die Frage ist natürlich, von wem erwartet man das jetzt, dass er das tut von unserer Regierung? Die sind damit beschäftigt, Glasfaserkabel zu vergraben. Nein, der Butter bei die Fische. Das Problem ist ja schlechte, da greifen die Politiker, die das entscheiden, haben das Fach noch nicht. Die wissen das nicht. Die können das auch nicht wissen. Sollts die Industrie machen? Sollts die Hardware Hersteller machen, die um ein gutes Geld mit ihren Lösungen verdienen? Na tot und teufel werden die tun. Natürlich wollen die es nicht machen. Und der dritte Punkt ist, wer kann es tun? Das sind die Leute, die sozusagen Linux groß gemacht haben. Diese Community kann das tun. Und wenn es die Community tun würde, dann würde ganz, ganz viel gehen und wenn die Community verzweifelt und sagt, das kriegt man nie hin, dann wird es nicht passieren. Ist ganz einfach. Und das, was ich jetzt damit dieser CPU vorgestellt habe und mit diesem Able-Trap-Haff und so was ist eigentlich nur deswegen entstanden, weil gewisse Leute gesagt haben, das kann nicht funktionieren. Und ich habe gesagt, das kann funktionieren. Und ich beweise dir, dass es funktioniert. Und es ist natürlich nur so eine ganz kleine, futzte, mini Mikrolösung. Aber ich habe gezeigt, dass es funktionieren kann, wenn man nur will. Und wenn das jetzt beschließen würde, 1.000 Leute sowas zu machen, das heißt, wenn sich die jungen Leute mehr für Low-Level-Sachen und nicht für Apps interessieren würden, dann hätten wir so eine Lösung in 15 Jahren oder 20, so wie Linux vielleicht. Und dann gäbe es plötzlich auch eine Industrie dahinter. Das ist heute völlig undenkbar, dass es kein Linux mehr gibt. Weil so viele Leute davon leben und weil so viele Leute das Know-how haben, das Zeug zu konfigurieren, zu warten, zu benutzen und das Systeme drauf aufzubauen, wenn man das schaffen würde, können wir den gleichen Effekt mit meiner Meinung nach auch mit Hardware erreichen. Das heißt also, jetzt zum Schluss, meine Aufforderung baut es, macht es, das geht schon. Vielen Dank, ich wurde gebeten. Du tust es? Ja, siehst du eine gewisse Chance, dass vielleicht die großen CPU-Hersteller irgendwelche Probleme mit ihren Altlasten haben, weil sie ja immer noch kompatibel sein müssen und die letzten 30 Jahre mit schleifen, dass vielleicht irgendwann diese einfachen CPUs einen Vorteil haben durch die ihre einfache Konstruktion und vielleicht ist auch bei der Performance sich zum Vorteil umkehrt? Also bei der Performance weiß ich nicht. Was man ja beobachten kann ist, dieses umken gibt es ja sozusagen schon seit 20 Jahren, so Intel wird an seiner Komplexität erdrinken. Die haben es bisher immer geschafft. Also man muss sagen, man kann über die Firma Schimpfen so viel mehr wählen, aber die haben echt eine gute Arbeit gemacht. Also diese Komplexität von dieser Architektur unter Kontrolle zu kriegen und immer wieder schneller zu werden ist sehr beeindruckend. Das heißt, ich weiß es nicht, die werfen halt im Endeffekt beliebig viel mehr Empower darauf. Was ich ganz interessant sehe ist, es fängt jetzt an, dass man mit mathematischen Methoden Chips formal verifiziert, dass man mathematische Beweise mit Tools macht, dass diese Dinger korrekt sind und da helfen natürlich einfache Strukturen. Und wenn man das für ein Security-Bereich macht, dann ist es sicherlich ganz arg spannend. Weil das sieht man jetzt ja an diesen Spektra und Meltdown Sachen, die in den Intel CPUs passieren. Die passieren ja deswegen, weil das System so unendlich komplex ist, diese CPU, dass die das einfach nicht gesehen haben. Und wie sie es gesehen hatten, war es eigentlich zu spät. Also ich kann dir mal vorstellen, die kleinen, einfachen Dinge kann man sehr gut dazu verwenden, Lösungen zu machen, die man voll unter Kontrolle hat, wo man genau weiß, da kein Trojaner drin ist, wo man beweisen kann, dass sie korrekt sind. Und das ist für Security ist es gut. Aber ob man die genau so schnell kriegt, aufgrund dieser einfachen Strukturen, wie jetzt so ein Vollfeatured CPU, glaube ich nicht. Also die machen den ganzen Aufwand nicht, deswegen, weil sie den ganzen Tag gerne Aufwand treiben. Also wenn es dann eine Lösung gäbe, hätten sie die wahrscheinlich auch schon so gefunden. Also so ein Super-Risk-Ansatz oder irgend sowas, glaube ich nicht. Hast du dir zufällig auch andere CPUs angeguckt, zum Beispiel die Seilen ZPU? Nein, habe ich mir nicht angeguckt. Es gibt ja eine ganze Menge, inzwischen eine ganze Menge etablierte CPU-Architekturen. Das Problem ist immer, eine CPU-Architektur zumindest so eine einfache zu bauen ist nicht so schwierig. Das Problem ist immer das Tooling. Du brauchst ein Betriebssystem und ein Compiler. Das ist immer aufwendig. Bei der ZPU gibt es sowas? Ja, das hat ein GCC-Port und 32-Bit Stack-Maschine. Sehr, sehr klein und Open Source. Also ist auch sicherlich ein interessanter Kandidat. Wenn ich jetzt heute eine 32-Bit CPU bauen wollte für so ein Projekt, würde ich auf Risk5 setzen. Einfach aus dem Grund, weil das von einer sehr großen Community gepusht wird. Weil da gibt es ganze Workshops dazu, wissenschaftliche Community. Es gibt Tooling. Es gibt viele Leute, die sich damit beschäftigen. Es gibt Bücher. Es gibt über die ESA von Risk5. Es gibt ganze Bücher. Ich sehe das relativ emotionslos. Also ich will ein Ziel erreichen und ob das jetzt ZPU oder Risk5 oder Jcore heißt, ist mir persönlich erst mal egal. Und Open Source funktioniert besonders dankgut, wenn sich viele Leute mit etwas beschäftigen. Deswegen sehe ich die ZPU ein bisschen kritischer. Obwohl es sicherlich keine schlechte Lösung ist. Gut, dann, wenn jemand noch Spaß hat. Ich kann das mal vorführen, was ich da gebastelt hab. Können wir mal im kleinen Kreise noch machen. Einfach kommen. Ich bin noch ein paar Minuten da. Viel Spaß noch.