 Hallo liebe Zuhörer, willkommen zum Talk von Jasek Regaining Trust in Everyday Computers. Das ist der Hacky-Way, wir sind Christian Felix und es geht um Franz, der später ins Mikro kommt. So, also was ist das Problem, das sind diese Leute, das Problem ist wir alle benutzen Sie stehen für euch. Also ich weiß nicht wofür ihr eure Computer benutzt, aber ich benutze sie hauptsächlich um mit anderen Leuten zu reden und da haben wir ein echtes Problem, denn obwohl wir eine ganze Menge von Lösungen entwickelt haben, um mit anderen Leuten sicher zu reden oder sicherer zu reden und uns vor diesen Leuten zu verstecken, ohne dass diese Leute wissen worüber wir reden und alle diese Lösungen, also GPG oder OTR oder auch Signal, diese Leute führen alle, also es werden alle auf diesem Ding hier ausgeführt. Das hier ist ein Blockdiagramm von einem modernen Computer, also in dem Fall dieser Lenovo X240, den ich benutze für diese Präsentation, das ist ein drei Jahre alter Laptop und er basiert auf einer Intel CPU und wie ihr sehen könnt auf diesem Blockdiagramm ist das ganze Ding sehr, sehr kompliziert und die Sache ist auf dieser Maschine führe ich meine PGP Geschichte und aus und alles ist verschlüsselt und alles ist fein, aber das Problem ist der Klartext von der E-Mail, die ich verschlüsselte, auch wenn ich eine Smartcard benutze, bewegt sich über dieses ganze Diagramm durch diese ganzen Komponenten. Das heißt wir haben ein sehr kompliziertes System und wir haben also ein paar Sachen, die ja auch hervorgehoben sind, das sind Subsysteme, die irgendeine Art von proprietärer Firmware ausführen, die wir nicht mal angucken können und das macht es sehr, sehr einfach, würde ich sagen, für einen hinreichend gut ausgestatteten Angreifer, dieses System anzugreifen. Also wenn wir uns dieses System anschauen wollen und was wir letztendlich von ihm wollen und in letzter Konsequenz möchte ich mit meinen Freunden reden über Computer und ich benutze eine Tastatur normalerweise, um Dinge einzutippen und das wird drückert dann auf senden und dann wird es verschlüsselt und entschlüsselt und auf der anderen Seite wird es auf einem Bildschirm angezeigt, wie als Worte eben und mein Freund kann das dann lesen. Die Sache ist, wie ihr auf meinem Blog Diagramm sehen könnt, habe ich die Teile, die über die ich über meine Präsentation rede, in grün markiert. Wenn wir sagen, dass Display und Keyboard sagen, benutzen wir Plain Text oder meine ich Plain Text, kann ich. Naja und letztendlich brauche ich da natürlich Klartext, aber ich möchte nicht diesen ganzen anderen Zeug, der da existiert, vertrauen. Also insbesondere diese Sachen, die nicht vertrauenswürdige Firmware ausführen. Aber das Problem bei der Sache ist, seit einigen Jahren hat uns Intel was geschenkt, nämlich CPUs und die Plattformen, auf der diese CPU läuft, also insbesondere auch integrierte Grafik und diese ganzen Dinger führen Firmware aus und die ist sehr widerstandsfähig dagegen, dass man sie reverse engeniert, dass man sie sich genauer anschaut. Das heißt, wir brauchen das natürlich in gewisser Weise, um Dinge zu verschlüsseln und zu entschlüsseln. Aber ich möchte halt nicht, dass diese Dinge irgendwie mit Klartext in Verbindung kommen, denn ich habe ja keine Möglichkeit, denen zu vertrauen. Aber es gibt nicht wirklich eine Möglichkeit, das zu umgehen. Und worüber wir uns jetzt Gedanken machen müssen, ist, wo wir diese Vertrauensgrenze ziehen wollen. Also was wir vertrauen, was wir nicht vertrauen wollen. Und meine Idee ist, diese Grenze hier oben zu ziehen. Also wo möchte ich, dass mein Klartext aufhört und mein verschlüsselter Text anfängt. Und ich bin der Meinung, das sollte bei ein Ausgabegeräten passieren. Denn ich bin nicht der Meinung, dass es eine große Chance gibt, dass wir für eine große Anzahl von Plattformen in der Lage sind, Intel-Triba auseinander zu nehmen und offen zugänglich machen für eine gewisse Anzahl von Jahren, sondern was wir brauchen, ist ein Gerät, was im Display-Bus sitzt. Also ein digitaler Display-Bus auf einem Detail, auf einem modernen Bereich ist das Embedded-Display-Port. Das sind noch zusätzliche Protokollebenen, aber es ist sehr, sehr schnell. Aber am Ende sind das nur Pixel-Daten. Also da wird jetzt keine Videocodex benutzt, sondern es werden tatsächlich nur die Daten, die Pixel-Daten, die angezeigt werden übertragen. Und dieser Laptop hier zum Beispiel und wahrscheinlich auch die meisten anderen Lenovo-Geräte, da ist der Embedded Controller so ein Management-Modul, das alles Mögliche macht, was sie nicht irgendwo anders noch unterbringen konnten. Das schaut sich die ganze Zeit die Tastatur an und die Tastatur ist im Wesentlichen nur eine Ansammlung von Schaltern. Das heißt, da ist gar keine aktive Technik drin. Und das bedeutet, wenn wir uns jetzt von da aus aus gehen, dann brauchen wir jetzt was zwischen diesen Komponenten, dass hoffentlich nur Dinge, denen wir nicht vertrauen müssen, also zum Beispiel verschlüsselte Daten und also insbesondere die CPU, der Embedded Controller, der also diese sich die Tastatur anguckt. Und was wir machen wollen ist, dass wir dann da die Verschlüsselung und Entschlüsselung machen wollen und dann nur noch mit Tastatur und Bildschirm reden müssen. Das sind Gott sei Dank relativ einfache Geräte, das heißt, da müssen wir nicht mehr viel machen, wenn wir jetzt mal Displayport und HDCP und so weiter ignorieren für den Moment. Das heißt, dieses Gerät, was diese Daten abfängt, das hat also nur diese zwei einfachen Busse, mit denen es reden muss. Und das hat einen netten Nebeneffekt, und zwar, dass diese einfachen Busse sehr an sehr vielen Orten benutzt werden. Also wenn wir uns dieses Blockdiagramm mal angucken, zum Beispiel, wie Texas Instrument gerne hätte, dass ein Smartphone liegt. Und das sieht also im Wesentlichen genauso aus. Es ist unterschiedlich, wer die Teile baut, aber am Ende machen die alle dasselbe, nämlich die CPU, die in Wirklichkeit, in Wirklichkeit ein großes System on a Chip ist, also alle möglichen Dinge eingebaut hat. Aber am Ende redet dieses Gerät in Wirklichkeit nur mit dem Ausgabegerät, also mit dem Monitor. Und die benutzen dann verschiedene Protokolle, also zum Beispiel Displayport, aber am Endeffekt ist das sehr, sehr einfach. Und jetzt haben die meistens Smartphones keine Tastaturen, aber die Touchstreams haben auch sehr, sehr einfache serielle Protokolle, die man da entsprechend auch anpassen kann. Das heißt, auch in so einem Fall könnte es funktionieren. Man muss natürlich auch noch überlegen, wo kommt die Energie her. Aber nur von der Elektronikseite und von der Informatikseite müsste auch das funktionieren in so einem Smartphone. Das heißt, wenn wir uns dieses Blockdiagramm von dieser Idee, die wir hier entwickeln wollen, dann gibt es diese Abfänger, dieses Gerät in der Mitte, dieses Abfängergerät. Das heißt, wir müssen also irgendwie Daten empfangen und verarbeiten und wieder rausschicken. Und wie funktioniert, wie würden wir das tatsächlich als Programm kontrollieren? Also, wie spricht das Programm jetzt mit diesem Gerät? Und die grundsätzliche Idee, die ich habe, ist, hier ist so ein Diagramm und wie sieht jetzt so ein Datenpaket aus, das über so ein Monitorstandard rausgeschickt wird. Also es gibt hier Vertical Sync und Verticale und horizontale Synchronisation. Damals als VGA noch eine Sache war, daher kommt das ursprünglich und dann wird also hier irgendwie der Bildschirm dargestellt. Da läuft dann irgendwie so ein Programm. Da sieht man dann ein einzelnes Fenster von einem Programm. Und dieses Programm enthält jetzt irgendwas, was es beschützen soll. Zum Beispiel denkt zum Beispiel an Thunderbird, wo ihr eine Verschlüsse, die mal an einen Freund senden wollt oder eine verschlüsselte Mail empfangen wollt. In dem Fall läuft Thunderbird auf mein Windungssystem, zeigt Fenster an und wenn ich das empfange, zeigt die verschlüsselte Nachricht an. Das heißt quasi, wie wenn ich kein Enig Mail oder ein ähnliches Plugin installiert hätte, also als ob ich den ASCII plaintext sehen würde. Den ASCII Cyphertext sehen würde. Wie wir das jetzt in diesem Szenario hinbekommen, hätten wir ein Thunderbird add on, das versteht, dass wir eine GBG Armored Cyphertext anzeigen wollen. Und wir nehmen jetzt diesen Armored Cyphertext und formatieren ihn als Bitmap, die wir dann anzeigen. Und diese Bitmap hat am Anfang einen Header, der am Anfang zeigt, wie groß jetzt die Bitmap ist. Das heißt, wie breit und wie hoch. Und außerdem auch ein Message Authentication Code. Das heißt, es soll auch skryptografisch sicherstellen, dass nicht irgendjemand mit meinem Gerät reden kann und einfach sagen kann, entschlüsselt mal das für mich. Und diese Bitmap wird dann von diesem Interceptor-Gerät, also von diesem Abfänger-Gerät gelesen und mit meinem PGB-Schlüssel entschlüsselt. Und dieses Gerät kann möglicherweise auch sagen, ja, gib mal das Passwort für den PGB-Key ein. Das hat ja Zugriff auf Tastatur und Display. Und der entschlüsselte Klartext wird dann angezeigt in einem selben Ort, wo vorher dieser Code war, diese Bitmap, die er benutzt hat, um das zu entschlüsseln. Das heißt, wenn ich so ein Add-on für Thunderbird baue, dann sieht es, wird also quasi die Anzeigefläche für die E-Mail wäre dann benutzt für diese Bitmap. Und der Abfänger-Gerät wird dann diese Bitmap während des angezeigt wird direkt umgewandelt in den Text, der da entschlüsselt wird. Und wie funktioniert das dann? Also was muss das Ding also machen? Das muss also diese Display, diesen Display-Buff, der sehr, sehr viele Daten überträgt, muss der also live verarbeiten können. Und wir wollen außerdem, das sollen außerdem nicht so kompliziert sein, damit wir dieses Gerät selbst auch irgendwie sicher machen können. Nicht, dass wir dann ein große Angriffsfläche mit einer anderen großen Angriffsfläche austauschen. Und die nahelängendste Sache für mich wäre, wir nehmen FPGA für die meisten Sachen, denn diese Sachen sind sehr passend für diese Anwendung, denn sie können mit großem Menge von Daten sehr gut umgehen. Also insbesondere wie zum Beispiel bei einem Display-Bus. Und das ist also meine Vorstellung von so einem von so einem Abfänger basiert auf einem FPGA. Das heißt, also ohne dass wir uns das zu genau anschauen, sehen wir schon, dass wir einen Vorteil haben gegen so eine X86-Plattform, wie wir wie das Lenovo X230, denn es gibt immer noch eine ganze Menge Komponenten, aber die sind jetzt, aber es sind nicht mehr so sehr zentralisiert. Also es gibt immer noch, also es wird in gewisser Weise untereinander abgetrennt. Denn ich habe zum Beispiel, also wenn wir uns zum Beispiel mal den Display-Daten-Pfad angucken, wenn dass die Anzeige keinen spezialen Marker, keinen Payload, keine Bitmap, wie wir sie vorher besprochen haben enthält, dann wird das direkt, also hier an der unteren rechten Seite reingehen. Also es kommt von dem nicht vertrauenswürdigen Gerät und wird dann also durch so ein Desirealisierer geschickt, der dann da erst mal so verschiedene Frequenzspektren auseinander teilt für den FPGA intern. Und wenn es diesen speziellen Marker nicht findet, den ich benutze in meiner E-Mail, dann wird das einfach nichts machen. Dann wird es einfach nur das Signal durchgeben. Und das Signal geht dann durch so ein Framebuffer, damit die Display-Ansteuerung funktioniert. Und dann geht es durch so ein Bufferumschalter, aber das tut in dem Fall auch nichts, denn es gibt ja gar keinen Payload, keine Daten, die da enthalten sind. Also an keinem Punkt wird dieses Signal, was alle mögliche andere Informationen enthält, die vielleicht auch nicht gar nicht will, dass dieses Abfanggerät, die überhaupt zur Kenntnis nimmt, wird das also nur an sehr einfachen Komponenten, also relativ einfachen Pfaden von digitaler Logik durchgeleitet. Also da ist keine CPU beteiligt, keine Schiftregister, keine Pattern, also keine Mustererkennungsalgorithmen. Und das bedeutet, ich kann das System so organisieren, dass Daten wirklich nur notwendige Ausführungspfade durchgeleitet werden. Also es gibt hier nicht verschiedene Busse, durch die das läuft, sondern ich kann auf diese Art und Weise quasi die Angriffsfläche auch reduzieren, ein Stück weit zumindest. Und jetzt schauen wir uns mal den Fall an von einem Bild, was tatsächlich verschlüsselte Daten enthält. Diese Daten sind dann implementierungsabhängig entweder im FPGA oder in irgendeinem Secure Access Module, z.B. einer Smartcard. Und die CPU und der Grafikprozessor, die diese Daten dann halt in diese Bitmap formatiert haben, kennen den Key nicht, also kennen diese Daten nicht, den Secure Access Module gespeichert sind, können deswegen damit nichts anfangen. Die Pattern Detectors erkennen dann diesen Header, den wir eben angesprochen haben und schalten dann eben um auf den anderen Fall dem Beginn. Sie schreiben dann die GPG-Verschlüsse in Daten, z.B. in dem Payload Buffer. Und diese Daten stehen dann dem Application Processor zu verfügen, also dem Anwendungsprozessor, das ist dann etwas anwendungsabhängig. Und dieser Anwendungsprozessor könnte dann den Payload Buffer verarbeiten und in dem Fall z.B. die Entschlüsselung umsetzen. Und die könnte dann, hierzu würde z.B. ein Hardwarebeschleuniger verwendet werden, z.B. ein Crypto-Croprozessor, sodass der Application Prozessor keine Crypto-Beschleunigung oder Ähnliches braucht. Und dieser Crypto-Croprozessor, der würde dann diese Daten entschlüsseln und möglicherweise mittels einer Smartcard oder einem sicheren Zugriffsmodul und wird dann den Clatext über einen anderen Datenfahrt zu dem Renderer weiterleiten, sodass der Anwendungsprozessor in diesem Szenario den Clatext überhaupt nicht sehen könnte. Das heißt, selbst wenn wir den kompromittieren würden, dann wären wir nicht in der Lage, den Clatext auszulesen. Und der Renderer, also das Anzeigemodul, wäre dann wahrscheinlich auch wieder eine Prozessor, der dann so eine Art UTF-8-Eingabe in Pixel-Daten umwandelt. Also das stellt also den Text in Pixel-Daten umwandelt und das ist tatsächlich sehr kompliziert, da kommen wir vielleicht später noch mal dazu. Und dieser Renderer, der erzeugt dann quasi eine Bitmap in einem Renderer-Puffer und der wird dann dynamisch in den originalen Datensstrom mit diesem der Bufferswitch baut diese zwei Bilder dann quasi zusammen. Also der Inhalt der Anzeige, die von dem System schon kommt und dem, was hier dieser Renderer Puffer gerade erzeugt hat. Und der musste dann hin und her schalten. Und das Schöne an dieser Trennung der Verantwortlichkeiten ist, dass es auch einige Sicherheitsfeatures möglich macht. Also wir sehen, das Ding hat zwei Eingaben. Also zum einen möchte der Anwendungsprozessor vielleicht ein Benutzer-Interface anzeigen. Also zum Beispiel eine Passworteingabe oder eine Nachricht. Und auf der anderen Seite möchte vielleicht der Krypto-Prozessor Klartext-Daten anzeigen. Und in dem Fall kriegt der Renderer zwei verschiedene Datenströme. Die könnte zum Beispiel farblich unterschiedlich sein. Also man könnte es zum Beispiel schwieriger dann machen, Nachrichten von diesem Anwendungsprozessor zu fälschen, indem man zum Beispiel den entschlüsselten Text in einer anderen Farb anzeigt. Und wenn man dann weiß, na gut, wenn es blau ist, dann ist es der Anwendungsprozessor ist. Und wenn der Text vielleicht rot ist, dann ist es der die entschlüsselte E-Mail, die wir gerade lesen. Und wenn dieses Szenario, also wir nehmen dieses Szenario an, ich kann Dinge entschlüsseln und sicher anzeigen, PGP E-Mails. Und jetzt gehen wir mal davon aus, ich möchte tatsächlich eine E-Mail schreiben. Wie würde ich das jetzt machen? Also die Idee ist, ich habe so ein Programm, was dieses Keyboard ausliest, also die Tastatur ausliest. Und dann gibt es einen Emulator, der eine andere Tastatur emuliert, sodass das Betriebssystem denkt, es gibt eine Tastatur. Und da gibt es dann vielleicht ein Spezial-Taste, so eine Funktionstaste, die dann immer explizit die Eingabe umleitet, sodass jedes Mal, sodass die Funktionstaste tatsächlich als elektrisches Signal direkt unmöglich macht, dieses emulierte Keyboard zu fälschen. Also ich fange zum Beispiel an, eine E-Mail zu, eine E-Mail zu schreiben und dann drücke ich eine spezielle Tastenkombination und die sagt dann diesem Abfanggerät, zeig mir mal bitte einen sehr einfachen Text-Editor an. Das muss kompliziert genug sein, da sich da also Text eingeben kann in eine Sprache, wo ich das gerne machen möchte. Und das muss dann intern in irgendeine Art und Weise zum Beispiel mit UTF-8 repräsentiert werden. Und dann gebe ich meine E-Mail Adresse in diesen Applikationsprozessor ein und drücke also am Ende wieder eine spezielle Tastenkombination und die könnte ich dann also zum Beispiel auch die Schlüssel-ID von dem Empfänger eingeben oder ich wähle das in dem Thunderbird Pluckin aus, das hängt von der Applikation ab und das würde dann diesen verschlüsselten ASCII als ASCII dargestellten verschlüsselten Text über die Tastatur in den E-Mail-Cline eingeben und das bedeutet auch, dass der Krypto-Co-Prozessor überhaupt keinen Zugriff auf die Tastatur brauchen wird. Denn also ich kann mir überhaupt nicht vorstellen, warum der Anwendungsprozessor auf meiner echten Tastatur irgendwelche Tasten drücken wollen würde. Das heißt, ich kann den Krypto-Co-Prozessor, der ist der Einzige, der Zugriff hat auf die Tastatur und ich kann dann also und der gibt dann einfach den verschlüsselten Text ein, als würde ich PGB sehr, sehr schnell tippen. Und das Betriebssystem muss dazu gar nichts wissen, denn für das Betriebssystem ist es einfach nur eine Tastatur. Es gibt da keine zusätzlichen Treiber im Betriebssystem, die ich brauche. Also ich brauche möglicherweise nicht mal Support für die spezielle Anwendung. Also ich könnte mir zum Beispiel vorstellen, dass manche von diesen, also diese Bitmap-Rendering, das könnte zum Beispiel auch in der Cloud also auf einem Programm im Internet laufen, weil ich dieser Maschine irgendwie mehr vertraue. Das heißt, das Verschlüsseln und Endschlüsseln muss also irgendwie aber noch zusätzliches Problem ist, dass wir auch Schlüssel verwalten müssen. Und das sieht also alles relativ unsicher aus. Was ist jetzt der Vorteil? Wenn ich jetzt im Gegensatz dazu ein X86 Mainboard habe, dann ist das relativ einfach. Das könnte man auf irgendwie so eine vierschichtigen PCB drucken. Das heißt, das ist tatsächlich für jemanden, der also da das als Hobby hat, da könnte das selber zusammenlöten. Und eine Möglichkeit, die wir uns überlegen müssen, ist, dass wir dieses Gerät tatsächlich in einem Hardware-Signalty-Modul umbauen, was man also zum Beispiel auch benutzt, um SSL-Zertifikate zu speichern. Und die sind tatsächlich nicht sehr kompliziert. Das heißt, so ein Ding hier wäre sehr, sehr viel schwieriger für einen Angreifer zu brechen, als wenn die Daten direkt im System gespeichert sind. Also man hat normalerweise in so einem Hardware-Security-Modul irgendwie ein Feature eingebaut, was verhindert, dass jemand einfach Löcher rein bohrt oder das Gerät aufmacht. Und dann gibt es eine Zusatzbatterie, die dafür sorgt, dass das Gerät weiterhin Strom hat, egal was passiert. Und was hier quasi die zusätzliche Neuigkeit wäre, ist könnte halt, also das zusätzliche Feature hier ist, dass das Gerät in der Lage ist, einen Schlüssel zu löschen, wenn es merkt, es wird geöffnet. Und wenn wir über Hardware-Sicherheitsmodule reden, dann müssen wir jetzt halt drüber reden, wie wir das tatsächlich machen würden. Also ich habe ein paar selber zusammengebaut oder auseinander gebaut und die meisten, die heutzutage benutzt werden, bestehen aus so einer Art CPU und ein bisschen Speicher und ein bisschen sicherem Speicher, der für den Schlüssel benutzt wird und das wird zusammen in eine Box reingeklebt. Und an der Innenseite von der Box gibt es so ein genanntes Mesh, das sind im Prinzip nur Drähte, die komplett außenrum gebastelt werden und an diversen Stücken in Verbindung stehen mit dem Board. Und es gibt einen Teil dieses Boards, was die ganze Zeit misst, ob irgendetwas von diesem Draht hier unterbrochen wurde. Und die Idee ist, um den an den Schlüssel zu kommen, muss ich erst das Gehäuse aufmachen und da werden also wahrscheinlich irgendwelche von diesen Kontakten unterbrochen. Und das kann ich, das heißt, ich kann auch keine Löcher rein bohren. Und ich denke, es kann sehr einfach auch umgesetzt werden, wenn man das selber macht, indem man zum Beispiel, was ich also tatsächlich in der Praxis schon gesehen habe, ist eine Plastikfolie auf die Silber drauf gedruckt wird. Und das ist im Prinzip das selbe Material, was es in, also was es auch in sehr, sehr billigen Tastaturen eingesetzt wird, also diese Dinger aus Gummi. Und wenn wir das komplett außenrum wickeln und dann kommt da noch ein chemisch widerstandsfähiges Material drüber, also zum Beispiel Epoxy. Und sobald man versucht es auseinander zu nehmen, wird also diese, diese, diese, diese Folie bzw. diese Silberrückstände auf der Plastikfolie werden dabei zerstört. Und das würde man dann auch messen können. Also ich denke, das wäre ein ganz kluger Ansatz. Es gibt auch ein paar andere, die ich gerne versuchen würde. Also zum Beispiel Radiointerferenzen. Das heißt, ich habe, messet die ganze Zeit irgendwelche Radiokarakteristiken und ich habe da zufällig, mehr oder weniger zufällig, so dass es schwer vollhersagbar ist, sind da einfach Drähte drin. Und dann schaue ich mir an, welche Eigenschaften die haben und Messe, also auch, wie die sich zusammenverhalten und Messe dann, wenn sich das ändert, ob das tatsächlich in der Praxis funktioniert. Das weiß ich nicht. Das ist vielleicht sehr, sehr teuer. Aber man könnte das zumindest sich mal anschauen. Ich könnte mir auch vorstellen, dass es so eine Art Ultraschall Methode gibt, mit der man dann Ultraschall misst. Und auf dem Hauptbord wäre dann kleine Piezo-Elemente, die Ultraschall empfangen und wir schicken quasi Ultraschall durch das Material und schauen uns dann an, ob die Antwort, die wir da kriegen, sich tatsächlich irgendwie ändert. Und ich kann mir vorstellen, dass da, also die Idee ist, dass man das Gehäuse anfassen muss, um es tatsächlich irgendwie zu verändern. Man vielleicht geht es auch, dass man da mit einem Laser rangeht, dann würde sich es nicht verändern. Aber so einen Ansatz könnte ich mir vorstellen. Und ein drittem Ansatz, den ich gerne versuchen würde, wäre Triluminiscence. Also man könnte zum Beispiel Fotodioden, die also sehr, sehr sensitiv sind, direkt auf die Platine. Und dann mache ich ein durchsichtiges Material drüber, in das, also so eine Art Friction Glow oder Smash Glow-Kristalle. Also es gibt verschiedene chemische Kristalle, die, wenn man die Kristalle aus kaputt macht oder gegeneinander reibt, dann leuchten diese hell. Und das hat man jetzt in diesem Material mit drin. Und dann kann ich mir vorstellen, es ist sehr, sehr schwierig, wenn dieses Material irgendwie chemisch resistent ist, wäre es sehr schwierig, dieses Material zu bewegen, ohne dass diese Kristalle Licht abgeben. Und das könnte man dann dedektieren. Und dann könnte man alle Schlüssel daschen. So, das sind alles nur Ideen, die man eventuell mal umsetzen könnte, um dieses, diesen Co-Prozessor zumindest moderat sicher zu machen gegen irgendwelche Angreifer. Aber es sollte mal klar sein, dass jede Hardware Security Hardware früher oder später kaputt gegeben kaputt gemacht werden kann, gegeben einen ausreichend ausgestatteter Angreifer. Ich kenne einigen Militär, Militärgeräte, wo Detonation oder Indies verwendet werden, aber damit beschäftigen wir uns jetzt nicht weiter. Also ich habe jetzt diese Idee, wie mit einem einigermaßen sich ausgerät, in meinen Laptop rein zu tun. Detona letztendlich ein relativ komplexes Stück Platine in unserem Computer. So, das heißt, welche Angriffsfläche kommt jetzt durch dieses neue Gerät hinzu? Das hier ist keine vollständige Liste, aber eine Liste an Dingen, die möglicherweise ziemlich kritisch sein könnten. Eins ist der Protokoll-Decoder. Wir müssen irgendwie diesen Header finden, wenn wir uns erinnern. Das heißt, wir müssen ja die Bitmap erkennen, den Header erkennen und dann den Buffer befüllen mit den GPG-Daten zum Beispiel. Das ist ein relativ komplexer Prozess, der den Systemzustand eventuell in einem nicht ganz vorgesehenen Vorgang beeinflussen könnte. Wir müssen allerdings nicht einen Riesenhaufen Register oder Speicher konfigurieren, um irgendetwas zum Laufen zu bekommen. Wir können also hier einen sehr, sehr einfachen FPGA bauen. Das ist die Idee, ich halte die Hardware sehr, sehr einfach. Ich tu einfach nur die Dinge, die ich brauche in dem FPGA und ich implementiere das tatsächlich in physikalischen Hardware-Schaltungen. Das ist also tatsächlich sehr, sehr einfach, sodass es sehr schwierig ist, diese Dinger so zu modifizieren, dass die in irgendeiner sinnvollen Art und Weise für einen Angreifer verändert werden. Und dann gibt es den Social Engineering-Angriffsvektor. Also wir sollten davon ausgehen, dass wir relativ kluge Leute sind. Also wir sind nicht so sehr, wir sind nicht einfach normale Benutzer, also Leute wie ihr eben hier. Das heißt, Social Engineering ist wahrscheinlich kein sehr, sehr schlimmes oder sehr, sehr großes Angriffsproblem werden, denn das betrifft in meiner Erfahrung eher Leute, also weniger Leute, die Dinge über Computer wissen, denn also das geht zumindest zurück, umso mehr Leute, die Leute tatsächlich verstehen über Computer. Die sind also weniger anfällig für Social Engineering-Angreife. Und dann physikalische Kompromittierung, das was bedeutet, wenn jemand tatsächlich das Modul aufmachen kann, ohne dass ich das bemerke. Naja, also die Sache ist die, wir können uns, also wir können das nicht ausschließen, aber wir können es zumindest schwieriger machen mit diesem Hardware-Sicherheitsmodul. Und dann FPGA-Backdoor steht hier nur mit oben, weil das, also in den Magazinen in der Forschung gerade sehr populär ist. Aber ich glaube, eine FPGA-Backdoor ist in dem Fall nicht sonderlich realistisch, denn es wäre sehr, sehr schwierig, etwas in den FPGA einbauen, dass mir irgendeine hilfreiche, hilfreiche Kompromottierung bedeutet in dem Szenario. Also Logikfehler können immer mal wieder passieren, das ist klar in dem Gerät. Aber ich denke auch da können wir ein bisschen was machen. Die Sache ist die, wir implementieren unsere eigene Hardware, das heißt wir haben vielleicht die Möglichkeit ein paar Gegenmaßnahmen mehr hier treffen, als wir das in Software tun könnten. Also man benutzt zum Beispiel Speicher, dass man nur lesen kann und nicht modifizieren. Wir können verschiedene Speichersysteme haben, eins für Stack, eins für Heap und eins für Code. Und dann wäre es nicht möglich, da in einem Speicher hin und her zu springen. Und wir können Privilegien trennen, also wir können zum Beispiel Krypto, Anwendung, Anzeige, das könnten wir alles trennen, das sind die drei Dinge, die mir sofort einfallen. Und möglicherweise können wir auch die Hardware Zugriffskontrolle machen lassen. Also wenn wir zum Beispiel uns irgendwas teilen müssen, also wenn es so eine FPGA gibt, dann haben wir also wahrscheinlich einen gemeinsamen Ramm, in dem die ganzen Pixel-Daten liegen. Und wir können das trennen, indem wir da in Hardware noch eine zusätzliche Zugriffskontrolle einbauen, sodass die verschiedenen Komponenten nur in ihren Adressbereich schreiben können. Und wir können das also ganz allgemein einfach lassen. Wenn es komplex wird, dann ist es sehr, sehr schwierig, das sicher zu halten. Aber wenn wir das super, super einfach halten, dann, also gerade, zumindest wenn wir es vergleichen mit einer X86-Plattform, dann kann die Angriffsfläche, um die es hier geht, tatsächlich klein, also managebar bleiben. Zumindest so, dass wir das noch, noch, noch händeln können. Und also die CPU insbesondere wäre also ein besonders risikoreiches Projekt. Und es gibt da ein Projekt, was einer Open Source CPU arbeitet, die also relativ gut spezifiziert ist und die auch relativ gut getestet ist. Und sie haben also auch logisch bewiesen, dass die Funktionen, also dass das funktioniert. Und es gibt auch ein paar andere Mechanismen. Und eine weitere Sache, die ich also noch, wo ich noch auf hinweisen wollte, ist, dass diese Systeme auf einem sehr niedrigen Level arbeiten. Wir können also nicht einfach nur alles zurücksetzen. Wir können einfach Dinge ständig zurücksetzen. Und das macht das Leben für einen Angreifer sehr viel schwieriger, denn das heißt, wenn wir einfach das gesamte System, also alles außer die Tasten, also zum Beispiel jedes Mal, wenn eine neue Frame reinkommt oder jedes Mal, wenn Daten reinkommen, dann wird es für einen Angreifer sehr viel schwieriger, den Zustand von dem System zu manipulieren, sodass es schwierig ist, das in einen neuen Zustand zu bringen, der vielleicht hilfreich ist für einen Angreifer. Und das macht die praktische Angreifbarkeit eben sehr viel schwieriger. So, wenn wir jetzt an diese Angriffsfläche denken, die wir hier mit möglicherweise erstaffen haben, mit diesem Gerät in dem Laptop und ohne dieses Gerät. So, ich habe einen Vergleich oder eine Gegenüberstellung erstellt, wie problematisch oder wie erfolgreich jeweils die Variante des Geräts mit oder ohne Interceptor-Gerät wäre. Und ich denke, als ungefährer Peilung ist das durchaus brauchbar. Das heißt, ich denke, wenn wir diesen Interceptor nicht im Gerät haben, können wir eine relativ gute Lösung erzielen, wenn wir Secure Boot Correct benutzen, wenn wir unsere Festplatte verstellen und so weiter. Aber es ist einmal implementierungsabhängig und nutzerabhängig. Und ich denke, wenn wir eben so ein Gerät, wie ich eben gezeigt habe, einsetzen würden, wäre es wirklicherweise deutlich einfacher, verschiedene dieser Ziele umzusetzen. Ein gängiges Angriffsszenario ist, dass das Gerät geklaut wird. Das heißt, jemand nimmt das Gerät weg und wir haben keine Zeit, den Bildschirm zu sperren. So, in diesem Moment hätten wir dasselbe Problem, wie wenn wir das Interceptor-Gerät entsperren würden und das Gerät dann geklaut werden würde. Aber wir müssen das Interceptor-Gerät nur entschlüsseln, wenn wir die tatsächliche Operation davon nutzen wollen, also Nachrichtverschlüsseln und Entschlüsseln. Ansonsten können wir es immer verschlossen lassen. Außerdem können wir zusätzliche Sicherheitsfeatures einbauen, die in Standard-Hardware nicht verfügbar sind. Das heißt, z.B. für den Fall, wenn unsere Hände davon entfernt worden sind. Ja, also wenn wir unsere Hände von der Tastatur wegnehmen, dann könnte es zum Beispiel sein, dass dann automatisch erkannt wird, da geht das Gewicht weg. Also löschen wir die Schlüssel. Und jetzt der nächste Punkt, also eine gezielte Angriff. Also was ich als gezielten Angriff bescheiden würde. Also jemand, der sehr viel Geld hat, der mag dich nicht. Also jemand möchte speziell deine E-Mails lesen können. Und ohne diesen Interceptor hast du jetzt wirklich ein Problem, denn selbst wenn du CubesOS benutzt und alles verschlüsselst mit GPG, dann hast du immer noch ein Standard-Linux-Betriebssystem mit einem Xenhypervisor auf eine x86-Plattform mit eine ganze Menge proprietaryer Firmenwehr und eine ganze Menge Orte, wo Klartextdaten vorliegen. Und dieses System, dieses komplierte Stack, dieses System ist so kompliziert, dass es fast garantiert ist, dass es irgendwo Fehler gibt. Und das sehen wir auch die ganze Zeit. Also zum Beispiel, Apple's iPhone hat eine relativ gute Sicherheitsarchitektur, aber es ist immer noch sehr komplex und Leute kommen um diese Sicherheitsarchitekte rum. Und der Xenhypervisor, der also für CubesOS als Isolationsfeature benutzt wird, der wird auch hoch angesehen, aber es werden halt immer noch Fehler gefunden, denn das ist eine sehr komplizierte Sache. Und ich glaube, dass wir diese Angrifffläche verkleinern können, dadurch, dass wir das auf dieses Interceptor-Device, also dieses Gerät, was ich da beschrieben habe, verkleinern, das also sehr wenig Schnittfläche hat mit der Welt da draußen. Das denke ich, könnte tatsächlich leichter sein, sich das genau anzugucken und Fehler zu finden. Und ein offensichtliches Problem mit oder ohne mit diesem Gerät ist, also du bist überwacht, also jemand hat eine Kamera in deiner Wohnung hinter dir, denn du musst den Klartext irgendwie ja aus dem Bildschirm rauskriegen, denn wir haben keine Krypto-Brillen. Und das heißt, jeder in dem selben Raum könnte das abfilmen, egal, ob man da jetzt so ein Privatsphärefilter benutzt, also irgendwie, wenn die Leute direkt hinter dir stehen, dann wären sie in der Lage, das zu lesen. Jeder Mechanismus, der also irgendwie ein Display benutzt, irgendwie ein Monitor benutzt, wird da dran scheitern. Also außer ihr benutzt so einen Snowdenumhang oder so was. Aber ich glaube, das könnte da tatsächlich auch nicht wirklich helfen. Ein physikalischer Zugriff wäre dann das Szenario, in dem jemand z.B. beim Versand oder an einer Grenzkontrolle Zugriff auf das Gerät erlangt, mit der Weise auch unwillentlich. Hier könnten ja z.B. Rotkits installiert werden, der Bootflash ausgetauscht werden etc. oder sie könnten irgendein Interceptor vor den Interceptor oder hinter den Interceptor packen. Und das heißt, man wüsste jetzt gar nicht wirklich, ob man denselben Laptop aus der Kontrolle oder nach dem physikalischen Zugriff durch eine dritte Partei zurückbekommt. Ich denke, dass in diesem Fall wir es etwas schwerer für solche Angreifer machen können, indem wir z.B. detektieren können, wenn das Gehäuse geöffnet wird und darauf irgendwie reagieren können. Aber komplett sicher wird das hier durch natürlich nicht. Wenn wir uns jetzt das Szenario anschauen, dass wir unter kompletter Überwachung stehen, haben wir immer noch das Problem, dass wir die ganze Zeit Metadaten liegen und das können wir auch nicht vor dem Betriebssystem oder ähnlichem verstecken und dementsprechend auch nicht vor einem Angreifer, der dort drüber Kontrolle hat. Nun, wenn wir uns überlegen, dass wir eben so einen Interceptor in unseren Laptop installieren. Dann machen wir natürlich zuerst mal die Angriffsoberfläche größer und wenn der Interceptor dieses Gerät dann kompromittiert wäre, dann wäre das natürlich total schrecklich. Aber in dem Moment sind natürlich in gewisser Weise die Probleme, also die Geheimnisse, die ich meinem Computer anvertraue, sind natürlich immer auf diesen Bassen. Aber ich denke, es wäre also unter dem Strich tatsächlich kein Sicherheitsfeature, also wäre tatsächlich von Vorteil. Und naja gut, die großen Probleme, die wir jetzt noch lösen müssen, um das mal tatsächlich praktisch umzusetzen, ist also tatsächlich zunächst mal diese Display-Port-Geschichte und LVDS-Geschichte. Dann wie gesagt, das ist sehr schwierig. Wenn ihr da noch Tipps habt oder Hinweise, dann bin ich da sehr interessiert. Auch Unicode darzustellen ist, denke ich, sehr schwierig. Also wir wollen, dass die Leute mit allen möglichen Sprachen über dieses Device kommunizieren können. Und wenn wir dann embedded-Device haben, was irgendwie sicher Unicode in Pixel-Daten umwandelt, das denke ich, ist sehr schwierig. Und dann müssen wir auch noch ein sicheres Paketformat definieren, sodass es also nicht komplex ist, aber trotzdem funktioniert. Und wir müssen auch die, also wir müssen sicherstellen, dass die Tastatur nicht ohne, dass ich das bemerke, Geheimnisse an das Betriebssystem weiter gibt, sondern dass immer klar ist, mit welchem Gerät ich das spreche. Und wir müssen also auch noch die Krypto trennen von dem Anwendungsprozessor auf eine Art und Weise, sodass wir am Ende tatsächlich irgendwas davon haben, sodass also nicht am Ende einfach nur die gesamte Angriffsoberfläche bei dem Krypto-Prozessor ist. Und wenn wir das mit einer Smartcard implementieren wollen, sodass auf der Smartcard der Schlüssel liegt, dann wird es wahrscheinlich schwierig, das richtig zu machen. Denn ich glaube, es ist als Privatpersonen nicht so einfach ist, Smartcard-Software-Development-Kits zu bauen, sodass wir dann für diese GPG-Kies auf dieser Karte sinnvoll verwalten können. Da müssen wir wahrscheinlich auch noch irgendwie was rausfinden. Und ich weiß jetzt nicht so richtig, aber ich hoffe, dass ich in der Lage war, euch diese Idee für euch interessant zu machen. Wenn ihr Feedback habt, wenn ihr Ideen habt oder vielleicht Dinge wisst in einem dieser Felder, die ich hier gerade genannt habe, es interessiert mich wirklich, hier auch Feedback zu bekommen und auch Hilfe zu bekommen. Und ihr könnt mich unter dieser E-Mail-Adresse erreichen. Der GPG-Kie ist direkt drunter. Und der Talk, auch die Folien, sind dann später auf diesem GitHub-Repository abrufbar. Und ihr könnt auch gerne da einfach ein Issue aufmachen, wenn ihr Feedback abgeben wollt. Danke erst mal, dass ihr zugehört habt. Also jeder, wir können, glaube ich, noch Fragen und Antworten machen. Danke, es war ein sehr auflösreicher Vortrag. Es gibt zwei Mikrofone. Stellt euch bitte an. Ich versuche, den ersten zu finden. Wir warten kurz, bis die Leute, die jetzt schon ausgehen wollen, den Raum verlassen haben. Okay, wir starten bei dem Mikro und Ping-Pong dann durch den Raum. Soweit ich das verstehe, ist der Interceptor, dass der Pläntext reingeht und der verschlüsselte Text da wieder rausgehen. Ich möchte meine ganzen E-Mails in E-Mails oder Wim bearbeiten mit den ganzen Paketen. Also klar, man muss eine gewisse Einschnitte in Benutzbarkeit in Kauf nehmen. Außer natürlich, der Interceptor führt dann auch tatsächlich Emacs aus. Das wäre möglicherweise möglich, dass man da vielleicht auch komplettes Linux ausführt. Aber das wäre natürlich auch wieder eine sehr große Angriffsoberfläche. Etwas allgemeiner. Der Vorteil, diese Anwendung in Software statt in Hardwarez haben, ist, dass wir sie updaten können. All das geht verloren in deiner Lösung, richtig? Also der Sprecher kann die Frage hier nicht ganz gut verstehen und die Frage wird jetzt nochmal... Also es ging um die Updatebarkeit. Also die Sache ist die, wenn das in einem FPGA implementiert ist, also nicht in einem ASIC, dann kann man es tatsächlich relativ leicht updaten. Und ich denke, es ist sinnvoll, das möglichst schwierig zu machen, das abzudaten, damit man nicht einfach, damit man da einen Schalter dran bauen muss oder so was, damit niemand über eine Softwareangriff einfach diesen Code austauschen kann. Und wenn man das macht, naja gut, dann könnte man es auch updaten. Okay, woher weiß ich wirklich, dass das, was ich sehe, wirklich vom Interceptor kommt und tatsächlich auch an den Interceptor geht, wenn ich dort etwas hinsende und nicht an die eigentliche Intellat wäre? Gute Frage. Also ich kann nicht mit absoluter Sicherheit wissen, dass jemand nicht vielleicht zum Beispiel ein Interceptor zwischen mir und dem Interceptor platziert hat. Aber die andere Art, darüber zu reden, ist, was ich haben möchte, ist, ich möchte kein Programm auf meinem Betriebssystem, das so aussehen kann wie ein Interceptor. Und eine Möglichkeit, um das möglich zu machen ist, man könnte, also die einfachste Möglichkeit dazu wäre, dass der Interceptor immer im vollen, also vollen Bildschirm angezeigt wird und dann benutze ich ein LED auf der Tastatur, um zu signalisieren, geht Eingabe gerade zum Interceptor oder geht das zu dem eigentlichen Rechner? Da könnte man also zum Beispiel die Mikrofonis gemuted LED dafür benutzen. Andere Möglichkeit wäre für die Ausgabe, dass man also einen speziellen Rand um die Ausgabe rummalt und dann wäre zum Beispiel rot, es ist Linux und blau ist der Interceptor. Aber ich denke, die Eingabe, das richtig zu machen, das wird relativ schwierig, denn wir wollen nicht, dass wir aus versehenden Passwort tippen. Und wenn man einen Passwort häufig eintippt, dann schaut man vielleicht gerade nicht auf den Bildschirm oder schaut da nicht sehr genug drauf. Das heißt, ein Ding, was man sehen kann, reicht in dem Fall vielleicht noch gar nicht. Gut, also der Moderator denkt, wir haben einen guten Anwendungsfall für den Think Vantage Button gefunden. Das Internet spricht mit uns. Die erste Frage ist, ob der Interceptor so funktionieren könnte, wie KVM funktioniert. Das heißt, Keyboard wird immer wieder um aus. Das heißt, man könnte die alle Ausgaben in eine Box umleiten und die würde dann die Arbeit machen. Ja, also das kann man definitiv so machen. In einem Desktop Anwendungsfall, das würde ich wahrscheinlich genauso implementieren. Aber in einem Laptop Fall muss es halt irgendwie in das Gehäuse integriert sein. Also zum Beispiel bei einem X230, da könnte man eine SSD einbauen statt der großen Festplatte und dann könnte man den freigewordenen Platz dafür benutzen. Und das ist eh schon relativ nah an den Anschlüssen. Hallo, ich mochte dann kreative Ideen sehr, sehr gerne. Es geht um die Risk 5 Implementierung, einer Risk V Implementierung. Ich bin mir nicht ganz sicher darüber, irgendeine Uni in England, die da Forschung zu macht. Was denkst du über ein System, den man vertrauen kann, dadurch, dass die gesamte Architektur offen ist? Also ich denke, das wäre sehr interessant. Also das wäre sicher eine der interessanteren Gründe, das überhaupt zu machen. Also man kann sicher irgendwie Kompis, Wobbly Windows und durchsichtige Fenster und alles, je nachdem, was für ein Betriebssystem man benutzt. Das hätte man halt gerne. Aber man möchte auch gleichzeitig den Vertrauensaspekt haben, der in dem Fall hier bei uns in diesem FPGA implementiert wird. Und was wir machen möchten, ist, wir möchten die Firmen, wer wirklich so einfach wie möglich machen, damit da nicht irgendwelche Crashers passieren können oder Angriffsoberfläche passieren. Aber letztendlich möchte man vielleicht mehr und mehr Funktionen reintun mit notwendiger Isolation natürlich. Das Internet spricht erneut. Eine kurze Frage, was ist mit USB-Tastaturen? Naja, also das hängt davon ab. Also wenn man das direkt in den Interceptor einstecken kann, naja, also USB ist vielleicht immer noch einfach genug, dass man das mit Aufwand auf einem FPGA implementieren könnte. In einem Laptop-Anwendungsfall denke ich, ist es schwierig, weil man müsste ja quasi alle USB-Ports abfangen. Ich verstehe den ganzen Punkt hinter dem, dahinter so ein Gerät zu haben, ist, dass man Krypto isoliert in einer sicheren Umgebung ausführen kann. Die Idee ist ja, dass man noch Integrationspunkte für diverse Anwendungen bereitstellen will. Ist das denn der einzige Weg, so etwas zu realisieren, zu integrieren? Ja, also ich glaube nicht, dass es der einzige Weg ist, wie man das machen kann. Man könnte zum Beispiel ja auch von einer Implementierungsstandpunkt viel einfacher Architektur, indem man einfach ein Gerät in die USB-Port einsteckt, was eine Tastatur und eine Anzeige hat, also zusätzlich zu der aktuellen Anzeige und der aktuellen Tastatur. Und der einzige Unterschied wäre, das wäre halt etwas weniger praktisch, das zu benutzen. Also es gibt mehrere Möglichkeiten, das zu machen. Aber ich denke, es ist eine interessante Idee, die Anzeige eben abzufangen, weil man das gut portieren kann zu vielen verschiedenen Plattformen. Und wenn man sich jetzt Integrationspunkte anguckt, Cube2S oder sowas, ich denke, das hat viel Potenzial. Also wenn man sich zum Beispiel EvilMate angucken würde, also ein System, das nicht gefaked werden kann. Ja, also in dem Fall von Cubes könnte man sowas zum Beispiel auch ein Stück weit mit einbauen, zum Beispiel in den DisplayManager, sodass der Interceptor und der DisplayManager zusammenarbeiten, sodass Cubes weiß, was dieser DisplayManager gerade macht, beziehungsweise der Interceptor gerade weiß, was der DisplayManager macht, sodass es schwieriger wird, das Passwort in das falsche Gerät einzugeben. Und jetzt ist mein Bildschirm schon angegangen. Es gibt eine weitere Frage aus dem Internet. Was ist mit CypherText, der länger ist, als das, was auf dem Bildschirm oder diese Box passen würde? Ja, das ist eine interessante Frage. Also das Problem ist hauptsächlich, was mache ich, wenn ich Klartext habe, der zu groß ist? Und was man halt machen würde, ist, man würde es auf verschiedene Bilder aufteilen. Also das liegt, also zum Beispiel, wenn man so ein Display anguckt, die übertragen sehr, sehr viele Daten. Also zum Beispiel selbst dieses schlägtliche Display, was ich hier am Laptop hat, hat mehrere Gigabit pro Sekunde. Und das heißt, ich kann es einfach in aufeinander folgende Frames rein stecken. Und klar, da werde ich auch irgendwann Probleme kriegen mit dem FPGA, weil der halt vielleicht auch Speicherprobleme hat und so weiter. Aber ich denke für ein allgemeines System, wo man sich ein bisschen Komplexität spart, das kann man lösen. Und für das Ausgabeproblem, das scrollt dann halt einfach. Da muss man halt also nur die Hoch-Runter-Pfeile oder Screen-Up-Screen-Down-Kies muss man halt irgendwie daran so belegen, dass die dann die Ausgabe scrollen. So, dein Hauptargument war ja, dass dein System wegen der Kontext hält und deswegen weniger angreifbar ist. Aber wie realisierst du dann die LVDS Interception? Wenn du jetzt etwas Einfaches haben willst mit wenig Attack-Service, wieso nutzt dann nicht einfach ein einfaches Display und hörst einfach nur die Keyboard, also die Tastatur. Ja, aber das wäre langweilig. Nein, also ernsthaft. Wenn man tatsächlich diese Live, die Anzeigedaten, abfängt, dann hat es den großen Vorteil, dass man, wie zum Beispiel bei meinem Laptop, der Laptop sieht ganz genauso aus wie vorher, nur dass er jetzt eben diese höhere Zusicherung hat, dass diese Operation tatsächlich das tun, was ich will. Das heißt, ich müsste jetzt also nicht noch ein Gerät mit mir rumtragen und hab dann vielleicht zwei verschiedene Tastaturen und andere Anzeige. Ich glaube, für E-Mail lesen, da würdest du früher oder später ein ernsthaftes Display haben wollen und an dem Punkt wird es dann halt auch wieder genauso kompliziert. Und wenn wir uns überlegen, die Entwicklungszeit, ja, LVDS wird sehr, sehr lang der Brauer brauchen, auch Displayport, vor allem weil es auch sehr genau getuned sein muss, damit also die Details alle stimmen. Ja. Wie genauer denkst du, wird denn etwas auf der CPU sein? Also wenn es so etwas gäbe, da ist Text von der CPU sendet. Ja, also wenn ihr Spyware auf eurem Rechner laufen habt, was also möglicherweise pgp, also verschlüsselte E-Mails abfängt, bevor sie verschlüsselt werden, dann sieht man vielleicht gar nicht den Unterschied, wenn Wire Shark zum Beispiel läuft. Denn wenn die Spyware irgendwie halbwegs gut ist, dann wird ihr wahrscheinlich irgendwelche Techniken benutzen, um seinen eigenen Traffic in dem üblichen Traffic zu verstecken. Das heißt, das wäre überhaupt nicht möglich, das leicht zu detektieren. So, also ich habe deinen Vorschlag auch in so Welt verstanden, dass man damit E-Mails schreiben soll oder mit diesem Ansatz. Das heißt, wenn wir in dem Interceptor den Key speichern und daran auch die Verschlüsselung umsetzen, wenn das korrekt ist, welche Art von Verschlüsselung planst du auf dem tatsächlichen Verschlüsselungsgerät zu machen. Das heißt, welches konkrete Verfahren wird dann benutzt werden, um ein E-Mail an andere Personen zu schicken? Ja, das hängt massiv von der Implementierung ab. Mein erster Ansatz wäre, dass wir zuerst E-Mail erweitern, sodass also wenn ich eine E-Mail öffne, dann gebe ich die in den Empfänger ein in Klartext, das ist sowieso Metadata und dann benutze ich das selbe Format, um den Public Key, also im Optimalfall mit der Signatur meines eigenen privaten Schlüssel an den Interceptor zu geben, sodass dann das Gerät, den Key ID von dem Empfänger gleich mit anzeigen kann, wie auch deine eigene Signatur das bestätigt hat, zusammen mit dem privaten Schlüssel, der nur im Interceptor vorhanden ist. Das ist ein bisschen komisch. Nehmen wir einfach mal an, das kann man so machen. Eine andere Möglichkeit wäre Key Management komplett in dem Interceptor zu machen, da gibt es dann eine Tastenkombination und da gibt es ein Menü und dann kann man dann vielleicht die E-Mail Adresse des Empfängers da eingeben. Nicht wirklich eine Frage, aber ich denke, dass du einen guten Anwendungsfall für die Touchbar MacBook Pro gefunden hast. Dann doch noch eine weitere Frage. Ich habe den Anfang vom Talk verpasst. Ist das schon fertig? Hast du schon einen Prototypen? Ich habe gerade zwei Raspberry Pi Zeroes in meinem Laptop und ich kann es perfekt zumachen. Aber eins kontrolliert die Tastaturen, eins kontrolliert das Netzwerk, aber hast du vielleicht irgendwie über sowas in der Richtung überlegt? Also ich würde ganz gerne Arm System of a Chips vermeiden, also Broadcom, Qualcomm, Texas Instruments. Ich habe ein paar von innen gesehen und das ist echt nicht hübsch. Sie sind sehr kompliziert und ich glaube, die sind nicht leichter sicher zu machen, als das Linux, was du eh schon ausführst. Qualcomm hat mehrere ernsthafte Probleme von ihrem Heiterweise allein im letzten Monat und wir können das, denke ich, im Wesentlichen ausschließen, dass wir dann einen Arm System of a Chips vermeiden.