Continue reading ‘Timing-Angriff auf einen Post-Quanten-Kryptoalgorithmus’ »]]>
Ich habe die Referenzimplementierung eines Kandidaten ausgewählt und diese daraufhin untersucht, ob sie anfällig gegen implementierungsspezifische Angriffe ist. Dabei habe ich einen theoretischen Ansatzpunkt für einen Timing-Angriff entdeckt. Alles weitere hier:
]]>Continue reading ‘Sicherheitsmechanismen von Bluetooth Low Energy’ »]]>
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
TKauf 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
TKverwendet. - OOB: Beide Seiten tauschen über einen zusätzlichen Kanal einen 128 Bit langen Zufallswert aus, der als
TKverwendet 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 c11 ,
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-CMAC2
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 106. 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 Tlife 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 Tlife zu verringern, indem sie die Zeit Tactive, 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
1Für ausführlichere Definitionen der hier nur kurz beschriebenen Funktionen sei auf die Bluetooth-Spezifikation [5, S. 2297 ff.] verwiesen. ⤴
2Der 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.
]]>Also war es an der Zeit, das Backup aus der Schublade zu holen. Ich hatte erst zwei Wochen zuvor mein altes Konzept, gpg-verschlüsselte Files per rsync auf einen externen Speicher zu schieben, durch den Service Tarsnap ersetzt. Tarsnap verschlüsselt die Daten lokal auf dem Server und schiebt sie dann in den gleichnamigen Onlinespeicher, der auf Amazon S3 basiert. Dabei kommt eine Deduplikation zum Einsatz, was es recht günstig macht, viele Versionen des Datenbestands aufzubewahren. Das dazugehörige Kommandozeilentool tarsnap ist – dank der guten Dokumentation auf der Website und der Manpage – recht einfach zu bedienen. Per Cronjob mache ich jeden Morgen ein neues, automatisches Backup meines vServers, und von Zeit zu Zeit lösche ich manuell mal die alten Snapshots weg.
Die letzte Version meines Tarsnap-Backups enthielt daher den Stand ein paar Stunden vor dem Crash. Also habe ich mir einen neuen vServer geklickt, die Basiseinrichtung durchgeführt, Tarsnap installiert, meinen Tarsnap-Key auf den neuen Server übertragen und die Wiederherstellung angestoßen.
Ich hatte nicht das gesamte Filesystem des alten Servers gesichert, sondern nur die Dateien der Webapplikationen und jeweils zum Backupzeitpunkt generierte Dumps der zugehörigen Datenbanken. Das Zurückspielen hat hervorragend funktioniert.
Insofern ist mein Backupkonzept jetzt unfreiwilligerweise praxiserprobt, sodass ich sagen kann: Tarsnap hat mir mal den Kopf gerettet – kann ich empfehlen!
]]>So geschah es auch heute wieder. Eigentlich wollte ich einen neuen Blogpost erstellen. Auf dem Weg in den WordPress-Editor habe ich im Backend aber noch ein wenig unveröffentlichtes, exklusives Material entdeckt. Deshalb kommen jetzt erst mal die ollen Kamellen, der „neue“ Artikel folgt dann die Tage – den hätte ich ohnehin noch nicht veröffentlichen, sondern nur vorbereiten können.
Außerdem habe ich endlich den schon lange existierenden Twitter-Account @returnfalsede mithilfe von IFTTT mit dem Blog verknüpft, sodass neue Posts ab sofort auch dort erscheinen sollten. Dafür ist dieser Beitrag ein Testballon. Ich bin gespannt.
]]>Aus diesem Grund habe ich mir mithilfe von Getmail 5.4 eine eine Archivierung auf meinem Homeserver gebastelt. Diese läuft alle paar Stunden, holt neue Mails aus den Postfächern ab und speichert sie in einem lokalen Maildir. Dabei werden ungelesene Mails nicht als gelesen markiert und es werden auch keine Mails auf dem Server gelöscht. Das einzige Problem, das ich noch nicht lösen konnte: Wenn ich eine Mail in einen anderen IMAP-Ordner verschiebe, lädt Getmail sie erneut herunter. Aber damit kann ich leben.
Ich habe dazu folgende Ordnerstruktur und einige Dateien angelegt:
/data/mail ├── getall.sh ├── getall.log ├── [email protected] │ ├── conf │ │ └── getmailrc │ ├── log │ │ └── getmail.log │ └── maildir │ ├── cur │ ├── new │ └── tmp ├── [email protected] │ ├── conf │ │ └── getmailrc │ ├── log │ │ └── getmail.log │ └── maildir │ ├── cur │ ├── new │ └── tmp └── <weitere E-Mail-Adressen> └── …
getall.sh ruft Getmail mit den entsprechenden Konfigurationsdateien pro Unterverzeichnis auf:
#!/bin/bash
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
echo "Script run $(date)"
for i in ${DIR}/*/conf
do
echo $i
cd $i
getmail -g./
done
echo "-------------------"
Ich rufe getall.sh einmal am Tag via cron auf.
0 3 * * * /bin/bash /data/mail/getall.sh >> /data/mail/getall.log 2>&1
Für die Gmail-Adresse sieht meine Getmail-Konfiguration getmailrc wie folgt aus:
[retriever] type = SimpleIMAPSSLRetriever server = imap.gmail.com username = [email protected] password = PASSWORD1234 mailboxes = ALL use_peek = true [destination] type = Maildir path = /data/mail/[email protected]/maildir/ [options] verbose = 1 message_log = /data/mail/[email protected]/log/getmail.log read_all = false
Die heruntergeladenen Mails landen als einzelne Dateien in maildir/new. Die IMAP-Ordnerstruktur geht dabei zunächst verloren, ist in den Mail-Dateien aber in einem zusätzlichen Header-Feld X-getmail-retrieved-from-mailbox noch vermerkt, sodass man sie bei Bedarf schon rekonstruieren könnte.
„Landkarte“ der öffentlichen PKI
Als Datenbasis diente mir censys.io, die ihre Informationen im Wesentlichen aus zwei Quellen beziehen: scannen sie den gesamten IPv4-Adressraum und zeichnen auf, welche Zertifikate ihnen dabei begegnen, und zweitens stützen sie sich auf die Informationen aus den öffentlichen Certificate-Transparency-Protokollen.
Aus dem Datenbestand von Censys habe ich mir also alle Root- und Intermediate-CAs geben lassen, denen ein Browser auf Basis des Mozilla NSS Certificate Store vertrauen würde. Der Suchbegriff lautet:
validation.nss.valid: true and (validation.nss.type: intermediate or validation.nss.type: root)
Das sind überraschend viele und es ist durchaus interessant mal ein wenig darin herumzustöbern. Damit ihr das auch machen könnt, findet ihr hier ein GraphML-File, das man sich mit yEd anschauen kann. Darin kann man einzelne Verbindungen etwas besser nachverfolgen und sich den Graphen auch nach Belieben rearrangieren (für die hochgeladene Variante habe ich die Option Layout → Baumartig → Ballon verwendet).
Also klickt euch mal rein und seid überrascht, wer wem sein Vertrauen vererbt und wem euer Browser alles vertraut. Ich will mal nicht die 100%ige Korrektheit versprechen, denn wie man sieht, liegen unten rechts im Bild ein paar einzelne Intermediates, die keiner Root zugeordnet sind – es geht also nicht so richtig auf. Aber für eine grobe Übersicht taugt die Grafik denke ich schon.
]]>Continue reading ‘Windows 7: Datenträgerüberprüfung beim Start bricht automatisch ab’ »]]>
Diese Datenträgerüberprüfung lässt sich in den ersten 10 Sekunden durch einen Tastendruck abbrechen und auf den nächsten Start verschieben. Nun ergab sich aber das Problem, dass aus ungeklärten Gründen die Überprüfung abgebrochen wurde, ohne dass eine Taste gedrückt wurde. Man sah also noch ganz kurz den Abbruch-Countdown bei 10 Sekunden beginnen und kurz darauf erschien die Meldung „Die Datenträgerüberprüfung wurde abgebrochen“ und der Startvorgang wurde normal fortgesetzt. Dieses Spiel wiederholte sich bei jedem Start des Windows-Systems.
Die Lösung: Ich konnte den Abbruch-Timeout über die Registry auf 0 Sekunden herabsetzen, dann lief die Überprüfung problemlos durch. Die Anpassung ist über den DWORD-Wert AutoChkTimeout im Schlüssel
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
möglich, der, wenn er nicht schon existiert, manuell angelegt und dann auf den Wert 0 gesetzt werden muss.
(via Lenovo-Forum und Winaero.com)
]]>Im Sourcecode konnte ich dann schnell das <meta>-Tag namens theme-color als Verantwortlichen ausmachen:
<meta name="theme-color" content="#005689">
Ich habe dann noch etwas damit herumgespielt und mich gefragt, ob die Farbe nach dem Laden der Seite, also zur Website-Laufzeit, von dieser noch verändert werden kann. Ergebnis: Ja, geht (hier eine kleine Demo) – zumindest im Chrome unter Android.
Einige konstruierte Anwendungsfälle:
- Man könnte einem Fortschrittsbalken mehr Aufmerksamkeit zukommen lassen, indem man den Fortschritt auch im Browser-User Interface darstellt (etwa als Farbwechsel von schwarz über grau nach weiß)
- Die Werbeindustrie kann jetzt endlich auch den Rahmen um die Website herum passend zur animierten Werbung mitblinken lassen
Und etwas genereller, auch ohne die Farbe ändern zu müssen:
- Die Phisher können ihre Phishing-Site seriöser erscheinen lassen, indem sie ihr eine grüne Adressleiste verpassen, ein DV-Zertifikat installieren um ein Schloss zu bekommen und auf ihre Site schreiben: „Achten Sie beim Online-Banking stets auf die grüne Adressleiste in Ihrem Browser – nur dann nutzen Sie eine sichere Verbindung!“ – und schon sieht die falsche Site sicherer aus als die echte.
Ich glaube, diese Neuerung hat noch Potential. Ich bin jedenfalls gespannt, was die Guten und die Bösen des Internets daraus machen.
]]>Daraus ergibt sich auch, dass ein schneller Wechsel zwischen Platte und DVD-Laufwerk nicht ohne Weiteres möglich ist.
Der gelieferte Adapter sah bei mir etwas anders aus als auf dem Artikelbild. Rechts von der Vertiefung für die Festplatte war ein Aufkleber mit einer Einbauanleitung für die Festplatte angebracht, und der Plastikplatzhalter vorne in der Vertiefung war in meinem Fall gleichzeitig ein Schraubendreher, mit dem man zwei kleine Dorne, die in die vorderen Schraubenvertiefungen der Festplatte greifen, lösen und festziehen konnte.
Es folgen einige Fotos des eingebauten Adapters, da ich solche vor dem Kauf gesucht und nicht gefunden hatte:
Vorher: Original-DVD-Laufwerk (älteres Bild)
Nachher: Jetzt mit Festplattenadapter
Vorne schließt der Adapter nahezu bündig mit dem Schacht ab
Hinten entsteht eine minimale Kante
Wie man sieht, schließt der Adapter an der Vorderkante bündig mit dem Laufwerksschacht ab, hinten entsteht eine kleine Kante – und insgesamt sieht die Front in der Tat etwas „schief“ aus. Ich finde das allerdings verschmerzbar.
Die Aktivitäts-LED leuchtet übrigens permanent grün, solange das ThinkPad eingeschaltet ist. Bei Zugriffen auf die Platte wird sie dann heller. Die von mir verbaute Platte ist für mein Empfinden sehr leise und stört mich nicht beim Arbeiten.
]]>Hier ist die Lösung: Ich habe ein minimalistisches, portables Screenshot-Tool zusammengehackt. Primär hab ich es für Linux-Systeme gemacht, da es aber keinen großen Aufwand bereitete, hab ich es auch für Windows kompiliert.
Einfach herunterladen, ausführbar machen (chmod +x screenshottool oder mit dem Dateimanager der Wahl), starten und einen Ordner auswählen, in dem die Screenshots gespeichert werden sollen. Dann verzieht sich das Programm in den System-Tray und wartet darauf, von euch angeklickt zu werden. Ein Klick, ein Screenshot. Eine Bestätigung gibt es durch ein kleines Pop-up, das nach einer Sekunde automatisch wieder verschwindet. Die Screenshots werden im PNG-Format abgelegt, der Dateiname ergibt sich aus Datum und Uhrzeit (yyyy-mm-dd_hh-mm-ss.png).
Screenshottool im LXDE-Benachrichtigungsbereich
That’s it. Es wird immer der ganze Bildschirm aufgenommen. Keine bunten Pfeile, keine rosa Herzchen, kein Blingbling.
- Download für Linux (32 Bit) (ca. 4 MB)
- Download für Linux (64 Bit) (ca. 5 MB)
- Download für Windows (ca. 2 MB)
Das Programm stelle ich unter die WTFNMFPL, hier ist der Source Code (GitHub).
Weitere Screenshots:
1. Schritt: Zielordner wählen
Ein Pop-up vermeldet (auf Wunsch): Ein Screenshot wurde aufgenommen!
Kontextmenü