Bluetooth Mesh Sicherheit & Datenschutz: Ein vertrauenswürdiges IoT Netzwerk aufbauen
In Teil 1 und 2 haben wir Bluetooth Mesh Architektur und Nachrichtenfluss erkundet. In der heutigen hyper-vernetzten Welt ist Sicherheit nicht optional – sie ist eine nicht verhandelbare Grundlage für jede Mesh-gestützte IoT-Lösung.
Die Bluetooth SIG verlangt, dass jedes Mesh-Gerät Sicherheit implementiert; Deaktivieren ist verboten. Klassische BLE Point-to-Point Verbindungen können dagegen ohne Sicherheit operieren, wenn der Entwickler dies wählt.
Der Provisioning-Prozess, der ein Gerät dem Mesh hinzufügt, und alle nachfolgenden Datenaustausche sind mit Sicherheit als höchster Priorität engineered.
- Man-in-the-Middle Angriffe werden durch Elliptic Curve Diffie-Hellman (ECDH) Schlüsselaustausch während des Provisioning vereitelt.
- Replay Angriffe werden durch per-Nachrichten Sequenznummern verhindert.
- Trash-Can Angriffe von verworfenen Geräten werden via Key-Refresh (Blacklisting) Prozedur neutralisiert.
Die Mesh Topologie basiert auf mandatory Keys, die jeden Stack Layer schützen. Lassen Sie uns die wichtigsten Sicherheits- und Datenschutzmechanismen im Detail durchgehen.
Provisioning: Hinzufügen eines unprovisionierten Geräts zum Mesh Netzwerk
Ein Mesh Gerät wird zum Node, wenn es provisioniert wird. Das Gerät, das Provisioning durchführt – ein Provisioner – ist typischerweise ein Smartphone. Der Provisioner erstellt das Netzwerk, weist einen Network Key zu und verteilt die erforderlichen Keys. Unprovisionierte Mesh Nodes bewerben sich nach Power-Up. Der Provisioner scannt nach diesen Beacons und etabliert eine Standard BLE Verbindung (mittels PB-GATT in heutigen Geräten), um Keys via ECDH auszutauschen.
Sobald der Session Key abgeleitet ist, verschlüsselt er den Network Key, Device Key, IV Index und Unicast Address, die dann an den Node übertragen werden. Nach erfolgreichem Provisioning tritt der Node in die Konfigurationsphase ein, wo der Provisioner die Fähigkeiten des Nodes entdeckt und Application Keys zuweist. Ein Node kann mehrere Application Keys halten; jeder Key ist an ein spezifisches Mesh Model gebunden, sodass nur die beabsichtigten Geräte den Application Payload entschlüsseln können.
Abbildung 1 illustriert die vollständige Provisioning-Sequenz für eine dimmbare Glühbirne mit dem CYBT-213043-MESH Evaluation Kit.
Wenn die Mesh Helper App des Smartphones die Birne von der unprovisionierten Liste auswählt, initiiert sie den Provisioning Handshake. Die Birne antwortet mit ihren Fähigkeiten – unterstützte Elements, Sicherheitsalgorithmen, OOB Optionen und Input/Output Methoden. Basierend darauf werden die Public Keys entweder via OOB oder über den BLE Link ausgetauscht, gefolgt von Authentifizierung. Nach Authentifizierung der Birne sendet der Provisioner die verschlüsselten Provisioning Daten (Network Key, Device Key, IV Index, Unicast Address, etc.). Der Node ist nun vollständig provisioniert und bereit für Konfiguration.
Network, Application und Device Keys
Network Keys ermöglichen es einem Node, Nachrichten bis zum Network Layer zu entschlüsseln und zu authentifizieren, sodass er Traffic relayen kann. Application Keys werden unter einer Teilmenge von Nodes geteilt, die ähnliche Funktionen ausführen; nur Geräte mit dem korrekten Application Key können den Payload entschlüsseln. Device Keys identifizieren jeden provisionierten Node eindeutig und werden ausschließlich während der Konfigurationsphase verwendet.
Network Key: Ein Node kann einen oder mehrere Network Keys halten, was die Erstellung mehrerer Subnetze innerhalb eines einzelnen Mesh Netzwerks erlaubt. Beispielsweise kann ein mehrstöckiges Parkhaus jede Ebene in ihr eigenes Subnetz isolieren und Relay Traffic auf die relevante Ebene beschränken.
Application Key: Typischerweise geteilt von Geräten, die denselben Zweck erfüllen – z. B. teilen alle Wohnzimmer-Lichter einen Key, während Bewegungssensoren oder Schlösser einen anderen nutzen. Nur Geräte mit dem passenden Key können eine Nachricht interpretieren, die den Zustand eines Lichts ändert.
Device Key: Während des Provisioning zugewiesen, identifiziert der Device Key einen Node eindeutig und wird exklusiv während der Konfigurationsphase genutzt.
Node Entfernung: Key Refresh und Blacklisting
Um zu verhindern, dass ein kompromittiertes oder verworfenes Node einem Zielnetzwerk wieder beitritt – ein Szenario bekannt als Trash-Can Attack – definiert die Mesh Spezifikation ein Key-Refresh Verfahren. Der Provisioner kann einen Node blacklisten und neue Network und Application Keys an alle nicht-blacklisteten Geräte ausgeben. Die alten Keys können keinen Zugriff mehr gewähren, was das Netzwerk gegen Ausbeutung schützt.
Datenschutz (Message Obfuscation)
Datenschutz wird durch einen Privacy Key erreicht, der vom Network Key abgeleitet wird. Das Mesh Protokoll nutzt diesen Key, um Header-Felder wie die Source Address zu obfuskieren, wodurch Eavesdropper daran gehindert werden, Nachrichtenursprünge zu tracken.
Replay Angriffe
Ein Replay Angriff involviert das Erfassen einer legitimen Nachricht und deren erneutes Senden, um das Netzwerk zu stören – beispielsweise das Retransmittieren eines Unlock Commands an ein Türschloss. Das Mesh Protokoll kontert dies mit zwei Safeguards: dem IV Index und der Sequenznummer (SEQ). Jede Nachricht trägt eine SEQ, die mit jedem Publish inkrementiert; Nodes verwerfen jedes Paket mit einer SEQ kleiner oder gleich dem letzten gültigen Wert. Der IV Index muss ebenfalls größer oder gleich dem letzten verarbeiteten Wert sein; andernfalls wird das Paket verworfen. Ein Angreifer bräuchte alle relevanten Keys, um diese Felder zu modifizieren, was erfolgreiche Replays infeasibel macht.
Zusammenfassend garantiert Bluetooth Meshs Provisioning-Prozess, dass nur vertrauenswürdige Geräte dem Netzwerk beitreten und schützt vor MITM, Replay und Trash-Can Attacken. Network Keys ermöglichen Subnetting, Application Keys stellen sicher, dass nur beabsichtigte Geräte Payloads interpretieren, und Key-Refresh Mechanismen entfernen kompromittierte Nodes sicher. Datenschutz Features verbergen Source Addresses, während Sequenznummern und IV Indizes Replay Angriffe verhindern. Zusammen etablieren diese Mechanismen Bluetooth Mesh als hochsichere und private Plattform für IoT Deployments.
In Teil 3 diskutieren wir, wie man das richtige Bluetooth Mesh Gerät für Ihre spezifische Applikation wählt.
Eingebettet
- Synopsys präsentiert vollständiges HBM3 IP-Paket für Multi-Die-Systeme mit 921 GB/s Bandbreite
- Bluetooth Mesh Design Entscheidungen: Module vs. Diskrete Devices
- Cypress launcht Dual-Mode Bluetooth 5.0 MCUs mit Mesh Networking, Bridging IoT Devices zu Smartphones
- Future Electronics formt globale Partnerschaft mit Silvair zur Beschleunigung Bluetooth Mesh Lösungen
- Contrinex 2020: Cloud-Ready Sensoren & Bluetooth Light Curtains für Safety
- Swissbit präsentiert Cutting-Edge Hardware Security für IoT Devices auf it-sa
- Renesas RX23W MCU stärkt IoT-Sicherheit mit Bluetooth 5.0
- Raspberry Pi Heimüberwachung: PIR-Bewegungserkennung mit Kamera-E-Mail-Benachrichtigung
- Nachhaltiger Erfolg: Lektionen in Beharrlichkeit von Abraham Lincoln und Instandhaltungsführung
- Können Sicherheit und Privatsphäre die IoT-Revolution bremsen?