Professional Documents
Culture Documents
Christian Unhold
BACHELORARBEIT
eingereicht am
Fachhochschul-Bachelorstudiengang
in Hagenberg
im September 2008
Diese Arbeit entstand im Rahmen des Gegenstands
Kommunikationsschnittstellen
im
Sommersemester 2008
Betreuer:
ii
Erklärung
Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeit selbst-
ständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen
und Hilfsmittel nicht benutzt und die aus anderen Quellen entnommenen
Stellen als solche gekennzeichnet habe.
Christian Unhold
iii
Inhaltsverzeichnis
Erklärung iii
Kurzfassung vi
Abstract vii
1 Einleitung 1
2 Bluetooth-Kernspezifikation 3
2.1 Funkschicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Frequenzen und Kanäle . . . . . . . . . . . . . . . . . 3
2.1.2 Sendeleistung . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.3 Modulationsarten . . . . . . . . . . . . . . . . . . . . . 4
2.2 Basisbandschicht . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 Physikalische Kanäle . . . . . . . . . . . . . . . . . . . 5
2.2.2 Vernetzung . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.3 Adressierung . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.4 Physikalische Verbindungen . . . . . . . . . . . . . . . 6
2.2.5 Datenpakete . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.6 Logische Kanäle . . . . . . . . . . . . . . . . . . . . . 8
2.3 Link Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1 Nachrichtenformat . . . . . . . . . . . . . . . . . . . . 9
2.3.2 Verbindungssteuerung . . . . . . . . . . . . . . . . . . 10
2.3.3 Authentifizierung . . . . . . . . . . . . . . . . . . . . . 11
2.3.4 Pairing . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.5 Verschlüsselung . . . . . . . . . . . . . . . . . . . . . . 14
2.4 Host Control Interface . . . . . . . . . . . . . . . . . . . . . . 14
2.4.1 Kommandopakete . . . . . . . . . . . . . . . . . . . . 15
2.4.2 Ereignispakete . . . . . . . . . . . . . . . . . . . . . . 16
2.4.3 Datenpakete . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Logical Link Control and Adoption Layer Protocol . . . . . . . 16
2.5.1 Datenkanäle . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5.2 Kanalverwaltung . . . . . . . . . . . . . . . . . . . . . 17
2.5.3 Datenpakete . . . . . . . . . . . . . . . . . . . . . . . . 18
iv
Inhaltsverzeichnis v
2.5.4 Signalpakete . . . . . . . . . . . . . . . . . . . . . . . 19
2.6 Service Discovery Protocol . . . . . . . . . . . . . . . . . . . . 19
2.7 RFCOMM-Protokoll . . . . . . . . . . . . . . . . . . . . . . . 21
3 Bluetooth im OSI-Referenzmodell 23
3.1 Bitübertragungsschicht . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Sicherungsschicht . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 Vermittlungsschicht . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Transportschicht . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5 Weitere OSI-Schichten . . . . . . . . . . . . . . . . . . . . . . 26
4 Bluetooth-Profile 27
4.1 Grundlegende Profile . . . . . . . . . . . . . . . . . . . . . . . 28
4.1.1 GAP – Generic Access Profile . . . . . . . . . . . . . . 28
4.1.2 SDAP – Service Discovery Application Profile . . . . . 29
4.1.3 SPP – Serial Port Profile . . . . . . . . . . . . . . . . 29
4.1.4 GOEP – Generic Object Exchange Protokoll . . . . . . 29
4.1.5 GAVDP – Generic Audio Video Transport Profile . . . 29
4.2 Abgeleitete Profile . . . . . . . . . . . . . . . . . . . . . . . . 29
Literaturverzeichnis 40
Kurzfassung
vi
Abstract
vii
Kapitel 1
Einleitung
1
1. Einleitung 2
Eine Schwäche von Bluetooth liegt in der Prozedur zum Aufbau einer si-
cheren Verbindung zwischen zwei Geräten. Während Bluetooth in der Ver-
sion 2 Schwächen der kryptographischen Verfahren beseitigt, lässt die User
Experience immer noch zu wünschen übrig. So müssen Passschlüssel einge-
tippt oder Verifikationsnummern verglichen werden. Die einzig komfortable
Methode, nach dem sogenannten Simply-Works-Verfahren, leidet weiterhin
an einer Sicherheitsschwäche. Sie ermöglicht Man-In-The-Middle-Angriffe.
Hier kann NFC aushelfen, eine neue Funktechnologie die von kontaktlosen
Chipkarten abstammt. Mit NFC als alternativem, sicherem Kommunikati-
onsmedium kann eine Bluetooth-Verbindung komfortabel aufgebaut werden.
In Kapitel 5 ist beschrieben, wie sich das intuitive Anwendungsparadigma
von NFC (Touch And Go) für Bluetooth nutzen lässt.
Kapitel 2
Bluetooth-Kernspezifikation
In der Kernspezifikation von Bluetooth sind die untersten Schichten des Pro-
tokollstapels beschrieben (Abbildung 2.1) [4]. Dieser Protokollstapel stellt
den Applikationen Kontroll- und Datenschnittstellen für die synchrone (Au-
dio) und asynchrone (Daten) Kommunikation zur Verfügung.
2.1 Funkschicht
2.1.1 Frequenzen und Kanäle
Bluetooth arbeitet im ISM-Band1 bei 2,4 GHz. Dieses Band erstreckt sich
von 2400 MHz bis 2483,5 MHz und darf praktisch weltweit frei benutzt wer-
den [14].
Für Bluetooth wird die verfügbare Bandbreite in 1 kHz breite Kanäle
unterteilt. Um ein Übersprechen auf Frequenzen außerhalb des ISM-Bandes
1
Industrial, Scientific and Medical
3
2. Bluetooth-Kernspezifikation 4
zu vermeiden, ist am oberen und unteren Ende ein nicht verwendeter Be-
reich vorgesehen [4]. Dieser Schutzbereich ist nach unten 2 MHz, nach oben
3,5 MHz breit.
Es ergeben sich 79 Kanäle mit der Breite von 1 kHz, die in einem kombi-
nierten Frequenzsprung- und Zeitduplexverfahren, dem Frequency Hopping
Spread Spectrum (FHSS) zur Datenübertragung verwendet werden. Dazu
wird die Zeit in sogenannte Slots eingeteilt, die jeweils 625 µs lang sind. Die
Kommunikationspartner senden abwechselnd für die Dauer eines Slots. Jeder
Slot nutzt zur Übertragung einen anderen der 79 verfügbaren Kanäle. Beim
Übergang von einem Slot zum nächsten wird der Kanal gewechselt (Hop-
ping). Der Wechsel der Kanäle erfolgt in einer pseudo-zufälligen Reihenfol-
ge. Durch das ständige wechseln der Frequenz werden Störungen vermindert
und ein Abhören der Kommunikation erschwert.
2.1.2 Sendeleistung
Bluetooth-Geräte werden nach der maximalen Sendeleistung in drei Leis-
tungsklassen eingeteilt, wie in Tabelle 2.1 dargestellt. Geräte der Leistungs-
klasse 1 müssen eine automatische Anpassung der Sendeleistung implemen-
tieren, um den Strombedarf und Interferenzen zu minimieren [4]. Bei Geräten
der anderen Leistungsklassen ist dies optional möglich. Die Anpassung der
Sendeleistung erfolgt durch Messung der empfangenen Signalstärke mittels
RSSI2 und Anpassung durch Kommandos des LMP-Protokolls (siehe Ab-
schnitt 2.3).
2.1.3 Modulationsarten
Es sind zwei Modulationsarten spezifiziert [4]:
Verbesserte Datenrate (EDR): Sie ist seit Version 2.0 des Bluetooth-
Standards [4] spezifiziert, und kann optional implementiert werden. Die PSK4 -
Modulation, eine Phasenmodulation, wird verwendet. Davon sind wiederum
2 Varianten möglich:
2.2 Basisbandschicht
2.2.1 Physikalische Kanäle
Ein Übertragungskanal wird durch die pseudo-zufällige Sprungsequenz inner-
halb der genutzten Trägerfrequenzen identifiziert. Geräte die untereinander
kommunizieren, kennen diese Sprungsequenz und wechseln zur selben Zeit
auf die gleiche Frequenz. Die Sprungsequenz wird durch die Geräte-Adresse
des Masters bestimmt (siehe Abschnitt 2.2.3). Der Master und ein Slave
senden abwechselnd Datenpakete, wobei der Master die geraden und der
Slave die ungeraden Zeitschlitze benutzt. Sollte es zu Kollisionen mit ande-
ren Übertragungskanälen kommen, weil zufällig zur gleichen Zeit die gleiche
Frequenz verwendet wird, wird die Kollision erkannt und das Datenpaket
später wiederholt. Normale Pakete belegen einen Zeitschlitz. Daneben gibt
es noch Pakete die 3 oder 5 Zeitschlitze belegen, um den Durchsatz zu erhö-
hen [4].
2.2.2 Vernetzung
Bluetooth-Geräte im gleichen physikalischen Kanal bilden ein Pikonetz. An
einem Pikonetz können maximal acht Geräte (Knoten) zur selben Zeit aktiv
teilnehmen. Es besteht aus einem Master -Knoten und bis zu sieben Slave-
Knoten. Weitere Geräte können geparkt sein, d. h. sie sind gerade vorüber-
gehend deaktiviert, können jedoch innerhalb weniger Slot-Zyklen aktiviert
werden. Geräte in Bereitschaft nehmen nicht am Pikonetz teil.
4
Phase Shift Keying
5
Differential Quaternary Phase Shift Keying
6
Differential Phase Shift Keying
2. Bluetooth-Kernspezifikation 6
Bei Bluetooth kann grundsätzlich jedes Gerät Master oder Slave sein.
Erst während ein Pikonetz aufgebaut wird, entscheidet sich, welche Rolle ein
Gerät einnimmt. Meistens wird dabei der Initiator der Kommunikation zum
Master. Es ist sogar ein Rollentausch in einem bestehenden Netz möglich [4].
2.2.3 Adressierung
Bluetooth verwendet vier Arten von Adressen [15]:
verfügt über genau einen ACL-Kanal, über den Nutzpakete und Steuerinfor-
mationen übertragen werden. Telegramme an alle Teilnehmer (Broadcast)
oder eine Gruppe (Multicast) sind möglich [25].
Master und Slave können, im Rahmen der gesamt möglichen Datenrate,
gleichzeitig mehrere SCO-Verbindungen und die ACL-Verbindung unterhal-
ten.
Die isochrone Verbindung stellt einen Sonderfall der asynchronen Verbin-
dung dar. Hier wird versucht, Datenpakete möglichst gleichmäßig zu über-
tragen. Es wird versucht, die Pakete rechtzeitig zuzustellen, was aber nicht
garantiert werden kann (Best Effort) [15]. Der zeitliche Bezug wird dabei
durch spezielle Timing-Pakete auf höheren Protokollebenen wieder herge-
stellt [25].
2.2.5 Datenpakete
Ein Bluetooth-Paket der Basisbandschicht besteht aus einem Zugriffscode,
einem Paketkopf und den Nutzdaten. In Abbildung 2.2 ist ein Paket der
Basisbandschicht bei der Übertragung mit der Grunddatenrate (Basic Rate)
dargestellt. Bei einer Übertragung mit verbesserter Datenrate (EDR) (Ab-
bildung 2.3) wird der Zugriffscode und Paketkopf in der Grunddatenrate
übertragen, dann wird auf die andere Modulation umgeschaltet.
• Der Channel Access Code (CAC) legt die Zugehörigkeit zu einem Piko-
netz fest. Er wird aus der 48-Bit Stationsadresse des Masters gebildet.
• Der Device Access Code (DAC) dient zum Aufruf eines bestimmten
Gerätes. Dieser wird aus der Stationsadresse des aufgerufenen Gerätes
gebildet.
2. Bluetooth-Kernspezifikation 8
• Das Paket vom Typ POLL prüft, ob Teilnehmer noch erreichbar sind.
2.3.1 Nachrichtenformat
Um ihre Aufgaben zu erfüllen, kommunizieren die Link Manager der Kom-
munikationspartner per Link Management Protocol (LMP). Die ausgetausch-
ten Nachrichten werden PDUs (Protocol Data Units) genannt. Das Format
der PDUs it in Abbildung 2.4 dargestellt: Die Transaktions-ID hilft bei der
Zuordnung von Abfragen und Antworten zu einer Transaktion. Das Feld
Opcode spezifiziert den Typ der Nachricht. Darauf folgen die Paramter der
Nachricht, fals vorhanden.
2. Bluetooth-Kernspezifikation 10
Der Austausch von PDUs erfolgt nach festgelegten Sequenzen, die logi-
sche Zusammenhänge beschreiben [4]. Ein Gerät muss nicht alle Sequenzen
unterstützen, nur grundlegende Funktionen sind zwingend zu implementie-
ren. Jedes PDU wird bestätigt, wobei bei einer negativen Bestätigung der
Grund in Form eines Fehlercodes angegeben wird [25].
2.3.2 Verbindungssteuerung
Der Link Manager verwaltet den Betriebsmodus einen Bluetooth-Gerätes
((Abbildung 2.5) und nimmt die Zustandsänderungen vor:
Ein Bluetooth-Gerät, das nicht an einem Pikonetz teil nimmt, ist im
Bereitschaftszustand (Standby). In diesem Zustand wird sehr wenig Strom
verbraucht, weil der Sende- und Empfangsteil vollständig deaktiviert werden
kann [9]. Von diesem Zusand aus kann das Gerät auf zwei Arten aktiv werden.
Das Gerät kann selbst ein Pikonetz gründen, oder prüfen, ob bereits ein
Pikonetz vorhanden ist.
Um selbst ein Pikonetz zu gründen, wechselt das Gerät in den Zustand
Inquiry. Nun werden Pakete mit dem Inquiry Access Code (IAC, siehe Ab-
schnitt 2.2.5) auf 32 festgelegten Trägerfrequenzen ausgesendet und auf Ant-
worten gewartet [25]. Das Gerät nimmt damit die Rolle des Master ein.
Um ein vorhandenes Pikonetz zu finden, wird auf den dafür festgelegten
Trägerfrequenzen nach IAC-Nachrichten gelauscht. Sobald so eine Nachricht
2. Bluetooth-Kernspezifikation 11
2.3.3 Authentifizierung
Um die Identität eines Kommunikationspartners zu verifizieren, wird ein Ver-
bindungsschlüssel verwendet, den beide Geräte kennen müssen.
Der Verbindungsschlüssel wird nach einem Abfrage-Antwort-Schema ge-
prüft. Dazu übermittelt das abfragende Gerät A dem abzufragenden Gerät
B eine Zufallszahl. Dieses berechnet nach einem festgelegten Algorithmus
aus der Zufallszahl, dem Verbindungsschlüssel und der eigenen Geräteadres-
se den Sicherheitsschlüssel, der als Antwort gesendet wird. Die Antwort wird
von Gerät A mit dem selbst ermittelten Sicherheitsschlüssel verglichen. Stim-
men die Ergebnisse überein, ist die Authentifikation gelungen. Gerät A hat
damit sichergestellt, das Gerät B den Verbindungsschlüssel kennt. Will Ge-
rät B den Verbindungsschlüssel von Gerät A prüfen, muss es ebenfalls eine
Authentifizierung nach der beschriebenen Methode durchführen.
2.3.4 Pairing
Das Aushandeln eines gemeinsamen Verbindungsschlüssels wird bei Blue-
tooth als Pairing bezeichnet. Pairing ist das zentrale Sicherheitskonzept
2. Bluetooth-Kernspezifikation 12
Authentifizierung Phase 1
Die erste Phase der Authentifizierung kann auf verschiedene Arten stattfin-
den, die sich in der Sicherheit und den Anforderungen an die Geräte un-
terscheiden. Um ein passendes Verfahren auszuwählen, verständigen sich die
Geräte über ihre Ein- und Ausgabemöglichkeiten.
Es sind vier Protokolle spezifziert:
Just Works Protocol: Das Just Works Protocol ist eine vereinfachte Form
des Numeric Comparision Protocol. Der letzte Schritt, in dem die sechsstelli-
ge Verifikationssnummer berechnet und verglichen wird, entfällt. Die Geräte
10
Diffie-Hellman-Schlüsselaustausch mit Kryptographie auf Basis elliptischer Kurven [4]
2. Bluetooth-Kernspezifikation 13
müssen somit über keine Ausgabemöglichkeit verfügen. Das Verfahren ist an-
fällig für Man-In-The-Middle-Attacken. Diese müssen jedoch zum Zeitpunkt
des Pairings stattfinden.
Authentifizierung Phase 2
In der zweiten Phase der Authentifizierung wird bestätigt, dass beide Gerä-
te den Schlüsselaustausch erfolgreich vollzogen haben. Dazu wird aus dem
gemeinsamen Schlüssel und allen vorher ausgetauschten Werten nach einem
Einweg-Algorithmus ein Wert errechnet und verglichen. Schlägt der Vergleich
fehl, wird der Pairing-Prozess abgebrochen.
Abbildung 2.6: Das HCI, die Schnittstelle zwischen Host und Controller
[25]
2.3.5 Verschlüsselung
Optional kann eine Verschlüsselung auf LMP-Ebene verwendet werden. Da-
zu werden die Nutzdaten der Basisband-Pakete (Abbildungen 2.2 und 2.3)
vom Link Manager verschlüsselt. Zugriffscode und Paketkopf werden immer
unverschlüsselt übertragen. Vorraussetzung ist der gemeinsame Verbindungs-
schlüssel aus dem Pairing-Protokoll [4].
2.4.1 Kommandopakete
Kommandopakete werden vom Host zum Controller gesendet und decken
den zentralen Funktionsumfang der HCI-Schnittstelle ab [25]. Die Details
finden sich in der Bluetooth-Kernspezifikation [4].
• Link Control Commands dienen der Kontrolle von Verbindungen zu
anderen Geräten. Damit werden andere Geräte aufgefunden, Verbin-
dungen erzeugt, authentifiziert und verschlüsselt.
2.4.2 Ereignispakete
Ein Kommandopaket wird vom Bluetooth-Controller mit einem Ereignis-
paket beantwortet. Ereignispakete dienen auch dazu, den Controller über
Ereignisse und Anforderungen zu informieren [25].
Normalerweise ist die Kommunikation zwischen Host und Controller im-
mer vom Host getrieben. Ein unerwartetes Ereignispaket kommt dabei in
seiner Bedeutung einem Interrupt gleich.
2.4.3 Datenpakete
Datenpakete werden vom Host-System und Bluetooth-Controller zum Ver-
senden von Nutzdaten verwendet. Dabei wird zwischen Datenpaketen für
ACL- und SCO-Verbindungen unterschieden.
Um eine gleichzeitige Kommunikation mit verschiedenen Geräten zu er-
möglichen, werden verschiedene virtuelle Kanäle durch ein Connection Hand-
le identifiziert [25].
2.5.1 Datenkanäle
Zur Kommunikation stellt das L2CAP virtuelle Datenkanäle zur Verfügung.
Diese Datenkanäle werden durch eine Kanal-ID (CID) identifiziert.
Es existieren drei Arten von Datenkanälen [15]:
2.5.2 Kanalverwaltung
Zum Aufbau und Abbau von Datenkanälen werden Signale über Kanal 1
übertragen. Es wird das Client-Server -Schema eingesetzt, wobei Client und
Server bei Bluetooth auch als Initiator und Akzeptor bezeichnet werden. Der
Initiator stellt eine Anfrage, die der Akzeptor beantwortet. Kanäle werden
über einen 3-Wege-Handshake auf- und abgebaut.
man Indication. Die dazugehörige Antwort wird als Response bezeichnet. Ei-
ne vollständige Liste aller Ereignisse ist in [4] und [25] zu finden.
Ein wichtiger Schritt beim Aufbau eines Kanals ist das Aushandeln der
Dienstgüte. Wenn eine höhere Schicht einen Kanal von L2CAP anfordert,
kann sie den Servicetyp festlegen. Anforderungen wie maximale Datenra-
te, Puffergröße, Latenz und Jitter 13 können spezifziert werden. Die maxi-
male Nutzdatengröße des Empfängers (MTU) sowie die Anzahl an Über-
tragungswiederholungen im Fehlerfall sind ebenfalls wichtige Eigenschaften
eines L2CAP-Kanals [25]. Bei der Übertragungswiederholung wird unter-
schieden zwischen Best Effort und einer garantierten Zustellung.
2.5.3 Datenpakete
L2CAP erlaubt das Versenden von Paketen mit einer Größe von bis zu
64 kByte. Die unterschiedlichen Typen von Datenkanälen besitzen unter-
schiedliche Paketformate. Die L2CAP-Pakete werden in Pakete der Basis-
bandschicht gekapselt. Nachdem die Pakete der Basisbandschicht nur maxi-
mal 340 Byte an Nutzdaten aufnehmen können, müssen die L2CAP-Pakete
aufgeteilt werden [4]. Der Paketkopf wird dabei nur im ersten Paket übertra-
gen. Die Flusskontrolle der Basisbandschicht dient dazu, den Anfang eines
neuen Paketes zu markieren und von einer fortgesetzten Übertragung von
L2CAP-Daten zu unterscheiden [4].
2.5.4 Signalpakete
Über eine Schnittstelle für die darüberliegende Schicht erlaubt die L2CAP-
Schicht das Versenden und Empfangen von Datenpaketen nach dem in Ab-
schnitt 2.5.3 beschriebenen Format. Zur Steuerung und Signalisierung wird
dieselbe Schnittstelle eingesetzt, wobei die ausgezeichnete Kanal-ID 0x0001
für den Steuerungskanal verwendet wird. In Tabelle 2.3 ist die Funktion der
existierenden Signalpakete kurz beschrieben. Eine Beschreibung der enthal-
tenen Datenfelder ist in [4] zu finden.
Eine weitere Form der Signale sind die sogenannten Optionen. Sie er-
weitern die möglichen Konfigurationsoptionen, indem sie dem Empfänger
über Eigenschaften des Gerätes informieren. Diese betreffen die maximale
Paketgröße, erweiterte Methoden zur Flusskontrolle und Übertragungswie-
derholung, sowie verbesserte Dienstgüte-Klassen [4].
deren Geräten genutzt werden können, muss ein Gerät Informationen über
die verfügbaren Dienste bereitstellen. Diese Aufgabe übernimmt das Service
Discovery Protocol (SDP).
SDP arbeitet nach dem Client-Server -Modell. Ein Gerät, das Dienste
anbietet, besitzt einen SDP-Server. Um Dienste abzufragen, wird der SDP-
Client verwendet. Eine Applikation zum Auffinden von Diensten (Service
Discovery Application) nutzt einen SDP-Client, um über einen SDP-Server
sogenannte Service Records abzufragen. Wenn die verfügbaren Dienste be-
kannt sind, kann nach einem spezifischen Protokoll eine Verbindung zu einem
Dienst aufgebaut werden [25].
Am Server sind die Service Records in einer Datenbank zusammenge-
fasst. Ein Service Record fasst verschiedene Attribute eines Dienstes zusam-
men. Ein Attribut ist die Serviceklasse. Sie beschreibt die Zugehörigkeit
eines Dienstes zu einem bestimmten Diensttyp. Serviceklassen sind hiera-
2. Bluetooth-Kernspezifikation 21
2.7 RFCOMM-Protokoll
Radio Frequency Communication (RFCOMM) nutzt das L2CAP-Protokoll,
um serielle Verbindungen zu emulieren. Damit erfüllt Bluetooth die ur-
sprüngliche Anforderung, bestehende Kabelverbindungen ersetzen zu kön-
nen.
RFCOMM baut auf dem ETSI14 -Standard TS 07.10 [6] auf, einem Multi-
plexing-Protokoll für Telefonie- und Datendienste. Von RFCOMM wird aber
nur ein Bruchteil von TS 07.10 implementiert und Bluetooth-spezifische Er-
weiterungen getroffen [3].
14
European Telecommunications Standards Institute
2. Bluetooth-Kernspezifikation 22
• Eine Verbindung eines Gerätes vom Typ 1 über einen Gateway und
ein anderes Übertragungsmedium (z.B. eine physikalische EIA-232-
Verbindung) zu einem Endgerät. Der Bluetooth-Gateway wird als Typ 2
bezeichnet. Mit diesem Typ der Verbindung können Geräte mit Kabel-
verbindung Bluetooth-tauglich gemacht werden.
15
Ein Standard für eine serielle Schnittstelle, ursprünglich RS-232
Kapitel 3
Bluetooth im
OSI-Referenzmodell
Das OSI1 -Referenzmodell [10] beschreibt abstrakt die Aufgaben eines Kom-
munikationssystems. Es wurde von der International Standard Organization
standardisiert. Das OSI-Modell basiert auf sieben Schichten, wovon jede ei-
ne Aufgabe erfüllt. Der Funktionsumfang einer Schicht ist genau definiert
und sie ist klar von den anderen Schichten abgegrenzt. Die Schichten sind
hierarchisch aufgebaut. Eine Schicht greift nur auf die Dienste der darunter
1
Open System Interconnect
23
3. Bluetooth im OSI-Referenzmodell 24
liegenden Schicht zu und stellt der darüber liegenden Schicht ihre Dienste
zur Verfügung. Durch definierte Schnittstellen zwischen den Schichten lassen
sich diese austauschen und wiederverwenden.
Logisch kommunizieren die einzelnen Schichten von Teilnehmern mitein-
ander, während physikalisch ein Informationsaustausch durch den Stapel aus
Schichten stattfindet. In Abbildung 3.1 sind die vorhandenen Schichten und
der Informationsfluss zwischen ihnen dargestellt.
Die Kernspezifikation von Bluetooth deckt nur einen Teil der Schichten im
OSI-Referenzmodell ab. Erst mit darauf aufbauenden, adaptierten Proto-
kollen ist ein Protokollstapel ähnlich dem OSI-Referenzmodell vorhanden.
Ein Beispiel für solche adaptierte Protokolle ist die IP2 -Protokollfamilie.
Für die Übertragung von IP über ein serielles Medium, hier die Dienste
der RFCOMM-Schicht, ist das Sicherungsprotokoll PPP3 nötig. Alternativ
kann das neuere BNEP4 verwendet werden, welches direkt auf L2CAP auf-
setzt und einen Transport von Netzwerkpaketen ermöglicht [2].
Abbildung 3.2 stellt einen Bluetooth-Protokollstapel mit aufgesetzter IP-
Protokollfamilie und eine mögliche Zurdnung zu den Schichten im OSI-
Referenzmodell dar. Im folgenden werden die untersten Schichten des OSI-
Referenzmodelles mit den Kernprotokollen von Bluetooth verglichen.
2
Internet Protocol
3
Point to Point Protocol
4
Bluetooth Network Encapsulation Protocol
3. Bluetooth im OSI-Referenzmodell 25
3.1 Bitübertragungsschicht
Die Bitübertragungsschicht beschreibt die bitweise Übertragung von Infor-
mationen über ein physikalisches Medium. Dazu gehört die elektrische und
mechanische Spezifikation des Übertragungsmediums [10].
Bei Bluetooth entspricht das der Funkschicht, also der Basisbandüber-
tragung im 2,4 GHz-Band mit Frequenzsprungverfahren [25].
3.2 Sicherungsschicht
Die Aufgabe der Sicherungsschicht ist es, Datenpakete zwischen den Enden
des Übertragungsmediums zu transportieren. Die Aufgaben werden in zwei
Bereiche geteilt.
Die Medienzugriffskontrolle (MAC5 ) ist für den geregelten Zugriff auf das
Kommunikationsmedium zuständig. Diese Aufgabe wird bei Bluetooth von
der Basisbandschicht übernommen [25].
Die Verbindungsverwaltung (LLC6 ) zerteilt die Daten in geeignete Da-
tenrahmen. Die Daten werden durch Prüfsummen abgesichert, um Übertra-
gungsfehler erkennen zu können. Übertragungsfehler können bis zu einem
gewissen Grad durch Wiederholungen ausgebessert werden. Grundsätzlich
ist aber keine verlustfreie Kommunikation garantiert [10]. Diese Aufgaben
werden bei Bluetooth von den Verbindungsprotokollen LMP und L2CAP
erfüllt [25].
3.3 Vermittlungsschicht
Die Vermittlungsschicht vermittelt zwischen Kommunikationspartnern in ei-
nem ausgedehnten Netzwerk und leitet Datenpakete über mehrere Netzwerk-
knoten weiter (Routing). In den Bluetooth-Kernprotokollen findet sich dazu
keine Entsprechung. Dies ist auch nicht nötig, weil durch die Netztopolo-
gie von Bluetooth normalerweise keine Kommunikation über mehrere Kno-
ten stattfindet. Eine Ausnahme ist das sogenannte Scatternetz. Hier nimmt
ein Bluetooth-Gerät wechselweise an zwei Pikonetzen teil. Der Bluetooth-
Standard bietet aber keine Möglichkeit, zwischen den Netzen zu vermitteln.
Diese Funktion muss in Form einer proprietären Anwendung implementiert
werden [4]. Adaptierte Protokolle, die Bluetooth als Transportprotokoll ein-
setzen, können ihre eigene Vermittlungsschicht mit sich bringen.
5
Media Access Control
6
Logical Link Control
3. Bluetooth im OSI-Referenzmodell 26
3.4 Transportschicht
Die Transportschicht teilt den Datenstrom in Pakete und setzt diese in
der richtigen Reihenfolge wieder zusammen. Sie ermöglicht eine gesicherte
und verlustfreie Datenübertragung in verschiedenen Dienstgüteklassen. Da-
bei wird eine Vermittlungsschicht angenommen, in der Paketverluste auftre-
ten können [10]. Auch diese Schicht ist bei Bluetooth nicht zu finden. Ihre
Aufgaben werden zum Teil von Basisband und L2CAP übernommen.
Bluetooth-Profile
27
4. Bluetooth-Profile 28
stellen Profile einen vertikalen Schnitt durch den Protokollstapel dar (Abbil-
dung 4.1) [25].
Die Profile sind hierachisch aufgebaut. Ein abgeleitetes Profil erweitert
oder spezialisiert die Funktionen der Basis. In Abbildung 4.2 sind alle zur
Zeit spezifizierten Profile und ihre Abhängigkeiten dargestellt.
1
Object Exchange
2
Audio/Video Distribution Transport
4. Bluetooth-Profile 30
Near Field Communication (NFC) ist eine neue Funktechnologie für kurze
Distanzen. Sie basiert auf RFID1 -Technik, verwendet also das magnetische
Feld von Spulen, um durch Induktion Daten zu übertragen. Bei einer Trä-
gerfrequenz von 13,56 MHz sind damit Datenraten von bis zu 424 kBit/s
möglich. NFC unterscheidet sich daher wesentlich von herkömmlichen Funk-
technologien. Die extrem geringe Reichweite von etwa 10 Zentimetern ist die
Basis von Anwendungsparadigma und Sicherheitskonzept.
Eine Verbindung wird einfach dadurch hergestellt, dass Sender und Emp-
fänger in Reichweite gebracht werden. Dadurch entsteht für den Benutzer ein
intuitives Anwendungskonzept: „Touch And Go“. Gleichzeitig wird das un-
erwünschte Aufbauen einer Verbindung vermieden [22].
Wie RFID ermöglicht NFC die Kommunikation mit passiven Geräten.
Passive Geräte können selbst kein Magnetfeld erzeugen, sondern senden Da-
ten, indem sie das Feld des Kommunikationspartners abschwächen (Last-
modulation). Gleichzeitig decken sie ihren Strombedarf aus dem Magnetfeld
und benötigen so keine eigene Stromversorgung [7].
NFC wird vor allem in mobilen Geräten zum Austausch geringer Daten-
mengen genutzt. Neben der Übertragung von Multimedia- und Kontaktdaten
wird es auch für Zutrittskontrolle und Bezahlsysteme genutzt [22].
NFC wird durch das NFC-Forum spezifziert. Das NFC-Forum wurde
1994 von NXP Semiconductors, Sony und Nokia gegründet, um NFC-Tech-
nologie zu spezifizieren und zu verbreiten. Mittlerweile hat das NFC-Forum
150 Mitglieder [24].
In Tabelle 5.1 werden NFC und Bluetooth verglichen. Durch die grundle-
gend verschiedenen Eigenschaften ist NFC keine Konkurrenz zu Bluetooth.
Die unterschiedlichen Frequenzbänder ermöglichen einen störungsfreien Be-
trieb von Bluetooth und NFC zur gleichen Zeit. NFC bietet die Möglichkeit,
die Pairing-Prozedur von Bluetooth zu vereinfachen, indem NFC als Out-of-
Band -Übertragungsmedium genutzt wird. Zum Herstellen einer Bluetooth-
1
Radio Frequency Identification
31
5. NFC für Bluetooth 32
NFC Bluetooth
Netzwerk-Konfiguration Peer to Peer Point to Multipoint
Reichweite 10 cm 10 m bis 100 m
Frequenz 13,56 MHz 2,4 GHz
Datenrate bis 424 kBit/s bis 2,1 MBit/s
Set-Up-Zeit kleiner 0,1 s ca. 6 s
Sicherheit Hardware, Protokoll Protokollebene
Kommunikationsmodi aktiv-aktiv, aktiv-passiv aktiv-aktiv
Verbindung werden die Geräte einfach aneinander gehalten. Dann sind die
Bandbreite und Reichweite der Bluetooth-Verbindung verfügbar. NFC macht
damit die Pairing-Prozedur intuitiv und sicher [7].
Typ A: Typ A setzt für die aktive Kommunikation von PCD zu PICC eine
ASK2 -Modulation mit 100% Abschwächung ein. Die Bits werden nach dem
Modified-Miller -Schema codiert. Für die passive Kommunikation von PICC
zu PCD wird OOK3 mit einer Manchester -Kodierung der Bits verwendet
[13].
2
Amplitude Shift Keying
3
On-Off Keying
4
Biplorar Shift Keying
5
Non-Return to Zero – Level
5. NFC für Bluetooth 33
Für die Implementation von passiven Tags bietet das NFC-Forum vier Tag
Operation Specifications. Diese Tags sind bereits kommerziell erhältlich oder
kompatibel zu existierenden Technologien [22].
Typ 1: Der Tag vom Typ 1 basiert auf ISO/IEC 14443 Typ A und kann
gelesen und geschrieben werden. Nachdem ein Schreibschutz aktiviert wurde,
kann der Tag nur mehr gelesen werden. Er verfügt über 96 Bytes an Speicher,
die sich über ein Paging-Verfahren auf bis zu 2 kByte erweitern lassen. Die
Datenrate liegt bei 106 kBit/s [18].
Typ 2: Dieser ist identisch zu Typ 1, verfügt aber nur über 48 Bytes an
Speicher [19].
Typ 3: Der Tag vom Typ 3 basiert auf dem Japanese Industrial Standard
JIS X 6319-4, besser bekannt unter dem Namem FeliCa. Bereits bei der
Herstellung wird bestimmt, ob diese Tags geschrieben werden können. Der
verfügbare Speicherplatz ist variabel, wobei das Limit bei 1 MByte liegt. Die
Datenrate liegt bei 212 kBit/s oder 424 kBit/s [20].
penbezeichner werden für häufig genutzte und wohlbekannte Typen sowie für
proprietäre (sogenannte externe) NFC-Lösungen eingesetzt [16]. Die NFC
Record Type Definition (RTD) [17] spezifiziert den Aufbau dieser NFC-
spezifischen Typenbezeichnungen. In Tabelle 5.2 sind die gültigen Werte für
das Feld TNF aufgelistet.
Der optionale Bezeichner ermöglicht eine Identifikation einzelner Nach-
richten und damit Beziehungen zwischen Nachrichten.
in dem die Medien gelistet sind, über die auch er verfügt. Besitzt er keine der
im Handover Selector gelisteten Möglichkeiten, wird eine leere Liste zurück
gesendet. Bekommt der Handover Selector eine Liste mit Einträgen, ist das
Handover -Protokoll erfolgreich abgeschlossen. Der Handover Selector kann
jetzt eine Verbindung über ein oder mehrere mögliche Übertragungsmedien
öffnen, wobei die Reihenfolge in der Liste einer Priorisierung durch den Han-
dover Selector gleich kommt. In Abbildung 5.2 ist der Vorgang anhand eines
Beispiels dargestellt.
5.3.3 Nachrichtenformat
Handover Request und Handover Select sind nach dem selben Schema aufge-
baut. Die NDEF-Nachrichten beginnen mit einem Handover Request Record
oder einem Handover Select Record. Diese haben den externen Typenbezeich-
ner „Hr“ oder „Hs“ und bestehen aus einer Versionsinformation und einem,
keinem oder mehreren Alternative Carrier Records mit dem Bezeichner „ac“.
Ein „ac“-Record verweist auf NDEF-Records, um die Informationen zu
einem alternativen Komunikationsmedium zusammen zu fassen. Der Carrier
Power State gibt an, in welchem Modus sich das Medium befindet. Die Car-
5. NFC für Bluetooth 37
Abbildung 5.4: Aufbau von Handover Select und Handover Request [23]
rier Data Reference verweist per Index auf einen NDEF-Record vom Typ
Handover Carrier Record oder Carrier Configuration Record.
Der Handover Carrier Record („Hc“) dient dazu, ein Kommunikations-
medium zu identifizieren, ohne weitere Parameter anzugeben. Er wird meist
bei Handover-Select-Nachrichten verwendet.
Der Carrier Configuration Record ist ein NDEF-Record von spezifischem
Typ, der Paramter für den Verbindungsaufbau beinhaltet. Der Typ ist vom
verwendeten Kommunikationsmedium abhängig und lautet bei Bluetooth
„bluetooth.org:sp“.
Die optionale Auxilary Data Reference verweist auf NDEF-Records von
beliebigem Typ die weitere Informationen zu einer aufzubauenden Verbin-
dung enthalten können.
2. Daraus wird ein Handover Request erzeugt und per NFC an ein anderes
Gerät übermittelt.
5. Die Antwort wird zusammen mit der eignenen Geräteadresse als Han-
dover Select per NFC an das anfragende Gerät zurück gesendet.
5. NFC für Bluetooth 39
5.5 Sicherheit
Bluetooth nutzt zum Aufbau einer sicheren Verbindung einen Schlüsselaus-
tausch nach dem Diffie-Hellman-Verfahren. Dieses Verfahren gilt als sicher,
solange ein Angreifer es nicht schaffen kann, die Kommunikation abzufangen
und die übermittelten Daten zu verändern (Man-In-The-Middle-Attack ) [4].
Ein Abhören der Kommunikation reicht nicht aus, um die Sicherheit zu kom-
promittieren. Die Sicherheit des OOB-Pairings mit NFC beruht daher auf
der Immunität von NFC gegenüber Man-In-The-Middle-Angriffen. Ein Man-
In-The-Middle-Angriff ist bei NFC zwar prinzipiell denkbar, durch die ge-
ringe Reichweite aber nur möglich, wenn sich der Angreifer direkt zwischen
den Kommunikationspartnern befindet.
Das NDEF-Protokoll übertragt Nutzdaten generell unverschlüsselt [16].
Eine Verschlüsselung der Daten ist optional auf Anwendungsebene möglich,
bei einem Connection Handover aus den beschriebenen Gründen aber nicht
vorgesehen [23].
Literaturverzeichnis
40
Literaturverzeichnis 41
[15] Labiod, Houda und Afifi, Hossam und De Santis, Constantino: Wi-Fi,
Bluetooth, ZigBee and WiMax. Springer, 2007.
[16] NFC-Forum: NFC Data Exchange Format (NDEF), Juli 2006. http:
//www.nfc-forum.org/specs/.
[17] NFC-Forum: NFC Record Type Definition (RTD), Juli 2006. http://
www.nfc-forum.org/specs/.