 Sehr oft waren in diesem Raum wunderschöne Vorträge und wir wollen uns auch von den Übersetzern willkommen heißen und der Vortragende hat gerade seinen Bachelor fertig gemacht hat über die Sicherheit für WPA, TLS und RC4 gemacht und der macht den Postdoc und schaut sich dort insbesondere die kabelose Sicherheit an und der Vortrag ist jetzt wie man WPA 200, 802, 2.11 Gruppenschlüssel vermuten kann. Eine große Runde Applaus. Okay, danke für den schönen Einführung. Ja, ich bin wirklich Vanif und ich möchte zeigen wie man Gruppenschlüssel erräht und missbraucht. So, da sind fall 802,11 Gruppenschlüssel. So, eine kleine Grundlage zur Wenern-Sicherheit. Was ist die Grundlage für Wenern-Sicherheit, bevor ich diese Forschung betrieben habe? Wenern-Sicherheit war früh angeschaut. Es gab viele Ergebnisse. Zum Beispiel wissen wir, dass die allererste Sicherheitsalgorithmus Wireless Equivalenz Privatsphäre, auch bekannt als Web, sehr viele Probleme hatte. Wahrscheinlich kennt ihr das alle, dass man ein WEP-Netzwerk innerhalb von wenigen Minuten knacken kann. Und wenn sie den neuesten Werkzeuge von Aircrack-NG runterladen, dann ausreichend Traffic auf dem Netzwerk ist, können sie den scheiten Schlüssel innerhalb von wenigen Minuten Haus finden. Manchmal, wenn sie Glück haben, sogar Sekunden. Der erste Angriff, Versuch von der 802-Gruppe ein Sicherheitsprotokoll zu machen, hat nicht so gut funktioniert. Wir haben auch andere Angriffe gegen den kabellose Netzwerke, insbesondere gegen WPA2. Ein Beispiel hierfür, das vor Kurzem herauskam, ist, dass einige Verkäufer und der Internet-Service-Provider, wenn sie ihre Router verteilen, einen initialen Passwort darauf speichern und anscheinend sind sie relativ gut zu raten. Insbesondere diese Standard-Passwort, welches sie hier irgendwo auf der Rückseite des Routers oder auf der Karte, die sie damit bekommen haben, wurde von der MAC-Adresse abgeleitet. So dass, wenn Sie diese Netzwerke eingreifen wollen, müssen Sie einfach das Netzwerk sniffen, die MAC-Adresse herausfinden und davon können Sie den Schlüssel des Netzwerkes herausfinden. Außerdem hören Sie Dictionary, also Wörterbücherangriffe. Es sind alles bekannte Angriffe und wie das funktioniert, ist, dass man einen Kleint dazu bringen kann, sich die Verbindung abzubrechen. Wenn es sich wieder verbindet, macht das einen neuen Handshake mit dem Zugangsknoten, um die neuen Session-Schlüssel auszutauschen. Und das Problem von diesem Key ist, dass man die vier Nachrichten speichern kann, die dort abgesendet werden. Und dann kann man offline daran raten, welches Passwort dort verwendet wird. Und wenn das Handshake besser designt wäre, dann wären solche Angriffe nicht möglich. Und leider war der Angriff auf diese Art und Weise designt und das kann dann offline ausprobiert werden. Also diese Angriffe sind leider möglich. Vor ein paar Jahren war auch ein Angriff, der gezeigt hat, dass ein bisschen soziales Engineering sogar WPE2-Enterprise-Netzwerke angriffbar sind. Da muss man einen Benutzernnahme und einen Passwort angreifen, also zum Beispiel Adorama oder Firmenetzwerke oder hier auch beim CCC-Netzwerk, dann sind auch diese Enterprise-Netzwerke. Und die Idee dahinter, ich werde jetzt noch nicht detailliert anschauen, der Methoden, die Sie benutzen, man sendet einen Netzwerk mit derselben SSID-Name und macht da einen Leerzeichen dahinter. Und wenn man jetzt den Netzwerknamen in dem Betriebssystem sich anschaut, dann sieht man nicht, dass das Netzwerk Iterome Leerzeichen ist. Also anscheinend ist ein komplett neues Netzwerk und wenn man mit einem komplett neuen Netzwerk sich verbindet, dann fragt das Betriebssystem, dann ist das okay für das Betriebssystem. Normalerweise sagt man, hey, normalerweise Iterome, jetzt benutzen wir auf einmal ein anderes Zertifikat, das ist ein Problem. Aber weil da in der Zeichen danach ist, nach dem SSID, denn wenn wir das Betriebssystem denken, oh, das ist ein neues Betriebssystem, alles in Ordnung. Okay, ich werde jetzt nicht in die Details darüber gehen. Ich sage es einfach nur, dass es das gibt. Vor kurzem waren auch ein paar theoretischerer Angriffe gegen WPA, TK, KIP. Das sind ähnliche Angriffe auf WEP, nur dass WPA deutlich schwieriger anzugreifen sind. Obwohl es andere Angriffmöglichkeiten gibt, also einfach nicht benutzen die ZTK, HIP-Erweiterung. Also es gibt Möglichkeiten, da durch die Zeichenschüssel heranzubekommen, wo die nur schwer anzuwenden sind. Wenn man alle diese vorherigen Arbeiten sich über die Sicherheit über ein Netzwerk anschaut, sieht man, dass es dort um die Sicherheit der vorher geteilten Schlüssel oder den ausgehandelten Zeichenschüsseln. Das hat sehr viel Forschung in dem Bereich gegeben. Sowohl Hecker haben sich das angeschaut, aber die Schlüssel für die Broadcast-Traffic, diese Gruppenschlüssel, die werden größtens nicht genau angeschaut. Ein bisschen komisch ist mit den Folien. Aus irgendeinem Grund fehlt eine Folie. Also diese Gruppenschlüssel werden benutzt, um Broadcast und Multicast-Nachrichten zu verschlüsseln. Das ist nicht Zusammenarbeit mit den Zeichenschüsseln. Man hat einen Access-Point, der hat einen Gruppenschüssel und einen Zeichenschüssel. Für jede Schlüssel, der mit dem Netzwerk verbunden ist. Und was wir merken ist, dass die Sicherheit von diesen aus vermuteten Zeichenschüsseln ist gut, aber die Sicherheit von diesem Gruppenschüssel hat sich noch niemand wirklich angeschaut. Und was ich gemacht habe, ist, ich habe mir angeschaut, wie diese Gruppenschlüssel erstellt werden während der gesamten Lebenszeit. Okay, was meine ich jetzt mit der Lebenszeit eines Gruppenschlüssel? Wir haben einen Zugangspunkt, einen Access-Point. Wenn Sie Ihren Access-Point starten und Sie in Router starten, dann erstellt ja zuallererst einen zufälligen neuen Gruppenschlüssel. Und hier merken wir, dass der Zufallszahlen-Generator, der RANDOM DELLOUT benutzt wird, um diesen Gruppenschlüssel zu erstellen, Probleme hat. Der Standard empfiehlt einen schlechten Zufallszahlen-Generator in der Standardimplementation und in einige Implementaren, also Implementaren benutzen auch einen Zufallszahlen-Generator, der ratbar ist. Und das ist der erste Angriff, also das ist der erste Punkt in diesem Lebenszyklus eines Gruppenschlüssel. Das zweite Punkt ist, wenn ein Klient mit dem Netzwerk sich verbindet, dann wird ein vierweiger Handshake erstellt. Dann werden die Session-Schlüssel erstellt, oder Paralyzed-Schlüssel. Und während dieses Handshakes wird dieser Gruppenschlüssel auch zum Kleinen übertragen, weil der natürlich den Gruppenschlüssel braucht, um die Broadcast und Multicast-Sendungen zu empfangen. Und was wir hier gefunden haben, ist, dass wir diesen Handshake manipulieren können als Angreifer, als meldende Mittel-Angreifer. Dann können wir eine RC4-Benutzung erfordern, so dass dann der Schlüssel mit RC4 verschlüsselt wird und RC4 ist eine unsichere Verschlüsselungsmethode und man sollte es nicht benutzen. Und okay, aktuell ist es nur theoretisch, aber wir können RC4 in diesem Situation angreifen. Ein der interessanteren Punkte ist, dass, wenn wir als Angreifer diesen Gruppenschlüssel haben, ja, was können wir dann mit diesem Gruppenschlüssel tun? Wenn wir diesen Schlüssel kennen, können wir Broadcast und Multicast-Pakete empfangen und einfügen, aber können wir vielleicht sogar mehr machen. Und ich werde zeigen, dass man ein paar cleveren Tricks, Unicast-IP-Traffic hinzufügen, also zusätzlich senden. Und wir werden auch zeigen, wie man fast allen Internetverkehr über dieses Netzwerk entschlüsselt. Und der letzte Teil dieser Präsentation ist, wie man das besser machen könnte. Wie man zufallszahlen besser generieren kann, wenn man entweder ein Gerät hat. Der Hauptteil der Präsentation sind diese ersten drei Schritte. Und dann kann man das ausnüsten, um den Verkehr zu entschlüsseln. Bevor ich jetzt zum Hauptteil meiner Präsentation komme, gebe ich noch einmal etwas Hintergrund, wie denn diese Gruppenschlüssel benutzt werden. Nehmen wir also mal an, wir sind in der folgenden Präsentation. Wir haben hier einen Access Point, der hat den Group Key vom Netzwerk. Er hat zwei Sitzungsschlüssel von den verbundenen Clients. Nehmen wir an, in dieser Situation will der Client A ein Broadcast über das ganze Netzwerk schieten. Wenn jetzt der Client A diesen Broadcast frame selbst schicken würde, dann gäbe es ein Problem. In manchen Situationen sind Client gegenseitig nicht erreichbar. Also der Client B will in diesem Fall nicht den Broadcast nicht erhalten, weil was zwischen ist. Das Protokoll umgeht das folgendermaßen. So ein Broadcast frame wird also zuerst an den Access Point geschickt. Und der Access Point ist zunächst einmal der direkte Empfänger, aber der endgültige Empfänger ist die Broadcast Adresse. Und der Access Point verschüsselt das mit dem Gruppen Key und verwendet den Access Point um das zu verschüsseln und den Gruppen Key um das zu endschüsseln. Denn die endgültige Adresse ist ja der Client, die Broadcast Adresse. Alle Clients sind natürlich in der Reichweite des Access Points. Wenn nun also der Access Point den Broadcast Frame weiter schickt, dann wird der Gruppenschüssel verwendet um den Frame zu verschüsseln. Das Wichtige dabei ist, dass nur der Access Point wirkliche Group Frames schickt. Denn der Client gibt es zunächst einmal an den Access Point, bevor es von dort weiter geleitet wird. Das war die kurze Einführung. Nun geht es also um die Vorhersage von R&G und die Entschlusselung des Verkehrs. Also wie würde man random den Verzufassungs-Generator brechen? Der Wifi-Standard gibt so ein paar Methoden vor, um den Gruppenschüssel zu erzeugen. Ja, also eine Methode wird empfohlen. Es gibt eine spezielle Methode, um diese Gruppenschüssel zu erzeugen. Die Kryptoleute nennen das eine Schüsselherarchie, die hier verwendet wird. Es ist ziemlich straight, einfach. Wenn der Access Point startet, dann wird der einen öffentlichen Wert erzeugen. Man muss nicht unbedingt bei null anfangen, also dieser Counter fängt irgendwo an. Und jeder außen darf diesen Counter auslesen. Zweitens wird ein privater Master-Schüssel erzeugt. Der muss dann geheim bleiben, weil sonst sind alle Sicherheitsschüssel entschlüsselbar. Nachdem das also geschehen ist, kann man jetzt ein Hash nehmen von beiden. Und der Output des Hashes ist jetzt der momentane Group Key. Der heißt auch temporäre Gruppenschüssel. Deswegen, weil er einfach jede Stunde, alle zehn Minuten oder auch jeden Tag erneuert werden kann. Der Vorteil dieser Konstruktion ist es, dass man sehr einfach ein Gruppenschüssel erzeugen kann. Ein erneuerter kann man erzeugen, indem man den Counter im Eins erhöht, den neuen Hash berechnet und dann hat man einen neuen Gruppenschüssel. Das schaut einem schönen und simplen Design aus. Neuer Gruppenschüssel ist einfach Counter erhöhen und dann neuen Hash berechnen. Dummerweise ist dieses Design ziemlich schlecht. Warum? Das liegt daran, dass diese zwei Werte nur dann wirklich zufällig sind zum Zeitpunkt des Startens von Systemen. Wenn ein Angreifer irgendwie diesen Schüssel erfährt, dann kann er alle zukünftigen Keys erfahren. Außerdem, wenn wir wissen, dass der Render Neutering schlecht ist, dann können wir alle zukünftigen Keys auch erfahren. Das ist ein schlechtes Design. Das sollte vermieten. Dummerweise ist das eben offiziell spezifiziert im Standard. Und es wird tatsächlich empfohlen, eben diese Prozedur zu verwenden. Jetzt nehmen wir mal an, dass wir diese beiden Werte, wenn wir die vorher sagen können, können wir auch den Gruppenschüssel vorher sagen. Wie werden also diese Zufallszahlen generiert? Ja, hier gibt es wieder eine Antwort im Standard, vom WIFI Standard. Der Vorschlag für einen Render Number 10, für einen Zufallszahlengenerator ist es, wenn man sich das anguckt, dann klingt es eigentlich recht vielversprechend. Der Beispielgenerator, so heißt es, erzeugt kriptografische Zufälligkeit. Und hier ein Zitat, eine Station muss in der Lage sein, eine kriptografische Zufallszahlen zu erzeugen. Siehe Appendix M5, da steht dann, wie das geht. Klingt super. Aber nur so lange, bis man dann wirklich in den Appendix geht und dann da reinguckt, und da steht ... Moment mal, also wir zeigen euch hier bloß so ein Beispiel, Zufallszahlengenerator, und du solltest besser deinen eigenen Generator implementieren. Das ist natürlich irgendwie ein bisschen komisch, weil der Standard sagt, der Appendix ist total sicher, aber wenn du dann Appendix analysst, dann sagt er nur, dass es hier bloß ein Beispiel code ist, vielleicht gar nicht so sicher, wie du das vorstellst. Also das ist in Konsistenz, ein Inkonsistent im Standard. Und dann gehen wir jetzt mal nochmal zurück hier in den Appendix. Da steht also, dass man wahrscheinlich komponieren sollte diese Empfehlung mit anderen Empfehlungen um ... und dann kann man das verbessern. Und es ist sehr komisch, solche Sprache in einem Standard zu sehen. Also wir haben jetzt eine nicht klare Beschreibung. Hier steht, es sollte sicher sein, und hier unten steht, ist es nicht wirklich sicher. Und jetzt müssen wir uns fragen, wie sicher ist dieser Zufallszahlengenerator wirklich? Und zweitens, wie viele Plattformen implementieren diesen? Lass uns jetzt mal anschauen, wie genau das Zufallszahlengenerator implementiert ist. Und hier sehen wir, dass der Standard eine Funktion definiert. Das ist der Zufallszahlengenerator. Und zuallererst ist eine selbe Funktion. Jetzt werde ich gleich darüber ruckkommen, da haben Sie eine schlicht Idee. Und da hat eine sehr wahre Beschreibung. Selbst wenn es nur ein Beispiel-Lösung ist, um Leute dabei zu helfen, loszulegen. Wenn man den Code anschaut, ist dort ein Hauptschleifer. Und die sagt, macht das, bis es ausreichend zufällig ist. Sie spezifizieren nicht, was das bedeutet. Das ist sehr komisch für ein Standard. Auch so ein bisschen komisch ist das am Ende der Schleifer. In manchen Teilen des Loops, wenn die Zeit nicht verfügbar ist, sagt einfach Null. Dies Zeile könnte nicht so schlecht sein, wenn Sie dort sagen, wenn Sie die Zeit zu Null schreiben, dritten Sie vielleicht mehr Interaktion, das Hauptschleifer machen. Aber wenn es nicht möglich ist, dann einfach überspringen. Also, wie ich schon gesagt habe, der Standard ist so ein bisschen schwer zu verstehen, weil Sie sagen, dass ein Beispiel-Infinition, oder wenn andere Teilen sagen, Sie, es sollte gut sein. Aber selbst wenn Sie nur meinten, dass das ein Beispiel für die Verkäufer ist, ist diese Beschreibung einfach nur zu ungenau, um nochmal zu diesem zurückzukommen. Der Zufall-Zahlen-Generator läuft nur, wenn es notwendig ist. Und nur während dieser Funktion läuft, wird Zufall gesammelt. Das ist auch wieder ein komisches Design. Wenn man einen guten Zufall-Zahlen-Generator hat, zum Beispiel den OpenBSD, oder den Linux, oder der in irgendeinem normalen Design, wird die ganze Zeit Zufall gesammelt. Zum Beispiel Interrupt Timing oder Packet Timing oder Veränderungen von Uhren. Und diese gesamte Sammlung, Zufalls, wird in einem Entropy Pool gesammelt. Und wenn dann eine Zufall-Zahl benutzt wird, wird aus diesem Entropy Pool eine Zahl herausgesucht, zum Beispiel durch einen Hash-Wert. Also, dass diese nur auf Befehl durchgeführt wird, ist ein schlechtes Design. Und wenn wir uns jetzt durch die wirklichen Events anschauen, wo Zufall herausgesucht wird, ist es hauptsächlich der Timestamp, wo Frames ankommen und die Zeitunterschiede. Und lassen Sie diese Designs mal ein bisschen näher anschauen, die Frames-Ankunftszeiten, zum Beispiel bei einem Internet-Cable. Und wenn dort viel Traffic drüber geht, kann man diese Zahl nur durch Internet-Traffic herausfinden. Aber es gibt keine Quarantie, dass ausreichend Traffic vorhanden ist. Und der Stand hat, das haben das mitgekommen und hat darüber geredet, vielleicht sind nicht so viel Traffic. Und was Sie gesagt haben, wenn da kein, wenn nicht ausreichend Traffic ist, dann wartet, bis ein Klein versucht wird, sich zu verbinden. Dann macht ein paar Mal ein Handshake, bis man ausreichend Frames oder Pakete bekommen hat. Also das ist zuallererst sehr langsam und zweitens ein Wetteresproblem ist, wenn man ein Klein ist und man versucht die ganze Zeit mit einem Handshake zu verbinden und es fehlt einfach ein paar Mal, dann wird das Gerät einfach sagen, hey, dieser exes Point ist kaputt und es wird auch nicht mehr funktionieren. Die Idee, die sie haben, ist in meiner Meinung nach absurd. Der zweite Quelle ist die Zeit. Also wenn Sie eine Zeit, eine Uhr, eine Clock implementiert haben, dann ist es immer eine kleine Abweichung, die man nicht als Angreifer erwarten kann. Aber das Problem ist, dass Sie nicht spezifizieren, welche Mindestresolution diese Uhr haben muss. Das heißt, ein Verkäufer könnte einfach eine sehr kleine Resolution halten, nur sehr wenig Intrepiti sammelt. Also nachdem ich das gesehen habe, dachte ich, naja, das ist nur eine grundlegende, ein großes Fehler des Standardisierungs und alle Leute haben das mitbekommen und haben etwas anderes implementiert. Etwas Besseres. Aber wenn ich das mir wirklich angeschaut habe, die ganzen Feldcode, dann ist das wirklich was Sie machen. Keine Ahnung, was Sie tun. Wenn man jetzt die Verkäufer, zum Beispiel MediaTag, es wurde auch mal Railing genannt, dann haben Sie genau diesen Zufallszahlen-Generator implementiert. Genau wie spezifiziert mit ein paar Änderungen und diese Änderungen zu machen, ist noch schlimmer, war es noch schwächer. Sie haben auch eine gute Entscheidung getroffen, da will ich gleich darüber reden. Dann ist da Broadcom der Zufallszahlen-Generator, die Sie benutzen, ist abhängig von dem Betriebssystem, das benutzt wird. Dann ist da noch OpenFirmware. Das ist ein gutes Beispiel für ein embedded device. Die benutzen eine Band-Version von Linux und die benutzen es ordentlich mit DevRandom. Wir haben kurz geraten, welche Implementationen Broadcom benutzen. Wir sind nur einfach durch die Stadt gefahren, haben geschaut, was für Oldspots da sind. Wir haben geschaut, ob MediaTag oder Broadcom benutzt wird anhand des Fingerabbruchs des Beacons. In einem anderen Paper wird das beschrieben. Ich habe ein sehr grobeln Stresswert gesammelt, dass vielleicht maximal 25% der Netzwerke eingriffen werden können. 5 oder 10% könnten mit ähnlichen Angriffen angriffen werden. Dieses sind sehr häufige Netzwerke und das könnten Sie vielleicht sogar in der Praxis benutzen. Zuerst, dass uns die erste Implementation von MediaTag näher anschauen. Was haben Sie gemacht? Zuerst haben Sie den Schüssel der Archie, den Schüssel-Generation so implementiert, wie der Standort das vorsteigt. Beispiel, das ist diese Konstruktion. Wir haben zwei Variablen. Eine, die geheim ist, und die andere, die öffentlich sein kann. Dann wird ein Hash gemacht und da wird der Output benutzt. Sie verbessern das ein kleines bisschen. Sie machen etwas, das gut ist. Wenn Sie einen neuen Gruppenschüssel generieren, anstelle davon den Counter um 1 zu erhöhen, erstellen Sie einen komplett neuen Zufallzahl für den Counter. Das ist eine sehr gute Idee, als Sie einen neuen Zufall hinzufügen, immer wenn ein neuer Gruppenschüssel generiert wird. Aber der Gruppenschüssel wird nur beim Boot gesammelt oder erstellt. Wir wissen jetzt, wie diese Konstruktion funktioniert und jetzt ist die Frage, wie implementieren Sie diesen Zufallzahlengenerator und können wir darauf hin ein Anger fahren. Da ist jetzt der schlechte Teil Ihres Angriffes. Sie haben nur Clock Jitter, um Zufallzahlen zu generieren. Insbesondere benutzen Sie den Jiffys Counter des Linux Kernels. Der R-Jiffy Counter ist etwas, das jeden Tick erstellt wird, nicht jeden Prozessor-Tick, aber jeder logische Tick. Dazu komme ich später an. Dieser Zufallzahlengenerator ist relativ schlecht und das ist gut für uns, zumindest für uns als Angreifer, weil wir nur den Gruppemasterschlüssel erörten müssen und diesen Zufallzahlengenerator, oder die Gruppenanz. Wenn wir die beiden erraten können, können wir den Gruppenschüssel erraten. Lassen Sie diesen Zufallzahlengenerator angreifen. Er benutzt diesen Jiffys als Zeller und das Problem, diese Jiffys sind besten Fall Millisekundenzeiten und das ist ziemlich niedrig. Das ist sehr niedrig. Das bedeutet, praktisch ist dieser GM Key, der beim Boot generiert wird, normalerweise immer dasselbe Werte und zumindest sehr ähnliche. Also praktisch ist der GMK 200, vielleicht 300 mögliche Werte. Also zumindest wenn Sie ein... Ich habe das bei meinen Geräten auch ausprobiert und für ein spezielles Gerät, für eine spezielle Firmware-Version, dann hat man einen sehr geringen Anzahl von Möglichkeiten. Natürlich, wenn Sie eine andere Firmware-Version laufen, haben wir Ihnen dann, könnten ein paar andere Sachen bei einem Bootprozess funktionieren, die diese Zeit, wo dieses Wert gesammelt wird. Aber wenn Sie die Implementation, die Sie angreifen, kennen, dann haben Sie sehr wenige möglichen Werte. Zweite ist, man muss diese Genance-Value erraten. In den meisten Routern ist der Gruppen-Schüssel jede Stunde erneut generiert. Das heißt, die Genance-Value wird auch jeden Wert erneut generiert. Das heißt, wir müssen die Abtime, das Routers, erraten, um die Jiffys-Values zu reduzieren. Und wie kriegen wir die Abtime des Routers heraus? Die Abtime ist im Beacon des meisten, fast all der Routers, veröffentlicht. Das heißt, wir müssen nur die Beacons abfragen und dann können wir die Abtime des Routers erraten und dann können wir die Zeit, wo dieses Genance erstellt wurde, erraten. Um einen erfolgreichen Angriff durchführen zu können, müssen wir einen verschüsselten Broadcast oder Multicast-Aktresser haben. Wir müssen außerdem ein paar Beacons haben für die Abtime und dann können wir eine Suche durch alle durch den ganzen Schüssel-Space machen. Und wir haben das gegen unsere eigenen Router durchgeführt, das ist dieser. Und hier haben wir bemerkt, wir haben das ein Programm implementiert, der auf der GPU läuft, auf dem CL um hinzukriegen, dass es effizient funktioniert. Wir haben gemerkt, dass die GPU in meinem Laptop, das ist ein ganz normales Standard-GPU. Sie können deutlich bessere haben oder mehrere. Sogar auf meinem Laptop habe ich die Schüsse innerhalb drei bis vier Minuten gekriegt. Ja, danke schön. Also da gehen wir jetzt davon aus, dass der Router ein Jahr lang an war. Und wenn der Router ein Jahr lang an war, dann gibt es eine Menge Clock-Drift. Wenn ich jetzt also in ein paar Minuten diesen Attack, diesen Angriff zeige, dann wird die Zeit, wird jetzt noch schneller klacken können, weil es weniger Clock-Drift gab, seitdem ich das letzte mal gemacht habe. Das ist also ein Worst-Case-S-Schätzung. Wenn man ein ganz spezielles Device angreift, wenn man die Flamme nicht kennt, dann hat man einen größeren Schüsselraum, den man durchsuchen muss. Am Ende hat man sowohl den Master Key wie auch den Schüssel, wie ein Gruppenschüssel. So, jetzt habe ich hier eine Demo geplant. Demos mit Wi-Fi sind immer risikoreich, vor allem in Situationen wie diese. Drücken Sie bitte die Daumen. Also schauen wir erst mal, ob bei den Bildschirmen irgendwie ... Okay, gut, das haben wir jetzt auf dem Bildschirm. Ich habe es hier, also ein Wi-Fi-Device, was im Monitor Mode läuft. Und ich habe einen Skript, was alle Frames mitschneidet, die der Router schickt. Ich habe das jetzt schon in den Monitor Mode mal geschaltet. Und jetzt werde ich mir Pakete mitschneiden, die vom Router kommen. Ich habe es ein kleines Python-Skript geschrieben, was das macht. Das führen wir jetzt mal aus und schneiden mal Pakete mit. So, ihr könnt sehen, also, es werden hier Pakete mitgeschüttet, aber es wird nichts empfangen. Der Router ist noch gar nicht an. Also schalten wir mal den Router an. Das haben wir natürlich jetzt so gemacht, aber um das wirklich zu demonstrieren, dass es echt ist, zwar Absicht. Jetzt putet der Router in ein paar Sekunden, schickt dann die Beacons und davon können wir die Abtime des Routers halt rausholen. Jetzt wartet es auf das erste verschlüsselte Paket. Eine Grenze des Angriffs ist es. Ah, okay. Wir haben so lange gewartet, bis der Laptop sich connectet hat. So lange niemand verbunden ist, gibt es natürlich keinen Traffic. Also erst, wenn es einen kleinen Gip oder wenn der Router einen Broadcast-Främie raus schickt mit dem Broadcast, der im Broadcast-Key verschlüsselt ist, dann gibt es nichts zu entschütteln und gibt es keine Daten. So, jetzt haben wir also einen Frame mitgeschnitten. Dann schauen wir uns das Capture-File mal an. Wie ihr seht, gibt es also eine Menge Beacon-Frames, die mitgeschnitten wurden. Da gibt es ein Feld, das heißt Time Stamp. Und ja, davon, daraus können wir die Abtime erraten. Es ist also sehr, sehr nah bei Null und jedes Mal, wenn es halt sich erhöht, dann können wir daraus die Abtime des Routes erraten. Am Ende des Captures gibt es dann das Broadcast-Paket und das es uns geht, dass wir dann auch gerne entschlüsseln wollen. Wie ich schon gesagt habe, das läuft auf der GPU. Gut, das muss ich also erst mal die GPU entablen, anschalten. Jetzt werde ich also die MediaTek-Implementierung angreifen und mit dem Capture, den ich gerade durchgeführt habe. Jetzt wird das File durchsucht und geparsed. Schaut sich alle Netzwerke an, die wir hatten. Ich hatte das schon so eingestellt, dass ich nur mein eigenes Netzwerk Capture und nicht alle anderen Netzwerke, die hier so umfliegen. Und wie ihr seht, versucht es jetzt, den Group Master Key vorherzusagen. Und es weiß, dass die... Ja, also die wurden geschätzt auf diese Werte. Jetzt fragt man sich, warum sind die GIFIs denn so hoch? Fangen die nicht bei null an. Das ist ganz interessant, meiner Meinung nach. Denn die Linux Kernel startet bei minus 5 Minuten, was die GIFIs angeht. Warum machte das? Weil, wenn man also irgendwie ein Entwickler ist und ein Bug eingebaut hat, wenn der Counter auf null überläuft, dann werde ich sehr schnell diesen Bug entdecken. Das erklärt, warum die Zahl so hoch ist, obwohl wir genau das angestellt haben. So, jetzt seht ihr also, dass wir den Group Key erfolgreich gefunden haben und das Paket tatsächlich sogar entschlüsselt wurde. Das hat also funktioniert. Es hat auch das entschlüsselte Paket in ein Pfeil geschrieben. Schauen wir uns das mal an, damit wir auch den Beweis haben, dass es funktioniert hat. So, und hier kann man also sehen, das entschlüsselte Paket, das war ein ARP-Paket. Und man sieht, dass das tatsächlich korrekt vorhergesagt wurde, der Group Key, um dann dieses Paket zu entschlüsseln. Applaus. Okay, jetzt wieder zur Präsentation. Okay. Schauen wir mal diese Folien. Okay. Das war die Demo. Demo-Rots. Vielen Dank, dass es funktioniert hat. So, doch mal zurück zu den anderen Herstellern. Broadcom. Es ist abhängig von Betriebssystemen, das Sie benutzen. Besonders, wenn Sie Linux benutzen, dann implementieren Sie die Gruppenschüsse, die Hierarchie genauso wie im Standard spezifiziert, aber Sie holen einfach Zufall von slash-dev-slash-urandom. Das ist sehr viel besser, als die Zufallzahlen, Generatoren, die im Standard vorgeschlagen werden. Aber vor ein paar Jahren, bei einem Paper, über Peace und Cure und Sie zeigen, dass insbesondere bei Embedded-Geräten und auf ältere Linux-Körnel Steffiurendom erratbar ist. Das heißt, in besonderen Geräten ist Steffiurendom erratbar und damit könnten alle Gruppenschüsse geraten werden. Aber wenn Sie einen neuen Linux-Körnel benutzen, sollte das nicht mehr ein Problem sein. Ich habe das jetzt nicht näher ausprobiert, aber in deren Paper meinen Sie, dass Steffiurendom nicht optimal ist für ältere Kernel-Implementationen. Diese Implementation läuft auch auf WXWorks und WXCos. Für die Leute, die diese Betriebssysteme nicht kennen, WXWorks und WXCos sind beide Echtzeit-Betriebssysteme. WXWorks ist eine sehr, echte Zeit-Betriebssysteme. WXWorks ist proprietär, es wird in Airspace benutzt, z.B. beim Marsland oder SpaceX. Es wird aber auch in Drohnen verwendet und natürlich in einigen Routern bzw. Zug-Exas-Points. Dann gibt es noch E-Cos, das ähnliche, das ist auch ein Echtzeit-Betriebssystem, weil man das nicht benutzt und mit der Air in militär-Situation. Aber wir fokussieren darauf, dass es im Router funktioniert oder als Zugang exas-Bount. Wir sehen, dass in diesem Fall Broadcom wieder den Standardgruppen-Schöße implementiert und vor Zufall-Zahlen-Werden nimmt das einfach den MD5-Fesh der aktuellen Zeit in Mikrosekunden. Das ist kein guter Zufall, überhaupt kein guter Zufall. Es ist noch ein weiterer Nachteil von ihrer Implementation. Sie benutzen diesen öffentlichen Counter im Handshake, in dem Vierweg Handshake, mit dem Sie mit dem Netzwerk verbinden. Das ist okay, das ist nichts falsch damit. Aber es macht es deutlich einfacher für uns als Angreifer, weil wir den Wert, der hier im Handshake benutzt wird und der im Gruppenschüssel wird nur ein bisschen davon weg sein. Das einzige, was wir erraten müssen, ist der Gruppen-Master-Schüssel. Wenn Sie den Gruppen-Master-Schüssel haben, dann können wir wieder den Gruppen-Schüssel erraten. Ein üblicher Router, der mit Problemen hat, ist der WRT54GV5. Nur mit V5 oder höher, weil dann der JS-Works-Counter beunzt wird. Wenn Sie einen Version 4 oder niedriger haben, dann läuft der Linux. Wenn Sie die DWRT darauf laufen lassen, dann ist das natürlich kein Problem. Aber wenn Sie Version 5 von diesem Gerät oder höher haben, dann könnten Sie damit ein Problem haben. Ungerechtlicherweise hatte ich nur eine ältere Version von diesem Router zu Hause, also habe ich diesen Angriff simuliert. Wieder mit OPCL und sogar mit sehr geringen Vermutungen. Vermute ich, dass es 4 bis 5 Minuten auf meiner GPU benutzt wird, um diesen Schüssel zu brechen. Und sollte jetzt meine Simulation nicht perfekt sein, dann können Sie einen stärkeren GPU benutzen und können es Ihnen mal noch in dieser Zeit herausfinden. Der MD5 der aktuellen Zeit in Microsekunden, das ist nicht ausreichend zu tun. Das sind diese beiden Implementationen und dann haben wir noch zwei andere Beispiele. Der erste ist OpenFirmware und der zweite ist Host-APD. OpenFirmware ist im Endeffekt ein einfaches BIOS-System und was wirklich überraschend war, war, dass während des BIOS-Systems sehr geringe Wi-Fi-Zuggerigkeit haben. Auch als Kleint. Sie können sich aber mit einem WPA2-Netzwerk verbinden. Das wäre sehr überraschend, dass ein BIOS-Wähner unterstützt, aber sie unterstützen es. Ich muss jetzt sagen, dass sie nur die kleinen Funktionalität implementieren und keine Access-Point-Funktionalität haben. Also generisieren sie keinen Schlüssel, aber sie benutzen einen Zufallzeigengenerator um andere Werte zu benutzen und für weder ein Handshake und zu anderen benutzen sie sehr einfache Methodologie. Sie nehmen die Menge von Text, der funktioniert ist, machen einen Lineargenerator, eine terministische Funktion und das wird als Zufallzeigengenerator benutzt. Und dieser Wert wird gehasht um einen ausreichenden langen Output zu bekommen. Das ist auch sehr einfach zu raten. Und wir studieren dies, weil das ein sehr gutes Beispiel dafür ist, was für ein Beispiel in einem embedded-Gerät läuft, wo kein ordentlicher Kernel ist, wo kein Zufallzeigengenerator ist. Es gibt keine Libraries um Zufallzahlen zu generieren. Es gibt keinen Kernel, der es für uns tut. Diesen Beispielen werden teilweise sehr schlechte Methoden benutzt. Am Ende der Präsentation werde ich einen Weg zeigen, wo sogar in solchen Situationen in embedded-Geräten gute Zufallzahlen generiert werden können. Als letztes Beispiel ist Haust APD. Das ist am weitesten verbreiteten Access Point bei Linux, zum Beispiel bei Android, wenn sie dort ihren Hotspot verwenden. Und die haben eine sehr gute Implementation. Sie implementieren den Gruppenschüssel, sie erweitern es, um Zufall hinzuzufügen. Jedes Mal, wenn ein Gruppenschüssel generiert wird, das ist sehr gut. Und noch besser lesen Sie von Steve Random, während es bootet. Und wenn da nicht ausreichend Zufall ist, dann wartet es einfach, bis der erste Knall verbindet und dann versucht er noch mal von Steve Random zu lesen. Und wenn da immer noch nicht ausreichend Zufall vorhanden ist, dann wird einfach die Verbindung abgebrochen. Also, wenn Sie Haust APD benutzen, dann sollte alles gut sein. Natürlich, wenn der Kernel und alles andere ordentlich so funktioniert, wie es soll. So, das ist, wie wir unsere Zufallzahlen, Gruppenschüssel raten können. Jetzt werden wir darüber reden, dass der zweite Hauptteil der Präsentation, wie wir diesen Gruppenschüssel benutzen können, um Traffic hinzuzufügen und zu den Schüsseln. Also, wie wollen wir ein Unicast IP-Packet verschütteln, um es zum Kleinen zu senden? Der Standard ID ist, nee, wir haben unser IP-Packet hier. Wir parken das in ein Broadcast-Valentframe. Hier haben wir den WLAN-Header. Wir haben Flags in dem Header, die sagen, hey, das ist ein Broadcast-Frame. Das soll zu einem Kleinen gesendet werden. Und der Empfänger ist die Broadcast-Mac-Adress. Weil der Empfänger die Broadcast-Mac-Adress ist, wird alles damit verschüttelt, mit dem Gruppenschüssel. Aber das funktioniert nicht, weil der Klein merkt, dass dieser Unicast IP-Packet empfangen wird von einer gruppenadressierten Bilan-Schüssel. Wie Bilan-Frame. Dass der 196 Check, sollten alle Pakete senden, der auf eine gruppenadressierten Link-Layer gesendet wird, aber zu einer Unicast IP-Adresse. Diese Methode funktioniert nicht. Aber wie können wir diese Technik umgehen? Na ja, was wir jetzt realistisch verstehen müssen, ist, dass dieser Angriff funktioniert, wenn ein Link-Layer-Packet auf ein Netzwerk-Layer weitergegeben wird, wo Unicast IP-Adressen verwendet werden. Und ein Zugriffspunkt funktioniert nur auf dem Link-Layer. Also wenn wir den Access-Point missbrauchen können, dann könnte dieser Check umgegangen werden. Also lass uns mal kurz die Technik erklären. Wir haben ein Netzwerk mit dem Anzugreifenden und dem Angreifer, der dem Client ein Paket senden möchte. Was der Angreifer macht, ist, er sendet dieses IP-Packet zum Access-Point. Wieder haben wir unsere IP-Packet hier. Und wir machen einen komplexeren WLAN-Header. Der sagt, dieses Group-Frame, dieses Broadcast-Frame, wird zum Access-Point gesendet. Und der nächste Angreifer-Empfänger ist der Broadcast-Mack-Adress, aber die endgültige Adresse ist der Opfer. Und wenn der Access-Point dieses Frame bekommt, dann wird er merkt er, jup, es ist für mich. Ich werde den Gruppenschützel benutzen, um es zu entschüsseln. Alles in Ordnung. Dann merkt er, während es noch auf dem Link-Layer ist. Oh, aber die Endadresse ist das Opfer. Also werde ich dieses Paket an den Access-Opfer weiterleiten. Und der Access-Point hat natürlich die Session-Keats von dem Kleinen, von dem Opfer und wird einfach dieses IP-Packet nehmen, das mit dem Session-Keats benutzen und zum Opfer senden. Für uns. Und jetzt, wenn der Opfer dieses Paket empfängt, scheint alles in Ordnung. Wir haben unsere Unicast-Empfangs-Adresse, Unicast-IP-Adresse, ist ordentlich verschlüsselt, alles in Ordnung, und der Angriff funktioniert. Der zweite Teil ist, dass wir auch Pakete endschlüsseln können. Die Idee dahinter ist sehr einfach, auch sehr einfach zu erklären. Wir senden einen ARP-Polsen auf den Router, dass die Adresse von dem Gateway Broadcast-Make-Adressen sind. Und dann der Router auf dem Kleinen sendet die Adresse für den Kleint über eine Broadcast-Adresse, und da wird ein Gruppenschlüssel, den wir haben, benutzt. Und wir können diese Pakete lesen. Und dann senden wir das weiter in den Kleint, sodass der da nichts merkt. Wie können wir das hier umgehen? Die allererste Methode ist, wenn das Access-Points ein Broadcast-Frame empfängt mit einem Unicast-Finale Endadres-Ziel, sollte das nicht weitergeleitet werden. Ein noch besserer Methode ist, dass in einem Infrastruktur-Netzwerk nicht unbedingt in einem Mesh-Netzwerk, aber in einem Infrastruktur-Netz haben, wo ein Access-Point existiert, dann sollte der Access-Point-Frames empfangen, die an eine Broadcast-Make-Adresse gesendet werden. Und damit sind diese ganzen Probleme umgangen. Und ich würde jetzt sagen, dass das Angriff der spaßigste Teil der Untersuchung war, und jetzt ein theoretischen Angriff gegen ein Handshake, der benutzt wird, wo wir eine Benutzung von AC4 erzinken können. Okay, also das nächste Mal erklären wir jetzt schnell, wie der Handshake funktioniert. Also wir haben hier den Kleint. Der heißt manchmal auch supplikant. Und dann haben wir den Access-Point. Am Anfang ist das alles ganz einfach. Der Access-Point gibt immer wieder Beacons raus. Die Beacons geben die Features des Access-Points raus. Zum Beispiel, ob es ein 802.11 Access-Point ist, oder ob es AC unterstützt. Und es unterstützt auch die unterstützenden Verschüsselungsverfahren des Netzwerks. Also zum Beispiel, ob es WP-CAP kann, oder IS-CCP kann. Der Kleint wird sich dann eines der Verfahren raussuchen und sendet eine Assoziationsanforderung. Und dieses Paket sagt im Netzwerk, dann eben ich möchte das Netzwerk joinen. So, dann gibt es eine Reply dazu. Und da kommt ein zufälliger Nons zurück. Der Access-Point macht auch einen Random Nons. Die sind gegen Replay-Attacks gedacht, gegen Replay-Angriffe. Danach hat man dann Session Schüssel. Jetzt haben wir also den A-Nons und den supplikant Nons. Das ist das gleiche wie der Kleint-Nons. So, nachdem Sie also die S-Nons ausgetauscht haben, können Sie die Sicher-Sitzungsschüssel dann ausrechnen. In der ersten Stufe des Handshakes können wir jetzt sicher gehen, dass es keinen Angreifer gab. Und der Access-Point schickt auch den Group-Temporal-Key den temporären Schüssel. In der dritten Message gibt es auch eine authentisierte Schüssel-Liste. Das ist gegen Downgrade-Attacks. Vor allem mit dem Mittel-Attack, zum Beispiel, wo der Attacker sagt, ich unterstütze nur die alte Methode, dann würde dann der Kleint mit dem T-Cip sich verbinden. Aber der echte Access-Point hat ja die echte Cypher-List, die mit den Netzwerkschüsseln verschüttelt ist. Da kann der Angreifer diese Liste nicht verändern. Und der Kleint würde merken, würde den Downgrade-Attack merken, weil er das gegen die Cypher-List matchen kann. Das Problem mit diesem Design ist, dass der Group-Key hier eben übertragen wird, und zwar bevor der Downgrade-Attack geworfen hindert werden kann. Also was kann ein Angreifer machen? Der Angreifer kann also ein Access-Point aufstellen, der Beacon-Bassistisch ausstrahlt und sagt, ich mache nur T-Cip. Und der Kleint verbindet sich dann halt mit WP T-Cip. Und wenn der Group-Key rausgeschickt wird, dann ist er mit RC4 verschüttelt. Hätte AIS verwendet, wäre das verwendet worden, dann wäre alles in Ordnung gewesen, aber in diesem Fall wird eben RC4 verwendet, wenn wir diesen Angriff machen. RC4 ist natürlich ziemlich schlecht. Also hier für die Kryptografer unter uns, ganz schnell, RC4 ist ein 16-byte Initialisierungsvektor und ein 16-byte Sicher-Schlüssel. Die ersten 256 Bytes vom Schlüsselstrom werden verworfen. Das ist ein etwas komisches Konzept. Also ich werde das mal intuitiv erklären, wo das Problem liegt. Ja, man sieht hier also eine Grafik, die sozusagen das RC4 Verhalten in diesem Fall zeigt. Normalerweise, wenn man diese Art von Grafen für einen Sicher-Schlüssel-Verfahren machen würde, wäre das komplett weiß. Was zeigt uns also diese Grafik? Nehmen wir mal an, wir sind bei Keystream Position 300. Und ich habe einen Wert von 90, dann sehe ich hier einen blauen Punkt. Was bedeutet der Blaupunkt? Der Blaupunkt bedeutet, dass das Keystream Byte bei Position 300 etwas unwahrscheinlicher ist, dass der Wert 90 drin ist. Das sollte eigentlich gleich verteilt sein. Mit einem gescheiten Seifer wäre das gleich verteilt. Jeder Weg wird gleich verteilt. Aber die blauen Punkte zeigen uns, dass manche Werte eben weniger und die roten Punkte zeigen uns, dass andere Werte wahrscheinlicher auftauchen. Das hängt alles mit dem Initialisierungswerk, der verwendet wird. Was ihr mitnehmen solltet, dass mit RC4 manche Schüsselwerte und andere Werte verwendet werden. Wenn man jetzt einen ähnlichen Angriff fährt, wie das, was gegen SSL und die BS gemacht wurde, dann ist es theoretisch, weil das 50 Jahre lang dauern würde, diesen Attack durchzuführen, weil wir sehr viel mitschneiden müssen. Das braucht bei einem Byte sehr, sehr lange. Natürlich werden Angriffe immer besser. Vor ein paar Wochen habe ich einen Trick gefunden, um diese Handshakes öfter durchzuführen. Ich denke, das bringt die Zahl um Faktor 2 oder 3 nach unten. Wir können wahrscheinlich diesen Wert von 50 Jahren weiter und weiter unterbringen. Wir sollten uns merken, kryptographisch gesehen ist RC4 gebrochen und das nicht mehr verwenden. Die Gegenmaßnahme ist, dass wenn man ein Netzwerk daheim hat und dann sollte man WAP T-CIP disabling, also daheim die WPA T-CIP nicht verwenden. Man muss das manchmal explizit konfigurieren, dass AES verwendet wird. Damit ist man gegen diesen speziellen Angriff gefeit. Der letzte Part der Präsentation ist eine ganz kurze Empfehlung darüber, wie man den Zufassgenerator verbessern kann. Wir möchten schauen, dass der Zufassgenerator auch auf Medit-System gut funktioniert, wenn es keinen Kernel gibt, wo wenig Ränder Zufall gesammelt werden kann. Was wir beobachtet haben, ist, es gibt einen WAP T-CIP und man sollte sich nicht aus den Wifi-Mitschnitten den Zufall erholen. Warum sollte man sich nicht Zufall aus dem Hintergrundrauschen holen? Tatsächlich haben wir einen Gad gefunden, dieses hier, das hat eben das so-called Spectral Scan Feature. Das heißt, dieser Chip kann also eine Menge Samples des momentanen Wifi-Backgrounds und Hintergrundrauschen sich holen und kann einen riesigen Anzahl von Samples pro Sekunde erzeugen. Der Nachteil ist, das kostet relativ viel Energie. Also, man kann es nicht sehr lange machen. Aber wir haben das also mal implementiert, diese Idee um tatsächlich Zufall aus dem Hintergrundrauschen zu holen, aus dem Wifi-Kanal und haben dann da statistische Tests gemacht und unsere Resultate sind sehr vielversprechend. Es ist tatsächlich möglich aus dem Hintergrundrauschen Zufall zu extrahieren. Das ist nur ein Vorschlag. Wir müssen da noch weiter forschen, aber wir denken, dass Access Points ein Feature zu verfügen stellen sollten, wo dann diese Zufälligkeit exportiert werden kann und den Random Pool im Kernel zu verbessern. Damit komme ich zum Ende meines Vortrags. Es gibt hier einige Lessons, die man lernen sollte. Wenn Sie einen Zufall-Zahlen-Generator haben, denken Sie immer darin, den Qualität des Outputs zu generieren. Und wenn Sie ein Standard erstellen, bitte schreiben Sie da keine richtig schlechten Standards rein. Was drin steht, sollte gut sein. Ansonsten externe Quellen benutzen, referenzieren, wo das besser funktioniert und um uns dagegen zu verschützen, wo wir allen Verkehr auf den Mitzweck entschützern können, sollten Access Points alle Frames ignorieren, die von einer Broadcast-Mac-Adresse kommen. Und sollte zumindest nicht Unicast-Frames weiterleiten, die auf einer Broadcast-Adresse gesendet werden. Und zu guter Letztens, das Protokoll, das jetzt im Handshake benutzt wird, sensitive Daten nicht senden, bevor Down-Rate-Attacken möglich sind. Das beendet dieser Vortrag. Wenn Sie noch weitere Fragen haben, bitte fragen Sie die. Danke, wir haben noch ein paar Minuten früher Fragen. Das heißt, wenn Sie noch irgendwelche Fragen haben, stellen Sie Ihre Fragen zu den Mikrofonen und stellen Sie Ihre Fragen. Zwei Fragen aus dem Internet. Die erste. Könnten Sie sich vorstellen, dass WPA2 mit Pre-Shared Key, das kann das immer noch sicher sein? Wenn der aus vorher ausgeteilte Schüssel gut und unnicht zu raten ist, dann funktionieren diese Dictionary-Angriffe nicht mehr. Aber Sie haben immer noch das Problem mit den Gruppenschlüsseln an. Diese Gruppenschlüssel, die schlecht generiert werden, das ist Teil von Enterprise-Netzwerken, die einen vorgekehrt geteilten Schlüssel benutzen. Aktuell glaube ich, dass der Handshake, der in Wiedern benutzt wird, verbessert werden kann. Also, wenn Sie einen vorher geteilten Schlüssel benutzen, vermute ich, dass es nicht so stark ist für ein Enterprise-Netzwerk, wo Sie ordentliche Krätenzels haben. So ein Net-Enterpreis-Netzwerk ist in den meisten Fällen sicher. Aber als Standard-Benutzer, wenn Sie einen komplexen vorher ausgeteilten Schlüssel haben, dann ist immer noch alles in Ordnung. Für das ARP-Sproofing haben Sie sich da überlegt, ob Sie ARP-Offer verwenden können? Ich glaube, das ist, was wir benutzt haben, um den Zugang vom kleinen vergiftet haben. Wir haben die ARP-Pakete in alle Connections mit dem Router gesendet haben. Also, Sie können auch ARP-Eindruffungen zu alle schicken. Also, nicht nur an den einen kleinen. Ja, klar. Man kann es zu allen kleinen senden. Ich kann sagen, hey, ich möchte traffic zu diesem kleinen senden oder zu allen. Ich habe mir das noch nicht detailliert angeschaut. Ich weiß, dass es funktioniert, wenn man einen kleinen anträft. Wenn man einen anderen anträft, dann möchte ich mit dem selben Angriff noch mal fahren. In Bezug auf Ihr Problem mit dem Access-Point-Bordcast-Packet in die Unikast-Pakete weiter schickt, dann machen das alle Implementierungen oder nur manche? Das ist eine gute Frage. Ich weiß nicht genau, was der Standard sagt. Was ich weiß, ist, dass nicht mal alle Implementationen diesen 100 und 96 Angriff implementiert werden. Da kann sich die kleinen Direct-Frames senden, ohne den Access-Point zu missbrauchen. Das ist nicht das, was die D-Pakete forwarding irgendwo im Standard genannt wird. Ich glaube, das haben Sie einfach nicht drüber nachgedacht. Aber ich vermute, dass die meisten Implementationen zu diesen forwarding-Angriff problematisch sind. Ich wüsste, wer überrascht, wenn ein vereinziger Hersteller dagegen sich geschützt hätten. Möglich, aber unwahrscheinlich. Keine Frage mehr.