 Ja, unser nächster Vortrag ist Practical Hashtags von Network. Willkommen zum 36 C3 zur Übersetzung. Alle Talks in Kongress werden live zwischen Deutsch und Englisch in eine weitere Sprache übersetzt. Für weitere Details und Informationen, wie die Streams genutzt werden können, besucht c3lingo.org. Wir freuen uns über eure Rückmeldungen und bevorzugt mit Hashtag C3D. Übersetzer für diesen Talks sind Goonies Bro und Eiphen. Hallo, vielen Dank, dass ihr heute Abend gekommen seid. Mein Name ist Michael. Ich möchte mit euch die Research-Teilen, die meine Gruppe in meiner Mastertheise gemacht hat. Also kurz zu mir, ich habe meine Mastertheise in Zürich absolviert und dann in Amsterdam. Ich arbeite jetzt als Cybersecurity-Analyst. Das hier sind die Menschen, die das möglich gemacht haben, meine Superweise, meine Kollegen, die mich unterstützt haben und die so viel Zeit und Aufwand auch in diese Forschung gesteckt haben. Das sind die wahren Rockstars hier. Ja, fangen wir mal an mit Cache-Attacken. Also Cache-Angriffe, die waren früher lokale Codausführungs-Angriffe. Hier links zum Beispiel haben wir zwei Virtula-Maschinen, die hardware sich teilen. Also sie machen Time-Sharing für TPU und auch den Cache. Und einen Angreifer kontrolliert, die wir eben zwei und kann dann darüber... Auf der rechten Seite sehen wir JavaScript. Ja, also der Browser läuft oder shared, teilt sich wieder eine Ressource mit einem anderen Prozess und auf die Art und Weise kann man wieder Angriff machen. Ja, diese JavaScript-Sache fühlt sich so ein bisschen irgendwie remote an, aber in Wirklichkeit wird das natürlich lokal ausgeführt, damit es überhaupt funktioniert. So, wir wollten jetzt mal gucken, ob man das weitertreiben kann und wirklich einen netzwerkbasierten Cache-Angriff fahren kann. Wir haben hier diesen Setting, wo der Client sich mit dem Server verbindet und dann haben wir eine Server-Maschine, die von dem Angreifer kontrolliert wird. Ich will euch zeigen, wir können die Geheimhaltung auf dem Server brechen von der dritten Maschine, ohne da wirklich einzugreifen. Also die TPU auf dem Server hat noch nicht mal irgendetwas zu tun mit diesen Cache-Angriffen. Es merkt da gar nichts davon, dass wir hier Daten absaugen. Also schauen wir uns das bitte genauer an. Wir haben hier diese schöne Cut, also eine SSH-Session betreibt. Jedes Mal, wenn die also eine Taste drückt, gibt es ein Paket zum Server. Das ist eigentlich immer so, wenn man irgendwie interaktive SSH-Sitzungen hat, denn wie es ja schon im Namen wiedergibt, das ist interaktiv, nicht wahr? Wenn wir das jetzt unter der Haube mal anschauen, dann werden diese Pakete, die treffen den letzten Level-Cache, den aussersten Level-Cache, der Angreifer. Ich starte jetzt diesen Angriff auf diesen selben Cache, indem er auch ein Netzwerkpakete schickt. Und indem er das tut, kann er die Ankunftszeiten der SSH-Pakete absaugen. Denke mal, was kann man damit anfangen mit diesen Ankunftszeiten? Also wie wird dadurch die Geheimhaltung der SSH-Sitzung kompromittiert? Naja, Benutzer tippen halt in speziellen Mustern. Wir sehen das jetzt hier. Das E kommt schneller nach B als zum Beispiel C nach E-Käme. Und ganz generell, wir können es generalisieren und eine statistische Analyse machen. Hier die Orangen an Punkte, die rekonstruieren, die Arrival, die Ankunftszeiten, ziemlich korrekt. Und korrekt heißt halt, wir können wirklich die genauen Zeiten rekonstruieren, wenn, wann, wo der Benutzer getippt hat, durch diese statistische Analyse der Ankunftszeiten. Und dadurch können wir herausfinden, was du in deiner privaten SSH-Session irgendwie getippt hast. Und das klingt jetzt echt, echt angsterregend und futuristisch. Aber ich werde euch das zeigen, wie das geht. Gut, also zum Namen unseres Papers. Also die Tradition erfordert es einfach, dass ein Paper einen Namen hat. Und wenn man Infosack tut, dass ich durchliest, dann ihr wisst wahrscheinlich schon, was jetzt kommt. Nämlich bei uns hieß das Paper Netcut. Ja, okay, das weißen Wortwitz. Also in diesem Fall war Netcut für Netzwerk, Cash, Attacke. Und mit Tumor, das funktioniert nicht immer so. Das geht manchmal nach hinten los und bei uns ging es massiv nach hinten los. Also wir haben da echt einen Twitter-Drama ausgelöst. Dadurch der Tweet, der am meisten geliked wurde, war von Jake, von diesen Menschen namens Jake. Also Twittert, welcher Idiot nennt eine Wallen-Netcut? Ja, also ich bin dieser Idiot. Also gut, wie können wir das reparieren? Wir wurden von Intel mit einer Bounty belohnt und auch haben eine CVI-Nambe bekommen. Und falls euch das jetzt so unbequem ist oder so, während des Twitter-Dramas hat uns jemand einen alternativen Namen geschickt, also mit einem Namen und einem Logo, also Neukut, ist jetzt der neue Name. Jedenfalls, ja, wir haben was draus gelernt mit dem Namensschema. Machen wir weiter. Gehen wir wieder zurück zu der Analyse unserer Verhundbarkeit. Kurze Zusammenfassung hier. Erst mal gehe ich auf den Hintergrund ein, Cash-Attacks, DDI, RDMA, die Schlüsseltechnologien, die wir brauchten für unsere Remote-Attack. Dann der Angriff selber, das Reverse-Engineering, zu Ende Angriff und am Ende natürlich die Demo. Cash-Attacks, die versuchen immer versteckten Zustand zu erhalten aus Software heraus, und zwar welche, die eigentlich nicht verfügbar sein sollte. Normalerweise geht es über geteilte Ressourcen. Zum Beispiel geht es über, bei einem Schloss kann man das über Geräusche machen, indem man schaut, wie das Schloss auf verschiedene Inputs reagiert. Bei Cash-Attacks am Computer ist es fast so ein bisschen ähnlich, dass Cash-Attacks funktionieren, so dass die Speicher, der häufig zugegriffen wird, eine kleine Relattance gibt. Auf modernen CPUs gibt es meist diese drei Ebenen von Cash-Attacks, nämlich einmal L1 zwischen Instruktionen und Daten geteilt, und dann L2, was geteilt ist dazwischen. Falls es Daten gibt, die schon in dem Cash drin sind, dann kriegst du es direkt, ansonsten wird es aus dem Hauptschweicher geladen, was ein Cashmistern ist. So wie kriegen wir jetzt mit, dass ein Cash getroffen wird, oder nicht? Weil wir können ja nicht direkt daraus lesen. Nein, wir können das zum Beispiel mit der Prime Probe machen. Das können wir zum Beispiel machen auch über das Netzwerk, zum Beispiel, wie funktioniert Prime in Probe? Also da geht es darum, dass der Cash erstmal in einen bekannten Zustand verfrachtet wird. Dann wartet der Angreifer darauf, dass der Opfer auf den Speicher zugegriffen wird, und diesmal machen wir das Probing wieder und schauen uns die Zugriffszeiten an. Und dann sehen wir, wenn der Cash schnelle Ergebnisse liefert, dann wurde der Cash getroffen, ansonsten wird wohl der Hauptschweicher getroffen worden sein. Das heißt, so kriegen wir mit, was auf was zugegriffen worden ist. Was können wir mit diesen Cash Hits und Misses machen? Wir können sie analysieren, und diese Timing Attacks, diese Timing Analyse können uns ziemlich viel über den Cash Zustand sagen. Nein, damit können wir uns Kryptoschlüsse rausfinden, besucht Webseiten ermitteln oder Speicher liegen. Wie können wir dann so etwas über das Netzwerk machen? Eine Schlüsse-Technologie ist GDIO, dafür müssen wir aber erst mal über DMA reden. DMA erlaubt ein PCI-Gerät, direkt mit dem Hauptspeicher zu interagieren. Zum Beispiel, wenn es ein Paket bekommt, dann kann das PCI-Gerät direkt in den Speicher tun. Und wenn die Anwendung damit was machen möchte, dann kann sie es einfach aus dem Hauptspeicher lesen. Mit DDIO kann das Gerät direkt in den Cash tun. So, dass es nicht mehr durch den Hauptspeicher gehen muss, sondern es kann direkt aus dem letzten Cash gelesen werden. So, DDIO steht für Datendirekte und Input-Output-Technologie. Es ist an auf allen Intel-Servern, Server-Prozessoren. Es ist transparent für Treiber- und Betriebssysteme. Das heißt, die meisten Leute haben wahrscheinlich gar nicht gemerkt, dass sich irgendwas geändert hat. Und das hat was ziemlich Drastisches geändert. Warum ist es überhaupt da wegen Performance? Hier haben wir ein bisschen Diagramm von Intel. Hier sehen wir den Unterschied zwischen verschiedenen Anzeilen der Netzwerkontroller. Und hier sehen wir, da sehen wir, nach vier Netzwerkarten hört es auf zu skalieren, aber mit diesen DDIO funktioniert es auch weiter zu skalieren. Das heißt, es existiert, um Anwendungen besser zu skalieren. Das andere, was wir benutzen, ist Remote-Direct-Memory-Access, RDMA, also entfernten direkten Speichezugriff. RDMA sorgt dafür, dass der Transport-Layer direkt in Hardware passiert, also neben der Kernel. Und hier sehen wir so ein Beispiel. Hier haben wir links den Klein- und rechtses Target. Und hier kann die Anwendung jetzt direkt Netzwerkdaten transferieren, ohne den Kernel zu involvieren. Also TCPIP-Stack wird alles geskippt. Das heißt, wir können beliebige Sachen schreiben auf dem Target remotely. Hier noch ein Quote. Die Target-CPU wird das nicht in die Caches gehen. Das sind Technologien, die werden ziemlich häufig verwendet in den Backends von Server- und Cloud-Infrastrukturen. Also RDMA können ihr euch aus öffentlichen Clouds wie ASHA, Urabe, Oracle holen oder auch Alibaba. SMB und NFS können auch RDMA unterstützen. Andere Applikationen sind hoch verfügbarkeitscomputing, Datacenters und so weiter und so fort. Also schauen wir uns nochmal die Details unserer Forschung an und wie wir diese Technologien jetzt missbraucht haben. Also wir wissen jetzt mittlerweile, dass eine geteilte Ressource durch das Netzwerk freigegeben wird, die DIO und dass wir sowohl read wie auch lesen und schreibt Primitives haben, um darauf zuzugreifen. Aber lassen wir noch was klarstellen hier. Natürlich haben wir viele Experimente getan und das exzensiv getestet, um die inneren Zusammenhänge zu verstehen. Aber doch haben wir hier zwei große Fragen, die wir beantworten müssen. Erstens können wir ein Cache Treffer oder Cache Miss unterscheiden mit Netzwerk, Latents und Paket, Cues und so weiter, Schlangen. Kann man da das Timing überhaupt richtig hinkriegen? Das wäre absolut notwendig für den Side-Channel, für die Side-Kanal-Attacke. Die zweite Frage ist, können wir den ganzen Last-Level-Cache tatsächlich angucken, dass wir auch notwendig. Also die erste Frage, können wir hier mit diesem Experiment beantworten. Wir haben auch hier links ein bisschen ein kleines Code-Stöpsel, eine Lesezugriff. Wir schreiben dann auf diesen Offset und wir schreiben wieder auf den Offset, dass alles mit Side-Stampeln. Was man jetzt sehen kann, ist, wenn man das 50.000-mal macht und bei verschiedenen Offsets, dann kann man ganz klar die zwei Verteilungen unterscheiden. Die blaue ist, wenn die Daten aus dem Hauptspeicher kommen und die Orangen, wenn die Daten aus dem Last-Level-Cache kommen. Man sieht hier auch die Netzwerkeffekte. Zum Beispiel die langen Schwänze von dieser Verteilung, die kommen halt von Paketen, die zu spät angekommen sind, in den Schlangen hängen geblieben sind. Also kurze Seitennotiz. Wir müssen wirklich hier auch reinschreiben in Cache, weil die DIO-Lesezugriffe, die machen mit dem Level-2-Cache nichts, mit dem Last-Level-Cache nichts. Wir müssen wirklich schreiben. Das sind also die Bausteine für unseren Attacker, für unseren Angriff. Aber wir brauchen immer noch das, was wir jetzt wirklich rausholen wollen. Wir brauchen uns die Angriffsoberfläche. Also können wir den ganzen Last-Level-Cache überhaupt sehen? Ist der es sichtbar? Also leider nicht. Die DIO hat eine Beschränkung, dass nur zwei von 20 Cache-Ways verfügbar sind. Die hören nicht nur die DIO, die hören auch der CPU. Aber trotzdem wir haben nur, wir sehen nur 10% der Cache-Activity der CPU im Last-Level-Cache. Das ist irgendwie nicht so toll für, also das hat nicht so richtig gut funktioniert für unseren ersten Attack, aber andere PCI-Geräte, eine zweite Netzwerkarte zum Beispiel, benutzt auch dieselben zwei Cache-Ways. Und damit erreichen wir 100% die Gesichtbarkeit, was andere Geräte auf dem Bus tun. Jetzt schauen wir uns also mal das End-to-End-Szenario an. Wie ich vorhin schon gesagt habe, haben wir jetzt dieses Setup, wo wir ein Client und ein Server haben und dazwischen die Maschine, und eine davon wird von uns kontrolliert. Der Client sendet ein Paket über ganz normales Ethernet in die Netzwerkarte, die zweite Netzwerkarte am Server, welche ist dem Angreifer erlaubt, eine RDMA-Operation zu starten. Wir wissen jetzt auch, dass alle Pakete und also alle Tastaturengaben machen mit dem Last-Level-Cache was. Wie können wir jetzt dann diese Ankunftszeiten der Pakete herausfinden, weil das ist ja das, was uns interessiert. Also, da schauen wir jetzt mal genauer rein, wie so Ankunft von Netzwerkpaketen eigentlich funktioniert. Also, der IP-Stack hat einen Ringpuffer, der ist im Wesentlichen dafür da, damit man Assyngrone-Operation zwischen der Hardware, also der Netzwerkkarte und der CPU machen kann. Also, wenn jetzt ein Paket kommt, dann wird das reingesteckt in die erste Position im Ringpuffer rechts. Auf der rechten Seite seht ihr das, was der Attacker sieht, der Angreifer sieht, die nur die Cash-Aktive, die sich angucken. Der sieht also, dass der Cash-Line bei Position 1 irgendwie aktiv ist. Wir wissen nicht, wo weitere Zugriffe dann hinkommen, aber wichtig ist jetzt, was bei dem zweiten Paket passiert. Der zweiten Paket wird wieder eine Cash-Line getroffen, diesmal eine andere. In diesem Fall ist es einfach die nächste Cash-Line. Und das nächste Paket trifft die nächste Cash-Line und so weiter und so fort. Und jetzt sehen wir, hier trifft sich ein schönes Treppenmuster, das zeichnet sich hier ab. Also, wir haben also ein vorher sagtbares Muster. Das können wir ausnutzen, nochmal Informationen rauszufinden, wann Pakete gekommen sind und wann die empfangen wurden. Und das ist einfach deswegen, weil halt dieser Ringpuffer so vergeben wird, dass er sich nicht selber ständig übertrampelt, sondern dass also das neu antrifffende Paket der nicht Alte überschreiben. Das ist wunderbar für uns als Angreifer, denn das erlaubt es uns, ein Profi zu erstellen. Schauen wir uns das mal jetzt im echten Leben an. Hier sieht man das Muster, wenn der Server ständig Pings empfängt. Da sehen wir, dass der Server auch wieder Positionen wiederverwendet. Hier ist wichtig, dass es hier keinen, hier wäre nicht der Inhalt der Daten gespeichert, sondern bloß die Metadaten. Aber das reicht uns für SSH, weil wenn wir uns diese Delays anschauen, dann können wir uns anschauen, wie der Nutzer tippt und dann kriegen wir so. Es ist eine zwei Stufen Pipeline, der schaut sich ein paar Cashlines an, die er die ganze Zeit beobachten kann. Und wenn er sieht, dann verschiebt er das Fenster, so dass er beim nächsten Mal vielleicht wieder richtig treffen wird. Wir wollen nämlich viel schneller sein als die SSH-Pakete, die auf dem Server ankommt. Und dort links sieht man, was der Online-Tracker macht. Hier gibt es so ein kleines Fenster, was sich der Online-Tracker anschaut. Und dann gibt es da immer so ein kleines Fenster, was noch ein bisschen heller ist. Das sind die tatsächlichen Netzwerk-Pakete. Also man sieht, es ist so ein bisschen Störung auch drin. Wir kriegen nicht genau die Paketzeiten. Und deswegen brauchen wir auch noch eine zweite Stufe. Nämlich den Extractor, der Offline arbeitet. Er versucht die Information, das Online-Tracker auszunutzen, um die Paketzeiten von unterschiedlichen Wörtern zu generieren. Jetzt haben wir das Internet, wo wir das Internet, wo wir das Internet, wo wir das Internet, wo wir das Internet, wo wir das Internet, wo wir das Internet, O sucht, energiert. Jetzt haben wir verschiedene Paket an Kunftszeiten. Aber jetzt wollen wir daraus weiter generieren. Wie ich euch vorher gesagt habe, benutzer oder den Menschen, haben so bestimmte Tipp-Muster. Und eigentlich haben wir da bloß Machine Learning gemacht zwischen den Latenzen beim Tippen und den Wörtern oder den Buchstaben. So, wir haben 20 Leute genommen, die frei und vorgegebenen Text transkript haben. Jede davon haben wir ein Punkt generiert für jedes Wort und dann haben wir quasi einfach bloß ein Canier's Neighbor drauf geworfen. Der Grund, warum wir so einen einfachen Algorithmus benutzt haben, ist, um zu zeigen, dass so ein Remote-Cache-Attacke schon ausreicht, um diesen Angriff zu launchen. So, schauen wir uns das mal genau an, wie gut funktioniert das. Links sehen wir den Klassizierer auf normalen Tastaturdaten, dort sehen wir die Genauigkeit. Und links sehen wir es bei einem lokalen Tastatur, bei einer lokalen Tastatur, was quasi der Best Case ist. Man kriegt genauer Zeiten raus und da haben wir eine Genauigkeit von 40%. Und Top 10 accuracy, da gibt es dann eine 85%ige Genauigkeit, wenn wir sagen, dass einer der Vorschläge in den Top 10 ist. Und wenn wir das jetzt über das Netzwerk machen, dann haben wir 11% weniger Genauigkeit und die Top 10 Genauigkeit ist dann ungefähr 60%. Wir haben jetzt bloß einen einfachen Machine Learning Algorithmus benutzt, da denken wir, das reicht, um zu zeigen, dass es möglich ist, solche Attacke durchzuführen. So, jetzt wollen wir natürlich das ganze Ding sehen. Da ich ein bisschen nervös hier bin auf der Bühne, würde ich das lieber nicht live auf der Bühne machen, sondern ein Video davon zeigen. Daher habe ich ein Video mitgebracht. Hier rechts sieht man den Tastopfer. Der wird gleich eine SSH Session beginnen. Links sehen wir den Angreifer. Dort unten ist der Online Checker und oben ist der Extraktor, der die Wörter hoffentlich erraten wird. SSH Session wird aufgebaut und links ist der Angreifer. Und der fängt jetzt an, der Profiled ist und dann wird der Victorimo Profiled. Es dauert jetzt ein bisschen links, aber das liegt einfach an dem Algorithmus, der ein bisschen braucht. So, und dann seht ihr jetzt gleich links die Wörter auftauchen, die rechts getippt werden. Und wie ihr seht können wir die Wörter tatsächlich erraten, indem wir Netzwerkpakete zum gleichen Server sind. Weil wir die wichtigen Informationen rauskriegen können, wann die SSH Pakete empfangen worden sind. Also jetzt fragt ihr euch vielleicht, wie kann man sich dagegen schützen? Also zum Glück sind, das geht es hier nur um die Server, nicht so sehr um die Clients. Aber aus unserem Standpunkt her ist das einzige, was wir noch machen können, ist entweder die DIO aufzuschalten oder kein RDMA zu benutzen. Beides hat natürlich dann ein Performance Einfluss. Wir sprechen hier von 10 bis 18 Prozent weniger Performance, je nach Applikation. Und wenn man nur das RDMA stellt, dann muss man wahrscheinlich die ganze Applikation neu schreiben. Also Intel, also bei Intel klang das ein bisschen anders, also lest es selber. Hier steht also, man sollte die von, also was unvertraute Netzwerke bedeutet, da kann man darüber diskutieren. Aber ja, also ich war sehr stolz, dass wir akzeptiert wurden am September 2019. Und dass wir hier in der Publikation das Börse bekamen und natürlich auch den Preis. So, also zusammenfassend, also die gesteigerte Performance der Peripherie musste zuführen, dass Intel den Last Level Cash in den schnellen IOP-Fahrt auf den Prozessoren platzieren musste. Und das hat dann microarchitekturelle Bestandteile exponiert. Unsere Vulnerability ist die erste DDIO Seitenkanalattacke. Wir glauben, wir haben nur die Oberfläche hier wirklich angekratzt. Also wir denken, da gibt es Storage-Device, Speicher-Devices, die Cash-Aktivitäten von Speichergeräten. Es gibt sogar so etwas wie eine grafische GPU Redi-Rect, dass die dann den Cash von der CPU benutzen. Aber das ist nochmal eine ganz neue Geschichte. Also wir denken, es gibt hier noch viel mehr zu entdecken. Bleibt dran. Wir können nur sagen vielen, vielen, vielen Dank an euch alle und alle Freiwilligen, die hier bei der Konferenz mitgeholfen haben. Vielen Dank. Vielen Dank Michael. Wir haben noch ein paar Fragen, Zeit für Fragen, stellt euch an eine Mikrofon. Ich sehe jemand bei Mikrofon 7. Vielen Dank für deinen Vortrag. Ich habe eine Frage über die Maschine. Normalerweise tippe ich nicht irgendwelche Wörter mit Dollarzeichen und so weiter. Hast du das ja auch mal angeschaut? Naja, was wir zeigen ist, dass man Passwörter liegen kann. Das Problem mit Passwörtern ist, dass man die nochmal ein bisschen anders tippt. Und dann wird es ein bisschen schwer, weil wenn man dann große Studie macht, wie sie Passwörter tippen, dann fragt man sie entweder nach ihren echten Passwörtern was nicht so ethisch wäre, oder man fragt sie nach anderen Passwörtern, aber dann könnten sie eventuell andere Stile haben, wie sie das Passwort tippen. Und natürlich gilt das gleiche auch für Kommandozeichen. Da hat mir einfach nicht den Wörter-Corpus gehabt. Danke. Nein, gut, Frage von Mikrofon 1. Vielen Dank für den Vortrag. Wie war das mit dem originalen SSH Timing Attack Paper? Das war, glaube ich, 2001 oder so, ja, genau. Was denkst du, da, warum es dagegen nichts gibt, könnte man noch nicht irgendwas machen? Naja, wir haben uns auch, wir hatten auch befürchtet, dass es irgendwie eine Form von Delay gibt oder so, seit 2001, aber es scheint einfach bloß so eine Art Trade-off zwischen der Interaktivität und der Sicherheit zu geben. Aber es ist auch ein bisschen schwer, soweit ich weiß, irgendwelche künstlichen Pakete dazwischen zu tun, sodass, wenn man das zu einfach macht, dann könnte man eventuell einfach rausfiltern. Aber ich weiß nicht genau, warum sie sich das nicht so gerne gepasst haben oder so. Mikrofon 4, bitte. Wie sehr müsst ihr den, wie gut derjenige tippt? Also kommt es darauf an, ob Sie mit zwei Fingern alle Tasten raussuchen oder wie funktioniert das? Na, wir haben, wir haben, wir haben da bloß diesen einfachen Machine Learning Algorithmus drauf geworfen. Also wenn es da keine Korrelationen gibt zwischen alten Wörtern und neuen Wörtern, dann können wir euch keine Garantien mehr über die Genauigkeit machen. Mikrofon Nr. 8, bitte. Dazu noch, ist das nicht eine getagete Angriff, weil man das auf der Person trainieren muss, die man angreifen möchte? Wie gesagt, die Forschung war nicht für Next Level Machine Learning von dem Tipp verhalten, sondern wir haben tatsächlich sogar die Information genutzt, welcher Nutzer getippt hat. Aber was man hier für allgemeinern kann, man kann tatsächlich Benutzer in verschiedenen Kategorien von TIP-Muster unterteilen. Und da konnte man jede Person in eine von sieben Kategorien unterteilen. Und es gibt, glaube ich, auch schon online Checking Tracker, die deinen TIP-Muster benutzen, um die personalisierte Werbung zu zeigen. Aber wir wollten nicht so richtig in die Tiefe davon zu gehen. Und noch eine Frage aus dem Internet. Habt ihr das mal auf einem Netzwerk mit hoher Latents probiert, wie zum Beispiel im Internet? Wir gehen schon so von einem konstanten Latents aus, sonst geht unser Timing Attack nicht. Wir haben es so ein bisschen in Datenzentrum Topologien getestet. Wenn man das anders machen möchte, dann müsste man den Benutzer fragen, das mehrmals zu tippen, aber das ist irgendwie unrealistisch. Mikrofon Nummer 1 bitte. Wenn das Opfer etwas in die SSH-Session pastet, dann könnt ihr das immer noch machen? Nein, dann kann man nichts machen, dann wird es alles auf einmal gesendet, dann gibt es da keine Timing Attack-Möglichkeit. Es gibt noch eine Frage von Mikrofon 6, das ich nicht sehe. Sobald ich das verstehe, kann bloß festgestellt werden, dass irgendein Packet angekommen ist. Das heißt, wenn es eine zweite SSH-Session gäbe, wird das komplett kaputtgehende Angriff. Es gibt schon Probleme mit anderen Netzwerkpaketen, da nutzt man eine Heuristik. Die Heuristik funktioniert so, dass SSH häufig zwei Packete direkt hintereinander sendet. Ich könnte mir vorstellen, dass wenn es eine zweite SSH-Session gäbe, dann könnte es wahrscheinlich komplett kaputtgehen. Danke schön. Mikrofon Nummer 7 bitte. Hier, du hast gesagt, es gibt zwei verschiedene Netzwerkkarten benutzt. Müssen die unterschiedlich sein, können sie die gleiche sein? Wir haben ein Netzwerkkarte benutzt, InfiniBand und das andere war eine ganz normale Netzwerk-Interface-Kontrolle. Wenn das andere auch InfiniBand wäre, wäre das eventuell ein bisschen komplizierter, weil wenn die dann beide das in den RDMA benutzen, dann wäre das ein bisschen problematisch. Ja, hallo. Ich weiß, es ging es nicht wirklich darum hier, aber können Sie sagen, wie praktikabel dieser Timing-Attacke wirklich ist? Wenn wir jetzt wirklich mal eine echte Simulation machen, würde nicht so unter Konträten umstellen. Also, was ist das State of the Art? Wo stehen wir da? Es geht um die Timing-Attacke, nicht um den Tech-Hash. Die ursprüngliche Forschung, die wir 2011 gemacht haben, seit dann haben viele Forscher gezeigt, dass es das Typing-Attacks möglich sind, dass man die auch von JavaScript aufrufen kann. Es ist schwer zu sagen, die meisten Forscher haben unterschiedliche Datensätze, also man kann die nicht so direkt vergleichen. Aber generell, wir haben einen großen Wort-Corpus verwendet, aber trotzdem hat es funktioniert, nicht superpräzise, aber es hat schon funktioniert. Also, ich glaube, das ist möglich. Aber um jetzt eine echte Attacke daraus zu machen, mit hoher Verlässlichkeit, da bräuchte man eine Menge Daten und weiterentwickelte Techniken, die es gibt, es gibt da weitere Maschinen-Lernen-Antätze, die da funktionieren mit verschiedenen Vorteilen. Ja, meine Damen und Herren, hier ist der Mann, der den Net-Catch gefunden hat.