Angriffe auf Bluetooth - Systeme

Transkript

1 Angriffe auf Bluetooth - Systeme von André Hentschelmann Abstract Dieser Artikel befasst sich mit Angriffen auf Bluetooth-Systeme. Es wird erläutert, wie ein Angreifer durch Abhören des Kopplungsprozesses Informationen gewinnen kann, die ihm Rückschlüsse auf die verwendete PIN ermöglichen. Um diese neue Angriffsvariante abzugrenzen, sollen bisherige Angriffsarten kurz vorgestellt und erläutert werden. Eine detaillierte Beschreibung des Kopplungsprozesses, inklusive der Analyse möglicher Schwachstellen, bildet die Grundlage für die Untersuchung einer existierenden Implementierung. Was ist Bluetooth? Bluetooth ist eine international standardisierte Schnittstelle für den Datenaustausch per Funk. Es unterstützt die Überwachung oder Steuerung selbst kleinster Geräte. Immer mehr Hersteller nutzen diese Technologie, um beispielsweise Handy-Zubehör drahtlos zu verbinden. Geschichtliches Im Jahre 1994 begann die Firma Ericcson mit einer Studie zur drahtlosen Vernetzung von Geräten, Hauptziel war die Verbindung des Headsets mit dem Handy. Nach erfolgreichem Abschluss dieser Studien wurde 1998 die Bluetooth Special Interest Group (SIG) gegründet, außer Ericsson gehörten auch Intel, IBM, Toshiba und Nokia zu den ersten Mitgliedern. Juli 1999 wurde die Spezifikation Version 1.0 verabschiedet und noch im selben Jahr erfolgte eine Verbesserung in Form der Version 1.0b. Die aktuelle Version 1.2 wurde im November 2003 veröffentlicht. Folgende Ziele wurden während der Entwicklung und Standardisierung verfolgt: Preisgünstiger u. kleiner Chip Geringer Stromverbrauch Ablösung von IrDA Drahtlose Übertragung von Stimme u. Daten Automatischer Aufbau einer Verbindung Sichere Übertragung Robuste Übertragung (Vermeidung von Interferenzen) offener Standard Der Name Bluetooth ist abgeleitet vom dänischen Wikinger König Harald Blatand (10.Jahrhundert), er soll auf den hohen Anteil skandinavischer Entwicklungsarbeit hinweisen

2 Technische Aspekte Bluetooth nutzt wie WLAN nach dem IEEE b Standard das ISM Band (industrial, scientific, and medical Band), welches weltweit für Funkanwendungen lizenzfrei genutzt werden darf. Dieses Frequenzband befindet sich im Bereich von 2,4GHz - 2,485GHz. Da Bluetooth nach dem Prinzip des Frequency Hopping Spread Spectrum (FHSS) arbeitet, unterteilt sich die zur Verfügung stehende Bandbreite in 79 Frequenzsprungkanäle zu jeweils 1MHz. Zwischen diesen Kanälen wird bis zu 1600 mal pro Sekunde gewechselt. Durch dieses Verfahren ist Bluetooth weniger störungsanfällig und abhörsicherer als bei der Nutzung nur eines Kanals. Als Modulationsverfahren wird Gaussian Phase Shift Keying (GFSK) verwendet. Bluetooth unterstützt sowohl symmetrische als auch asymmetrische Datenverbindungen, wobei eine Gesamtdatenrate von 0,7 Mbit/s zur Verfügung steht. Der Bluetooth-Standard definiert drei Leistungsklassen. Diese unterscheiden sich durch die Sendeleistung der Geräte und die damit erzielbare Reichweite. Leistungsklasse 1: Sendeleistung von 100 mw Mindestreichweite von 100 Metern Leistungsklasse 2 Sendeleistung von 2,5 mw Mindestreichweite von 20 Metern Leistungsklasse 3 Sendeleistung von 1 mw Mindestreichweite von 10 Metern Anwendungsgebiete Bluetooth hat Aufgrund seiner Vielfältigkeit eine große Verbreitung gefunden, nahezu jedes Handy, viele Notebooks und PDAs werden schon vom Hersteller mit entsprechenden Modulen ausgerüstet. So ist es beispielsweise möglich, den PDA mit dem Notebook zu synchronisieren, den PC mit der ISDN Telefonanlage zu verbinden oder Eingabegeräte drahtlos mit dem Computer zu verbinden. Darüber hinaus findet Bluetooth zum Patienten - Monitoring in der Medizin oder bei der Heim-Automation Verwendung. Bisherige Attacken In der Vergangenheit wurden immer wieder Attacken bekannt, die auf fehlerhafte Bluetooth- Implementierungen einiger Gerätehersteller fußten. So war es beispielsweise möglich, das Telefonbuch auszulesen (Snarf Attack), SMS über das fremde Handy zu versenden (Backdoor Attack, Bluebug Attack) oder Telefongespräche zu unterbrechen (Denial of Service Attack). Normalerweise sind solche Attacken nur bei Geräten möglich, die sich im so genannten discoverable oder visible Modus befinden, allerdings gibt es mittlerweile schon Tools ( redfang 1 ) im Internet die auch einen Zugriff ermöglichen, wenn sich das Gerät im nondiscoverable Modus befindet

3 Wenn der Nutzer also ein Gerät mit einer in Bezug auf die Bluetooth-Implementierung fehlerfreien Firmware besaß, dann war er bisher gegen solche Attacken immun. Diese Sicherheit könnte nun nicht mehr gegeben sein. Zwei israelische Forscher haben einen Angriff beschrieben, mit dem sich die PIN zweier bereits gekoppelter (paired) Geräte und somit auch der Verschlüsselungs-Key knacken lässt. Damit ist es möglich, die Verbindung zu belauschen und auf Bluetooth-Geräte zuzugreifen und das trotz aktivierter Sicherheitsfunktionen. Im Folgenden soll die Arbeit von Yaniv Shaked und Avishai Wool vorgestellt werden. Sie basiert auf einer Attacke, die Oliver Whitehouse bereits im April 2004 vorstellte. Er beschrieb die Möglichkeit, mit Hilfe der belauschten Bluetooth-Pakete eines Pairing-Prozesses die richtige PIN zu erraten. Wool und Shaked haben diese Idee aufgegriffen und eine praktische Realisierung für einen Angriff vorgestellt. Pairing Prozess Es gibt drei Sicherheitsmodi für eine Bluetooth-Verbindung zwischen zwei Geräten. Sicherheitsmodus 1: o Das Bluetooth-Gerät initiiert selbst keine speziellen Sicherheitsmechanismen, reagiert aber auf Authentisierungsanfragen anderer Geräte. Sicherheitsmodus 2: o Auswahl und Nutzung von Sicherheitsmechanismen werden abhängig vom Bluetooth-Gerät ("trusted" oder "non-trusted") und vom Dienst auf Anwendungsebene festgelegt. Das Gerät leitet erst dann Sicherheitsprozeduren ein, wenn es eine Aufforderung zum Verbindungsaufbau erhalten hat. Sicherheitsmodus 3: o Es ist generell eine Authentisierung beim Verbindungsaufbau erforderlich; die Verschlüsselung der zu übertragenden Daten ist optional. Der Pairing Prozess ist Bestandteil des Sicherheitsmodus 3, er umschreibt den Kopplungsprozess von zwei Bluetoothgeräten, bei dem ein Verbindungsschlüssel erzeugt wird, der zur späteren Authentifizierung und als Grundlage für eine weiteren Schlüssel zur Chiffrierung der Nutzdaten dient. Es werden folgende Sicherheitselemente verwendet. Eine weltweit eindeutige IEEE-48-Bit- Adresse, die Bluetooth Device Address (BD_ADDR). 128bit lange Zufallswerte (RAND), die von einem (Pseudo-)Zufallszahlengenerator in einem Bluetooth-Gerät erzeugt werden und eine konfigurierbare, üblicherweise vier und bis maximal 16 Octets (32 bis 128bit) lange geheime Endgerätekennung (PIN). Damit der Pairing Prozess stattfinden kann, müssen die Geräte sich im discoverable oder visible Modus befinden, sonst könnten sie sich gegenseitig nicht finden. Natürlich sind sie auch für einen Angreifer auffindbar, so das dieser in der Lage ist, die entsprechende Bluetooth Device Address auszulesen

4 Folgende drei Schritte sind Bestandteil des Kopplungsprozess: 1. K init generieren 2. K ab generieren 3. Gegenseitige Authentifizierung K init generieren Master Slave IN_RAND BD_ADDR PIN E22 E22 BD_ADDR PIN K init K init Abbildung 1 - Generierung von K init Wie in Abbildung 1 ersichtlich, erzeugt der Master eine 128bit lange Zufallszahl (IN_RAND), die im Klartext zum Slave übetragen wird. Beide Parteien bilden dann unter Verwendung des E22-Algorithmus aus der PIN, die der Nutzer auf beiden Seiten eingeben muss, der Bluetooth Device Address und der Pseudozufallszahl einen Initialisierungsschlüssel (K init ), der auf beiden Seiten verfügbar ist. BD_ADDR IN_RAND PIN E22 K init Abbildung 2 - K init ' für den Angreifer Für einen potentiellen Angreifer ergibt sich die Möglichkeit, in den Besitz der Pseudozufallszahl IN_RAND zu kommen. Über die ihm bekannte Bluetooth Device Address und einer von ihm geratenen PIN erzeugt er ein vermeintliches K init

5 K ab generieren Master Slave LK_RAND A K init K init LK_RAND B BD_ADDR A BD_ADDR B BD_ADDR B BD_ADDR A E21 E21 E21 E21 K ab K ab Abbildung 3 - Generierung von K ab Nach der Erzeugung des Initialisierungsschlüssels wird der Verbindungsschlüssel erzeugt. Dafür generieren beide Parteien jeweils eine Pseudozufallszahl, genannt LK_RAND A und LK_RAND B. Anschließend werden diese bitweise XOR mit K init verknüpft und zum jeweils anderen übertragen. Dort erfolgt eine erneute bitweise XOR-Verknüpfung, so dass auf beiden Seiten LK_RAND A und LK_RAND B vorliegt. Sowohl Master als auch Slave bilden unter zweimaliger Verwendung des E21-Algorithmus aus LK_RAND A mit BD_ADDR A und LK_RAND B mit BD_ADDR B einen gemeinsamen Verbindungsschlüssel K ab. Der genaue Ablauf ist in Abbildung 3 dargestellt. Ein Angreifer ist in der Lage, LK_RAND A und LK_RAND B jeweils XORed mit K init zu erfahren, er wird sein K init verwenden, um LK_RAND A und LK_RAND B zu erraten. Um den Verbindungsschlüssel zu erhalten, wird der Angreifer anschließend die gleichen Operationen durchführen wie die beiden attackierten Geräte. Da der Angreifer von einer erratenen PIN ausgegangen ist und kann auch K init falsch sein. Daraus resultiert aber auch das K ab falsch sein könnte. In Abbildung 4 wird das detaillierte Vorgehen des Angreifers dargestellt

6 BD_ADDR A LK_RAND A XORed mit K init K init LK_RAND B XORed mit K init BD_ADDR B E21 E21 K ab Abbildung 4 - K ab ' für den Angreifer Gegenseitige Authentifizierung Verifier Claimant AU_RAND A BD_ADDR A E1 E1 BD_ADDR A K ab K ab SRES A = SRES A Nein Ja Stop Nochmal mit getauschten Rollen Abbildung 5 - Ablauf der gegenseitigen Authentifizierung Der dritte Schritt im Kopplungsprozess ist die gegenseitige Authentifizierung, dabei wird vom Verifier eine 128bit lange Pseudozufallszahl (AU_RAND A ) generiert und zum Claimant übertragen, beide Parteien erzeugen dann ein Prüfwort, SRES genannt. Dieses Prüfwort wird unter Zuhilfenahme des E1-Algorithmus gebildet. Die Eingabewerte für E1 sind AU_RAND A, BD_ADDR A und K ab. Der Claimant überträgt das von ihm erzeugte Prüfwort zum Verifier, der es mit dem von ihm erzeugten Prüfwort vergleicht. Sollte dieser Vergleich positiv ausfallen, - 6 -

7 erfolgt der gleiche Prozess noch einmal mit getauschten Rollen. Ein negativ ausgefallener Vergleich erwirkt eine erneute gegenseitige Authentifizierung. BD_ADDR A AU_RAND A K ab E1 == SRES A Nein Ja Nächste PIN Nochmal mit BD_ADDR B Abbildung 6 - Möglichkeit zum Überprüfen der PIN für den Angreifer Für den Angreifer ergibt sich durch die gegenseitige Authentifizierung eine Möglichkeit die von ihm gewählte PIN und die daraus abgeleiteten Schlüssel zu testen. Er nutzt ebenso den E1-Algorithmus und generiert im ersten Schritt aus dem abgefangenen AU_RAND A, BD_ADDR A und seinem K ab ein Prüfwort, das er mit dem SRES A des Claimants vergleicht. Fällt dieser Vergleich positiv aus, erfolgt der zweite Schritt, jetzt wird aus AU_RAND B, BD_ADDR B und K ab ein Prüfwort generiert, das mit SRES B verglichen wird. Sollte auch dieser zweite Test positiv ausfallen, weiß der Angreifer, dass die von ihm gewählte PIN und die daraus generierten Schlüssel richtig sind

8 Programmablauf PIN =0 PIN =PIN Kinit berechen PIN++ LK_RANDA LK_RANDB decodieren Kab berechen Nein Nein Ja SRES aus AU_RANDA berechnen SRES A = SRES Ja SRES aus AU_RANDB berechnen SRES B = SRES Abbildung 7 - Blockdiagramm für einen möglichen Programmablauf Wie schon im vorigen Abschnitt deutlich geworden, nutzt der Angreifer die hauptsächlich im Klartext übertragenen Daten des Kopplungsprozesses um mit einem Brute-Force-Algorithmus die verwendete PIN zu erfahren. Er wird dabei alle möglichen PINs durchprobieren. Da er sowohl IN_RAND als auch BD_ADDR kennt, kann er den E22-Algorithmus mit diesen Werten und seiner geratenen PIN nutzen. Er erhält ein vermeintliches K init, das er zum decodieren von LK_RAND A und LK_RAND B nutzt. Diese beiden Wörter enthalten für den Angreifer genug Informationen, um den vermutlichen Verbindungsschlüssel K ab zu erzeugen. Die Daten die während der gegenseitigen Authentifizierung abgehört werden können nutzt der Angreifer, um die von ihm erzeugten Schlüssel zu testen

9 Ergebnisse/Messwerte P4 3GHz HT optimiert P3 450MHz optimiert P3 450MHz ,35 269, ,127 25,98 26, ,609 2,58 2,69 1 0,75 0,27 0,1 0,063 0, Abbildung 8 - Programmlaufzeit in s in Abhängigkeit von der PIN - Stellenanzahl Die beiden Forscher haben mit ihrer Implementierung praktische Tests durchgeführt, die Zusammenfassung dieser Ergebnisse sind in Abbildung 8 dargestellt. Der erste Testlauf, des in C geschriebenen Programms, erfolgte auf einem Pentium 3 mit 450MHz.. Eine vierstellige numerische PIN wird so beispielsweise in 2,58 Sekunden errechnet. Anschließend wurde das Programm zum Beispiel durch Compileroptimierungen, Verwendung von Inline Assembler und algebraischen Manipulationen weiter verbessert. Durch diese Optimierungen ergab sich eine Verzehnfachung der Rechengeschwindigkeit. Anschließend wurde das Programm auf einen aktuellen Rechner portiert, der auf Basis eines Pentium 4 mit 3GHz und Hyperthreading einen weiteren Geschwindigkeitszuwachs um den Faktor 4 erzielt. Das knacken einer vierstelligen numerischen PIN dauerte so nur noch 63 Millisekunden. Da Wool und Shaked keine Angaben für die Berechnungsdauer von PINs mit mehr als sieben Stellen machen und leider auch keine alphanumerischen PINs berücksichtigt haben, wurde dies in Abbildung 9 von mir anhand von Annahmen gemacht. Grundlage dafür ist, dass das probieren einer PIN 6,3 Nanosekunden Rechenzeit benötigt. Alphanumerische PINs verwenden die Zeichen 0 9, a z und A Z, also insgesamt 62 Symbole. PIN Länge Ungefähre Berechnungsdauer Numerische PIN Alphanumerische PIN 8 13 Minuten 43 Jahre 9 2 Stunden 2700 Jahre 10 1 Tag Berechnung dauert 11 9 Tage tausende Jahre Tage Abbildung 9 Interpolierte Programmlaufzeiten - 9 -

10 Re-Pairing Attack Wie im Vorhergehenden beschrieben, findet der Kopplungsprozess zwischen zwei Bluetooth Geräten nur sehr selten statt, da beide Geräte nach dem ersten Kopplungsprozess den selben Verbindungsschlüssel haben und somit die ersten beiden Schritte des Pairing Prozess übersprungen werden können und direkt die gegenseitige Authentifizierung erfolgt. Ein Angreifer muss also entweder in der Lage sein zur richtigen Zeit am richtigen Ort zu sein, oder er ist in der Lage, die beiden Bluetooth Geräte zu einem erneuten Pairing Prozess zu bringen. Ein Ansatzpunkt bietet sich bei genauer Betrachtung der Bluetooth Spezifikation, laut dieser darf ein Bluetooth Gerät einen Verbindungsschlüssel vergessen. Sollte dies der Fall sein, findet statt der gegenseitigen Authentifizierung der komplette Kopplungsprozess statt. Ein Angreifer muss für diese Attacken in der Lage sein, seine eigene Bluetooth Device Address zu ändern, um dem jeweiligen Gegenüber den richtigen Kommunikationspartner zu mimen. Im Folgenden sollen nun drei Varianten vorgestellt werden, die diese Schwäche im Bluetooth Standard ausnutzen. 1. Variante Master Slave Angreifer AU_RAND A LMP_not_accepted Abbildung 10 - Re-Pairing Variante 1 Da die beiden Geräte die ersten zwei Schritte des Kopplungsprozess überspringen, kommt es sofort zur gegenseitigen Authentifizierung, der Master schickt also dem Slave die AU_RAND A Nachricht und erwartet vom Slave ein gültiges SRES zurück. Bevor der Slave antwortet, sendet der Angreifer die LMP_not_accepted Nachricht unter Verwendung der Bluetooth Device Address des Slaves. Diese Nachricht bedeutet für den Master, dass der Slave seinen Verbindungsschlüssel vergessen hat. Der Kopplungsprozess wird angestoßen. 2. Variante Master Slave Angreifer IN_RAND Abbildung 11 - Re-Pairing Variante 2 Zu Beginn der gegenseitigen Authentifizierung erwartet der Slave das AU_RAND A des Masters, stattdessen aber schickt der Angreifer, unter der Bluetooth Device Address des Masters, die IN_RAND Nachricht. Der Slave geht in einem solchen Fall davon aus, dass der Master seinen Verbindungsschlüssel vergessen hat. Ein erneuter Kopplungsprozess wird durch den Master begonnen

11 3. Variante Master Slave Angreifer AU_RAND A Zufälliges SRES Abbildung 12 - Re-Pairing Variante 3 Bei der dritten Variante beginnt der Prozess der gegenseitigen Authentifizierung wieder mit dem Senden der AU_RAND A Nachricht durch den Master, aber statt das korrekte SRES vom Slave zu erhalten, empfängt der Master nur SRES Nachrichten, die der Angreifer nach einem Zufallsprozess generiert und an den Master sendet. In einem solchen Fall wird der Master den Prozess der gegenseitigen Authentifizierung bis zu einem bestimmten Grenzwert immer wieder neu starten. Nach Überschreiten dieser Grenze wird der Kopplungsprozess neu gestartet. Machbarkeitsanalyse Ein Durchführen des vorgestellten Angriffes erfordert das Belauschen des kompletten durch Bluetooth genutzten Frequenzbandes, dies ist mit Standardhardware derzeit nicht möglich. Es kann ebenso davon ausgegangen werden, dass es auch in Zukunft nicht möglich sein wird, mit herkömmlichen Bluetooth Adaptern derartige Angriffe auszuführen, da schon hardwareseitig nicht die nötigen Voraussetzungen gegeben sind. Also bleibt nur der Weg über so genannte Bluetooth-Protokollanalysatoren, deren Preis sich in der Größenordnung von befindet. Ein weiteres Problem stellt der Pairing Prozess an sich dar, er findet sehr selten statt, wird meist in sicherer Umgebung durchgeführt und muss wirklich vollständig belauscht werden. Um eine für den Angreifer günstige Wiederholung des Pairing Prozesses zu erzwingen, wurde die Re-Pairing Attack vorgestellt, aber auch diese ist nur unter erhöhtem Aufwand und bei unvorsichtigen Nutzern möglich. So muss der Angreifer in der Lage sein, unter gespoofter Bluetooth Device Address, zum rechten Zeitpunkt Nachrichten in die Kommunikation der beiden zu koppelnden Geräte einzuschleusen. Kritisch ist dabei das Abpassen des konkreten Zeitpunktes und das Editieren der eigenen Bluetooth Device Address, da dies nur mit Hersteller Tools möglich ist. Die Re-Pairing Attacke erfordert ein erneutes Eingeben der Pin durch den Nutzer, welcher durch die erneute Aufforderung alarmiert sein sollte. Für einen Angreifer wird die Programmlaufzeit bei der Verwendung von PINs mit mehr als 12 Stellen zu lang, um diese Attacke noch praktikabel durchzuführen. Zusammenfassung Eine ausführliche Recherche im Internet hat gezeigt, dass die Idee zu dieser Attacke nicht neu ist. So befindet sich auf der offiziellen Bluetooth Webseite in der Sektion Security/FAQ folgende Beschreibung: Theoretically a hacker can monitor and record activities in the frequency spectrum and then use a computer to regenerate the PIN codes being exchanged. This requires specially built hardware and thorough knowledge of Bluetooth systems. By using a PIN code with 8 or more

12 alphanumeric digits it would take the hacker years to discover the PIN. By using a 4 digit numeric PIN code, the hacker could discover the PIN in a matter of a few hours. Still advanced software is required. 2 Die Bluetooth Entwickler sind sich also durchaus dieser Angriffsmöglichkeit bewusst, schätzen aber offensichtlich deren Gefährlichkeit als gering ein. Diese Einschätzung trifft nur zum Teil zu, da Wool und Shaked gezeigt haben, dass es nicht einige Stunden dauert, um eine vierstellige numerische PIN zu knacken, sondern nur einige Millisekunden. Allerdings bietet eine achtstellige PIN die von den Bluetooth Entwicklern angegebene Sicherheit, da es tatsächlich mehrere Jahre dauert um diese zu knacken. Um möglichst hohe Sicherheit bei gekoppelten Bluetooth Geräten zu erreichen, sollte der Nutzer folgende Ratschläge befolgen: Möglichst 16-stellige alphanumerische PIN verwenden Den Kopplungsprozess nur in sicherer Umgebung durchführen Bei einer erneuten PIN-Abfrage den Kopplungsprozess abbrechen Auch die Hersteller sind in einer solchen Situation in der Pflicht, so sollten alle Hersteller bei der Implementierung ihrer Software darauf achten, das kurze PINs nicht zugelassen werden und von Anfang an auf die maximal PIN-Länge beim Kopplungsprozess bestanden wird. Quellen [1] Yaniv Shaked and Avishai Wool, Cracking the Bluetooth PIN [2] [3] [4] [5] Bundesamt für Sicherheit in der Informationstechnik (BSI), Bluetooth Gefährdungen und Sicherheitsmaßnahmen [6] Ollie Whitehouse, War Nibbling: Bluetooth Insecurity [7] Heise Newsticker, Forscher knacken Bluetooth-PINs gekoppelter Geräte,