Seit der Einführung von Bluetooth im Jahr1999 hat sich diese Funktechnologie mittlerweile nicht nur bei Consumern, sondern auch bei vielen industriellen Anwendungen etabliert. Schätzungsweise mehr als 1,5 Milliarden Bluetooth-Chips wurden in den ersten zehn Jahren verbaut.
Mit zahlreichen Aktualisierungen und Erweiterungen des Standards versucht die Bluetooth Special Interest Group (Bluetooth SIG oder BSIG), dem Standard eine erfolgreiche Zukunft im Wettstreit der Funktechnologien zu sichern.
Im zweiten Teil unserer Mini-Serie zum Bluetooth-Standard zeigen wir Ihnen, wie die eigentliche Kommunikation zwischen den Geräten abläuft. Außerdem werfen wir einen Blick auf die Sicherheits-Features von Bluetooth und weisen auf mögliche Lücken hin. Teil 1 finden Sie hier.
HCI-Interface und Aufbau der Anwendungsprotokolle
Das Host-Controller-Interface (HCI) ist eine Befehlsschnittstelle für den Basisband-Controller und den Link-Manager. Es stellt auch den Zugriff auf die Verbindungsparameter zur Verfügung. Im typischen Fall kann das HCI in etwa mit der TCP-Socket-Schnittstelle gleichgesetzt werden.
Mit dem HCI kommen auch Host-Entwickler in Berührung, da die im HCI bereitgestellten Befehle durch einen HCI-Driver auf dem Bluetooth-Host angesprochen werden, wie dies in Abbildung 9 gezeigt ist.
Der Host Control Transport Layer, der durch die physische Anbindung bereitgestellt wird, verbindet die beiden HCI-Instanzen der beiden miteinander kommunizierenden Bluetooth-Controller. Die jeweiligen Hosts werden durch asynchrone Nachrichten über die HCI-Ereignisse informiert und sind dann dafür verantwortlich, die möglichen Events zu parsen und die erforderlichen Aktionen durchzuführen.
Die Befehlsstruktur des HCI
Die umfangreichen Befehle des HCI sind in die folgenden Gruppen untergliedert: Generic Events, Device Setup, Controller Flow Control, Controller Information, Controller Configuration, Device Discovery, Connection Setup, Remote Information, Synchronous Connections, Connection State, Piconet Structure, Quality of Service, Physical Links, Host Flow Control, Link Information, Authentication and Encryption und Testing.
Die für das Finden von Geräten zuständigen Befehle (Device Discovery) mögen den Umfang und die Aufgaben des HCI illustrieren: Inquiry Command , Inquiry Result Event , Inquiry Result with RSSI Event , Inquiry Cancel Command , Periodic Inquiry Mode Command, Exit Periodic Inquiry Mode Command, Read Inquiry Scan Activity Command, Write Inquiry Scan Activity Command, Read Inquiry Scan Type Command, Write Inquiry Scan Type Command, Read Inquiry Mode Command und Write Inquiry Mode Command
Das Service Discovery Protocol
Eine wichtige Rolle im Ablauf einer Bluetooth-Kommunikation spielt das Service Discovery Protocol (SDP). Damit können unterschiedliche Bluetooth-Geräte erkennen, welche Dienste und Charakteristika die jeweilige Gegenstelle ermöglicht. Hinter diesem System stecken Spargedanken: Dank SDP müssen die Hersteller nicht den kompletten Bluetooth-Stack in ihren Geräten verbauen, sondern können ihre Systeme modular aufbauen.
Wollen zwei Geräte eine Verbindung zueinander aufbauen, können sie die zur Verfügung stehenden Dienste abfragen und darauf basierend eine Verbindung aufbauen. SDP stellt eine wesentliche Grundlage dar, um spontane (Ad-hoc-)Netzwerke aufzubauen.
RFCOMM – Grundlage für Verbindungen
Der RFCOMM-Standard ist mit eines der wichtigsten Anwendungsprotokolle. Er emuliert eine serielle RS-232-Schnittstelle und passt dazu einen Teil der ETSI-Spezifikation TS 07.10 für den Bluetooth-Standard an. Dieser beschreibt die Punkt-zu-Punkt-Verbindung zwischen zwei Geräten über die »serielle Schnittstelle Luft«. Aus diesem Grund werden zum Beispiel auch LAN-Verbindungen über TCP/IP über das serielle Point-to-Point-Protocol (PPP) über RFCOMM implementiert.
RFCOMM besitzt eine ähnlich zentrale Bedeutung wie die drahtgebundene RS232-Schnittstelle. In diesem Fall bedeutet dies, dass das RFCOMM-Protokoll in praktisch allen Bluetooth-Stack-Implementierungen vorliegt und viele proprietäre Anwendungen hierüber abgewickelt werden.
Häufigstes Anwendungsszenario: Gekoppelte Dienste
Zu den meistvorkommenden Bluetooth-Anwendungsfällen gehört das Koppeln verschiedener Geräte. Im Alltag tritt wahrscheinlich die Kopplung einer Freisprecheinrichtung und eines Telefons am häufigsten auf, etwa als Headset oder Freisprecheinrichtung in Fahrzeugen. Hier signalisiert Telephony Control Service – Binary (TCS Binary) den Gesprächsaufbau und -abbau auf der Grundlage der ITU-T-Empfehlung Q.931. Zusätzlich hat die Bluetooth SIG einen Satz der sogenannten AT-Kommandos aus den einschlägigen ITU- und ETSI-Spezifikationen übernommen, um die Ansteuerung von Modems und Mobiltelefonen zu gewährleisten.
Darüber hinaus stehen auch Fax-Dienstleistungen zur Verfügung. Es ist darauf hinzuweisen, dass nur der Gesprächsaufbau über das TCSBIN-Protokoll und die L2CAP-Ebene erfolgt. Die Übertragung der Nutzdaten erfolgt über das Audioprotokoll, das unmittelbar auf einen SCO-Link im Baseband zugreift.
Weitere Anwendungsprotokolle
Darüber hinaus haben verschiedene weitere anwendungsnahe Protokolle Eingang in den Bluetooth-Standard gefunden. Hierzu zählt das Object-Exchange-(OBEX-)Protokoll, das aus dem IrDAStandard für Infrarot-Verbindungen übernommen wurde und das die Repräsentation von Objekten und die Strukturierung von Dialogen zwischen den Objekten modelliert.
Mithilfe von OBEX wird das vCard-Protokoll abgewickelt, das den Austausch von virtuellen Visitenkarten ermöglicht. Das Wireless Application Protocol (WAP), das für die Übermittlung von WML-Ressourcen auf Mobiltelefone entwickelt wurde, steht ebenfalls im Bluetooth-Standard zur Verfügung und wird über die TCP/IP-Schichten realisiert.
Sicherheit in Bluetooth
Sicherheit ist bei drahtlosen Systemen von überragender Bedeutung. Dazu ist eine starke Autorisierung notwendig; zudem muss die Vertraulichkeit zwischen den beiden Geräten stets garantiert sein. Daher unterstützen Bluetooth Sicherheitsmaßnahmen sowohl auf Link als auch auf Application Layer (Bluetooth Security Whitepaper, PDF-Download). Diese sind symmetrisch ausgeführt, sodass jedes Gerät in identischer Art und Weise Authentifizierung und Verschlüsselung in der gleichen Art und Weise durchführen kann.
Das Schlüsselmaterial für den Link Layer wird aus vier Bestandteilen generiert: der Bluetooth Geräteadresse, zwei geheimen Schlüsseln und einer pseudozufälligen Zahl, die für jede Übertragung neu erzeugt wird (laut Specification of the Bluetooth System).Für den Bluetooth-Standard wurde ein spezieller Satz von kryptografischen Algorithmen der sogenannten E-Familie von Massey und Rueppel entwickelt:
Die Authentifizierung der Geräte nutzt ein symmetrisches zweiseitiges Challenge/Response-System, der sogenannten E1 Algorithmus. Für die Verschlüsselung der Daten wird der E0-Algorithmus verwendet, ein symmetrisches Stromverschlüsselungsverfahren.
Die Schlüsselverwaltung und -verwendung besteht aus verschiedenen Elementen. Für die Schlüsselgenerierung werden die kryptografischen Elemente der sogenannten E2- und E3-Algorithmen verwendet.
Sicherheitslücken
Wie immer lassen sich bei kryptografischen Sicherheitssystemen zwei Arten von möglichen Angriffen unterscheiden: Es kann sowohl Schwächen im Algorithmus an sich als auch in der Implementierung im Protokoll geben.
Der E0-Algorithmus wurde umfangreich von der Community analysiert, und es existieren gute Abschätzungen der kryptografischen Stärke. Insbesondere weist mit dem Summationsgenerator ein Element eine Schwäche auf, die in Korrelationsangriffen ausgenutzt werden könnte. Dies erscheint aber angesichts der hohen Resynchronisationsfrequenz unrealistisch.
Direkte Angriffe auf das E0-Verfahren sind bekannt, weisen aber eine erhebliche Komplexität auf: Der Bericht „Security Weaknesses in Bluetooth“ stellt zwei solche Angriffe vor. Auch die Untersuchung “Analysis of the E0 Encryption System” von Scott R. Fluhrer und Stefan Lucks zeigt einen Angriff, der nachweist, dass sich die maximale effiziente Schlüssellänge 84 Bits reduziert, wenn 132 Bits dem Angreifer des verschlüsselten Datenstroms bekannt sind. Die maximale effektive Schlüssellänge kann sich bis auf 73 Bits verringern, wenn 243 Bits des verschlüsselten Datenstroms bekannt sind.
Abgesehen von diesen komplexen theoretischen Lücken sind auch einige allgemeine Schwächen vorhanden. So gab es in der Vergangenheit beispielsweise fehlerhaft implementierte Bluetooth-Stacks, etwa 2006 bei Toshiba. Eine weitere Schwachstelle sind Standard-PINs. Hier machte vor einiger Zeit die Trifinity-Gruppe mit ihrem Car Whisperer von sich reden.
Bekannte Sicherheitsrisiken
Im Bereich der Protokollimplementierungen sind folgende Schwächen bekannt – es sind im Wesentlich auch jene, die zu bekannten Angriffen führen:
Die Schlüssellänge kann zwischen zwei Stationen ausgehandelt werden, wobei die größte gemeinsame Schlüssellänge ausgewählt wird. Bietet eine Station also nur eine geringe Schlüssellänge an, so wird die gesamte Kommunikation mit dieser geringen Länge verschlüsselt.
Die Wahl der PIN-Codes für die Authentifizierung ist ebenfalls eine häufige Schwachstelle. In manchen Systemen ist der PIN-Code sogar fest vorgegeben. Die wechselseitige Authentifizierung basiert nicht auf Zertifikaten und erlaubt damit grundsätzlich auch einen Man-in-the-middle-Angriff.
Die meisten Anwendungsprotokolle bieten selbst keine Sicherheit. Da einige der Protokolle aber auch Zugriff auf das Dateisystem erlauben, eröffnen sich einem Angreifer weitere Sicherheitslücken. Das Service Discovery Protocol (SDP) erlaubt das aktive Sammeln von Informationen über die Stationen, ihre Adressen und die bereitgestellten Dienste.
Fazit und Ausblick
Trotz all dieser Angriffsmöglichkeiten sollte nicht unerwähnt bleiben, dass die Spezifikation der Bluetooth-Security-Mechanismen potenziellen Angreifern bei korrekter Implementierung durch Systementwickler und korrekten Einsatz durch die Benutzer ein hohes Know-how abfordert.
Zum zehnjährigen Geburtstag erscheint die Bluetooth-Entwicklung kein bisschen müde – im Gegenteil: Es scheint eher die Gefahr zu bestehen, dass sich die SIG zu viele neue Ziele setzt. Denn auch andere Techniken versuchen, am Erfolg von Bluetooth anzuknüpfen. Eines der prominentesten Beispiele ist dabei sicherlich Wireless USB. Die Technologie hat durchaus das Zeug, Bluetooth Konkurrenz zu machen, denn die meisten Anwender kennen USB schon, die Hemmschwelle zur Nutzung ist also dementsprechend niedrig.
Dennoch wird Bluetooth auch in den nächsten Jahren nicht aus dem mobilen Alltag wegzudenken zu sein. Denn vor allem in seinem angestammten Bereich, der Koppelung eines Handys mit einem anderen Gerät, kann sich diese Technologie immer wieder beweisen. (mja)