Bluetooth Low Energy
Dr. Blauzahn braucht Sicherheit
Bluetooth Low Energy bietet für medizinische Geräte jede Menge Vorteile. Doch mit den Vorteilen gehen auch Risiken – insbesondere bezüglich der Sicherheit – einher. Wie lassen sich Schwachstellen rechtzeitig erkennen?
Neuere IoMT-Anwendungen (Internet of Medical Things) sind weniger auf kontinuierliches Streaming angewiesen, sondern übermitteln stattdessen in regelmäßigen Abständen kleine Datenmengen. Das gilt vor allem für Sensoranwendungen, bei denen ein entferntes Peripherie-/Medizingerät Informationen weitergibt – wie etwa in der Patientenüberwachung durch smarte Glukosemessgeräte oder diagnostisch vielseitig einsetzbare Sensorpflaster. Möglich macht diese Anwendungen die Weiterentwicklung des Bluetooth-Standards.
BT Classic versus Low Energy
Gefühlt gibt es Bluetooth (BT) schon ewig. Die ursprüngliche Spezifikation kam bereits 1998, die ersten Freisprech-Headsets 1999 auf den Markt. Für Computermäuse, Tastaturen, tragbare Lautsprecher und Kopfhörer ist es längst Standard und hat kabelgebundene Verbindungen fast aussterben lassen. Bluetooth Classic deckt bis zu 79 Kanäle ab und kann bis zu 3 Mbit/s über eine Entfernung von bis zu 50 Meter übertragen – was es unter anderem für die Datenübertragung, das Streaming von Audio und den Austausch von Bildern mit anderen Smartphones nützlich macht.
Während viele Geräte, die Bluetooth Classic verwenden, batteriebetrieben sind (zumindest die Peripheriegeräte), war die Stromversorgung nie ein Problem, da die Komponenten für ein einfaches Aufladen und Austauschen der Batterien konzipiert wurden. Es machte nichts aus, wenn die Batterie einer Computermaus nur noch ein paar Tage hielt. Man konnte einfach ein Ladekabel einstecken oder die Batterien austauschen.
Bluetooth Low Energy (BLE) wurde als neuer Standard entwickelt, um niedrigere Bandbreiten von 125 kbit/s bis zu 2 Mbit/s zu unterstützen, einschließlich eines neuen verbindungslosen Modus zusätzlich zum verbindungsorientierten Modus von Classic. Der größte Fortschritt bei BLE ist die Möglichkeit, Energie zu sparen und Geräte viel länger mit Strom zu versorgen. Standardmäßig befinden sich BLE-Peripheriegeräte im Ruhezustand, bis sie zur Datenübertragung bereit sind. In Kombination mit der geringeren Leistungsaufnahme während der Übertragung bei den niedrigeren Datenraten beträgt der Stromverbrauch von BLE-Geräten in der Regel nur 1 bis 5 % der Geräte, die Bluetooth Classic verwenden. Ihr Stromverbrauch liegt im Bereich von 15 bis 20 Mikroampere, was bedeutet, dass eine Standardknopfzelle die meisten BLE-Geräte jahrelang mit Strom versorgen kann.
Das IoMT neu gestalten
Angemessene Datenübertragungsraten in Verbindung mit einem geringen Stromverbrauch machen BLE-Geräte ideal für vernetzte medizinische Geräte im IoMT. Ein Blutzuckermessgerät kann beispielsweise BLE nutzen, um den Blutzuckerspiegel zur bequemen Überwachung an ein Smartphone zu übermitteln. In Krankenhäusern können kostengünstige BLE-Tags, die an Geräten angebracht sind, die Bestandsverfolgung und Standortbestimmung erheblich erleichtern. Die Unterstützung von BLE für eine große Anzahl von vernetzten Peripheriegeräten macht es in einer klinischen Umgebung oder in einem Krankenhaus noch wertvoller, da hier möglicherweise Hunderte (oder Tausende) von vernetzten medizinischen Geräten eingesetzt werden. Man denke zum Beispiel an eine Überwachungsstation für das Pflegepersonal. Mit BLE können Sie alle EKGs und andere Patientenüberwachungsgeräte der Etage an eine zentrale Stelle weiterleiten. Die gleiche Idee steckt hinter gesundheitsbezogenen Wearables wie Herzmonitoren und Fitnessuhren, die alle Pulsinformationen über BLE weitergeben.
Die Abschaffung von Kabeln und sperrigen Batterien sowie die Möglichkeit der Kommunikation mit dem Smartphone sind ein großer Fortschritt. Aber wie bei jeder Innovation gibt es unvermeidliche Risiken. Und im Falle medizinischer Geräte sind diese Risiken nicht einfach nur Unannehmlichkeiten wie nachlassende Audioqualität oder Batterielaufzeit. Im Falle des IoMT können die Risiken der Geräte die Sicherheit der Patienten direkt gefährden.
Cybersecurity im IoMT
In vernetzten medizinischen Geräten stellen Cyberangriffe eine massive Bedrohung für die Patientensicherheit dar. So kann unter anderem ein Angriff auf eine BLE-Funkschnittstelle die wesentliche Leistung eines IoMT-Geräts beeinträchtigen – was einem Patienten schaden oder ihn möglicherweise töten könnte. Mehrere Schwachstellen dieser Art wurden bereits in Bluetooth-fähigen medizinischen Geräten entdeckt, was zu weithin veröffentlichten Meldungen, obligatorischen Abhilfemaßnahmen und Geräterückrufen führte. Eines der folgenreichsten Beispiele ist die SweynTooth-Schwachstelle, die eine Reihe von BLE-IoMT-Geräte betraf. Die Auswirkungen waren so gravierend, dass die FDA eine Sicherheitsmitteilung an die Hersteller medizinischer Geräte veröffentlichte, in der sie vor den Gefahren warnte – die Geräte könnten abstürzen, blockieren und einfrieren oder es einem Angreifer sogar ermöglichen, die Sicherheitsvorkehrungen zu umgehen.
Die wichtigste Lehre aus SweynTooth und anderen Schwachstellen dieser Art war, dass die Hersteller dadurch auf vorgelagerte Schwachstellen in der Lieferkette aufmerksam wurden. So besorgniserregend die Schwachstellen auch waren, die Hersteller medizinischer Geräte haben den fehlerhaften Code nicht geschrieben. Tatsächlich wussten sie nicht, dass sie existierten. Sie bezogen einfach ein Bluetooth System on Chip (SoC) von einem Hersteller elektronischer Komponenten und bauten es in ihr Gerät ein. Die SoCs enthielten die Sicherheitslücken. Werden nicht genügend Sicherheitstests vor der Komponentenauslieferung durchgeführt, ist jedes System, in dem sie enthalten sind, einem Risiko ausgesetzt.
Schwachstellen mit Protokoll- Fuzzing aufdecken
Von den SweynTooth-Schwachstellen waren mehrere versierte Hersteller betroffen, darunter Texas Instruments, NXP, Cypress, Dialog Semiconductors, Microchip, STMicroelectronics und Telink Semiconductor. Wie konnten so viele verschiedene Hersteller betroffen sein? Das Problem besteht darin, dass die Schwachstellen in den Protokoll-Stacks versteckt waren, sodass es unglaublich schwierig war, sie zu erkennen und zu diagnostizieren. Während die Sicherheits-Community eine Reihe von Best Practices für das Aufspüren von Schwachstellen auf Anwendungsebene – darunter gängige Taktiken und Datenbanken mit Bedrohungsbibliotheken, die mit Anwendungssoftware und -bibliotheken verglichen werden können – entwickelt hat, sind Schwachstellen auf Protokollebene viel schwieriger zu erkennen. Tatsächlich gibt es nur eine Möglichkeit, diese Art von Schwachstellen angemessen zu testen: ein umfassender Testmechanismus, der als Protokoll-Fuzzing bekannt ist.
Protokoll-Fuzzing bedeutet einfach ausgedrückt, dass systematisch verschiedene Fehler in einen Übertragungsvorgang eingeschleust werden, um den Empfänger am anderen Ende der Verbindung zu verwirren und in einen falschen Zustand zu versetzen. Dabei kann es sich um recht einfache Fehler handeln, wie das Senden mehrerer Kopien eines Pakets, oder um komplexere Verfälschungen eines Protokolls. Ein paar Beispiele sind:
- Die Flags, die den Beginn und das Ende einer Verbindung anzeigen, können in einem einzigen Paket gesetzt werden.
- Felder innerhalb eines Pakets können zu groß oder auch zu klein sein.
- Felder innerhalb eines Pakets können auf ungültige Werte gesetzt werden.
- Pakete können in falscher Reihenfolge zugestellt werden.
In vielen Fällen ist der »Handshake«, der zu Beginn einer Verbindung stattfindet, um Sicherheits-, Verschlüsselungs- und andere Kommunikationsparameter festzulegen, ein leichtes Ziel für Angriffe. Da das entfernte Gerät sich selbst auf der Grundlage der während des Handshakes festgelegten Einstellungen konfiguriert, können speziell korrumpierte Pakete oder Paketfolgen Abschaltungen oder Kommunikationsfehler verursachen, die manuell zurückgesetzt werden müssen.
Im schlimmsten Fall könnte ein Angreifer den Handshake selbst angreifen, wie in CVE-2019-19194 dokumentiert. Da der Handshake Sicherheits- und Verschlüsselungsparameter festlegt, kann ein Angreifer die Kontrollen umgehen, die normalerweise bestimmte Aktionen einschränken würden, und eine willkürliche Kontrolle über das System ermöglichen. Insbesondere für IoMT-Geräte könnte das offensichtliche und katastrophale Auswirkungen haben. Ein Angreifer könnte das Gerät anweisen, falsche Telemetriedaten zu melden, andere Befehle zu ignorieren, Datenschutzbestimmungen für Patienten zu verletzen, indem er Daten an ein nicht autorisiertes System anzeigt, oder sogar eine potenziell tödliche Medikamentendosis zu verabreichen.
Absicherung auf Protokollebene
Die aufgezeigten Schwachstellen stellen ein ernsthaftes Problem für die Hersteller medizinischer Geräte dar, wie die amerikanische FDA und ähnliche Kontrollbehörden weltweit zeigen. Doch wie lassen sich vernetzte Geräte am besten schützen? Für den Anfang bedeutet das die Implementierung von Validierungs- und Verifizierungsstrategien, um Schwachstellen in SoC-Protokoll-Stacks zu identifizieren. Die Hersteller müssen als letzte Verteidigungslinie fungieren. Schließlich sind sie diejenigen, die Warnmeldungen, Abhilfestrategien und Firmware-Updates zur Behebung von Schwachstellen für betroffene Geräte schnell an Patienten und Pflegedienstleister weitergeben müssen. Und wie im obigen Beispiel erwähnt, sind selbst die bestausgestatteten Anbieter nicht davor gefeit, anfällige Chipsätze zu liefern.
Sicherheit ist jedoch eine Reise, kein Ziel. Aus diesem Grund müssen Gerätehersteller zumindest darauf bestehen, dass die Chipsatzhersteller vor der Produktfreigabe entsprechende Updates bereitstellen. Gleichzeitig müssen sie es auf sich nehmen, umfangreiche Protokoll-Fuzzing-Bewertungen ihrer Systeme durchzuführen und ihre Validierungs- und Verifizierungsstrategien in die FDA-Anträge vor der Marktfreigabe aufzunehmen.
Mit der zunehmenden Verbreitung von BLE-Konnektivität für IoMT-Geräte wird die Protokoll-Fuzzing-Validierung noch wichtiger, um die Patientensicherheit und das Vertrauen in fortschrittliche Technologien zu erhalten. Glücklicherweise werden inzwischen zahlreiche Protokoll-Fuzzing-Toolkits angeboten und sind einfacher zu verwenden – selbst für Qualitätskontrollteams, die wenig oder gar keine Erfahrung mit Cybersecurity haben. In Anbetracht der Zeit, die ein Chipsatzhersteller benötigen kann, um Schwachstellen gründlich zu reproduzieren, zu diagnostizieren, zu beheben und zu validieren, ist es jetzt an der Zeit, mit dem Testen von Produkten in der Entwicklungspipeline zu beginnen. Man braucht nur einen Blick auf SweynTooth zu werfen, um zu sehen, dass die Auswirkungen der Behebung umso kostspieliger sind, je später eine Schwachstelle gefunden wird. (uh)
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Wireless MedTech
Kabellose Medizinprodukte rechtskonform entwickeln
Intelligente Assistenzsysteme
Der Pflege digital auf die Beine helfen
Medizintechnik-Entwicklung
Was bedeutet Embedded KI für MedTech?
