2024-11-14

Table of Contents

Einführung

In meiner Bachelorarbeit habe ich unter anderem die Bluetooth Low Energy Verbindung eines Fitnesstrackers mit einer Android App untersucht.
Dieser Artikel soll als Leitfaden dienen, um Bluetooth Low Energy Verbindungen auf Sicherheitsproblematiken zu untersuchen.

Bluetooth Low Energy

Die drahtlose Bluetooth-Technologie ist eine für kurze Distanzen geeignete Kommunikationsmethode, die erstmals in den 1990er Jahren entwickelt wurde (Bluetooth SIG, 2024). Bluetooth ist besonders robust und hat einen geringen Energieverbrauch bei gleichzeitig niedrigen Herstellungskosten. Die Technologie verfügt über viele Funktionalitäten, von denen einige optional sind, und kann in verschiedenen Produkten eingesetzt werden.
Es existieren zwei Varianten von Bluetooth: Basic Rate (BR) und Low Energy (LE). Während BR mit der optionalen Enhanced Data Rate (EDR)-Erweiterung für Anwendungsfälle mit einer höheren Anforderung an Datenübertragung gedacht ist, bei denen der Stromverbrauch eine untergeordnete Rolle spielt, ermöglicht LE einen geringeren Energieverbrauch, geringere Kosten und geringere Komplexität. Für Lautsprecher wird beispielsweise das klassische Bluetooth BR verwendet, während Bluetooth LE bei Geräten wie Fitnesstracker eingesetzt wird.
Bluetooth Low Energy (BLE), auch als Bluetooth Smart bekannt, arbeitet in der unlizenzierten 2,4 GHz Frequenz und verwendet Sprünge über verschiedene Frequenzen, um Störungen zu vermeiden (Bluetooth SIG, 2024, S. 190).

Bluetooth LE Protocol Stack Bluetooth LE Protocol Stack

Der Bluetooth Protocol Stack besteht aus einem Host und einem oder mehreren Controllern. Ein Host ist dabei definiert als eine logische Einheit über dem Host Controller Interface (HCI) und ein Controller als eine logische Einheit unter dem HCI. Das HCI abstrahiert also die LE- oder BR-Controller mit einem einheitlichen Interface, wodurch es möglich wird, dass die Protokolle im Host unabhängig vom Controller funktionieren (Bluetooth SIG, 2024, S. 187-188). Diese Unterteilung in Host und Controller ermöglicht auch, dass Host und Controller von unterschiedlichen Herstellern produziert werden können. Nachfolgend wird der Bluetooth Protocol Stack am Beispiel eines LE-Controllers erklärt.
Die physikalische Schicht (Physical Layer) verwaltet die Radio Frequency (RF)-Operationen wie Adaptive Frequency Hopping (nachfolgend Channel Hopping). BLE teilt dabei die Frequenzen zwischen 2400 MHz und 2483,5 MHz in 40 RF Channel mit jeweils 2 MHz ein, die in der folgenden Tabelle dargestellt sind:

BLE Physical Channel indices BLE Physical Channel indices (Bluetooth SIG, 2024, S. 2680-2682)

Drei RF Channel werden für das Advertising als „Primary Advertising Channel“ reserviert und 37 RF Channel als „General-Purpose Channels“ für den Großteil der Kommunikation.
Um beim Channel Hopping im LE den Channel für die nächste Nachricht zu errechnen, werden zwei Werte benötigt. Das hopIncrement beschreibt, wie viele Channel gesprungen werden soll und das hopInterval nach wie vielen Nachrichten in den nächsten Channel gesprungen werden soll. Daraus ergibt sich eine einfache Formel, um den Channel zu berechnen, der als nächstes verwendet wird unmappedChannel = (lastUnmappedChannel + hopIncrement) mod 37 (Bluetooth SIG, 2024, S. 2817). Der lastUnmappedChannel wird beim ersten Verbindungsaufbau mit 0 initiiert und für das hopIncrement wird eine zufällige Ganzzahl zwischen 5 und 16 gewählt (Bluetooth SIG, 2024, S. 2703). Wenn die Verbindung geschlossen wird, wird der lastUnmappedChannel für den nächsten Verbindungsaufbau auf den unmappedChannel gesetzt.

Der Link Layer hat sieben verschiedene Zustände: Standby, Advertising, Scanning, Initiating, Connection, Synchronization und Isochronus Broadcasting (Bluetooth SIG, 2024, S. 2673). Zu jeder Zeit darf nur einer der Zustände aktiv sein, weshalb die Zustände und deren Übergänge gut in einem Zustandsdiagramm dargestellt werden können:

Zustandsdiagramm der Link Layer State Machine (Bluetooth SIG, 2024, S. 2676)

Die einzelnen Zustände werden in dem folgenden Beispiel für einen Verbindungsaufbau erklärt: Gerät A befindet sich im Advertising-Zustand, in dem der Link Layer „Advertising Physical Channel“ Pakete mithilfe von Undirected Advertising versendet und auf Antworten wartet. Gerät B wechselt aus dem Standby-Zustand, in dem keine Pakete versendet oder empfangen werden können, in den Scanning-Zustand, um auf Advertising Physical Channel-Pakete zu hören. Sobald Gerät B dann ein Advertising Paket von Gerät A empfängt, wechselt Gerät B über den Standby-Zustand in den Initiating-Zustand und baut eine Verbindung auf, um in den Connection-Zustand wechseln zu können. Alternativ könnte, insofern die beiden Geräte schon einmal eine Verbindung in der Vergangenheit aufgebaut haben, Gerät A nur Directed Advertising-Pakete an Gerät B senden, welches, ohne in den Scanning-Zustand zu wechseln, aus dem Initiating-Zustand dann direkt in den Connection-Zustand wechseln kann. Für Directed Advertising pflegt der Advertiser (Gerät A) eine Whitelist mit den betreffenden Geräten.

Die Schicht L2CAP ist u. a. zuständig für Fragmentierungen, Flusskontrolle und Fehlermanagement (Bluetooth SIG, 2024, S. 1014-1017). Da sich bei untersuchungen von Geräten nicht mit diesen Grundlegenden Bluetooth Funktionen auseinandergesetzt wird, wird nicht tiefer auf L2CAP eingegangen.

Auf dem Host Layer arbeiten Protokolle wie das Security Manager Protocol (SMP) und das Attribute Protocol (ATT). SMP behandelt die Schlüsselgenerierung und Schlüsselverwaltung für Verschlüsselung und Identitäten von Geräten und das darüberliegende Generic Access Profile (GAP) ist für das Advertising, Verbindungsverwaltung und Rollenmanagement zuständig (Bluetooth SIG, 2024, S. 206-207). ATT und das darauf aufbauende Generic Attribute Protocol (GATT) ermöglichen die einfache Datenübertragung mithilfe von Key Value-Paaren mit Operationen wie Lesen, Schreiben und dem Abonnieren von Benachrichtigungen und Indikationen (Bluetooth SIG, 2024, S. 280).

Bluetooth Device Address

Netzwerkgeräte besitzen eine Medium Access Control (MAC)-Adresse, die sie eindeutig identifizieren. Im Bluetooth Standard wird diese als Bluetooth Geräte Adresse (Bluetooth Device Address) bezeichnet (Bluetooth SIG, 2024, S. 1366, 2677). Das große Problem von öffentlichen MAC-Adressen (Public MAC Addresses) ist, dass dadurch Geräte dauerhaft Advertising-Pakete versenden. Hierdurch kann ein Gerät, wie beispielsweise ein Smartphone, verfolgt werden und damit auch sein Besitzer. Dafür wären jedoch über eine große Fläche verteilte Sensoren notwendig, die die Advertising-Pakete aller Geräte erfassen. Da das ein signifikantes Problem für die Privatsphäre vieler Menschen verursachen würde, wurde, neben der öffentlichen Geräte Adresse, die zufällige Geräte Adresse (Random Device Address) eingeführt. Eine zufällige Geräte Adresse ist, wie der Name bereits sagt, zufällig generiert und kann entweder eine statische Adresse (Static Address) oder private Adresse (Private Address) sein. Folgende Abbildung illustriert das Format von zufälligen Bluetooth Adressen:

Format von zufälligen Bluetooth Adressen (Bluetooth SIG, 2024, S. 2678)

Welche Art von zufälliger Geräte Adresse ein Gerät besitzt, kann durch das 47 und 48 Bit der Adresse ermittelt werden, die in der folgenden Tabelle aufgeführt sind:

Random Bluetooth Device Adress sub-types (Bluetooth SIG, 2024, S. 2678)

Eine zufällige statische Adresse wird nach jedem Einschalten generiert und kann sich, während das Gerät angeschaltet bleibt, nicht mehr ändern. Das Problem ist, dass das Smartphone einen zuvor verbundenen Fitness-Tracker aufgrund einer neuen zufälligen Adresse nicht mehr zuordnen kann. Dementsprechend muss die Verbindungen komplett neu aufgebaut werden.
Die anderen privaten Adressen werden, selbst wenn das Gerät eingeschaltet ist, regelmäßig neu generiert. Sie unterscheiden sich ein weiteres Mal in auflösbare (resolvable) und nicht-auflösbare (non-resolvable) Adressen.
Zufällige auflösbare private Adressen ermöglichen im Gegensatz zu zufälligen statischen Adressen, dass die Identität des Geräts aufgelöst werden kann, wenn das Gerät sich schon einmal mit dem Smartphone verbunden hat. Das wird durch einen Local oder Peer Identity Resolving Key (IRK) möglich, der bei der ersten Verbindung ausgetauscht wird. Wenn das Smartphone dann die Advertising-Pakete des Fitness-Trackers empfängt, kann es mithilfe des IRK überprüfen, ob es sich schon einmal mit diesem Fitness-Tracker verbunden hat und den Fitness-Tracker dann dem gespeicherten äquivalent Gerät zuordnen.

Format einer zufälligen auflösbaren privaten Adresse (Bluetooth SIG, 2024, S. 2679)

Für die Überprüfung der in der obenstehenden Abbildung gezeigten Adresse, wird ein einfacher Hash über der aus der MAC-Adresse zu entnehmenden Zahl prand und dem IRK generiert, der dann mit dem Hash aus der MAC-Adresse übereinstimmen muss (Bluetooth SIG, 2024, S. 2678-2680).
Im Gegensatz zu zufälligen auflösbaren privaten Adressen kann eine zufällige nicht-auflösbare private Adresse nicht aufgelöst werden. Der Unterschied einer zufälligen nicht-auflösbaren privaten Adresse zu einer zufälligen statischen Adresse ist, dass die Geräte, mit denen eine Verbindung aufgebaut wird, deren Adresse nicht speichern. Andere Bluetooth Geräte wissen durch den Adresstyp, dass sie das Gerät später nicht mehr wiedererkennen und sich dementsprechend auch nicht mehr mit diesem verbinden können.
Durch die zufälligen Geräteadressen ist es also nicht mehr möglich, ein Gerät anhand seiner MAC zu verfolgen. Auch wenn das Smartphone den Fitness-Tracker wiedererkennen sollte, wird die Verbindung immer noch über die öffentlich einsehbare zufällige Adresse aufgebaut.

Pairing

Um eine verschlüsselte Verbindung aufbauen zu können, benötigen beide Geräte denselben Schlüssel. Der Prozess des Informations- und Schlüsselaustauschs wird als Pairing bezeichnet und wird unter BLE vom Security Manager mit dem Security Manager Protocol (SMP) übernommen. Das Protokoll wird verwendet, um neben Verbindungsinformationen auch Schlüssel auszutauschen, die für eine verschlüsselte Verbindung oder zur Wiedererkennung des Geräts benötigt werden. Nach dem Austausch der Schlüssel kann optional ein Bonding stattfinden, was so viel bedeutet, dass beide Geräte Schlüssel speichern, um später schneller eine Verbindung aufbauen zu können.
Nachfolgend wird das Gerät, das die Verbindung initiiert, „Initiator“ und das, welches auf die Verbindungsanfrage antwortet, „Responder“ genannt.

Feature Exchange

Bevor die Verbindung verschlüsselt werden kann, müssen beide Parteien ihre unterstützten Sicherheitsfunktionen austauschen. Dementsprechend sind die zu diesem Zeitpunkt versendeten Pakete nicht verschlüsselt. Dafür sendet der Initiator ein „Pairing Request“-Paket und der Responder antwortet mit einem „Pairing Response“-Paket.

SMP Pairing Request/ Response Paket Aufbau (Bluetooth SIG, 2024, pp. 1590-1595)

Sowohl das Pairing Request- als auch das Pairing Response-Paket enthalten verschiedene Informationen oder auch Flags, sind aber wie folgt gleich aufgebaut:

  • Code: Eindeutiger Optcode für den Pakettyp; 0x01 entspricht dem Pairing Request und 0x02 der Pairing Response
  • I/O Cap: Input/Output (IO) Funktionalitäten
    Mögliche Werte für I/O Funktionalitäten im SMP Pairing Request/ Response Paket (Bluetooth SIG, 2024, S. 1591)
  • OOB Data Flag: Beschreibt, ob die Out-of-Band (OOB)-Authentifizierung möglich ist, wobei 0x01 beschreibt, dass ein Gerät vorhanden und 0x00, dass kein Gerät vorhanden ist
  • AuthReq: Angefragte Security Eigenschaften
  • Maximum Encryption Key Size: Maximale Größe für den Verschlüsselungsschlüssel. Die Größe des Schlüssels muss minimal 7 Bytes und kann maximal 16 Bytes betragen (Bluetooth SIG, 2024, p. 1562). Verwendet wird der kleinste Wert der zwischen den Geräten übertragenen maximalen Schlüsselgrößen
  • Initiator und Responder Key Distribution/Generation: Beschreibt, welche Schlüssel der Initiator/Responder anfragt, die der Responder/Initiator verteilen/generieren soll

Die angefragten Sicherheitseigenschaften, kurz AuthReq, sind weiter aufgeteilt:

  • Die Bonding Flag (BF) beschreibt, ob nach dem Pairing ein Austausch von Langzeitschlüsseln stattfinden soll. Durch den Austausch kann ein Großteil des Pairings bei einem späteren Verbindungsaufbau übersprungen werden, was den Verbindungsaufbau einfacher und schneller macht. Beim Wert 0x01 soll Bonding durchgeführt werden und bei 0x00 nicht
  • Das Man-in-the-Middle (MITM)-Feld beschreibt, ob ein MITM-Schutz angefragt wird
  • Das Secure Connection (SC)-Feld sagt aus, ob LE Secure Connections Pairing unterstützt wird. Wenn beide Geräte das SC Feld auf 0x1 setzen, wird LE Secure Connection verwendet, andernfalls soll LE Legacy Pairing verwendet werden
  • Das Keypress Feld wird ausschließlich für Passkey Entry-Protokolle verwendet und kann in anderen Protokollen ignoriert werden
  • Das Reserved Feld reserviert 1 Bit für CT2, ob also die (Hash-) Funktion h7 unterstützt wird, und 2 Bit für RFU

Authentication und Key Generation

Nachdem die verschiedenen Fähigkeiten ausgetauscht wurden, kann mit den Informationen folgend entschieden werden, wie die verbindung verschlüsselt wird. Im ersten Schritt des Entscheidungsprozesses wird bestimmt, ob die Verbindung mit Legacy Pairing oder Secure Connections verschlüsselt wird. In den darauffolgenden Schritten wird bestimmt, welche Pairing-Methode verwendet werden soll, um die Verbindung zu authentifizieren:

  1. Wenn beide Geräte Secure Connections unterstützen, wird LE Secure Connection Pairing verwendet. Sonst wird LE Legacy Pairing verwendet.
  2. Wenn beide Out-of-Band Data unterstützen, wird die OOB-Methode verwendet. Wenn dies nicht der Fall ist, ist das MITM-Feld ausschlaggebend.
  3. Sollte keines der Geräte MITM-Protection unterstützen, wird Just Works verwendet. Wenn eins oder beide Geräte die MITM-Protection unterstützen, werden die I/O Fähigkeiten evaluiert, um bestenfalls eine Benutzerinteraktion anzufordern. Die nachfolgende Abbildung ermöglicht ein schnelles Ablesen der Pairing-Methode, basierend auf den I/O Fähigkeiten der beiden Geräte: Zuweisung von I/O Fähigkeiten zu der dazugehörigen Schlüsselgenergierungsmethode. Quelle: https://academy.nordicsemi.com/topic/pairing-process-2 (Abgerufen: 11.07.2024)

Zusätzlich erwähnenswert ist, dass LE Legacy Pairing die Pairing-Methoden „Just Works“, „Passkey“ und „Out-of-Band (OOB)” unterstützt, während LE Secure Connection zusätzlich noch „Numeric Comparison“ unterstützt.
Ebenfalls kann BLE drei verschiedene Security Modi verwenden. Für Security Modus 1 sind die Level 1-4 definiert (Bluetooth SIG, 2024, S. 1334-1336):

  1. Keine Sicherheit (keine Authentifizierung und keine Verschlüsselung)
  2. Unauthentifiziertes Pairing mit Verschlüsselung
  3. Authentifiziertes Pairing mit Verschlüsselung
  4. Authentifiziertes LE Secure Connection Pairing mit Verschlüsselung durch einen 128-Bit starken Schlüssel

Ein Gerät kann sich zusätzlich im „Secure Connections Only“-Modus befinden - in diesem Modus dürfen nur Verbindungen mit Security Modus 1 Level 4 eingegangen werden.
Der Security Modus 2 wird nur für verbindungsbasierte Signierung von Daten verwendet und der Security Modus 3 nur für das Broadcasting. Beide sind jedoch nicht relevant für diese Arbeit.

LE Legacy Pairing

Das LE Legacy Pairing wird ab Bluetooth 4.0 unterstützt und ist, wie der Name schon sagt, eine veraltete Pairing-Methode. Diese Methode wird als Fallback verwendet, falls eines der Geräte kein LE Secure Connection unterstützt.
LE Legacy Pairing unterstützt drei verschiedene Pairing-Methoden, um einen Temporary Key (TK) auszutauschen, der anschließend verwendet wird, um den Verschlüsselungsschlüssel zu generieren. Sollte der TK keine 128 Bit lang sein, wird dieser mit einem Padding aus Nullen aufgefüllt.
Just Works ist für Szenarien wie bei Kopfhörern gedacht, wo mindestens eins der Geräte keinen Bildschirm oder keine Tastatur hat, um den TK einzutippen oder anzuzeigen. Dadurch, dass der TK immer 0 und somit bekannt ist, existiert auch kein Weg, die Geräte zu authentifizieren oder sie gegen MITM-Angriffe zu schützen.
Passkey verwendet eine sechsstellige Ganzzahl von 000000 bis 999999 als TK, die durch den Benutzer an das andere Gerät weitergegeben wird (Bluetooth SIG, 2024, pp. 1619, 1566-1567). Diese Methode ist für Szenarien gedacht, wenn ein Gerät keinen Bildschirm hat, dafür aber über Tasten verfügt, über die der TK eingegeben werden kann. Ein gutes Beispiel hierfür ist eine Bluetooth Tastatur und ein Computer, wobei der Computer den TK auf dem Bildschirm anzeigt, der dann in die Tastatur zur Authentifizierung der Verbindung eingegeben werden muss. Die Passkey-Methode ist so lange sicher, bis ein Angreifer die Nummer selbst von Bildschirm ablesen kann.
Abschließend verwendet Out-of-Band (OOB) Pairing eine andere drahtlose Technologie wie z. B. NFC, um den TK auszutauschen (Bluetooth SIG, 2024, pp. 1620, 271-272, 1567). Der Vorteil von OOB ist, dass der TK signifikant größer sein kann, mit bis zu 128 Bits. Der Schutz gegen MITM-Angriffe wird an die verwendete Technologie abgegeben. Damit ist OOB der sicherste Weg, um den TK auszutauschen und die Verbindung aufzubauen. Da Fitnesstracker in der Regel kein OOB-Pairing unterstützen, wird diese Variante im Folgenden nicht weiter behandelt. Mehr Informationen zum OOB-Pairing können bei Bedarf im Bluetooth Standard unter V5.4 Vol. 3 Part H 2.3.5.6.4 nachgelesen werden.

Detaillierte Beschreibung des Verbindungsablaufs beispielhaft für Just Works Ablauf von LE Legacy Just Works Pairing (Bluetooth SIG, 2024, S. 1619)

Wie der Abbildung 8 zu entnehmen ist, wird zuerst ein TK generiert, der für die Authentifizierung der Geräte dient. Bei Just Works wird der TK mit 0 initiiert (Bluetooth SIG, 2024, pp. 1618, 271, 1566). Anschließend werden eine 128 Bit Random Number Rand_I für das Initiating-Gerät und Rand_R für das Responding-Gerät generiert, die gegen Replay Angriffe schützen. Mit der Random Value, dem TK und anderen Daten wird dann eine 128 Bit Confirm Value Confirm_I und Confirm_R berechnet. Das Initiating-Gerät übermittelt diesen Wert dann an das Responding-Gerät, welches abschließend seine Confirm Value an das Initiating-Gerät versendet. Sobald die Confirm Values ausgetauscht wurden, sendet das Initiating-Gerät seinen Rand_I zum Responding-Gerät. Das Responding-Gerät kann nun die Berechnungen wiederholen, die das Initiating-Gerät mit seinem Rand_I Wert durchgeführt hat und sein eigenes Confirm_I errechnen. Das selbst errechnete Confirm_I kann dann mit dem erhaltenen Confirm_I verglichen werden. Sollten die Werte nicht übereinstimmen, wird eine Fehlermeldung generiert. Wenn die Werte übereinstimmen, kann das Responding-Gerät auch seine Rand_R zum Initiating-Gerät versenden, das dann in der Lage ist ein Confirm_R zu errechnen. Auch hier werden die Werte verglichen und bei nicht Übereinstimmung eine Fehlermeldung angezeigt. Im Erfolgsfall kann das Initiating-Gerät den Short Term Key (STK) generieren und dem Controller mitteilen, dass die Verbindung verschlüsselt werden kann.
Wenn als Pairing-Methode Passkey Anwendung findet, wird anstatt der 0 als TK, wie in der Abbildung dargestellt, eine zufällige sechsstellige Ganzzahl verwendet. Dieser TK wird dann vor der Generierung der Random Values Rand_R und Rand_I durch den Benutzer ausgetauscht.

Nachdem die Verbindung authentifiziert wurde, wird ein Short Term Key (STK) generiert, damit die Verbindung mit AES-CCM verschlüsselt werden kann (Bluetooth SIG, 2024, S. 266-268). Der STK = s1(TK, Rand_R, Rand_I) wird mithilfe der in V5.4 Vol. 3 Part H 2.2.4 beschriebenen Funktion s1 erzeugt, die den TK, Rand_R und Rand_I zur Eingabe übernimmt. Anschließend wird der STK für die Verschlüsselung der Verbindung verwendet.
Das Problem liegt nicht am verwendeten Verschlüsselungsalgorithmus AES-CCM, sondern im Key Exchange, da dieser keinen Schutz gegen passives Eavesdropping bietet (Ryan, Bluetooth: With Low Energy Comes Low Security, 2013). Dadurch, dass die in s1 verwendeten Werte Rand_R und Rand_I jeweils über eine unverschlüsselte Verbindung übertragen werden, sind sie einem potenziellen Angreifer, der die Verbindung mitliest, bekannt. Bei Just Works ist der TK ebenfalls mit 0 bekannt und ein Angreifer kann dadurch den STK errechnen, um anschließend die Verbindung zu entschlüsseln. Auch wenn der TK bei Passkeys nicht bekannt ist, hilft jedoch die Information, dass er eine Ganzzahl zwischen 0 und 999999 ist. Dadurch ist es möglich, den STK mithilfe von Rainbow-Tabellen effizient und in kurzer Zeit zu bestimmen. Das funktioniert, weil die Random Values nicht ganz zufällig sind, was diese vorhersehbarer macht. Ein Tool wie crackle (Ryan, mikeryan/crackle, 2020) ermöglicht das Errechnen des korrekten TK innerhalb von weniger als einer Sekunde. Mit dem TK kann dann der STK errechnet werden, der wiederum verwendet werden kann, um den Long Term Key (LTK) zu errechnen. Dadurch entsteht folgendes signifikantes Problem: Sobald der LTK geknackt ist, kann er zwischen Verbindungen wiederverwendet werden und somit können gleichzeitig alle zukünftigen Verbindungen mit dem LTK entschlüsselt werden.
Zusammenfassend kann festgehalten werden, dass LE Legacy Pairing unsicher ist, weil ein eigenes unsicheres Key Exchange Protokoll verwendet wird, anstatt ein bereits existierendes zu verwenden.

LE Secure Connect Pairing

Das Pairing mit LE Secure Connect wird ab Bluetooth 4.2 unterstützt und ist eine bis heute als sicher geltende Methode, die Elliptic Curve Diffie-Hellman (ECDH) zum Schlüsselaustausch verwendet (Bluetooth SIG, 2024, S. 1569-1574).

Detaillierte Beschreibung des Verbindungsablaufs beispielhaft für Just Works Authentication der Pairing Methoden Just Works und Passkey (Bluetooth SIG, 2024, S. 1571)

Das Initiating- (a) und Responding (b)-Gerät generieren zuerst jeweils ihre Public-Private-Key-Paare und tauschen anschließend ihre öffentlichen Schlüssel Pka und PKb aus, um den gemeinsamen Diffie-Hellman Key zu berechnen. Ab diesem Punkt ist die Kommunikation im Gegensatz zu LE Legacy Pairing durch den Diffie-Hellman Key verschlüsselt, und es wird jeweils eine zufällige 128 Bit nonce Na und Nb generiert, um sich gegen Replay-Angriffe und Bruteforcing verteidigen zu können (Bluetooth SIG, 2024, pp. 985-991). Um den Verbindungsaufbau im Hinblick auf mögliche Angreifer oder Übertragungsfehler zu prüfen, wird anschließend ein sogenanntes „Commitment“ generiert. Für das Responding-Gerät b errechnet sich das Cb mit Nb, PKa, PKb und 0 und sendet dieses an das Initiating-Gerät, bevor es dessen Nonce Na erhält. Im Anschluss sendet auch das Responding-Gerät seine Nonce Nb an das Initiating-Gerät, welches daraufhin das Commitment Cb überprüfen kann. Sollte diese Überprüfung fehlschlagen wird das Pairing wird abgebrochen. Andernfalls ist das Paring mit Just Works nach Schritt 6a vollendet.

Secure Connection Pairing unterstützt eine vierte Methode namens Numeric Comparison (Bluetooth SIG, 2024, pp. 270-271). Hierbei wir dasselbe Vorgehen wie bei Just Works verfolgt, jedoch mit einem zusätzlichen Schritt. Wie im Schritt 7a und 7b in Abbildung 9 gezeigt, generieren die beiden Geräte, nachdem das Commitment überprüft wurde, noch eine sechsstellige Zahl, die dem Benutzer angezeigt wird. Er muss im Moment der Anzeige die Nummern selbstständig vergleichen und bei beiden Geräten bestätigen, dass diese identisch sind. Diese Methode findet heutzutage vermehrt Anwendung, wenn beide Geräte einen Bildschirm und eine Eingabemöglichkeit besitzen. Ein Beispiel ist das Verbinden eines Mobiltelefons mit einem Auto. In diesem Beispiel haben beide Geräte einen Bildschirm und Touch oder einen Bestätigungsknopf als Eingabemöglichkeit.
Bei der Verwendung von Passkeys wird bei dem oben beschriebenen Ablauf das Commitment anstatt mit einer 0 mit jedem Bit der sechsstelligen Zahl einzeln generiert und der gesamte Prozess dementsprechend insgesamt 20-mal für die 20 Bits durchlaufen. Der Bluetooth Standard betont noch einmal, dass die sechsstellige Zahl für jede neue Verbindung zufällig generiert werden muss und nicht von den vorherigen Durchläufen wiederverwendet werden darf.

Durch die Verwendung von ECDH wird jede Methode signifikant sicherer. Insbesondere profitiert Just Works von ECDH, da die Implementierung unter LE Legacy Pairing keinerlei Sicherheit ermöglichte. Dennoch bietet die Just Works-Methode auch unter Secure Connect keinen Schutz gegen MITM-Angriffe und es besteht keine Möglichkeit, die Verbindung zu authentifizieren. OOB-Pairing verwendet, wie es bei LE Legacy Pairing der Fall ist, immer noch eine andere zusätzliche drahtlose Technologie, um die öffentlichen Schlüssel, Nonce und Bestätigungswerte auszutauschen. Daher ist der Schutz vor passivem Abhören und MITM-Angriffen weiterhin abhängig von der verwendeten Technologie.

Im Gegensatz zu LE Legacy Pairing wird bei LE Secure Connect kein STK generiert. Es wird direkt nach dem Diffie-Hellman Key Exchange (DHKE) und der Authentifizierung der Geräte ein LTK generiert, der unabhängig vom „TK“ ist. Dieser Schritt ist bei allen Pairing-Methoden gleich. Eine Neuerung gegenüber LE Legacy Pairing ist, dass für jede Verbindung vom LTK ein temporärer Sitzungsschlüssel abgeleitet wird, um die Verbindung zu verschlüsseln. Das führt dazu, dass nicht immer derselbe Schlüssel zum Verschlüsseln jeder zukünftigen Verbindung verwendet wird, sondern immer ein neuer.

Generierung des LTK Generierung des LTK bei LE Secure Connect (Bluetooth SIG, 2024, S. 1577)

Ein MacKey und der LTK werden mithilfe des Diffie-Hellman Key und anderen Daten IocapA, IocapB, A und B generiert (Bluetooth SIG, 2024, S. 1576-1577). Anschließend wird mithilfe der vorab übermittelten Daten und dem neu erhaltenen MacKey ein Confirmation-Wert Ea für das Initiating-Gerät und Eb für das Responding-Gerät generiert, um die Verbindung zu authentifizieren. Das Initiating-Gerät sendet dann seinen Ea an den Responder, der den Ea mit dem selbst errechneten Ea vergleicht. Daraufhin sendet auch der Responder seinen Confirmation Wert Eb an den Initiator, der den Wert ebenfalls mit seinem selbst errechneten vergleicht. Wenn der Vergleich bei einem der beiden Geräte fehlschlägt, wird die Verbindung abgebrochen. Andernfalls kann davon ausgegangen werden, dass beide Geräte denselben LTK besitzen.

Zusammengefasst ist LE Secure Connection Pairing sicherer als LE Legacy Pairing, da der Schlüssel durch ECDH sicherer ausgetauscht wird.

Key Distribution

Nachdem die Verbindung aufgebaut ist und verschlüsselt wurde, müssen während der Key Distribution weitere Schlüssel ausgetauscht werden. Welche Schlüssel ausgetauscht werden, wird bereits im Pairing Request / Response-Paket im Initiator / Responder Key Distribution / Generation-Feld festgelegt, das in die folgenden Felder unterteilt wird:

LE Initiator / Responder Key Distribution / Generation Feld Format (Bluetooth SIG, 2024, S. 1601)
  • Bei Legacy Pairing beschreibt EncKey, ob der LTK und damit auch der Encrypted Diversifire (EDIV) und die Random Number (RAND) ausgetauscht werden sollen. Unter Secure Connect kann das Feld ignoriert werden.
  • Das IdKey Feld beschreibt, ob der IRK und die Public oder Random Private Address ausgetauscht werden sollen.
  • Das SignKey Feld gibt an, ob der Connection Signature Resolving Key (CSRK) ausgetauscht werden soll.
  • Das LinkKey Feld gibt an, ob der Link Key aus dem LTK abgeleitet werden soll. Für Geräte, die kein Secure Connect unterstützen, soll das Feld ignoriert werden.

In der Regel werden bei LE Legacy Pairing der LTK, EDIV, RAND und IRK ausgetauscht. Bei LE Secure Connect werden nur der IRK und CSRK austauscht, da der LTK bereits im Vorhinein ausgetauscht wurde und daher auch EDIV und RAND nicht mehr benötigt werden. Je nach dem welche Felder angegeben werden, werden die Schlüssel in einer festen Reihenfolge ausgetauscht.
RAND wird zusammen mit dem EDIV verwendet, um den LTK während des Pairings bei LE Legacy Pairing zu identifizieren. Er wird jedes Mal neu generiert, wenn ein neuer LTK verteilt wird.
Der CSRK wird ausgetauscht, da LE einen Austausch von signierten Daten über eine unverschlüsselte ATT-Verbindung unterstützt. Der Schlüssel signiert dann die übertragenen Daten und wird an das Paket angehängt.
Sofern das EncKey-Feld auf 0x1 gesetzt ist, wird für LE Legacy Pairing der LTK mit LTK = d1(ER, DIV, 0) generiert (Bluetooth SIG, 2024, S. 1614). Die Generierung erfolgt unabhängig vom TK sowie STK und verwendet eine Diversifizierungsfunktion d1, an die der Encryption Root (ER) und ein Diversifier (DIV) übergeben wird. Der LTK wird in allen Fällen erst beim Wiederverbinden mit dem Gerät zur Verschlüsselung eingesetzt.

Bonding

Nachdem alle notwendigen Schlüssel ausgetauscht wurden, findet, falls während des Pairings vereinbart, das Bonding statt. Bonding beschreibt die Beziehung zwischen zwei Geräten, die aufgebaut wird, wenn sich beim Future Exchange darauf geeinigt wurde. Nach dem erstmaligen Pairing werden dann auf beiden Geräten die ausgetauschten Schlüssel gespeichert, sodass diese nach Beenden der Verbindung nicht verloren gehen. Das Speichern der Schlüssel im Rahmen des Bondings, wie z. B. des LTKs, ermöglicht bei der nächsten Verbindung das Überspringen des Pairing-Prozesses, was wiederum zur Reduzierung des Energieverbrauchs und der Dauer des Verbindungsaufbaus beiträgt.

ATT und GATT

Das Attribute Protokoll (ATT) ermöglicht unter anderem das Schreiben und Lesen von kleinen Daten von einem BLE-Gerät. Jeder gespeicherte Wert wird als Attribute bezeichnet und besitzt einen Universally Unique Identifier (UUID), um die Daten zu identifizieren (Townsend, 2024).
Das Generic Attribute Profile (GATT) baut auf ATT auf und fügt Services und Characteristics zu ATT hinzu. GATT besteht aus zwei wichtigen Rollen: dem GATT-Server, der dafür zuständig ist, die Daten, Services und Characteristics zu speichern, und dem GATT-Client, der Anfragen an den Server sendet und Antworten empfängt. z. B. baut das Smartphone als GATT-Client eine Verbindung zu einem Fitnesstracker als GATT-Server auf.

Aufbau der GATT-Elemente

GATT-Transaktionen basieren auf verschachtelten Objekten namens Profiles, Services und Characteristics, die in der Abbildung illustriert sind.
Zwar existieren Profile nicht wirklich auf dem GATT-Server, sie stellen jedoch eine vordefinierte Sammlung an Services dar, die von der Bluetooth SIG so vordefiniert werden. Ein Beispiel ist das Blood Pressure Profile, das einen Blood Pressure Service und einen Device Information Service enthalten muss. Eine komplette Liste kann unter der offiziellen GATT-Profilen und Services unter https://www.bluetooth.com/specifications/gatt angesehen werden (Bluetooth SIG, 2024).

Services unterteilen die Daten in logische Teile, die jeweils die Daten enthalten. Diese Teile werden als Characteristics bezeichnet. Jeder Service kann eine oder mehrere Characteristics besitzen, die wiederum durch eine 16-Bit UUID für offizielle Services oder eine 128-Bit UUID für benutzerdefinierte Services identifiziert werden. Der Blood Pressure Service mit der UUID 0x1810 besitzt beispielsweise die Blood Pressure Measurement- und Blood Pressure Feature-Characteristic.

Ein Characteristic wird dann wieder wie Services durch eine 16-Bit oder 128-Bit UUID identifiziert und beinhaltet nur einen einzelnen Wert. z. B. enthält die Blood Pressure Measurement Characteristic mit der UUID 0x2A35 einen Wert, dessen Bytes durch ein eigenes Format in die Subfelder Systolic Blood Pressure, Diastolic Blood Pressure, Mean Arterial Pressure etc. unterteilt werden (Medical Devices Working Group, 2022).
Die offiziell von der Bluetooth SIG definierten Services und Characteristics folgen dem 128-Bit UUID Format 0000XXXX-0000-1000-8000-00805f9b34fb, wobei XXXX die eindeutige 16-Bit UUID in Hexadezimalrepräsentation ist. UUIDs für Services und Characteristics können auch noch einmal auf der Assigned Numbers Seite unter https://www.bluetooth.com/specifications/assigned-numbers/ eingesehen werden (Bluetooth SIG, 2024).
Auf Characteristics kann mithilfe von verschiedenen Zugriffstypen zugegriffen werden:

  • „read“: Lesen des Werts in der Characteristic
  • „write“: Schreiben eines Werts in eine Characteristic. Es existiert das normale „write“ und das „write-without-response“, bei welchem der Server keine Antwort an den Client versendet
  • „notify“: Der Client wird über Änderungen des Werts der Characteristic informiert
  • „indicate“: Ähnlich wie „notify“, nur das der Server eine Bestätigung vom Client erwartet, dass die Indikation empfangen wurde

Untersuchung von BLE-Verbindungen

Es existieren verschiedene Techniken, um die BLE Verbindung zweier Geräte zu untersuchen.

Android Bluetooth HCI-Snoop-Protokoll

Android bietet einen „Bluetooth HCI snoop log“ für Entwickler an, bei dem alle Bluetooth-Pakete in eine Log-Datei geschrieben werden.
Dafür muss auf einem Android Smartphone zunächst der Entwicklermodus aktiviert werden, indem fünf Mal hintereinander in den Einstellungen auf die „Build Number“ getippt wird. Im Anschluss kann in den Entwicklereinstellungen unter „Bluetooth HCI-Snoop-Protokoll aktivieren“ das Snooping und unter „Debugging“ das „USB-Debugging“ aktiviert werden, um den Log später vom Smartphone zu extrahieren. Abschließend muss Bluetooth noch einmal aus- und eingeschaltet werden, dann erst werden zukünftige Verbindungen aufgezeichnet.
Nachdem eine entsprechende Bluetooth Verbindung aufgezeichnet wurde, kann beispielsweise die Android Debug Bridge (ADB) verwendet werden, um die Logs aus dem Smartphone zu extrahieren. ADB kann für Windows, Mac und Linux einfach unter https://developer.android.com/tools/releases/platform-tools heruntergeladen werden und ist alternativ auch in der Android Sdk enthalten, falls diese auf dem Gerät installiert ist, und zwar unter ~/Android/Sdk/platform-tools (Google LLC, 2024).
Nach dem Herunterladen kann das Smartphone mit dem Computer über USB verbunden und der Befehl adb devices ausgeführt werden, um alle erkannten Geräte aufzulisten. In vielen Fällen muss vorab auf dem Smartphone noch die Berechtigung zur Datenübertragung aktiviert werden. Die Einstellungen können mit einem Klick auf die Benachrichtigung „USB-Datenübertragung aktiviert“ geöffnet werden. Dort muss dann unter „Verwendungszweck für USB-Verbindung“ die Option „Dateiübertragung / Android Auto“ ausgewählt werden.
Bei der ersten Ausführung eines ADB-Befehls wird im Commandline Interface (CLI) neben dem Gerät „unauthorized“ angezeigt. Dies liegt daran, dass auf dem Smartphone bei der Benachrichtigung „USB-Debugging zulassen“ auf „Zulassen“ geklickt werden muss, bevor ADB das USB-Debugging nutzen kann.

~ adb devices
    * daemon not running; starting now at tcp:5037
    * daemon started successfully
    List of devices attached
    123456789ABCDE	device

In der Ausgabe wird das Smartphone mit einer Nummer aufgelistet. Mit dem Befehl adb bugreport ble-report wird der Report generiert und in die Datei ble-report.zip in das aktuelle Verzeichnis geschrieben (Android Open Source Project, 2024). Abschließend muss nur noch die Logdatei mit unzip ble-report.zip FS/data/misc/bluetooth/logs/btsnoop_hci.log aus dem Archiv extrahiert und mit Wireshark geöffnet werden.
Wichtig anzumerken ist, dass zum Zeitpunkt des Aufzeichnens die Daten im Gegensatz zum externen Sniffen bereits entschlüsselt sind. Das hat den Vorteil, dass die Pakete nicht erst entschlüsselt werden müssen, sondern direkt in lesbarer Form vorliegen.

GATT Endpoint Testing

Jedes BLE-Gerät stellt seine Services und Characteristics zum Auslesen zur Verfügung. Mithilfe der Python Bibliothek Bleak oder dem Linux Befehl bluetoothctl können die vom Ring veröffentlichten BLE-Services aufgelistet werden. Die UUIDs der Services können dann beispielsweise im Programmcode einer App gesucht werden, um das dazugehörige Kommunikationsprotokoll zu Reversen und anschließend selber Daten über die GATT Verbindung zu versenden.

from bleak import BleakClient
    import asyncio

    async def main():
        _read_queue = asyncio.Queue()
        BLE_MAC_ADDRESS = "00:00:00:00:00:00"
        SERVICE = '00000000-0000-0000-8000-000000000000'
        WRITE_CHARACTERISTIC_UUID = "00000000-0000-0000-0000-000000000000"
        READ_CHARACTERISTIC_UUID = "00000000-0000-0000-0000-000000000000"

        def notification_handler(_sender, data):
            _read_queue.put_nowait(data)

        async with BleakClient(BLE_MAC_ADDRESS, services=[SERVICE]) as client:
            await client.pair()
            await client.start_notify(READ_CHARACTERISTIC_UUID, notification_handler)
            await client.write_gatt_char(WRITE_CHARACTERISTIC_UUID, bytes([8, 3, 0, 0, 0]))
            response = await asyncio.wait_for(_read_queue.get(), timeout=15)
            print(f"Version Information: {response.hex()}")
            await client.unpair()


    if __name__ == '__main__':
        asyncio.run(main())

Angriffstechniken auf BLE-Verbindungen

Es existieren verschiedene Techniken, um Pakete einer BLE-Verbindung mitzulesen, zu bearbeiten oder die Zustellung zu verhindern.

Connection sniffing, jamming und hijacking mit BtleJack

Damien Cauquil veröffentlichte auf der DEF CON 26 sein neues Python basiertes BLE-Framework mit dem Namen BtleJack, als Reaktion auf die hochpreisigen und teils instabilen bereits auf dem Markt existierenden Tools (Cauquil, BLE Sniffing 101, 2018). Das Open Source Framework ist ein Nachfolger für BtleJuice und kann bestehende und neue BLE-Verbindungen sniffen, stören und übernehmen (Cauquil, BtleJack, 2023).
BtleJack verwendet ein oder mehrere BBC Micro:Bit (Micro:bit Educational Foundation, 2024), die mit einer spezifischen Firmware laufen, um Pakete auf den verschiedenen Bluetooth Channels mitzulesen. Der BBC Micro:Bit ist ein preiswerter Einplatinencomputer basierend auf ARM (Arm Limited, 2024). Zusätzlich zum BBC Micro:Bit wurde auch die Unterstützung für den Adafruit BLE Sniffer und das nRF51822 Eval Kit zu BtleJack hinzugefügt.
Um BtleJack zu verwenden, sollten optimalerweise mindestens drei BBC Micro:Bit über USB an den Computer angeschlossen werden, sodass alle Advertising Channels abgedeckt und das Hop Interval, Hop Increment sowie die Channel Map schneller ermittelt werden können.
Das Framework kann mit dem Python Paketverwaltungsprogramm pip installiert werden. In manchen Fällen muss einem Benutzer unter Linux noch der Zugriff auf den Serial Port gewährt werden, da der Zugriff besondere Berechtigungen fordert.

# BtleJack installieren
    pip3 install btlejack
    # Die Gruppe für den serial port überprüfen
    ls -l /dev/ttyACM1
    # Den Benutzer in die Gruppe hinzufügen (z. B., dialout)
    sudo usermod -a -G dialout $USER
    # Ab- und Anmelden
    newgrp dialout
    # Gruppen des Benutzers überprüfen
    groups

Bevor BtleJack verwendet werden kann, muss die dazugehörige Firmware auf den BBC Micro:Bit installiert werden. Dafür wird der Befehl btlejack -i ausgeführt, der die Geräte automatisch anhand des Namens erkennt und die Firmware installiert.

~ btlejack -i
    BtleJack version 2.1

    [i] Flashing /media/user/MICROBIT with btlejack-fw-v1.hex ...
    [i] Flashing /media/user/MICROBIT1 with btlejack-fw-v1.hex ...
    [i] Flashing /media/user/MICROBIT2 with btlejack-fw-v1.hex ...
    [i] Flashed 3 devices

Sobald die Firmware auf den Geräten installiert ist, kann mithilfe von btlejack -s nach aktiven BLE-Verbindungen gesucht werden.

~ btlejack -s
    BtleJack version 2.1

    [i] Enumerating existing connections ...
    [ - 46 dBm] 0x75add856 | pkts: 1
    [ - 46 dBm] 0x75add856 | pkts: 2
    [ - 46 dBm] 0x95ed0e95 | pkts: 1
    [ - 46 dBm] 0x95ed0e95 | pkts: 2
    [ - 46 dBm] 0x75add856 | pkts: 3
    [ - 46 dBm] 0x75add856 | pkts: 4
    [ - 46 dBm] 0x95ed0e95 | pkts: 3

Der erste Wert der Ausgabe beschreibt die Signalstärke in dBm, der zweite Wert ist die Zugriffsadresse (Access Address). Diese ist ein eindeutiger 32-Bit-Wert, der eine Verbindung zwischen zwei BLE-Geräten identifiziert. Der letzte Wert beschreibt die Anzahl der gesehenen Pakete einer Verbindung.
Um die Pakete einer Verbindung mitzulesen, kann der Befehl btlejack -f 0x75add856 verwendet werden. Das Anhängen der Option -o output.pcap bewirkt, dass die Pakete gleichzeitig in einer pcap-Datei gespeichert werden. Das PCAP-Dateiformat ist ein simples und weitverbreitetes Format, um Netzwerkdaten zu speichern und kann z. B. in Wireshark geöffnet werden (Wireshark Foundation, 2020).

~ btlejack -f 0x75add856 -5
    BtleJack version 2.1

    [i] Detected sniffers:
     > Sniffer #0: fw version 2.1
     > Sniffer #1: fw version 2.1
     > Sniffer #2: fw version 2.1

    [i] Synchronizing with connection 0x75add856 ...
    ✓ CRCInit: 0x301ec1
    ✓ Channel Map = 0x1ffbffdfe7
    ✓ Hop interval = 1009
    ✓ CSA2 PRNG counter = 0
    [i] Synchronized, packet capture in progress ...
    LL Data: 03 05 a3 42 ec 2d 03
    LL Data: 0f 0c df 06 8b 84 02 9f ad b6 25 fc 02 c2
    LL Data: 0f 0c df 06 8b 84 02 9f ad b6 25 fc 02 c2
    LL Data: 03 05 79 f9 62 2d 6b

Sollte der Verbindungsaufbau nicht mitgeschnitten worden sein, errechnet BtleJack die verschiedenen Parameter, um der Verbindung folgen zu können. Sobald alle Parameter erfasst wurden, kann BtleJack der Verbindung folgen und die aufgezeichneten Pakete auslesen. Da das Framework nicht ermitteln kann, ob es sich um eine BLE 5-Verbindung handelt, muss der Befehl mit und ohne der -5 Option ausgeführt werden. Die Option informiert BtleJack darüber, dass der neue Channel Selection Algorithm (CSA) #2 von BLE 5 verwendet werden soll. Es kann davon ausgegangen werden, dass moderne Geräte die neuere Bluetooth LE Version 5 verwenden.

Eine Verbindung kann mit dem Befehl btlejack -f 0x75add856 -t übernommen werden. Sobald die Verbindung übernommen wurde, können die exponierten Services und Characteristics mit dem Befehl discover ausgelesen werden. Anschließend können Daten mit den Befehlen read <handle> und write <handle> <format> <data> aus/ auf Characteristics gelesen/ geschrieben werden. Das Übernehmen von BLE 5-Verbindungen ist zum aktuellen Zeitpunkt mit dem Framework noch nicht möglich.
Neben BtleJack existieren andere Tools, wie der Ubertooth oder Bluefruit LE Sniffer, die extern Bluetooth Low Energy Verbindungen sniffen können.

BLE Legacy Connect Cracking mit crackle

Für BLE existieren zwei verschiedenen Pairing Modi: LE Legacy Pairing und LE Secure Connections Pairing. Das Programm crackle bricht die Verschlüsselung von LE Legacy Pairing und ermöglicht das Entschlüsseln versendeter Pakete (Ryan, mikeryan/crackle, 2020).
Um die aufgezeichnete Kommunikation von zwei Geräten entschlüsseln zu können, benötigt crackle die Pairing-Pakete, die als Grundlage für die Generierung des STK und des LTK dienen. Der Verbindungsaufbau zwischen zwei Geräten, die sich zuvor schon einmal verbunden haben, reicht dabei nicht aus, da das LTK der vorherigen Verbindung wiederverwendet und nicht neu berechnet wird.
Wenn eine aufgezeichnete Verbindung, z. B. in Form einer BLUETOOTH_LE_LL_WITH_PHDR-PCAP-Datei, aus BtleJack vorliegt, LE Legacy Pairing verwendet und der gesamte Pairing-Prozess aufgezeichnet wurde, kann crackle die Pakete ohne Weiteres entschlüsseln. Ein zum Zeitpunkt der Veröffentlichung der Arbeit noch nicht eingepflegter Feature Request beinhaltet ebenfalls Support für BLUETOOTH_LE_LL-Dateien (arunima06, 2020).
Um crackle zu installieren, muss das Github Projekt mit den folgenden Befehlen heruntergeladen und gebaut werden:

~ git clone https://github.com/mikeryan/crackle /opt/crackle
    ~ make -C /opt/crackle

Um die Pakete entschlüsseln zu können, muss nur die aufgezeichnete pcap-Datei an crackle übergeben werden.

~ /opt/crackle/crackle -i encrypted.pcap -o decrypted.pcap
    Found 1 connection

    Analyzing connection 0:
      08:3e:8e:e1:0b:3e (public) -> 78:c5:e5:6e:dd:e8 (public)
      Found 3 encrypted packets
      Cracking with strategy 0, 20 bits of entropy

      !!!
      TK found: 000000
      ding ding ding, using a TK of 0! Just Cracks(tm)
      !!!

      Decrypted 3 packets
      LTK found: 7f62c053f104a5bbe68b1d896a2ed49c

    Decrypted 3 packets, dumping to PCAP
    Done, processed 713 total packets, decrypted 3

In diesem Fall wurde der LTK einer LE Legacy Pairing-Verbindung, die über die Just Works-Methode aufgebaut wurde, berechnet. Der gefundene LTK kann anschließend verwendet werden, um Pakete aus später aufgenommenen Verbindungen zu entschlüsseln. Dazu muss einfach das Argument -l <ltk> an den Befehl angehängt werden: /opt/crackle/crackle -l 7f62c053f104a5bbe68b1d896a2ed49c -i encrypted.pcap -o decrypted.pcap
Sollte vorab unklar sein, ob LE Legacy Pairing oder LE Secure Connections Pairing in der Verbindung verwendet wurde, kann die pcap-Datei an crackle übergeben werden, das wiederum, im Falle von LE Secure Connect verwendet wurde, den Fehler „LE Secure Connections“ wirft.
Die einzige Einschränkung ist hierbei, dass der gesamte Pairing Prozess mitgelesen werden muss, damit crackle die notwendigen Informationen erhält, um die Pakete entschlüsseln zu können. Der Verbindungsaufbau mit einem Gerät, dass schon einmal verbunden wurde, ist nicht ausreichend, weil der LTK der vorigen Verbindung verwendet wird und dadurch LTK nicht neu berechnet wird.

BLE MITM mit BtleJuice oder GATTACKER

Bei einem Man-in-the-Middle Angriff befindet sich der Angreifer zwischen den beiden Geräten. BtleJuice (Cauquil, DigitalSecurity/btlejuice: BtleJuice Framework, 2018) und auch GATTACKER (Jasek, 2018) nutzen die Tatsache aus, dass die Verbindung und das Advertisen nicht zeitgleich stattfinden können. Wenn also ein Fitnesstracker im Advertising-Zustand ist, ist er in der Liste der gefundenen Bluetooth-Geräte z. B. eines Smartphones aufgelistet, mit denen ein Verbindungsaufbau möglich ist. Sobald sich ein Gerät mit dem Fitnesstracker verbindet, verschwindet der Tracker aus der Liste der verfügbaren Bluetooth-Geräte. Dieser Zustand kann ausgenutzt werden, indem sich der Angreifer selbst mit dem Tracker verbindet und dieser dadurch nicht mehr in der Liste von Geräten in der Nähe angezeigt wird. Daraufhin kann der Angreifer einen Klon des Fitnesstrackers mit identischer MAC-Adresse, Parametern, Services und Characteristics erstellen und Advertising-Pakete senden, die denen des Fitnesstrackers gleichen. Sobald sich jemand mit dem Klon-Gerät verbindet, können die Anfragen zum eigentlichen Fitnesstracker weitergeleitet werden. Dies ermöglicht es gleichzeitig alle Pakete unverschlüsselt auszulesen und sogar zu manipulieren.
MITM-Angriffe sind aufgrund der in BLE implementierten Schutzmechanismen ausschließlich bei der Just Works-Methode in LE Legacy und LE Secure Connections möglich.

Fazit

Mit BLE Secure Connections sind BLE Verbindungen um einiges sicherer geworden. Dennoch nutzen viele Geräte veraltete Versionen oder lassen unsichere Verbindungen durch downgrading Angriffe zu.

Quellen

  • Bluetooth SIG - Origin of the Bluetooth Name - 2024 - https://www.bluetooth.com/bluetooth-origin/
  • Bluetooth SIG - Bluetooth Core Specification - 11.06.2024 - https://www.bluetooth.com/specifications/specs/core-specification-amended-5-4/
  • Ryan, Mike - Bluetooth: With Low Energy Comes Low Security - 13.08.2013 - https://www.usenix.org/conference/woot13/workshop-program/presentation/ryan
  • Ryan, Mike - mikeryan/crackle: Crack and decrypt BLE encryption - 2020 - https://github.com/mikeryan/crackle
  • Townsend, Kevin - GATT - Introduction to Bluetooth Low Energy - 08.03.2024 - https://learn.adafruit.com/introduction-to-bluetooth-low-energy/gatt
  • Bluetooth SIG - Specifications and Documents - 2024 - https://www.bluetooth.com/specifications/gatt
  • Medical Devices Working Group - Blood Pressure Service - 18.01.2022 - https://www.bluetooth.com/specifications/bls-1-1-1/
  • Bluetooth SIG - Assigned Numbers - 2024 - https://www.bluetooth.com/specifications/assigned-numbers/
  • Google LLC - Google Developers: Versionshinweise zu SDK Platform Tools - 12.07.2024 - https://developer.android.com/tools/releases/platform-tools
  • Android Open Source Project - Ubuntu Manpage: adb - 2024 - https://manpages.ubuntu.com/manpages/bionic/man1/adb.1.html
  • Cauquil, Damien - BLE Sniffing 101 - 23.10.2018 - https://www.youtube.com/watch?v=VHJfd9h6G2s
  • Cauquil, Damien - BtleJack: a new Bluetooth Low Energy swiss-army knife - 04.10.2023 - https://github.com/virtualabs/btlejack
  • Micro:bit Educational Foundation - Micro:bit - 2024 - https://microbit.org/
  • Arm Limited - BBC micro:bit - 2024 - https://www.arm.com/company/success-library/arm-designs/microbit
  • Wireshark Foundation - Wireshark Wiki - Libpcap File Format - 14.10.2020 - https://wiki.wireshark.org/Development/LibpcapFileFormat
  • arunima06 - mikeryan/crackle: PR #46 - added support for BlUETOOTH_LE_LL frames - 2020 - https://github.com/mikeryan/crackle/pull/46
  • Cauquil, Damien - DigitalSecurity/btlejuice: BtleJuice Framework - 03.10.2018 - https://github.com/DigitalSecurity/btlejuice
  • Jasek, Slawomir - securing/gattacker: A Node.js package for BLE Man-in-the-Middle & more. - 03.10.2018 - https://github.com/securing/gattacker