Dieser Beitrag ist mal wieder eine Zweitverwertung. Im Rahmen meines Studiums habe ich einen Text über die Sicherheitsmechanismen von Bluetooth Low Energy geschrieben. Warum muss man eigentlich sechsstellige Zifferncodes abtippen oder miteinander vergleichen? Und was bedeutet es für die Sicherheit, wenn man das (nicht) machen muss?

Die Arbeit gibt einen Überblick über den Protocol Stack, die Sicherheitsmechanismen und einige Schwächen. Weil ich es immer ein bisschen schade finde, wenn solche Texte nach der Abgabe in der Schublade verschwinden, veröffentliche ich den Text hier für alle Interessierten. Viel Spaß beim Lesen!

---

Abstract. Die drahtlose Übertragungstechnik Bluetooth Low Energy (BLE) ist auf geringen Energiebedarf ausgelegt. Alle Protokolle und Sicherheitsmechanismen wurden vor diesem Hintergrund entworfen und sind das Ergebnis von Abwägungen zwischen Sicherheit und Energieeffizienz. Die Spezifikation lässt Geräteherstellern Spielräume bezüglich der Implementierung von Sicherheitsmechanismen, um auch in äußerst ressourcenbeschränkten Anwendungsfällen anwendbar zu sein. Mit der Einführung von LE Secure Connections Pairing durch die Spezifikation 4.2 ist ein Pairing-Verfahren verfügbar, das einen authentifizierten und vertraulichen Kanal auch in Anwesenheit passiver Angreifer etabliert.

I. Einleitung

Bluetooth Low Energy (BLE) ist eine drahtlose Übertragungstechnik, die auf minimalen Energiebedarf optimiert ist. Daher eignet sie sich insbesondere für batteriebetriebene Geräte, die möglichst lange ohne Aufladung oder Wechsel des Energiespeichers betrieben werden sollen. Die Sicherheitsmechanismen müssen mit dieser Anforderung harmonieren: sie müssen effektiv und gleichzeitig energieeffizient sein. Die vorliegende Arbeit liefert einen Überblick über die Sicherheitsmechanismen von BLE und stellt bekannte Schwachstellen und Angriffe dar.

Die Arbeit gliedert sich in die folgenden Teile: Abschnitt II beschreibt wichtige Grundprinzipien von BLE. In Abschnitt III werden die Sicherheitsmechanismen von BLE dargestellt. Die bekannten Schwachstellen und Angriffe sind Gegenstand des Abschnitts IV.

II. Bluetooth Low Energy

BLE wurde erstmals 2010 in der Bluetooth-Spezifikation 4.0 von der Bluetooth Special Interest Group (SIG) veröffentlicht. Die Sicherheitsmechanismen wurden mit dem Schritt auf Version 4.2 wesentlich überarbeitet [1, S. 22].

Zur Abgrenzung von BLE wird die ursprüngliche Bluetooth-Technologie, die auf die Verbindung von Rechnern, Kommunikations- und Audiogeräten ausgelegt ist, in der Literatur auch als Bluetooth Classic bezeichnet [2, S. 3 ff.].

BLE und Bluetooth Classic sind untereinander nicht ohne Weiteres kompatibel: sie erfordern unterschiedliche Hard- und Softwarekomponenten, auch wenn sich die Architekturen an vielen Stellen ähneln. Geräte, die beide Technologien implementieren, werden als Dual-Mode devices bezeichnet [2, S. 26].

BLE wurde vor dem Hintergrund fünf wesentlicher Ziele entworfen: weltweite Betriebsmöglichkeit, geringe Kosten, Robustheit gegen Übertragungsfehler, geringe Reichweite und geringe Energieaufnahme [2, S. 7]. Damit eignet es sich insbesondere für die Anwendung in Sensoren, Sport-, Fitness- und Gesundheitsgeräten sowie anderen Komponenten des Internet of Things (IoT) [1,  S. 8 ff.].

BLE-Netze sind topologisch als Piconet aufgebaut, wie in Abbildung 1 dargestellt. Darin nimmt genau ein Gerät die Master-Rolle ein, beliebig viele weitere Geräte agieren als Slave [1, S. 139]. Der Master ist üblicherweise ein stärkeres, komplexeres Gerät wie z. B. ein Smartphone oder ein Gateway, das die Slaves ansteuert. Slaves sind meist einfachere, oft batteriebetriebene Geräte wie Sensoren, die dem Master Informationen zur Verfügung stellen oder Befehle von diesem entgegennehmen [2,  S. 9 f.].

Die Architektur von BLE setzt sich aus mehreren Schichten zusammen, die den in Abbildung 2 dargestellten Protocol Stack bilden [1, S. 142 f.]. Dieser lässt sich in zwei miteinander kommunizierende logische Bereiche aufteilen: Controller und Host. Der Controller führt die unteren Schichten des Stacks aus, der Host die oberen Schichten. Der Controller läuft in der Regel auf einem dedizierten Bluetooth-Chip. Der Host kann entweder auf einem Bluetooth-Chip oder in Software implementiert werden. Die Kommunikation zwischen beiden Komponenten erfolgt über eine standardisierte Schnittstelle, das Host Controller Interface (HCI) [1, S. 25 f.]. Die folgenden Unterabschnitte beschreiben die einzelnen Schichten und deren zentralen Funktionen.

A. Bluetooth Radio (Physical Layer)

BLE operiert im 2,4-GHz-ISM-Band (Industrial, Scientific and Medical) und damit im gleichen Frequenzbereich wie Bluetooth Classic und WLAN. Dieses Band kann weltweit lizenzfrei genutzt werden. Der Frequenzbereich ist in 40 Kanäle mit einem Abstand von 2 MHz aufgeteilt, davon 37 Datenkanäle und 3 Advertisement-Kanäle [1, S. 147 ff.].

B. Link Layer

Der Link Layer definiert eine Abstraktion von der Übertragung über die 40 Kanäle des Physical Layers, indem er diese in einen Data Physical Channel und einen Advertisement Physical Channel zusammenfasst. Der Advertisement Physical Channel wird zum Finden von anderen BLE-Geräten (Discovery), zum Verbindungsaufbau und für Broadcast-Nachrichten genutzt, während der Data Physical Channel der Übertragung von Daten zwischen zwei miteinander verbundenen Geräten dient [1,  S. 156 f.].

Beide Kanäle verwenden dieselbe Paketstruktur, die in Abbildung 3 dargestellt ist. Ein Paket beginnt mit einer alternierenden Folge von Eins- und Nullbits. Darauf folgt die Access Address, die für Advertising Packets standardisiert ist (0x8E89BED6), für Data Packets entspricht sie einem Zufallswert, der eindeutig eine Verbindung zwischen zwei Geräten kennzeichnet. Der Header gibt die Art des Pakets (Data oder Advertising) an und abhängig von der Art zusätzliche Flags. Das Längenfeld enthält die Länge der Payload im Datenfeld. Für Advertising Packets werden von den reservierten acht Bit bis zur Bluetooth-Spezifikation 5.0 nur die niederwertigsten sechs Bit genutzt, die übrigen zwei Bit sind in der Spezifikation mit Reserved for Future Use (RFU) gekennzeichnet und auf null zu setzen [3, S. 2582 f.]. Die Payload enthält die Daten der höheren Schichten. Zuletzt wird eine Cyclic Redundancy Check (CRC)-Prüfsumme angehängt [2,  S. 79 ff.].

Advertising Packets werden üblicherweise auf allen drei Advertising-Kanälen ausgesendet. Die Häufigkeit der Aussendung, das sog. Advertising Interval, kann in einem Bereich von 20 ms bis 10,28 s gewählt werden. Um das Kollisionsrisiko zu verringern, wird jedes Advertising Packet zusätzlich zufällig um 0 ms bis 10 ms verzögert [2, S. 90].

Es existieren vier Typen von Advertising Packets [1, S. 171 ff.]:

• ADV_IND: Erlaubt jedem BLE-Gerät, eine Verbindung aufzubauen.
• ADV_DIRECT_IND: Erlaubt einem bestimmten BLE-Gerät, eine Verbindung aufzubauen.
• ADV_NONCONN_IND: Erlaubt keine Verbindungen, sendet lediglich eine Payload aus (z. B. Ortsinformationen).
• ADV_SCAN_IND: Erlaubt keine Verbindungen, aber das Anfragen von weiteren Informationen über den Advertising Channel.

Der vom Data Physical Channel genutzte physische Kanal wird durch den Adaptive Frequency Hopping-Mechanismus regelmäßig gewechselt, um Interferenzen mit anderen Geräten zu verringern. Ein Kanalwechsel findet in einem regelmäßigen, anwendungsspezifischen Abstand zwischen 7,5 ms und 4 s statt. Kanäle, auf denen Interferenzen festgestellt werden, können als unused markiert werden, sodass diese in späteren Iterationen nicht mehr verwendet werden. Zu diesem Zweck nutzen beide Kommunikationspartner eine Datenstruktur namens Channel Map, die jedem nicht verwendeten Kanal einen störungsfreien Ersatzkanal zuordnet [1, S. 156 ff.].

C. Host Controller Interface (HCI)

Das HCI definiert einen Kommunikationsmechanismus zwischen den unteren und den oberen Schichten des Protocol Stacks. Die von der Bluetooth-Spezifikation definierten HCI-Pakete können physisch über Schnittstellen wie Universal Asynchronous Receiver Transmitter (UART), RS232 oder USB übertragen werden. Sind die oberen und die unteren Schichten des Protocol Stacks auf demselben Chip implementiert, kann das HCI entfallen [1, S. 26 ff., S. 197].

D. Logical Link Control and Adaptation Protocol (L2CAP)

Das L2CAP hat zwei Aufgaben im BLE Protocol Stack: Multiplexing und Segmentierung.

1) Multiplexing

L2CAP definiert drei Kanäle, die über fest vorgegebene Channel IDs angesprochen werden können:

• Attribute Protocol (ATT) Channel: Überträgt Daten der Attribute Protocol-Schicht (siehe Unterabschnitt II-F).
• Security Manager (SM) Channel: Überträgt Daten der Security Manager-Schicht (siehe Unterabschnitt II-E).
• L2CAP Signaling Channel: Dieser Kanal dient der Steuerung von Verbindungsparametern wie bspw. dem Connection Event Interval. Dieser Wert bestimmt u. a. die Häufigkeit des Channel Hoppings. Die Konfigurierbarkeit dieser Parameter trägt zur Minimierung der Energieaufnahme bei.

2) Segmentierung

Die L2CAP-Schicht teilt Pakete höherer Schichten, deren Länge die maximale Paketlänge des Link Layers übersteigt, in mehrere Pakete auf und setzt diese auf der Gegenseite wieder zusammen [1, S. 217 ff.].

E. Security Manager (SM)

Der Security Manager übernimmt verschiedene Sicherheitsfunktionen in der BLE-Architektur. Dazu gehört das Generieren, Austauschen und Speichern von kryptografischen Schlüsseln zur Verschlüsselung und Authentisierung von Verbindungen.

Der initiale Schlüsselaustausch zwischen zwei BLE-Geräten findet während des Pairings statt. Die Spezifikation sieht dafür verschiedene Modi vor, die in Abschnitt III näher beschrieben werden. Werden zwei Geräte dauerhaft miteinander assoziiert (sog. Bonding), werden die ausgehandelten kryptografischen Schlüssel und Parameter zur Wiederverwendung bei einem erneuten Verbindungsaufbau gespeichert.

Zudem generiert der SM pseudonyme Adressen, die ein BLE-Gerät aus Gründen der Privatsphäre bei der Kommunikation verwenden kann, und löst solche Adressen auf die tatsächliche Identität eines Gerätes auf [1, S. 231 ff.].

F. Attribute Protocol (ATT)

Als Attribute werden Dateneinheiten bezeichnet, die über das ATT gelesen, geschrieben oder gefunden (discovered) werden können. Das ATT nutzt eine Client-Server-Architektur, wobei ein Server eine Menge von Attributen zur Abfrage durch einen oder mehrere Clients bereitstellt. Ein Server hat die Möglichkeit, Clients über Änderungen bestimmter Attribute zu benachrichtigen. Ein BLE-Gerät kann eine oder beide dieser Rollen implementieren.

Ein Attribut setzt sich aus vier Datenfeldern zusammen [1, S. 259 ff.]:

• Attribute Type: Art des Attributs (z. B. Primary Service oder Serial Number)
• Attribute Handle: Eindeutige Nummer zur Identifikation des Attributs
• Attribute Permissions: Gibt an, wie auf ein Attribut zugegriffen werden darf. Die Beschränkungen beziehen sich sowohl auf die Art des Zugriffs (lesend, schreibend), als auch auf die Sicherheitsanforderungen bei der Übertragung (Verschlüsselung, Authentifizierung)
• Attribute Value: Wert des Attributs

G. Generic Attribute Profile (GATT)

Das GATT erweitert das ATT um die Möglichkeit der Hierarchiebildung. Dabei nutzt es zwei verschiedene Typen von ATT-Attributen: Services und Characteristics.

Als Characteristic wird ein Datenwert bezeichnet, bspw. die aktuelle Raumtemperatur oder die Modellnummer des Geräts. Ein Service ist eine Menge von Characteristics, die gemeinsam eine bestimmte Funktion des BLE-Gerätes bereitstellen. Mehrere Services können zudem zu Profilen zusammengefasst werden. Abbildung 4 verdeutlicht diese Hierarchie am Beispiel eines GATT-basierten Profils zur Pulsmessung.

Das GATT definiert Befehle für Lese- und Schreibzugriffe auf Characteristics und zum Finden von Characteristics. Außerdem können Benachrichtigungen über Änderungen von Characteristics angefordert werden [1, S. 285 ff.].

H. Generic Access Profile (GAP)

Das GAP steuert, wie und ob sich Geräte gegenseitig finden. Außerdem verwaltet es die Verbindungen.

Das GAP definiert vier Rollen [1, S. 332]:

• Broadcaster: Das Gerät sendet regelmäßig Advertising Events aus
• Observer: Das Gerät empfängt Advertising Events
• Peripheral: Das Gerät akzeptiert Verbindungsanfragen von anderen Geräten (als Slave in einem Piconet)
• Central: Das Gerät initiiert Verbindungen (als Master in einem Piconet)

Darüber hinaus werden zwei mehrstufige Security Modes definiert, die dazu dienen, BLE-Verbindungen nach ihrem Sicherheitsniveau zu klassifizieren. Diese werden in Abschnitt III näher betrachtet.

Zwischen zwei BLE-Geräten kann außerdem ein Bond erstellt werden. Als Bond wird eine Beziehung zwischen den Geräten über eine einzelne Verbindung hinaus beschrieben. Diese entsteht, wenn beide Geräte die beim Pairing ausgehandelten Schlüssel zur weiteren Verwendung bei späteren Verbindungen speichern [2, S. 292].

I. GATT-basierte Profile

Auf die bisher beschriebenen Schichten des Protocol Stacks und die vom GATT angebotene Struktur aufbauend implementiert ein BLE-Gerät Profile, die die eigentliche Funktionalität des Gerätes nach außen bereitstellen [1, S. 359].

Abbildung 4 zeigt beispielhaft ein Profil für einen Pulssensor (Heart Rate Profile). Dieses Profil umfasst zwei Services: den Device Information Service, um allgemeine Informationen über das BLE-Gerät preiszugeben und den Heart Rate Service, der es dem Kommunikationspartner erlaubt, Messwerte abzufragen (Heart Rate Measurement Characteristic), sich über Änderungen benachrichtigen zu lassen (Heart Rate Measurement Client Characteristic Conf Descriptor) oder abzufragen, an welchem Körperteil der Benutzer den Pulssensor trägt (Body Sensor Location) [4].

J. Ablauf einer Verbindung

Abbildung 5 zeigt einen beispielhaften Ablauf einer Verbindung zwischen zwei BLE-Geräten, bspw. einem Smartphone und einem Sensor, für einen einfachen Fall.

Um eine Verbindung herstellen zu können, wird der Link Layer des Smartphones zunächst in den Scanning-Zustand versetzt, sodass Advertising Packets empfangen werden können. Der Sensor muss Advertising Packets aussenden. Dazu teilt der Host des Sensors dem Link Layer die Advertising-Parameter mit, u. a. den Paket-Typ (hier ADV_IND) und das Advertising Interval [2, S. 148 ff.]. Zudem können Datenfelder des Advertising Packets gesetzt werden, um z. B. den Anzeigenamen des Geräts oder herstellerspezifische Daten zu übertragen [1, S. 335 f.].

Hat der Link Layer des Smartphones Advertising Packets empfangen, meldet er dies an den Host, der dem Benutzer die gefundenen BLE-Geräte auflistet. Wählt der Benutzer ein Gerät aus, fügt der Host dieses zu einer White List von Geräten hinzu, mit denen der Link Layer eine Verbindung aufbauen soll. Der Link Layer antwortet auf das nächste empfangene Advertising Packet dieses Geräts mit einem Connection Request und stellt so eine Verbindung her. Da ein BLE-Slave immer nur mit einem Master kommunizieren kann, kann der Sensor das Aussenden von Advertisements für die Dauer der Verbindung einstellen [2,  S. 154 f.].

Nun können die Geräte Daten untereinander austauschen, z. B. um ein Pairing oder Bonding durchzuführen oder um herauszufinden, welche Services das jeweils andere Gerät anbietet. Wird die Verbindung nicht mehr benötigt, wird sie terminiert [2,  S. 164 f.].

III. Sicherheitsmechanismen

Der Bluetooth-Standard sieht Sicherheitsmechanismen vor, die optional aktiviert werden können. Übertragene Daten können verschlüsselt oder signiert werden. Zum Schutz der Privatsphäre des Nutzers ist es außerdem möglich, die Geräteadresse in zeitlichen Abständen zu wechseln.

Die Entscheidung, wann welche Sicherheitsmechanismen aktiviert werden, kann entweder generell für alle Verbindungen mit einem Gerät oder beschränkt auf Interaktionen mit bestimmten Services getroffen werden. Die Sicherheitsanforderungen an eine Kommunikation werden auf der GAP-Schicht in den folgenden Sicherheitsstufen ausgedrückt [1, S. 353 f.]:

• LE Security Mode 1
  • Level 1: No security (keine Authentifizierung, keine Verschlüsselung)
  • Level 2: Unauthenticated pairing with encryption
  • Level 3: Authenticated pairing with encryption
  • Level 4: Authenticated LE Secure Connections pairing with encryption
• LE Security Mode 2
  • Level 1: Unauthenticated pairing with data signing
  • Level 2: Authenticated pairing with data signing

LE Security Mode 1 stellt ab Level 2 einen verschlüsselten Kanal zur Verfügung, ab Level 3 ist auch die Authentifizierung der Gegenseite sichergestellt. Level 3 und 4 unterscheiden sich durch die Pairing-Methode (siehe Unterabschnitt III-A). LE Security Mode 2 stellt lediglich Signaturen bereit, jedoch keine Verschlüsselung.

Innerhalb eines LE Security Modes umfasst jeder Level alle Sicherheitsfunktionen der vorherigen Levels. Darüber hinaus bieten Level 3 und 4 des LE Security Mode 1 auch alle Sicherheitsfunktionen von LE Security Mode 2 Level 2 [5,  S. 2068].

Die folgenden Abschnitte beschreiben, wie gesicherte Verbindungen aufgebaut, übertragene Daten signiert und wechselnde Adressen generiert und aufgelöst werden.

A. Pairing

Der initiale Schlüsselaustausch zum Aufbau eines verschlüsselten Kanals wird als Pairing bezeichnet. BLE kennt vier verschiedene Pairing-Methoden, die je nach Ein- und Ausgabemöglichkeiten (Displays, Tastaturen, etc.) der beteiligten Geräte verwendet werden [1,  S. 234]:

• Just Works: Diese Methode ist für Geräte vorgesehen, die keinerlei Ein- oder Ausgabemöglichkeiten besitzen. Der Benutzer muss keine Bestätigung des Pairings durch eine Eingabe vornehmen.
• Passkey Entry: Auf einem Gerät wird eine sechsstellige Ziffernfolge angezeigt, die der Benutzer auf dem anderen Gerät zur Bestätigung eingeben muss.
• Out of Band (OOB): Diese Methode verwendet den Datenkanal eines anderen Protokolls, bspw. Near Field Communication (NFC), über den Daten ausgetauscht werden können.
• Numeric Comparison: Beide Geräte berechnen als Ergebnis des Schlüsselaustauschs eine sechsstellige Ziffernfolge. Liegen die entsprechenden Ein-/Ausgabemöglichkeiten vor, werden die Ziffernfolgen dem Benutzer angezeigt. Dieser vergleicht die Ziffernfolgen und bestätigt die Gleichheit, sofern eine Eingabemöglichkeit vorhanden ist. Diese Methode wurde erst mit der Bluetooth-Spezifikation 4.2 eingeführt.

Der SM unterscheidet zudem zwischen vier Sicherheitsmodi, die mit den Mode-1-Sicherheitsstufen des GAP korrespondieren. Diese sind in der linken Spalte von Tabelle I aufgelistet.

LE Secure Connections Pairing wurde mit der Bluetooth-Spezifikation 4.2 eingeführt. Dieser Sicherheitsmodus verwendet asymmetrische Kryptografie: Er führt einen Diffie-Hellman-Schlüsselaustausch auf Basis der elliptischen Kurve P-256 [5,  S. 2309 f.] aus. Diese Kurve wurde vom National Institute of Standards and Technology (NIST) generiert und in [6] standardisiert.

Die übrigen Modi werden seit der Spezifikation 4.2 auch als LE Legacy Pairing bezeichnet. Sie basieren auf symmetrischer Kryptorgrafie mit dem Advanced Encryption Standard (AES). Sofern nicht die OOB-Methode verwendet wird, bieten diese Modi keinen Schutz gegen einen Angreifer, der die ausgetauschten Nachrichten während des Pairings mithören kann (siehe Unterunterabschnitt IV-A1) [1, S. 235]. Tabelle I zeigt, welche Pairing-Methoden für welche Sicherheitsmodi verwendet werden können.

Sicherheitsmodus	Pairing-Methoden
LE Secure Connections Pairing (ab Spezifikation 4.2)	Authentifiziert: Passkey Entry, OOB, Numeric Comparison Nicht authentifiziert: Just Works
LE Legacy Pairing
No Security Requirements	—
Unauthenticated (No MITM Protection)	Just Works, OOB über nicht vertrauenswürdigen Kanal
Authenticated (MITM Protection)	Passkey Entry, OOB über vertrauens- würdigen Kanal

Der Pairing-Prozess besteht aus drei Phasen und wird immer vom Master gestartet. Dieser wird im Pairing-Prozess daher auch als Initiator bezeichnet, die Gegenseite als Responder [1, S. 231 ff.].

In der ersten Phase werden Informationen über die Kommunikationspartner ausgetauscht. Phase 2 dient der Verschlüsslung und (falls möglich) der Authentifizierung der Verbindung. In der letzten Phase werden kryptografische Schlüssel für weitere Sicherheitsfunktionen ausgetauscht.

Die Sequenzdiagramme in Abbildung 6 geben einen Überblick über den Ablauf und die ausgetauschten Nachrichten während eines beispielhaften Pairings. Teil (a) zeigt den generellen Ablauf mit Fokus auf die Phasen 1 und 3, während die Teile (b) und (c) die zweite Phase für LE Legacy Pairing bzw. LE Secure Connections Pairing darstellen. Die folgenden Abschritte beschreiben diesen Ablauf genauer.

1) Pairing-Phase 1: Pairing Feature Exchange

Im ersten Schritt tauschen die beiden Geräte folgende Informationen aus [5, S. 2308]:

• Sicherheitsanforderungen des GAP an den Kommunikationskanal
• Ein- und Ausgabemöglichkeiten beider Geräte
• Liegen OOB-Daten vor?
• Unterstützte Schlüssellängen (zwischen 56 und 128 Bit)
• Welche Schlüssel sollen in Phase 3 ausgetauscht werden?

Diese Informationen werden vom Initiator in ein Pairing Request Packet, vom Responder in ein Pairing Response Packet kodiert und übertragen (vgl. Abbildung 6 (a)) [5, S. 2340].

2) Pairing-Phase 2: Authentication and Encryption

Beide Geräte leiten aus den in Phase 1 ausgetauschten Informationen ab, ob LE Secure Connections Pairing oder LE Legacy Pairing verwendet wird und welche der vier Pairing-Methoden verwendet wird. In der BLE-Spezifikation sind Tabellen angegeben, die vorgeben, welche Methode wann zu verwenden ist [5, S. 2312 ff.].

Das weitere Vorgehen in Phase 2 unterscheidet sich für LE Legacy Pairing und LE Secure Connections Pairing.

a) LE Legacy Pairing

Es wird zunächst ein gemeinsamer 128-Bit-Temporary Key (TK) ausgetauscht. Daraus wird ein 128-Bit-Short-Term Key (STK) abgeleitet.

Der TK wird je nach Pairing-Methode unterschiedlich erzeugt [5, S. 2315 f.]. In Abbildung 6 (b) ist der Ablauf für die Methode Passkey Entry dargestellt.

• Just Works: Beide Seiten setzen den TK auf null.
• Passkey Entry: Ein Gerät generiert eine zufällige Folge von sechs Dezimalziffern und zeigt diese an. Der Nutzer gibt diese Ziffernfolge auf dem anderen Gerät ein. Alternativ können auch beide Geräte den Benutzer auffordern, eine identische Ziffernfolge einzugeben. Beide Geräte füllen die Dezimalzahl mit Nullbits auf, bis eine Schlüssellänge von 128 Bit erreicht ist. Das Ergebnis wird als TK verwendet.
• OOB: Beide Seiten tauschen über einen zusätzlichen Kanal einen 128 Bit langen Zufallswert aus, der als TK verwendet wird. Die Übertragung ist nicht Gegenstand der Bluetooth-Spezifikation.

Aus dem TK wird im nächsten Schritt der STK generiert. Beide Seiten generieren je einen 128-Bit-Zufallswert Mrand bzw. Srand. Diese Zufallswerte gehen in die Berechnung des STK mit ein. Somit haben beide Seiten die Möglichkeit, Entropie zum STK beizusteuern.

Der Initiator berechnet mit der Funktion c1¹ , die auf dem AES basiert, einen 128-Bit-Wert Mconfirm mit folgenden Eingabedaten:

Mconfirm = c1(TK, Mrand, Pairing Request aus Phase 1, Pairing Response aus Phase 1, Initiator-/Responder-Adresse und deren Art)

Der Responder berechnet mit der Funktion c1 einen 128-Bit-Wert Sconfirm. Die Berechnung ist identisch zu Mconfirm, jedoch wird der Wert Srand statt Mrand verwendet.

Beide Seiten tauschen ihre Bestätigungswerte Mconfirm/Sconfirm und die Zufallswerte Mrand/Srand aus. Anschließend nutzen sie die empfangenen Zufallswerte, um die empfangenen Bestätigungswerte durch Nachrechnen zu überprüfen. Sie können so insbesondere erkennen, ob beide Seiten denselben TK verwenden. Stimmen die Werte nicht überein, wird das Pairing abgebrochen.

Je nach Pairing-Methode kann diese Prüfung auch als Authentifizierung und Man in the Middle (MITM)-Schutz dienen (siehe Tabelle I). Dies lässt sich an der Methode Passkey Entry verdeutlichen: Der TK stimmt nur überein, wenn der Nutzer den korrekten Passkey eingegeben hat. Ein aktiver Man in the Middle müsste daher den Passkey kennen, um die Prüfung zu passieren. Unter der Annahme, dass der Angreifer den Benutzer nicht während des Pairings beobachten kann, müsste er diesen mit einer Erfolgswahrscheinlichkeit von 10^-6 raten [5, S. 2315]. Für die Methode Just Works ist diese Sicherheit nicht gegeben, da der TK bekannt ist.

Im Erfolgsfall generieren beide Seiten den STK mit der Funktion s1, die ebenfalls auf dem AES basiert. Die Funktion konkateniert die oberen 64 Bit der Zufallswerte Srand und Mrand miteinander und verschlüsselt das Ergebnis mit dem Schlüssel TK mit dem AES-Algorithmus:

STK = s1(TK, Srand, Mrand) = AES-128(TK,Srand[64:127] || Mrand[64:127])

(1)

Der STK wird zur Aktivierung der Verschlüsselung auf der aktuellen Verbindung verwendet [5, S. 2315 ff.].

b) LE Secure Connections Pairing

Alternativ zu LE Legacy Pairing kann in Phase 2 auch LE Secure Connections Pairing genutzt werden, sofern beide Seiten dieses Verfahren unterstützen. Der Ablauf ist in Abbildung 6 (c) für die Methode Numeric Comparison dargestellt.

Beide Geräte, die in der Spezifikation auch mit A für den Initiator und B für den Responder bezeichnet werden, benötigen jeweils ein Schlüsselpaar. Dieses muss nur einmalig pro Gerät generiert werden, darf aber optional auch vor einem Pairing erneuert werden. Das Schlüsselpaar besteht aus einem privaten Schlüssel SKa (Initiator) bzw. SKb (Responder) und einem öffentlichen Schlüssel PKa (Initiator) bzw. PKb (Responder). Die öffentlichen Schlüssel sind Punkte auf der elliptischen Kurve P-256, die privaten Schlüssel sind positive Ganzzahlen [5, S. 1692].

Um ein Pairing zu initiieren, tauschen die Geräte zunächst ihre öffentlichen Schlüssel PKa/PKb aus. Aus diesen Schlüsseln können beide Parteien den gemeinsamen Diffie-Hellman-Schlüssel DHKey berechnen:

• A berechnet: DHKey = P256(SKa, PKb)
• B berechnet: DHKey = P256(SKb, PKa)

Die Funktion P256 führt eine Punktmultiplikation auf der elliptischen Kurve P-256 aus und gibt die x-Koordinate des Ergebnispunkts zurück [5, S. 1692].

Der weitere Ablauf des Secure Connections Pairing unterteilt sich in zwei Stufen.

Stufe 1: Der genaue Protokollablauf dieser Stufe ist abhängig von der gewählten Pairing-Methode und ist im Folgenden am Beispiel der Numeric Comparison-Methode beschrieben.

A und B generieren je eine zufällige 128-Bit-Nonce (Na, Nb), die das Protokoll vor Replay-Angriffen schützen. Anschließend setzen beide die Werte ra und rb auf 0. Diese Werte sind nur bei anderen Pairing-Methoden relevant, fließen aber später in Kontrollrechnungen ein. Daher werden sie hier auf einen statischen, bekannten Wert gesetzt.

B generiert nun mit der Einwegfunktion f4 auf Basis des AES-CMAC² einen 128-Bit-Commitment-Wert Cb über PKa, PKb und Nb und schickt diesen an A. Damit legt sich B gegenüber A auf den Wert seiner Nonce Nb fest, ohne sie offenzulegen.

Im nächsten Schritt tauschen die Kommunikationspartner ihre Nonces Na/Nb aus. Da A nun die Nonce Nb kennt, kann er den Commitment-Wert Cb durch Nachrechnen prüfen. Stimmen die Werte nicht überein, wird das Pairing abgebrochen. Wird das Verfahren nach einem Abbruch wiederholt, müssen neue Nonces generiert werden [5, S. 2320].

Im Erfolgsfall berechnen beide Geräte den sechsstelligen Prüfwert (User Confirm Value) Vb = g2(PKa, PKb, Na, Nb) und zeigen ihn dem Nutzer an. Die Funktion g2 berechnet einen AES-CMAC modulo 10⁶. Wenn der Nutzer (auf beiden Geräten, sofern die Eingabemöglichkeiten es erlauben) die Gleichheit der Werte bestätigt, kann mit Stufe 2 fortgefahren werden [5,  S. 2318 ff.].

Auch dieses Verfahren bietet je nach Pairing-Methode Schutz vor MITM-Angriffen. Für die Numeric Comparison-Methode ist der Schutz gegeben: Durch das Commitment von B (Cb) kann ein aktiver Man in the Middle nicht die Nonce Nb von B übernehmen, sondern müsste einen Wert Nb' erraten, der zu demselben User Confirm Value Vb führt wie Nb. Die Erfolgswahrscheinlichkeit dafür liegt bei 10^-6. Da der User Confirm Value durch eine Benutzerinteraktion bestätigt werden muss, ist ein häufiges Wiederholen des Protokolls, bis zufällig eine Übereinstimmung erreicht wird, nicht erfolgversprechend, solange der Benutzer den Vergleich gewissenhaft ausführt. Für die Methode Just Works ist die MITM-Sicherheit nicht gegeben, da kein Vergleich der User Confirm Values stattfindet [5,  S. 2320]. Die Sicherheit der Numeric-Comparison-Methode mit Vergleich der User Confirm Values ist theoretisch beweisbar [8].

Stufe 2: Beide Geräte berechnen aus den ausgetauschten Werten den MacKey und den Long-Term Key (LTK):

MacKey || LTK = f5(DHKey, Na, Nb, A, B)

Die Funktion f5 basiert auf dem AES-CMAC [5, S. 2303 f.]. A und B sind die Geräteadressen von A und B während des Pairings [5, S. 2325].

Um zu prüfen, ob beide Seiten die gleichen Schlüssel MacKey und LTK berechnet haben, berechnen beide einen Prüfwert. Dazu wird die Funktion f6 verwendet, die ebenfalls auf dem AES-CMAC basiert [5, S. 2305]:

• A berechnet:

  Ea = f6(MacKey, Na, Nb, rb, IOcapA, A, B)

  (2)

• B berechnet:

  Eb = f6(MacKey, Nb, Na, ra, IOcapB, B, A)

  (3)

Die Werte IOcapA und IOcapB enthalten in Phase 1 ausgetauschte Informationen (Sicherheitsanforderungen an den Kanal, Ein-/Ausgabemöglichkeiten, Vorhandensein von OOB-Daten) [5, S. 2305].

A und B tauschen die berechneten Werte Ea und Eb aus und prüfen den jeweils empfangenen Wert durch Nachrechnen. Im Fehlerfall wird das Pairing abgebrochen [5, S. 2325].

3) Pairing-Phase 3: Transport Specific Key Distribution (optional)

Im Falle von LE Legacy Pairing kann an dieser Stelle, falls ein Bond aufgebaut werden soll, ein LTK ausgetauscht werden. Dann werden zudem die Werte EDIV und Rand übertragen, die den LTK eindeutig identifizieren. Der LTK kann von beiden Seiten generiert werden.

Sowohl LE Legacy Pairing als auch LE Secure Connections Pairing unterstützen darüber hinaus den beidseitigen Austausch der folgenden Schlüssel [1, S. 245 f.]:

• Identity Resolving Key (IRK): Dieser Schlüssel wird zum Generieren und Auflösen von Adressen verwendet (siehe Unterabschnitt III-B). Außerdem kann die öffentliche Geräteadresse in einem Identity Address Information Packet übertragen werden.
• Connection Signature Resolving Key (CSRK): Dieser Schlüssel wird zur Signatur und zur Verifikation im LE Security Mode 2 verwendet (siehe Unterabschnitt III-C).

Der IRK und der CSRK existieren genau ein Mal pro Gerät, nicht pro Verbindung. Somit schützen sie nur vor Angreifern, die diese Schlüssel nie mit dem Gerät ausgetauscht haben [5, S. 2327 f.].

Abbildung 6 (a) zeigt beispielhaft die Übertragung eines LTK (mitsamt dessen Identifikationsmerkmalen), eines IRK und eines CSRK durch den Slave an den Master.

B. Random Addresses

Um das Erstellen von Bewegungsprofilen über BLE-Geräte anhand ihrer Adresse zu erschweren, können zufällige Geräteadressen (Random Addresses) verwendet werden. BLE-Adressen sind immer 48 Bit lang. Random Addresses heißen resolvable, wenn ein dazu autorisierter Kommunikationspartner aus diesen Adressen auf die Identität des Geräts zurückschließen kann. Dafür muss zuvor der IRK ausgetauscht worden sein. Um eine Resolvable Random Address zu generieren, wird zunächst eine 24-Bit-Zufallszahl prand generiert. Aus der Zufallszahl wird ein 24-Bit-Hashwert hash = ah(IRK, prand) auf Basis des AES berechnet. Die Adresse setzt sich dann aus der Konkatenation dieser Werte zusammen: hash || prand.

Ein BLE-Gerät im Scanning-Modus kann diese Adresse mithilfe des IRK auflösen. Es zerlegt jede Adresse in zwei 24 Bit lange Hälften hash || prand und berechnet: localHash = ah(IRK, prand). Falls hash und localHash übereinstimmen, kann die Adresse dem Inhaber des IRK zugeordnet werden [5, S. 2558 f.].

C. Signieren von Daten

Der LE Security Mode 2 sieht das Übertragen signierter Daten über eine unverschlüsselte Verbindung vor. Der Vorteil gegenüber einem verschlüsselten Datenkanal ist der schnellere Verbindungsaufbau und eine höhere Übertragungsrate [1, S. 355 f.]. Zur Initialisierung wird der Schlüssel CSRK im Rahmen eines Pairings ausgetauscht. Dieser symmetrische Schlüssel wird zur Signatur und zur Verifikation mit dem AES-CMAC-Verfahren genutzt [5, S. 2333 ff.]. Die Signatur wird von der SM-Schicht an ein Datenpaket (Protocol Data Unit (PDU)) angehängt und besteht aus einem 4-Byte-Zähler sowie einer 8-Byte-Signatur [5,  S. 2077].

IV. Schwachstellen und Angriffe

Die bekannten Angriffe und Schwachstellen lassen sich in drei Kategorien aufteilen: Schwächen in Protokollen oder der Spezifikation, Implementierungsschwachstellen und inhärente Schwachstellen von Drahtlostechnologien.

A. Protokoll- und Spezifikationsschwachstellen

Die folgenden Abschnitte beschreiben Schwachstellen, die in der Spezifikation von BLE und den darin beschriebenen Protokollen begründet sind.

1) Abhören des Legacy Pairings

Ein passiver Angreifer, der das Pairing abhört, kann die während des LE Legacy Pairing mit einer der Methoden Just Works oder Passkey Entry ausgetauschten Schlüssel durch einen Brute Force-Angriff rekonstruieren. Die Schwäche liegt im geringen Schlüsselraum bei der Generierung des TK. Der Angreifer muss maximal 1.000.000 Schlüssel ausprobieren, um TK zu erraten (siehe Absatz III-A 2a). Die Software Crackle führt diesen Angriff auf einer Core i7-CPU in weniger als einer Sekunde aus. Ist der TK bekannt, kann aus dem weiteren Protokollablauf leicht der STK rekonstruiert werden, da dieser nur von TK und den im Klartext übertragenen Werten Srand und Mrand abhängt (siehe Gleichung 1). Mit Kenntnis des STK kann der Angreifer auch die in Phase 3 ausgetauschten Schlüssel sowie jede weitere Kommunikation, die mit einem eventuell ausgetauschten LTK verschlüsselt wird, entschlüsseln [9, S. 4 f.].

Ein LE Legacy Pairing mit der Methode Just Works oder Passkey Entry erzeugt also nur dann einen vertraulichen Kanal, wenn das Pairing in einer vertrauenswürdigen Umgebung durchgeführt wurde. Bei LE Legacy Pairing mit der OOB-Methode hängt die Größe des Schlüsselraums bei der Generierung des TK von der konkreten Implementierung ab. Die OOB-Methode kann daher sicherer sein als Just Works und Passkey Entry [5, S. 2315 f.].

2) Aktiver MITM-Angriff

Wird eine Pairing-Methode verwendet, die die Authentizität der Gegenseite nicht sicherstellen kann, ist es einem Angreifer möglich, eine Verbindung zu beiden Kommunikationspartnern aufzubauen und die Nachrichten der Geräte untereinander weiterzuleiten. Um eine solche Verbindung zu initiieren, kann z. B. Advertisement Spoofing (siehe Unterunterabschnitt IV-C1) verwendet werden. Der Angreifer kann dann Nachrichten einsehen, einfügen, verändern oder verwerfen. Mit der Software GATTacker kann der Angreifer gegenüber dem Master den Slave imitieren, inklusive der angebotenen Services und Characteristics. Die Software erlaubt es, Services und Characteristics des originalen Gerätes auf GATT-Ebene auszulesen und zu übernehmen [10,  S. 8 ff.].

3) Manipulation der Pairing-Phase 1/Downgrade auf Just Works

Der folgende Angriff ist in [11] für Secure Simple Pairing bei Bluetooth Classic beschrieben. Da die Protokollabläufe jedoch analog zum LE Secure Simple Pairing sind, ist die Übertragbarkeit wahrscheinlich.

Ein aktiver Man in the Middle kann die in Phase 1 des Pairing-Prozesses ausgetauschten Nachrichten über die Ein- und Ausgabemöglichkeiten der Geräte so manipulieren, dass die Kommunikationspartner zu daraus ableiten, dass sie nur die Just Works-Methode zum Pairing verwenden können. Dies ist möglich, da die Nachrichten in Phase 1 über einen unverschlüsselten und nicht authentifizierten Kanal ausgetauscht werden. Durch die Auswahl von Just Works als Pairing-Methode kann auch das Pairing keine Authentifizierung leisten, sodass der Man in the Middle weiter aktiv bleiben kann. Auch die Berechnung von Ea und Eb in Stufe 2, in die die Werte IOcapA/B einfließen (siehe Gleichung 2 und 3), bieten keinen wirksamen Schutz, da der Angreifer diese ebenfalls mit den manipulierten Werten aus Phase 1 berechnen kann [11,  S. 3 f.].

4) Weitere Schwachstellen

Das NIST übt generelle Kritik an der BLE-Spezifikation. Es werden insbesondere die folgenden Eigenschaften bemängelt [12,  S. 37 ff.]:

• Existenz des LE Security Mode 1 Level 1: Es ist möglich, BLE ohne Sicherheitsmechanismen (weder Verschlüsselung noch Authentifizierung) zu verwenden.
• Es findet grundsätzlich keine Authentifizierung des Nutzers, sondern immer eine Authentifizierung des Geräts statt.
• Es ist erlaubt, statische Diffie-Hellman-Schlüssel zu verwenden, statt vor jeder Verbindung neue Schlüssel zu generieren.
• Der Bluetooth-Standard berücksichtigt nur ausgewählte Sicherheitsziele (i. W. Authentifizierung, Vertraulichkeit, Privatsphäre) und bspw. nicht Audit-Logs oder Nicht-Abstreitbarkeit.

B. Implementierungsschwachstellen

Die folgenden Abschnitte beschreiben Schwachstellen, die auf Implementierungsfehler oder Implementierungsentscheidungen zulasten der Sicherheit zurückzuführen sind.

1) Schlechte Zufallszahlengeneratoren

Die Sicherheit vieler kryptografischer Anwendungen hängt von der Möglichkeit ab, nicht vorhersagbare Bitfolgen zu erzeugen. Gerade auf ressourcenbeschränkten Geräten ist es jedoch schwierig, eine ausreichend hohe Entropie zu erreichen. In der Vergangenheit sind Implementierungen aufgefallen, die bspw. auf die letzten Stellen des Messwerts eines Temperatursensors zurückgriffen. Diese ähneln auf den ersten Blick einem zufälligen Rauschen, nähere Betrachtung zeigte jedoch Muster in der erzeugten Bitfolge auf [13],  [10, S. 10].

2) Android: Unsichere Speicherung von Schlüsseln

Das Betriebssystem Android verwaltet Bonds und die zugehörigen kryptografischen Schlüssel zentral und systemweit statt getrennt pro Applikation. Sivakumaran und Blasco [14] haben dieses Verhalten auf mehreren Android-Versionen bis 8.1.0 untersucht und beobachtet.

Eine Angreifer-App kann über die Android-Bluetooth-API auf Bonds zurückgreifen, die durch andere, legitime Apps aufgebaut wurden. Die Angreifer-App hat gegenüber dem BLE-Gerät dieselben Berechtigungen und kann bspw. auf geschützte Charakteristiken zugreifen. Für solche Zugriffe auf ein gleichzeitig mit dem Smartphone verbundenes Gerät sind lediglich die Android-Berechtigungen BLUETOOTH und BLUETOOTH_ADMIN erforderlich, die keine gesonderte Bestätigung durch den Benutzer erfordern. Nur für das Scannen nach Geräten – und damit für den Verbindungsaufbau – ist ab Android 6 die Berechtigung LOCATION erforderlich, die eine separate Benutzerbestätigung bei der ersten Nutzung erfordert [14,  S. 3 ff.].

3) Nichtnutzung der Sicherheitsmechanismen von BLE

Laut [10, S. 5] implementiere eine „signifikante Anzahl“ von BLE-Geräten keine Sicherheitsmechanismen wie Random Addresses oder Pairing. Die Aussage wird in der Veröffentlichung nicht weiter quantifiziert.

Eine Untersuchung von acht Fitness-Armbändern von acht verschiedenen Herstellern kam zu dem Ergebnis, dass nur eines davon Random Addresses verwendet [15, S. 24]. Eine andere Untersuchung von vier Fitness-Trackern zeigte, dass nur ein Gerät Sicherheitsmaßnahmen implementierte, die einen vertraulichen und authentifizierten Kanal zwischen Tracker und Smartphone etablieren [16, S. 423 f.].

4) BleedingBit

Zwei Schwachstellen der BLE-Chipfamilie Texas Instruments CC26xx wurden unter der Bezeichnung BleedingBit veröffentlicht [17]. Diese Chips sind u. a. in WLAN Access Points verbaut, um bspw. Ortsdaten oder zusätzliche Wartungsschnittstellen bereitzustellen. Beide Schwachstellen erlauben einem nicht authentifizierten Angreifer die Ausführung von Code über die BLE-Funkschnittstelle.

Die erste Schwachstelle (CVE-2018-16986) ist eine unzureichende Validierung des Längenfelds von BLE Advertising Packets. Die zwei Bits, die in der Bluetooth-Spezifikation mit RFU markiert sind (siehe Unterabschnitt II-B), werden fälschlicherweise dem Längenfeld zugerechnet. Ein Angreifer kann über die Payload von Advertising Packets Shellcode im RAM des BLE-Chips platzieren, durch das Setzen der RFU-Bits einen Buffer Overflow erzeugen und einen Function Pointer im RAM überschreiben, sodass der Shellcode ausgeführt wird [17, S. 6 ff.].

Die zweite Schwachstelle (CVE-2018-7080) geht auf die mangelhafte Implementierung der Firmware-Update-Prozedur des BLE-Chips zurück. Texas Instruments liefert zu diesem Zweck eine Routine, die die Gerätehersteller an ihre Bedürfnisse anpassen können. In der Standardkonfiguration findet keine Authentifizierung des übertragenen Firmware-Updates statt. Auch der Einsatz von Verschlüsselung ist optional. Beispielhaft untersuchte Access Points des Herstellers Aruba forderten als einzigen Schutzmechanismus die vorherige Übertragung eines fixen, geheimen Wertes, der sich aus der Original-Firmware extrahieren ließ. Da der BLE-Chip in diesen Access Points auch als Wartungsschnittstelle dient, kann eine modifizierte Firmware des BLE-Chips leicht Kontrolle über die WLAN-Funktionalität erlangen [17, S. 27 ff.].

C. Inhärente Schwachstellen einer Drahtlostechnologie

Die folgenden Abschnitte beschreiben Angriffe, die durch die Verwendung einer Funkschnittstelle ermöglicht werden.

1) Advertisement Spoofing

Ein Angreifer kann gefälschte Advertisements in möglichst kurzen Intervallen aussenden. Diese Advertisements enthalten je nach Angriffsszenario die Adresse des echten Geräts oder vom Angreifer gewählte Werte im Datenfeld für herstellerspezifische Daten (siehe Unterabschnitt II-J). Ein Gerät, das eine Verbindung aufbaut, reagiert auf das zuerst empfangene Advertisement. Die Erfolgswahrscheinlichkeit kann durch Jamming (siehe Unterunterabschnitt IV-C3) des echten Senders weiter erhöht werden. Der Angreifer kann so einen Denial of Service (DoS)-Zustand herbeiführen oder den Advertisement-Empfängern falsche Informationen über das Datenfeld übermitteln. Einige Hersteller haben als Gegenmaßnahme eine Verschlüsselung oder Signatur der Inhalte des Datenfelds implementiert [10, S. 7].

2) Denial-of-Sleep-Angriffe

BLE-Slaves arbeiten oft batteriebetrieben. Ihre Energiespeicher sind so ausgelegt, dass sie bei einem angenommenen Durchschnittsverbrauch eine gewisse Lebensdauer T_life erreichen. Der tatsächliche Verbrauch hängt jedoch stark von der Aktivität des Geräts ab.

Für BLE sind zwei Betriebsmodi zu unterscheiden: Aktivität (Senden, Empfangen oder Durchführen von Berechnungen) und Inaktivität. Denial of Sleep (DoSL)-Angriffe haben das Ziel, die Batterielebensdauer T_life zu verringern, indem sie die Zeit T_active, die das Gerät im aktiven Zustand verbringt, maximieren [18, S. 1232 f.].

Uher et al. [18] haben Experimente am Beispiel eines Fitness-Armbands durchgeführt. Sie identifizierten durch Abhören der Kommunikation zwischen Fitness-Armband und Smartphone ein Sensor Dump Command, das dazu führt, dass das Gerät mit einer großen (nicht näher quantifizierten) Datenmenge antwortet. Zusätzlich füllten die Autoren das an das Armband gesendete Anfrage-Paket bis zur maximal zulässigen Paketgröße mit zufälligen Bytes auf, um die Funkschnittstelle möglichst lange aktiv zu halten. So war es möglich, die Batterielebensdauer von 120 Stunden im Normalbetrieb auf 6 Stunden zu reduzieren [18,  S. 1233 ff.].

3) Gezieltes Jamming

Funktechnologien lassen sich prinzipbedingt durch das Senden von Störsignalen im verwendeten Frequenzbereich in einen DoS-Zustand versetzen. Dieser allgemeine Angriff ist jedoch leicht erkennbar und für den Störer relativ energieaufwendig, da permanent auf einem weiten Frequenzbereich gesendet werden muss. Effizienter und unauffälliger ist dagegen die selektive Störung der Advertisement-Pakete ausgewählter BLE-Geräte [19, S. 1].

Brauer et al. [19] beschreiben einen BLE-Jammer, der Advertisement Packets anhand der darin enthaltenen Absenderadresse stört. Dazu werden die Zieladressen zunächst in eine Whitelist eingetragen. Der Jammer lauscht auf dem ersten Advertising-Kanal, bis er die Bitfolge 0x8E89BED6 erkennt. Dies ist die Access Address, die jedes Advertisement Packet enthält. Ab dieser Position wertet der Jammer noch die nächsten 64 Bit aus, nämlich die 8 Bit des Headers, die 8 Bit des Längenfelds und die ersten 48 Bit der Payload, die der Absenderadresse entsprechen (siehe Unterabschnitt II-B). Sofern die Adresse in der Whitelist enthalten ist, wird der BLE-Transciever des Jammers in den Sendemodus versetzt und ein kurzes Störsignal ausgesendet. Für den Moduswechsel werden ca. 140 µs benötigt. Das gesendete Signal stört die weitere Übertragung des Advertisement Packets und führt dazu, dass die CRC-Prüfsumme auf Empfängerseite nicht mehr zu den Paketdaten passt. Das Paket wird daher verworfen. Da BLE-Geräte ihre Advertisements meist nacheinander auf allen drei Advertisement-Kanälen aussenden, wechselt der Jammer in den nächsten Advertisement-Kanal und wiederholt die Stör-Prozedur [19,  S. 4].

V. Zusammenfassung und Ausblick

Die Sicherheitsmechanismen von BLE sind das Ergebnis von Abwägungen zwischen Sicherheit, Benutzbarkeit und Energieeffizienz. Die Spezifikation lässt den Implementierern bewusst große Spielräume zulasten der Sicherheit, um auch in äußerst ressourcenbeschränkten Anwendungsfällen anwendbar zu sein. Mit der Einführung von LE Secure Connections Pairing durch die Spezifikation 4.2 ist ein Pairing-Verfahren verfügbar, das einen authentifizierten und vertraulichen Kanal auch in Anwesenheit passiver Angreifer etabliert. Einzig der Downgrade-Angriff durch einen aktiven MITM bleibt eine Gefahr.

In Szenarien, in denen mit BLE ausschließlich nicht-authentifizierte Verbindungen aufgebaut werden können, da keine ausreichenden Ein-/Ausgabemöglichkeiten vorliegen, müssen Gerätehersteller bei Bedarf selbst zusätzliche Mechanismen (bspw. über digitale Signaturen oder eine Public-Key-Infrastruktur (PKI)) implementieren, die eine Authentifizierung auch in diesen Fällen sicherstellen können. Diese lassen sich in die bestehenden Strukturen des Protocol Stacks integrieren.

In der Praxis scheint sich noch ein anderer Schwachpunkt herauszukristallisieren: Die von Geräteherstellern zu treffende Abwägung zwischen Entwicklungsaufwand, Sicherheit und Benutzbarkeit fällt offenbar häufig zulasten der Sicherheit aus, indem sie die Spielräume der Spezifikation nutzen und auf Sicherheitsmaßnahmen weitgehend verzichten, auch wenn die Implementierung grundsätzlich möglich wäre. Im Falle von Wearables und ähnlichen Geräten für Endbenutzer könnten hier die Hersteller von Smartphone-Betriebssystemen gegensteuern, indem sie den Benutzer vor der Nutzung ungesicherter Kommunikationskanäle warnen.

Literatur

[1]    N. K. Gupta, Inside Bluetooth Low Energy, 2nd ed. Boston, London: Artech House, 2016.

[2]    R. Heydon, Bluetooth Low Energy: The Developer’s Handbook. Prentice Hall, 2012.

[3]    Bluetooth SIG, “Bluetooth Core Specification v4.2,” Dec. 2014. [Online]. Available: https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=286439

[4]    ——, “Bluetooth Service Specification: Heart Rate Service,” Jul. 2011. [Online]. Available: https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=239866

[5]    ——, “Bluetooth Core Specification v5.0,” Dec. 2016. [Online]. Available: https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=421043

[6]    Information Technology Laboratory, “Digital Signature Standard (DSS),” National Institute of Standards and Technology, Gaithersburg, MD, Tech. Rep. NIST FIPS 186-4, Jul. 2013. [Online]. Available: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf

[7]    M. Dworkin, “Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication,” National Institute of Standards and Technology, Gaithersburg, MD, Tech. Rep. NIST SP 800-38B, Oct. 2016. [Online]. Available: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38B.pdf

[8]    A. Y. Lindell, “Comparison-Based Key Exchange and the Security of the Numeric Comparison Mode in Bluetooth v2.1,” in Topics in Cryptology – CT-RSA 2009, ser. Lecture Notes in Computer Science, M. Fischlin, Ed. Springer Berlin Heidelberg, 2009, pp. 66–83.

[9]    M. Ryan, “Bluetooth: With Low Energy Comes Low Security,” in USENIX Workshop on Offensive Technologies (WOOT), 2013. [Online]. Available: https://www.usenix.org/system/files/conference/woot13/woot13-ryan.pdf

[10]    S. Jasek, “Gattacking Bluetooth Smart Devices,” 2016. [Online]. Available: https://github.com/securing/docs/raw/master/whitepaper.pdf

[11]    K. Hypponen and K. M. J. Haataja, ““Nino” man-in-the-middle attack on bluetooth secure simple pairing,” in 2007 3rd IEEE/IFIP International Conference in Central Asia on Internet, Sep. 2007, pp. 1–5.

[12]    J. Padgette, J. Bahr, M. Batra, M. Holtmann, R. Smithbey, L. Chen, and K. Scarfone, “Guide to Bluetooth Security,” National Institute of Standards and Technology, Gaithersburg, MD, Tech. Rep. NIST SP 800-121r2, May 2017. [Online]. Available: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-121r2.pdf

[13]    S. Joshi, “BGScript Random Number Generator,” Apr. 2015. [Online]. Available: http://www.sureshjoshi.com/embedded/bgscript-random-number-generator/

[14]    P. Sivakumaran and J. Blasco, “Attacks Against BLE Devices by Co-located Mobile Applications,” arXiv:1808.03778 [cs], Aug. 2018. [Online]. Available: http://arxiv.org/abs/1808.03778

[15]    A. Hilts, C. Parsons, and J. Knockel, “Every Step You Fake: A Comparative Analysis of Fitness Tracker Privacy and Security,” 2016. [Online]. Available: https://openeffect.ca/reports/Every_Step_You_Fake.pdf

[16]    Q. Zhang and Z. Liang, “Security analysis of bluetooth low energy based smart wristbands,” in 2017 2nd International Conference on Frontiers of Sensors Technologies (ICFST), Apr. 2017, pp. 421–425.

[17]    B. Seri, G. Vishnepolsky, and D. Zusman, “The hidden attack surface within BLE chips,” 2018. [Online]. Available: https://go.armis.com/bleedingbit

[18]    J. Uher, R. G. Mennecke, and B. S. Farroha, “Denial of Sleep attacks in Bluetooth Low Energy wireless sensor networks,” in MILCOM 2016 – 2016 IEEE Military Communications Conference, Nov. 2016, pp. 1231–1236.

[19]    S. Brauer, A. Zubow, S. Zehl, M. Roshandel, and S. Mashhadi-Sohi, “On practical selective jamming of Bluetooth Low Energy advertising,” in 2016 IEEE Conference on Standards for Communications and Networking (CSCN), Oct. 2016, pp. 1–6.

Fußnoten

¹Für ausführlichere Definitionen der hier nur kurz beschriebenen Funktionen sei auf die Bluetooth-Spezifikation [5, S. 2297 ff.] verwiesen. ⤴

²Der Cipher-based Message Authentication Code (CMAC)-Algorithmus und der gleichnamige Betriebsmodus für Blockchiffren sind in [7] durch das NIST standardisiert [5, S. 2333 f.]. ⤴

---

Wie immer gilt natürlich, dass ich vor Irrtümern nicht gefeit bin. Wenn du also etwas besser weißt, oder meinst, dass ich etwas Wichtiges vergessen habe, hinterlasse gerne einen Kommentar oder schreib mir eine Mail. Dasselbe gilt für Layout-Fehler oder fehlerhafte Links – ich habe den Text von LaTeX nach HTML umgewandelt und manuell nachbearbeitet, dabei können Fehler passiert sein.