Bluetooth und NFC

Christian Unhold

BACHELORARBEIT

eingereicht am
Fachhochschul-Bachelorstudiengang

Hardware/Software Systems Engineering

in Hagenberg

im September 2008
Diese Arbeit entstand im Rahmen des Gegenstands

Kommunikationsschnittstellen

im

Sommersemester 2008

Betreuer:

Prof. (FH) Mag. DI Josef Langer

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.

Hagenberg, am 4. September 2008

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

5 NFC für Bluetooth 31

5.1 Grundlagen von NFC . . . . . . . . . . . . . . . . . . . . . . . 32
5.2 NFC Data Exchange Format . . . . . . . . . . . . . . . . . . 33
5.3 Connection Handover . . . . . . . . . . . . . . . . . . . . . . 35
5.3.1 Negotiated Handover . . . . . . . . . . . . . . . . . . . 35
5.3.2 Static Handover . . . . . . . . . . . . . . . . . . . . . 36
5.3.3 Nachrichtenformat . . . . . . . . . . . . . . . . . . . . 36
5.3.4 Carrier Configuration Record für Bluetooth . . . . . . 37
5.4 Ablauf von Pairing mit NFC . . . . . . . . . . . . . . . . . . 38
5.5 Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Literaturverzeichnis 40
Kurzfassung

Bluetooth ist eine weit verbreitete Funktechnologie, die geschaffen wurde

um Kabelverbindungen zu ersetzen. Es zeichnet sich durch einen geringen
Strombedarf aus, und benötigt zum Aufbau kleiner Netzwerke keine Basis-
station. Daher wird Bluetooth vor allem bei mobilen Geräten eingesetzt.
Mit einer Reichweite von 10 bis 100 Metern und einer Datenrate von bis zu
2,1 Mbit/s eignet sich Bluetooth für ein weites Spektrum an Anwendungen.
Dementsprechend umfangreich und differenziert gestaltet sich die Spezifikati-
on. Eine Vielzahl von optional zu implementierenden Protokollen ermöglicht
eine gute Anpassung an eine bestimmte Anwendung. Um trotzdem eine hohe
Kompatibilität zwischen den Implementierungen verschiedener Hersteller zu
ermöglichen, fasst Bluetooth für einen Anwendungsfall benötigte Funktionen
und Protokolle zu sogenannten Profilen zusammen.
Bluetooth umfasst ein Konzept, um sichere Verbindungen zwischen zwei
Geräten herzustellen. Je nach verwendeter Methode muss der Anwender Zah-
lenfolgen eintippen oder vergleichen, um eine Verbindung zu erhalten. Um
diese Prozedur zu vereinfachen, kann Near Field Communication (NFC) ein-
gesetzt werden, ein Funkstandard der von kontaktlosen Chipkarten abgeleitet
ist. Damit wird ein schneller und intuitiver Verbindungsaufbau möglich, ein-
fach indem die beteiligten Geräte in sehr kurze Distanz zueinander gebracht
werden.

vi
Abstract

Bluetooth is a widely used wireless communication technology created to

replace cable connections. It is characterized by a low power consumption
and the ability to build up small networks without a base station. Therefore
it is mostly used by mobile devices. With a range of 10 to 100 meters and
a data rate of up to 2.1 Mbps it is suited for a wide range of applications.
As a consequence, the specification is comprehensive and sophisticated. A
multitude of protocols that are optional to implement allow a good adaption
for a specific application. To provide a high level of compatibility between
the implementations of differnt vendors, Bluetooth combines protocols and
functions for specific use cases into profiles.
Bluetooth includes a mechanism for establishing secure connections be-
tween two devices. Depending on the methode used, the user has to enter or
compare sequences of numbers to obtain a connection. To simplify this pro-
cedure, Near Field Communication (NFC) may be used. Near Field commu-
nication is a wireless technology that was derived from contacless integrated
circuit cards. It enables a fast and secure establishment of the connection,
simply by bringing the devices into close proximity.

vii
Kapitel 1

Einleitung

Bluetooth ist eine standardisierte Funktechnologie. Sie wurde geschaffen, um

Kabelverbindungen, vor allem von mobilen Geräten, abzulösen. Sie wird von
der Bluetooth-SIG1 [5] entwickelt und spezifizert. Aktuell (2008) liegt die
Spezifikation in der Version 2.1 vor [4].
Die Reichweite liegt typischerweise im Bereich von wenigen Metern, kann
jedoch optional bis zu 100 Meter betragen.

Bluetooth ermöglicht die Vernetzung weniger Geräte ohne weitere Infrastruk-

tur in sogenannten Pikonetzen. In einem Pikonetz können bis zu acht Geräte
miteinander kommunizieren. Ein Gerät kann aber auch mehreren Pikonetzen
gleichzeitg angehören.
Die Rohdatenrate liegt typischerweise bei 1 Mbit/s, seit Version 2.0 ist
durch EDR2 eine Rate von 3 Mbit/s möglich.
Weil Bluetooth hautptsächlich bei mobilen Geräten eingesetzt wird, wur-
de besonderes Augenmerk auf einen geringen Strombedarf gelegt. Die Geräte
befinden sich die meiste Zeit in einem Stromsparmodus und aktivieren ihre
Sendestufe nur bei Bedarf.

Die Kernspezifikation von Bluetooth wird in Kapitel 2 behandelt. Darin sind

die Funktionen einer Bluetooth-Implementierung von der Funkschicht bis hin
zur Abstraktion auf logische Kanäle und Verbindungsverwaltung beschrie-
ben.
Darauf bauen Protkolle und Anwendungen auf, die dem Benutzer die
Technologie erst zugänglich machen. Vielfach werden einfach bestehende Pro-
tokolle, wie OBEX3 oder IP4 auf Bluetooth aufgesetzt.
Um eine bessere Übersicht über die Protokolle von Bluetooth zu erlangen,
wird in Kapitel 3 eine Einordnung in das OSI-Schichtenmodell vorgenommen.
1
Special Interest Group
2
Enhanced Data Rate
3
Object Exchange Protocol
4
Internet Protocol

1
1. Einleitung 2

Eine Zusammenstellung von optional zu implementierenden Funktionen

und Protokollen, um einen bestimmten Anwendungsfall zu ermöglichen, wird
bei Bluetooth Profil genannt. Alle typischen Bluetooth-Anwendungen wer-
den durch eigene Profile abgedeckt. Beispiele sind Headsets, Mobiltelefone
als Modem, Synchronisation von Kontaktdaten und der Austausch von Visi-
tenkarten. Auch diese Profile werden von der Bluetooth-SIG standardisiert
und machen damit Geräte unterschiedlicher Hersteller kompatibel. Sie wer-
den in Kapitel 4 beschrieben.

Die wichtigsten Eigenschaften sind also Stabilität, Kompatibilität, gerin-

ge Kosten und geringer Strombedarf. Mit diesen Eigenschaften konnte sich
Bluetooth am Markt etablieren und wird in tausenden verschiedenen Ge-
räten eingesetzt [8]. Bis zum Jahr 2008 wurden innsgesamt 1,5 Milliarden
Bluetooth-Geräte ausgeliefert [5].

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

Abbildung 2.1: Protokollstapel der Kernprotokolle [25]

3
2. Bluetooth-Kernspezifikation 4

Tabelle 2.1: Leistungsklassen von Bluetooth-Geräten [4]

Leistungsklasse Max. Sendeleistung

1 100 mW
2 2.5 mW
3 1 mW

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]:

Grunddatenrate: Es wird die GFSK3 -Modulation verwendet. Dabei han-

delt es sich um eine binäre Frequenzmodulation, die sich mit geringem Auf-
wand implementieren lässt [25]. Dadurch werden die Kosten für die Sende-
und Empfangseinheit gering gehalten. Dieser Modus wird von jedem Bluetooth-
Gerät unterstützt und liefert eine Rohdatenrate von 1 Mbit/s.
2
Receiver Signal Strength Indication, ein Indikator für die Empfangsfeldstärke
3
Gaussian Frequency Shift Keying
2. Bluetooth-Kernspezifikation 5

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:

• π/4-DQPSK5 , eine Phasenmodulation bei dem jedes Sendesymbol 2

Datenbits (ein Quadbit) kodiert. Sie liefert eine Rohdatenrate von
2 Mbit/s.

• 8DPSK6 eine Phasenmodulation mit 8 Phasenlagen, bei der pro gesen-

detem Symbol 3 Datenbits kodiert werden. Die Rohdatenrate liegt bei
3 Mbit/s.

Diese beiden Varianten können optional implementiert werden. Zum Ein-

satz können sie nur kommen, wenn der Kommunikationspartner die gleiche
Modulationsart unterstützt.

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]:

• BD_ADDR: Die Bluetooth-Geräteadresse. Sie wird vom Hersteller ver-

geben, ist 48 Bit lang und weltweit einzigartig, vergleichbar mit der
MAC-Adresse bei Ethernet. Sie wird zum Verbindungsaufbau verwen-
det oder um Geräte eindeutig zu identifizieren.

• LT_ADDR: Die aktiver-Teilnehmer-Adresse. Sie ist 3 Bit lang und

adressiert die aktiven Knoten in einem Pikonetz.

• PM_ADDR: Die geparkter-Teilnehmer-Adresse. Diese ist 8 Bit lang

und wird für inaktive (geparkte) Teilnehmer eines Pikonetzes verwen-
det.

• AR_ADDR: Adresse für Zugriffs-Anfragen. Sie wird von geparkten

Teilnehmern verwendet, um wieder die aktive Kommunikation aufzu-
nehmen.

2.2.4 Physikalische Verbindungen

Bluetooth unterscheidet zwei Arten von physikalischen Verbindungen, die

• SCO7 -Verbindung, eine leitungsvermittelte synchrone Kommunikation,

und die

• ACL8 -Verbindung, eine paketvermittelte asynchrone Kommunikation.

Die SCO-Verbindung wird zur Übertragung von Sprachsignalen verwen-

det, die deterministisch übertragen werden müssen. Zeitverzögerungen bei
der Übertragung wären unmittelbar als Störung wahrnehmbar. Für diese
Verbindung erstellen Master und Slave eine exklusive Verbindung. In gleich-
bleibendem Abstand werden eine bestimmte Anzahl an Zeitschlitzen reser-
viert. Damit ist die benötigte Bandbreite zu jeder Zeit verfügbar [25].
Die ACL-Verbindung dient zur Übertragung von Daten in den übrig ge-
bliebenen Zeitschlitzen. Weder eine bestimmte Bandbreite noch eine recht-
zeitigte Zustellung der Daten kann garantiert werden. Jedes Bluetooth-Gerät
7
Synchrounus Connection Oriented
8
Asynchrounus Connectionless Link
2. Bluetooth-Kernspezifikation 7

Abbildung 2.2: Datenpaket der Basisbandschicht, Basic Rate [4]

Abbildung 2.3: Datenpaket der Basisbandschicht, EDR [4]

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.

Es gibt drei Arten von Zugriffscodes:

• 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

• Der Inquiry Access Code (IAC) wird benutzt, um Anfragen an alle

Geräte zu stellen. Damit werden andere Bluetooth-Geräte gefunden.

Der Paketkopf enthält die 3-Bit aktiver-Teilnehmer-Adresse, Bits zur

Flusskontrolle und den Typ des Paketes.

Für Steuerinformationen existieren vier Pakettypen:

• Das ID-Paket wird für Abfragen und Antworten verwendet.

• Das NULL-Paket dient der Bestätigung von übertragenen Paketen und

der Flusssteuerung.

• Das Paket vom Typ POLL prüft, ob Teilnehmer noch erreichbar sind.

• Das FHS9 -Paket wird verwendet, um Stationsadresse, Teilnehmeradres-

se und Sprungreihenfolge mitzuteilen. Es dient dem Aufbau der Kom-
munikation und der Synchronisation während der Kommunikation. Auch
die Serviceklasse des Gerätes wird gesendet. Damit teilt ein Teilneh-
mer mit, welcher Geräteklasse er angehört (z.B. Laptop, Modem) und
welche Funktionen er unterstützt (Serviceklassen, z.B. Telefonie, Bild-
gebung, Netzwerk) [4].

Die Pakettypen von ACL-Verbindungen sind in Tabelle 2.2 aufgelistet.

Sie können 1, 3 oder 5 Zeitschlitze lang sein. Es existieren Varianten mit und
ohne Vorwärtsfehlerkorrektur (FEC), wobei die verwendete Variante je nach
Empfangsbedingungen gewählt wird [15]. Bis auf das AUX1-Paket enthalten
alle Datenpakete für ACL einen Prüfwert zur Fehlererkennung (CRC). Das
AUX1-Paket kann somit verwendet werden, wenn die Sicherung der Bitüber-
tragung bereits auf einer höheren Protokollebene erfolgt ist.
Für SCO-Verbindungen existieren drei Pakettypen, die sich nur in der
Form der Vorwärtsfehlerkorrektur unterscheiden. Ausserdem existiert ein Pa-
ket zur gleichzeitigen Übertragung von Daten und Sprache.

2.2.6 Logische Kanäle

Logische Kanäle sind verschiedene Typen von Kanälen, die über physikali-
sche Verbindungen aufgebaut werden. Es sind verschiedene logische Kanä-
le zur Übermittlung von Steuerungsinformation und Benutzerdaten defi-
niert [4]:

• Link Control (LC)

• Link Manager (LM)

• User Asynchrounus (UA)

9
Frequency Hopping Synchronisation
2. Bluetooth-Kernspezifikation 9

Tabelle 2.2: Pakettypen für ACL [25]

Typ Slots FEC CRC Maximale Nutzlast (Byte)

DM1 1 2/3 ja 18
DH1 1 nein ja 28
DM3 3 2/3 ja 122
DH3 3 nein ja 184
DM5 5 2/3 ja 225
DH5 5 nein ja 340
AUX1 1 nein nein 30

• User Isochronous (UI)

• User Synchrounus (US)

Die Daten der Steuerkanäle werden gegenüber den Nutzdaten priorisiert.

2.3 Link Manager

Der Link Manager erweitert die Funktion der Basisbandschicht, indem er
Funktionen für den Verbindungsaufbau und die Verwaltung eines Pikonetzes
bereitstellt. Er stellt den übergeordneten Schichten ein einfaches Kommuni-
kationsmodell bereit. Die höheren Schichten Audio und Control greifen aber
auch direkt auf die Basisbandschicht zu (Abbildung 2.1) [25]. Der Betriebs-
zustand eines Bluetooth-Gerätes wird vom Link Manager verwaltet. Auch
die Sicherheitsfunktionen von Bluetooth sind auf Ebene des Link Managers
implementiert.
Der Link Manager ist typischerweise die höchste Protokollschicht, die
noch im Bluetooth-Controller implementiert ist. Dem Host-System bietet es
eine festgelegte Schnittstelle, das Host Control Interface (HCI).
Im Folgenden werden das Nachrichtenformat und die wichtigsten Funk-
tionen des Link Managers beschrieben.

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

Abbildung 2.4: Paketformat von PDUs [4]

Abbildung 2.5: Betriebszustände [25]

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

erkannt wird, wird ein FHSS-Paket gesendet, um Geräteadresse und Zeitin-

formationen mitzuteilen. Das Gerät nimmt die Rolle des Slave ein.
Wird durch eine der beiden Möglichkeiten ein anderes Gerät gefunden,
wird in den Ausrufe-Zustand (Page) gewechselt. Der Master beginnt da-
mit, Verbindungen zu den erkannten Geräten aufzubauen. Dazu berechnet
er aus den Geräteadressen die Frequenzsprungfolge des Pikonetzes (siehe Ab-
schnitt 2.2.1). Der Master ruft die Slaves nun nacheinander auf und synchro-
nisiert sie mit seiner Uhr. Sobald ein Gerät die Sprungfolge des Pikonetzes
übernommen hat, wechselt es in den Zustand Connected [9].

Vom Zustand Connected können die Teilnehmer in drei Stromsparmodi wech-

seln. Im Zustand Sniff wird die Anzahl an Slots, in denen Daten empfangen
werden können, reduziert. Dazu handeln Master und Slave das Intervall und
die Anzahl an Slots aus, die der Slave zuhört. Der Slave ist ab dann nur
noch in diesen aktiven Phasen erreichbar [25].
Im Modus Park wird die Kommunikation zu einem Slave vollständig
ausgesetzt und ihm die aktiver-Teilnehmer-Adresse entzogen. Stattdessen
wird ihm eine geparkter-Teilnehmer-Adresse zugewiesen. Geparkte Teilneh-
mer lauschen in regelmäßigen Intervallen auf eine Mitteilung vom Master.
Der sogenannte Beacon-Kanal wird ausschließlich für die Aktivierung ge-
parkter Teilnehmer verwendet [25].
Im Zustand Hold ist die Kommunikation über die ACL-Verbindung ange-
halten. SCO-Verbindungen können weiter laufen. Der Master kann Slaves in
diesen Zustand versetzen, wenn er gerade keine Daten verarbeiten kann [15].

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

von Bluetooth und ermöglicht sichere Punkt-zu-Punkt-Verbindungen. Pai-

ring geht in fünf Phasen vonstatten, die im Folgenden beschrieben sind [4].
Für die kryptograhischen Algorithmen wird auf [4] verwiesen.

Austausch der öffentlichen Schlüssel

Jedes Gerät generiert ein Paar aus einem öffentlichen und einem privaten
Schlüssel nach dem ECDH10 -Algorithmus. Diese Schlüssel haben eine be-
sondere Eigenschaft: Mit dem öffentlichen Schlüssel verschlüsselte Nachrich-
ten können nur mit Hilfe des privaten Schlüssels wieder entschlüsselt wer-
den (asymetrische Kryptographie) [4]. Die Geräte tauschen die öffentlichen
Schlüssel aus.

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:

Numeric Comparison Protocol: Die Geräte generieren jeweils eine zu-

fällige Zahl. Das angefragte Gerät verschlüsselt seine Zufallszahl mit einer
Kombination aus den öffentlichen Schlüsseln der beiden Geräte und sendet
das Ergebniss an den Kommunikationspartner. Nun teilen sich die Geräte
die Zufallszahlen mit. Das anfragende Gerät kann nun prüfen, ob sich aus
der Zufallszahl des Anderen wirklich das zuvor mitgeteilte Ergebniss ableiten
lässt. Gelingt diese Verifikation, generieren die Geräte aus beiden Zufallszah-
len und den öffentlichen Schlüsseln eine sechsstellige Verifikationsnummer,
die auf beiden Geräten angezeigt wird. Der Benutzer vergleicht die Verifi-
kationsnummern und gibt an, ob die Werte übereinstimmen. Ohne diesen
Vergleich der Verifikationsnummern ist dieses Protokoll anfällig gegen aktive
Man-In-The-Middle-Attacken.
Um dieses Verfahren verwenden zu können, müssen die Geräte eine Möglich-
keit besitzen, dem Benutzer die Verifikationsschlüssel mitzuteilen. Denkbar
sind neben einem Display etwa ein Ausdruck bei einem Drucker oder eine
Sprachansage bei einem Headset. Der Benutzer muss außerdem den Verifi-
kationsschlüssel bestätigen oder ablehnen. Dazu reichen etwa zwei Taster.

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.

Out Of Band Protocol: Für diese Form der Authentifizierung müssen

die Geräte über eine andere Kommunikationsmöglichkeit als Bluetooth (Out
of Band ) verfügen. Dazu ist im Link Manager eine Schnittstelle vorgesehen,
über die externe Informationen in den Pairing-Prozess einfließen können.
Überhaupt wird bei dieser Form der Authentifizierung der gesamte Pairing-
Prozess durch das Übertragen der Out-Of-Band -Daten angestoßen. Dieses
Verfahren ist grundsätzlich so sicher wie das verwendete alternative Kommu-
nikationsmedium. Im Bluetooth-Standard [4] wird als Beispiel NFC genannt.
Die weiteren Details dieses Verfahrens werden in einem späteren Kapitel be-
sprochen.

Passkey Entry Protocol: Bei dieser Methode der Authentifizierung gibt

der Benutzer in beide Geräte einen Passschlüssel ein. Alternativ kann auch
ein Gerät einen Passschlüssel anzeigen, der in das andere Gerät eingegeben
wird.
Die bei Bluetooth Version 1 gängige Variante, bei einfachen Geräten ohne
Display (zB. Headsets) den Passschlüssel unveränderlich festzulegen und in
der Bedienungsanleitung abzudrucken, ist nach Bluetooth Version 2 nicht
mehr gestattet.
Nun wird ein Schlüsselaustausch ähnlich dem Numeric Comparison Protocol
ausgeführt. Zusätzlich fließt in die Verifikationsnummer noch der Passschlüs-
sel mit ein.
Dieses Verfahren bietet eine hohe Sicherheit, ist jedoch auch für den Benut-
zer mit dem höchsten Aufwand verbunden. Die Geräte müssen über eine
Möglichkeit zur Eingabe von Zahlen verfügen.

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.

Berechnung des Verbindungsschlüssels

Aus dem gerade getauschten Schlüssel, den verwendeten Zufallszahlen und
den Geräteadressen berechnen die Geräte den Verbindungsschlüssel. Dieser
Verbindungsschlüssel hält von nun an das Pairing aufrecht; alle bisher ver-
wendeten Werte und Schlüssel können verworfen werden.
2. Bluetooth-Kernspezifikation 14

Abbildung 2.6: Das HCI, die Schnittstelle zwischen Host und Controller
[25]

LMP Authentifizierung und Verschlüsselung

Im finalen Schritt wird aus dem Verbindungsschlüssel der Verschlüsselungs-
code generiert, der für die Verschlüsselung der Verbindung auf LMP-Ebene
dient. Bei einer erneuten Verbindung und nach einer bestimmten Menge an
übertragenen Daten wird ein neuer Verschlüsselungscode aus dem Verbin-
dungsschlüssel generiert.

Der ausgetauschte Verbindungscode wird permanent in den Geräten gespei-

chert. Wollen die Geräte erneut eine verschlüsselte Verbindung herstellen,
muss die Pairing-Prozedur nicht wiederholt werden [15].

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 Host Control Interface

In einer typischen Bluetooth-Implementierung wird der Hochfrequenzteil
vom Bluetooth-Controller angesteuert. Auf diesem ist die Basisbandschicht
und der Link Manager implementiert. Der Host Computer greift über das
Host Control Interface auf Basisband und Link Manager zu (Abbildung 2.6).
Die Funktionen und das Übertragungsformat des HCI sind im Bluetooth-
Standard [4] für die Schnittstellen RS232, USB und I2C zwischen Host-
2. Bluetooth-Kernspezifikation 15

Abbildung 2.7: Der gesamte Übertragungsweg zwischen zwei Hosts [4]

System und Bluetooth-Controller definiert. Dadurch lassen sich Bluetooth-

Module verschiedener Hersteller untereinander austauschen [25]. Abbildung
2.7 stellt den gesamten Pfad der übertragenen Daten zwischen zwei Hosts
dar. Horizontal ist die logische Kommunikation zwischen den einzelnen Schich-
ten eingezeichnet.
Vor allem im Embedded -Bereich werden Bluetooth-Module eingesetzt, die
einen größeren Funktionsumfang im Bluetooth-Controller implementieren,
oder ganz ohne Host Controller funktionieren [25]. Solche Lösungen werden
in der Bluetooth-Spezifikation [4] nicht beachtet. Die Hersteller sind daher
auf proprietäre Lösungen für ihre Schnittstellen angewiesen.
Die Kommunikation zwischen Host und Controller erfolgt durch drei
Arten von HCI-Paketen.

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.

• Link Policy Commands verwalten die Dienstgüte eines Kanals. Neben

den QoS-Parametern wird damit in die Stromsparmodi Sniff, Hold und
2. Bluetooth-Kernspezifikation 16

Parked gewechselt. Auch der Rollentausch zwischen Master und Slave

wird durch Link Policy Commands ermöglicht.

• Host Controller & Baseband Commands parametrisieren und steuern

den Bluetooth-Controller. Dazu gehört das Auslesen und Setzen des
Gerätenamens und der Serviceklasse.

• Informational Parameters lesen Geräteeigenschaften wie Versionsinfor-

mationen, unterstützte Funktionen und Geräteadresse aus.

• Status Parameter zeigen Eigenschaften des Funkkanals wie Empfangs-

stärke und Verbindungsqualität an.

• Testing Commands werden für Systemtests benutzt.

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 Logical Link Control and Adoption Layer Pro-

tocol
Das Logical Link Control and Adoption Layer Protocol (L2CAP) stellt den
Anwendungen Kanäle zur Kommunikation zur Verfügung. Es ist die ers-
te Schicht des Protokollstapels, die auf dem Host-System implementiert
wird. Über einen HCI-Treiber greift es auf die Funktionen des Bluetooth-
Controllers zu [4]. Während der Link Manager sich um die Verbindung zwi-
schen den Geräten kümmert, realisiert L2CAP einzelne Kommunikations-
kanäle zwischen Anwendungen und Diensten. Es baut somit nicht direkt auf
dem Link Manager auf, sondern greift über das HCI direkt auf die vom Link
Manager konfigurierte Basisbandschicht zu [15]. L2CAP greift dabei nur auf
2. Bluetooth-Kernspezifikation 17

die ACL-Verbindung zu. SCO-Verbindungen werden nicht unterstützt.

Die vier wesentlichen Aufgaben der L2CAP-Schicht sind [25]:

• Bündelung von Datenkanälen (Multiplexing und Demultiplexing)

• Segmentierung von Datenpaketen

• Bereitstellung von Dienstgüten (Quality of Service)

• Verwaltung von Gruppen für Punkt-zu-Multipunkt-Verbindungen (Mul-

ticasts)

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]:

• Ein Signalisierungskanal zur Steuerung der Kommunikation und dem

Auf- und Abbau von Kanälen. Dieser besitzt die Kanal-ID 0x0001.

• Verbindungsorientierte Kanäle für die bidirektionale Übertragung von

Daten zwischen zwei Kommunikationspartnern. Dazu werden Kanal-
IDs im Bereich von 0x0040 bis 0xFFFF dynamisch zugewiesen.

• Verbindungslose Kanäle für gerichtete Kommunikation in Form von

Broadcasts 11 und Multicasts 12 . Der Absender benutzt eine dynamisch
zugewiesene Kanal-ID. Die Empfänger von Broadcasts bekommen die
Daten immer über den Kanal 0x0002 zugestellt. Für Multicasts wird
ebenfalls eine Kanal-ID dynamisch zugewiesen. Diese muss für alle
Empfänger der Gruppe gleich sein.

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.

Nachrichten aus anderen Protokollschichten werden als Ereignisse bezeich-

net. Ereignisse der oberen Protokollschicht heißen Request, und werden durch
eine Confirmation beantwortet. Ein Ereignis aus der unteren Schicht nennt
11
Eine Nachricht an alle Teilnehmer
12
Eine Nachricht an mehrere bestimmte Teilnehmer
2. Bluetooth-Kernspezifikation 18

Abbildung 2.8: L2CAP-Paket für einen verbindungsorientierten Kanal [25]

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].

• Beim verbindungsorientierten Kanal besteht ein Paket aus den Nutz-

daten mit vorangesteller Länge und Kanal-ID (Abbildung 2.8). Ein
Kanal wird bei der verbindungsorientierten Kommunikation exklusiv
von einem Dienst genutzt. Eine Unterscheidung des verwendeten Kom-
munikationsprotokolls ist also nicht nötig [25].

• Bei einem verbindungslosen Kanal enthalten die L2CAP-Pakete zu-

sätzlich noch ein Feld zur Angabe des Protokolls (Protocol Service
Multiplexor, PSM) (Abbildung 2.9). Dabei wird zwischen den darüber-
liegenden Protokollen SDP, RFCOMM und TCS unterschieden [25].
Die Kanal-ID ist für Broadcasts 2, für Multicasts wird der Empfänger-
Kanal der Gruppe verwendet [4].
13
Die Größe der Abweichung der Verzögerung
2. Bluetooth-Kernspezifikation 19

Abbildung 2.9: L2CAP-Paket für einen verbindungslosen Kanal [25]

Abbildung 2.10: Aufbau eines L2CAP-Signales [4]

• Der Signalisierungskanal verwendet das gleiche Paketformat wie der

verbindungsorientierte Kanal. Die Nutzdaten bestehen aus einem oder
mehreren Signalen, die nach einem einheitlichen Format aufgebaut sind
(Abbildung 2.10). Der Code gibt die Art des Signales an. Jeder Re-
quest und Response besitzt einen eigenen Code. Das Feld ID dient
der Zuordnung von Request und Response. Im Datenfeld sind eventuell
vorhandene Parameter abgelegt [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].

2.6 Service Discovery Protocol

Mit den bisher vorgestellten Protokollen ist es zwei Bluetooth-Geräten mög-
lich, sich mit Hilfe des Link Managers zu verbinden und über L2CAP-Kanäle
Daten auszutauschen. Weiters definiert Bluetooth Profile. Damit können
Dienste für einen bestimmten Anwendungsfall über ein standardisiertes Pro-
tokoll miteinander kommunizieren. Damit die angebotenen Dienste von an-
2. Bluetooth-Kernspezifikation 20

Tabelle 2.3: L2CAP-Signale und ihre Funktion [4]

Command Reject Antwort auf ein unbekanntes oder fehlerhaftes

Signal. Auch zu lange Pakete werden damit ab-
gewiesen.
Connection Request Wird gesendet um einen L2CAP-Kanal zwi-
schen zwei Geräten anzufordern.
Connection Response Antwort auf einen Connection Request. Im Feh-
lerfall wird die Fehlerursache mitgeteilt.
Configuration Request Dient dem Aushandeln der Eigenschaften eines
L2CAP-Kanals.
Configuration Response Damit wird die vorgeschlagene Konfiguration
eines Configuration Request bestätigt oder ab-
gelehnt. Die abgelehnten Eigenschaften werden
markiert und andere Werte dafür vorgeschla-
gen.
Disconnection Request Leitet den Abbau eines Kanals ein.
Disconnection Response Schliesst den Abbau eines Kanals ab.
Echo Request/Response Dient dem Test der Verbindung oder der Über-
tragung Hersteller-spezifischer Konfigurations-
daten in einem optionalen Datenfeld.
Information Request Fragt Details der L2CAP-Implementierung ei-
nes Verbindungspartners ab.
Information Response Teilt Details der L2CAP-Implementierung mit.
Diese betreffen Flusskontrolle, Übertragungs-
wiederholung im Fehlerfall und Unterstützung
von Dienstgüteklassen.

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

Abbildung 2.11: Nullmodem-Verkabelungsschema von RFCOMM [3]

chisch aufgebaut. Ein Dienst kann also zu mehreren Serviceklassen gehören.

Die Service-ID beschreibt die Zugehörigkeit zu einem spezifizieren Service-
Typ. Eine Protokoll-Liste beschreibt die zur Verwendung nötigen Protokoll-
Schichten. Weiters können der Name des Anbieters, des Dienstes und eine
Beschreibung hinterlegt sein [4].

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

RFCOMM bietet eine verlässliche Kommunikation und Flusskontrolle. Es

können bis zu 60 virtuelle serielle Verbindungen gleichzeitig geöffnet werden.
Alle Verbindungen werden über den selben L2CAP-Kanal betrieben. Diese
Verbindungen können also nur zum gleichen Gerät aufgebaut werden. Um
RFCOMM-Verbindungen zu verschiedenen Geräten aufzubauen, sind meh-
rere Instanzen des RFCOMM-Treibers nötig, was nicht von allen Geräten
unterstützt wird.
Die emulierte serielle Verbindung verhält sich komplett wie eine EIA-
23215 -Schnittstelle und implementiert dazu auch Hardware-Handshake und
Statusleitungen. Die maximale Geschwindigkeit liegt bei 115 kBit/s. Es wird
eine Verkabelung nach dem Nullmodem-Schema emuliert (Abbildung 2.11).

RFCOMM ermöglicht zwei Arten von Verbindungen:

• Eine direkte Punkt-zu-Punkt-Verbindung zwischen Bluetooth-Geräten.

Diese Geräte werden als Typ 1 bezeichnet.

• 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

Abbildung 3.1: Informationsfluss zwischen den Schichten im OSI-Modell

[10]

23
3. Bluetooth im OSI-Referenzmodell 24

Abbildung 3.2: Zuordnung der Bluetooth-Protkolle zu den Schichten des

ISO-OSI-Referenzmodelles [25]

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.

3.5 Weitere OSI-Schichten

Die Sitzungsschicht sorgt für die Prozesskommunikation zwischen zwei Sys-
temen. Die Darstellungsschicht setzt systemabhängige Darstellungen von
Daten in eine unabhängige Form um. Damit ist der syntaktisch korrekte
Austausch zwischen unterschiedlichen Systemen möglich. Die Anwendungs-
schicht stellt Dienstleistungen zur transparenten Übertragung von Informa-
tionen zur Verfügung, die von den technischen Details vollständig abstrahiert
sind [10].
Bei Bluetooth werden diese Schichten in der Anwendung zusammenge-
fasst [25].
Kapitel 4

Bluetooth-Profile

Bluetooth umfasst die Kernspezifikation [4] und optional zu implementie-

rende Protokolle [2]. Weiters setzen darauf adaptierte Protokolle auf. Insge-
samt ergibt das eine große Anzahl an Protokollen, die sich zum Teil nur für
bestimmte Einsatzzwecke eignen. Um die Komplexität und damit die Kos-
ten und den Strombedarf von Bluetooth-Geräten gering zu halten, sind viele
Protokolle optional zu implementieren. Sogar innerhalb eines Protokolls sind
bestimmte Funktionen oft nicht zwingend vorgeschrieben. Um trotzdem eine
Interoperabilität zwischen den Geräten verschiedener Hersteller zu verwirk-
lichen, definiert Bluetooth Profile [1].
Ein Profil beschreibt, welche Protokolle und Fähigkeiten ein Gerät im-
plementieren muss, um einen bestimmtes Einsatzszenario zu ermöglichen.
Während die Protokolle die horizontalen Schichten der Kommunikation sind,

Abbildung 4.1: Profile stellen vertikale Schnitte durch den Protokollstapel

dar [25]

27
4. Bluetooth-Profile 28

Abbildung 4.2: Existierende Bluetooth-Profile und ihre Abhängigkeiten,

abgeleitet aus den Profilspezifikationen [1]

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.

4.1 Grundlegende Profile

4.1.1 GAP – Generic Access Profile
Das GAP ist die Grundlage für alle anderen Profile. Es spezifiziert die
Voraussetzungen und eine Anwendungsschnittstelle für allgemeine Proze-
duren [25]. Damit werden die Funktionen von Link Manager und L2CAP
zur Verfügung gestellt. Es ermöglicht die Erkennung von Geräten, Verbin-
dungsaufbau und Verbindungsmanagement. Das GAP muss von allen Gerä-
ten unterstützt werden. Als einziges Profil ist es in der Kernspezifikation zu
finden [4].
4. Bluetooth-Profile 29

4.1.2 SDAP – Service Discovery Application Profile

SDAP stellt eine Schnittstelle für eine Applikation zur Abfrage von Profilen
bereit und spezifiziert die Funktionalität einer solchen Applikation. Es wird
das Service Discovery Protocol genutzt.

4.1.3 SPP – Serial Port Profile

Das SPP wird immer dann verwendet, wenn Bluetooth als Ersatz für Ka-
belverbindungen genutzt wird. Wie aus Abbildung 4.2 ersichtlich, basieren
viele andere Profile darauf. SPP definiert eine Schnittstelle, um eine Ver-
bindung nach dem RFCOMM-Protokoll auf dem Host als virtuelle serielle
Verbindung einzurichten [1].

4.1.4 GOEP – Generic Object Exchange Protokoll

Das GOEP beschreibt Protokolle und Prozeduren zum Austausch von kom-
plexen Objekten. Damit können Dateien über Rechner- und Betriebssystems-
grenzen hinweg ausgetauscht werden [25]. Diese Fähigkeit entstammt dem
OBEX1 -Protokoll [2], das für Bluetooth adaptiert wurde und das von GOEP
eingesetzt wird.

4.1.5 GAVDP – Generic Audio Video Transport Profile

Das GAVDP kommt zum Einsatz, wenn qualitativ hochwertige Audio- oder
Video-Datenströme übertragen werden sollen [1]. Als Grundlage dient das
AVDTP2 -Protokoll [2]. Dieses ermöglicht den kontinuierlichen Transport ei-
nes Datenstroms über eine ACL-Verbindung.

4.2 Abgeleitete Profile

Alle weiteren Profile sind speziell für einen Einsatzzweck geschaffen worden.
Die Spezifikation [1] umfasst bereits mehrere tausend Seiten und werden
ständig um weitere Profile ergänzt. Tabelle 4.1 listet diese Profile und ihre
Anwendungsszenarien auf.

1
Object Exchange
2
Audio/Video Distribution Transport
4. Bluetooth-Profile 30

Tabelle 4.1: Bluetooth-Profile und ihre Anwendungsszenarien [1]

A2DP Advanced Audio Dis- Übertragung eines hochwertigen Audio-

tribution Profile Datenstroms in Stereo oder Mono
AVRCP Audio/Video Remote Steuerung von Audio/Video-Equipment
Control Profile
BIP Basic Imaging Profile Übertragung von Bilddateien
BPP Basic Printing Profile Drucken von verschiedenen Dokumenten-
formaten
CTP Cordless Telephony Profil für ein universelles Schnurlostelefon,
Profile das sich sowohl mit Mobilfunk als auch ei-
ner Festnetz-Basisstation nutzen lässt
DI Device ID Profile Identifikation von Geräten auf Basis von
Hersteller und Produktbezeichnung
DUN Dial-Up Networking Nutzung von Modem-Diensten über Blue-
Profile tooth
FAX Fax Profile Nutzung von Fax-Diensten über Blue-
tooth
FTP File Transfer Profile Anzeigen, Verwalten und Ändern der Da-
teien in einem Verzeichnis
HFP Hands-Free Profile Audio-Übertragung und Anrufsteuerung
für Freisprecheinrichtungen
HCRP Hardcopy Cable Repla- Ersetzt Kabelverbindungen von Druckern
cement Profile und Scannern
HSP Headset Profile Vollduplex-Übertragung von qualitativ
hochwertigen Audiodaten
HDC Health Device Profile Übertragung von Sensordaten im Fitness-
und Medizin-Bereich
HID Human Interface Devi- Übertragung von Daten von Eingabegerä-
ce Profile ten
ICP Intercom Profile Sprechverbindungen zwischen Bluetooth-
Geräten (Walkie-Talkie)
OPP Object Push Protocol Dateien an andere Geräte senden
PAN Personal Area Networ- Ermöglicht mit Hilfe von BNEP den
king Protocol Transport von Paketen verschiedener
Netzwerkprotokolle
SAP SIM Access Profile Zugriff auf die SIM-Karte eines Mobilte-
lefons über Bluetooth, nützlich für Frei-
sprecheinrichtungen im Auto
SYNC Synchronization Profi- Synchronisation von PIM-Daten wie Tele-
le fonbucheinträgen oder Visitenkarten
VDP Video Distribution Übertragung von Videosignalen
Profile
Kapitel 5

NFC für Bluetooth

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

Tabelle 5.1: Vergleich zwischen Bluetooth und NFC [7]

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].

5.1 Grundlagen von NFC

Der ISO/IEC-Standard 14443 [13] beschreibt die physikalischen Eigenschaf-
ten von kontaktlosen Chipkarten. Die Kommunikation erfolgt über Ringspu-
len, die über ein magnetisches Feld per Induktion (aktiv) oder Lastmodu-
lation (passiv) Daten übermitteln. Das aktive Lesegerät wird als Proximity
Coupling Device (PCD) bezeichnet. Für die passiven kontaktlosen Karten
wird der Begriff Proximity Integrated Circuit Card (PICC) verwendet. Es
wird das ISM-Band bei einer Mittelfrequenz von 13,56 MHz genutzt. Die
Bandbreite beträgt dabei 2 MHz. Es werden zwei Typen unterschieden, die
unterschiedliche Modulationsarten verwenden.

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].

Typ B: Als Modulation von PCD zu PICC wird eine ASK-Modulation

mit 10% Abschwächung eingesetzt. Für die Lastmodulation kommt BPSK4
zum Einsatz. Die Bits werden direkt in Signalpegel umgeformt (NRZ-L5 -
Kodierung) [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

NFC stellt eine einfache Erweiterung dieses Standards dar. In ISO/IEC

18092 [11] und ISO/IEC 21481 [12] ist das Near Field Communication Inter-
face and Protocol (NFCIP) beschrieben. Es definiert aktive und passive Kom-
munikationsmodi, das Modulationsschema, Codierung, Transferraten und
das Rahmenformat der Funkschicht. Es werden Initialisierungs-Prozeduren
und Methoden zur Vermeidung von Kollisionen beschrieben. Weiters wird
das Protokoll zum Datentransport und Methoden zum Datenaustausch de-
finiert.

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].

Typ 4: Typ 4 ist vollständig kompatibel mit ISO/IEC 14443 A und B.

Auch bei diesem Typ wird der Schreibschutz bei der Herstellung festgelegt.
Es sind bis zu 32 kByte Speicher möglich. Die Tags können mit einer Daten-
rate von bis zu 424 kBit/s gelesen und geschrieben werden [21].

Neben dem aktiv/passiven-Kommunikationsmodus nach ISO/IEC 14443 er-

möglicht NFCIP einen Modus, bei dem beide Geräte aktiv senden.

5.2 NFC Data Exchange Format

Aufbauend auf NFCIP definiert das NFC Data Exchange Format (NDEF)
ein Nachrichtenformat zum Austausch von Informationen über NFC. NDEF-
Nachrichten können von aktiven NFC-Geräten gesendet oder von passiven
Tags gelesen werden. NDEF ist ein simples binäres Nachrichtenformat, das
5. NFC für Bluetooth 34

Abbildung 5.1: Format eines NDEF-Records [16]

Tabelle 5.2: Gültige Werte für das Feld TNF

0x01 NFC-Forum: wohlbekannter Typ

0x02 MIME-Typ
0x03 Absolute URI
0x04 NFC-Forum: externer Typ

mehrere unabhängige Sätze Anwendungs-spezifischer Nutzdaten von belie-

biger Größe und Typ in eine Nachricht kapseln kann. So ein Nutzdatenfeld
wird als Record bezeichnet. In Abbildung 5.1 ist das Format eines Records
dargestellt. Jeder Record wird durch den Typ, die Länge und einen optiona-
len Bezeichner beschrieben [16].
Ein gesetztes Flag im Feld MB kennzeichnet den Beginn einer Nachricht,
während der letzte Record einer Nachricht durch das Feld ME markiert ist.
NDEF ermöglicht auch die Übertragung von Daten mit unbekannter Grö-
ße. Damit können dynamisch generierte Daten übertragen werden. Das Feld
CF zeigt dazu an, dass der aktuelle Record nur ein Teil eines Datensatzes
ist.
Das Feld SR gibt an, ob das Feld für die Länge der Nutzdaten aus einem
oder aus vier Bytes besteht. Damit ist eine effiziente Übertragung von kurzen
Datensätzen möglich.
Im Feld IL ist angegeben, ob die Nachricht über einen Bezeichner verfügt,
und daher die Felder ID-Länge und ID vorhanden sind oder nicht.
Der Typ kann durch eine URI6 , einen MIME-Typ7 oder einen NFC-spe-
zifischen Typenbezeichner gegeben sein. Das Feld Type Name Format (TNF)
gibt über den verwendeten Typenbezeichner Auskunft. NFC-spezifische Ty-
6
Uniformal Resource Identifier, eine Zeichenfolge zur Identifizierung einer Ressource
7
Internet Media Type, klassifiziert die Daten im Rumpf einer Nachricht
5. NFC für Bluetooth 35

Abbildung 5.2: Beispiel für einen Negotiated Handover [23]

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.

5.3 Connection Handover

Die Connection Handover Specification [23] definiert NDEF-Nachrichten, mit
denen ein NFC-Gerät bei seinem Kommunikationspartner den Aufbau einer
Verbindung über ein alternatives Kommunikationsmedium anfordern kann.
Es ist auch möglich, verfügbare Trägermedien bei einem Tag abzufragen.
Durch die statische Natur der Informationen auf einem Tag unterliegt diese
Möglichkeit einigen Einschränkungen.
Ein Gerät, das eine alternative Kommunikation anfordert, wird als Han-
dover Requester bezeichnet. Das angefragte Gerät übernimmt die Rolle des
Handover Selectors.
Zur Zeit definiert die Connection Handover Specification die Verwendung
von Bluetooth und Wi-Fi. Die Spezifikation lässt sich aber leicht für andere
Funktechnologien erweitern [23].

5.3.1 Negotiated Handover

Sind zwei aktive Geräte beteiligt, kommt der sogenannte Negotiated Hando-
ver zum Einsatz. Der Handover Requester sendet einen Handover Request an
den Handover Selector. Der Handover Request stellt eine Liste der alternati-
ven Kommunikationsmedien dar, über die der Handover Requester verfügt.
Der Handover Selector vergleicht die empfangene Liste mit den für ihn ver-
fügbaren Kommunikationsmedien. Er antwortet mit einem Handover Select,
5. NFC für Bluetooth 36

Abbildung 5.3: Beispiel für einen Static Handover [23]

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.2 Static Handover

Der Static Handover kommt zum Einsatz, wenn ein Gerät nicht über NFC
verfügt, aber auf einem Tag seine Handover -Informationen verfügbar sind.
Ein Tag stellt nur Daten zur Verfügung und kann keine Handover-Select-
Nachricht dynamisch generieren. Ein vorgefertigter Handover Select ist sta-
tisch auf der Karte abgelegt. Durch die fehlende Verbindung zum Host-
Prozessor muss dieser die Schnittstellen für die alternative Kommunikation
immer empfangsbereit halten, um eine Anfrage zu erkennen. Beim Negotiated
Handover können diese deaktiviert werden, bis ein Handover Request erfolgt.
Abbildung 5.3 stellt einen Static Handover dar.

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.

5.3.4 Carrier Configuration Record für Bluetooth

Um Bluetooth-Geräte sicher miteinander zu verbinden, definiert die Blue-
tooth-SIG mehrere Pairing-Methoden [4]. Eine davon ist die Übertragung
von Geräteeigenschaften und kryptographischen Daten über ein Out-Of-
Band -Kommunikationsmedium wie NFC.
Zur Übertragung dieses OOB-Datenblocks wird vom NFC-Forum das For-
mat eines spezifischen NDEF-Records vom externent Typ „bluetooth.org:sp“
vorgeschlagen [23]. Ein Beispiel für so eine Nachricht ist in Abbildung 5.5
dargestellt. Die einzelnen Datenfelder sind nach dem TLV8 -Schema abgelegt.
Dieser Carrier Configuration Record kommt sowohl beim Handover Request
als auch beim Handover Select zum Einsatz. Ein Datenfeld besteht also aus
einem Tag, der die Art der Information beschreibt, einer Längenangabe und
den Daten. Die Felder mit den kryptographischen Informationen (P und
C) sind optional [23]. Wenn sie nicht vorhanden sind, wird NFC nur zum
Auffinden eines Bluetooth-Gerätes benutzt, und ein herkömmlicher Pairing-
Machanismus über Bluetooth verwendet [4].
8
Tag, Length, Value
5. NFC für Bluetooth 38

Abbildung 5.5: Beispiel einer Handover -Nachricht für Bluetooth [23]

5.4 Ablauf von Pairing mit NFC

Um die OOB-Daten in den Pairing-Vorgang von Bluetooth 2.1 einfliessen zu
lassen, definiert das Generic Access Profile eine Schnittstelle, um über das
Host Control Interface mit dem Link Manager zu kommunizieren.

1. Die Anwendung zur Verwaltung von Bluetooth-Verbindungen fragt von

seinem Bluetooth-Link-Manager die Geräteadresse und einen neu er-
zeugten Pairing Hash (P) und Pairing Randomizer (C) ab.

2. Daraus wird ein Handover Request erzeugt und per NFC an ein anderes
Gerät übermittelt.

3. Die Verwaltungs-Anwendung auf dem zweiten Gerät zeigt seinem Link

Manager an, dass OOB-Daten zur Verfügung stehen. Dieser holt sich
die Daten von der Anwendung ab.

4. Nach dem in Abschnitt 2.3.4 beschriebenen kryptographischen Algo-

rithmus wird daraus wiederum eine Antwort, bestehend aus einem neu-
en P und C, generiert.

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

6. Bei geglückter Authentifizierung beginnt dieses Gerät nun damit, die

Bluetooth-Verbindung aufzubauen und den Pairing-Vorgang abzuschlie-
ßen.

Alternativ können die kryptograhischen Zahlen P und C auch einfach von

einem Tag in Form eines Handover Select abgefragt werden, um damit das
Pairing zu initiieren [23].

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

[1] Bluetooth SIG: Bluetooth Profile Specifications. Stand August 2008,

www.bluetooth.com/Bluetooth/Technology/Building/Specifications.
[2] Bluetooth SIG: Bluetooth Protocol Specifications. Stand August 2008,
www.bluetooth.com/Bluetooth/Technology/Building/Specifications.
[3] Bluetooth SIG: Bluetooth Specification, Version 1.1, Juni 2003. www.
bluetooth.com/Bluetooth/Technology/Building/Specifications.
[4] Bluetooth SIG: Bluetooth Specification, Version 2.1 + EDR, Juli 2007.
www.bluetooth.com/Bluetooth/Technology/Building/Specifications.
[5] Bluetooth SIG: About the Bluetooth SIG, Juli 2008. www.bluetooth.org/
About/bluetooth_sig.htm.
[6] European Telecommunications Standards Institute: ETSI TS 101 369
(3GPP TS 07.10), März 2002. www.etsi.org/WebSite/Standards/
StandardsDownload.aspx.
[7] Ghanname, T.: How NFC can to speed Bluetooth transactions – today,
Feb. 2006. www.wirelessnetdesignline.com/howto/180201430.
[8] Heise Zeitschriften Verlag: Bluetooth-Datenbank, Juli 2008. www.heise.
de/mobil/bluetooth/db/.
[9] Holtkamp, H.: Einführung in Bluetooth, März 2003. www.rvs.uni-
bielefeld.de/~heiko/bluetooth/bluetooth.pdf.
[10] International Standard Organization: ISO 7498-1: Open Systems Inter-
connection - Basic Reference Model, Nov. 1994. http://www.iso.org/
iso/iso_catalogue.htm (kostenpflichtig).
[11] International Standard Organization: ISO/IEC 18092: Near Field Com-
munication – Interface and Protocol (NFCIP-1), 2004. http://www.iso.
org/iso/iso_catalogue.htm (kostenpflichtig).
[12] International Standard Organization: ISO/IEC 21481: Near Field Com-
munication Interface and Protocol -2 (NFCIP-2), 2005. http://www.nfc-
forum.org/specs/.

40
Literaturverzeichnis 41

[13] International Standard Organization: ISO/IEC 14443: Identification

cards, Contactless integrated circuit cards, Proximity cards, 2008. http:
//www.iso.org/iso/iso_catalogue.htm (kostenpflichtig).

[14] International Telecommunication Union: Frequently asked questions,

März 2007. www.itu.int/ITU-R/terrestrial/faq/index.html#g013.

[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/.

[18] NFC-Forum: Type 1 Tag Specification, Juli 2007. http://www.nfc-forum.

org/specs/.

[19] NFC-Forum: Type 2 Tag Specification, Juli 2007. http://www.nfc-forum.

org/specs/.

[20] NFC-Forum: Type 3 Tag Specification, Aug. 2007. http://www.nfc-

forum.org/specs/.

[21] NFC-Forum: Type 4 Tag Specification, März 2007. http://www.nfc-

forum.org/specs/.

[22] NFC-Forum: About NFC, Aug. 2008. www.nfc-forum.org/aboutnfc.

[23] NFC-Forum: Connection Handover Specification (Candidate), Apr.

2008. http://www.nfc-forum.org/specs/.

[24] NFC-Forum: The NFC-Forum, Aug. 2008. www.nfc-forum.org/aboutus.

[25] Wollert, J.: Das Bluetooth Handbuch. Franzis, 2002.