Bluetooth und NFC

Bluetooth und NFC

Christian Unhold

BACHELORARBE IT

eingereicht amFachhochschul-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 Quellenund Hilfsmittel nicht benutzt und die aus anderen Quellen entnommenenStellen 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 32.1 Funkschicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Frequenzen und Kanäle . . . . . . . . . . . . . . . . . 32.1.2 Sendeleistung . . . . . . . . . . . . . . . . . . . . . . . 42.1.3 Modulationsarten . . . . . . . . . . . . . . . . . . . . . 4

2.2 Basisbandschicht . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.1 Physikalische Kanäle . . . . . . . . . . . . . . . . . . . 52.2.2 Vernetzung . . . . . . . . . . . . . . . . . . . . . . . . 52.2.3 Adressierung . . . . . . . . . . . . . . . . . . . . . . . 62.2.4 Physikalische Verbindungen . . . . . . . . . . . . . . . 62.2.5 Datenpakete . . . . . . . . . . . . . . . . . . . . . . . . 72.2.6 Logische Kanäle . . . . . . . . . . . . . . . . . . . . . 8

2.3 Link Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.1 Nachrichtenformat . . . . . . . . . . . . . . . . . . . . 92.3.2 Verbindungssteuerung . . . . . . . . . . . . . . . . . . 102.3.3 Authentifizierung . . . . . . . . . . . . . . . . . . . . . 112.3.4 Pairing . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.5 Verschlüsselung . . . . . . . . . . . . . . . . . . . . . . 14

2.4 Host Control Interface . . . . . . . . . . . . . . . . . . . . . . 142.4.1 Kommandopakete . . . . . . . . . . . . . . . . . . . . 152.4.2 Ereignispakete . . . . . . . . . . . . . . . . . . . . . . 162.4.3 Datenpakete . . . . . . . . . . . . . . . . . . . . . . . . 16

2.5 Logical Link Control and Adoption Layer Protocol . . . . . . . 162.5.1 Datenkanäle . . . . . . . . . . . . . . . . . . . . . . . . 172.5.2 Kanalverwaltung . . . . . . . . . . . . . . . . . . . . . 172.5.3 Datenpakete . . . . . . . . . . . . . . . . . . . . . . . . 18

iv

Inhaltsverzeichnis v

2.5.4 Signalpakete . . . . . . . . . . . . . . . . . . . . . . . 192.6 Service Discovery Protocol . . . . . . . . . . . . . . . . . . . . 192.7 RFCOMM-Protokoll . . . . . . . . . . . . . . . . . . . . . . . 21

3 Bluetooth im OSI-Referenzmodell 233.1 Bitübertragungsschicht . . . . . . . . . . . . . . . . . . . . . . 253.2 Sicherungsschicht . . . . . . . . . . . . . . . . . . . . . . . . . 253.3 Vermittlungsschicht . . . . . . . . . . . . . . . . . . . . . . . . 253.4 Transportschicht . . . . . . . . . . . . . . . . . . . . . . . . . 263.5 Weitere OSI-Schichten . . . . . . . . . . . . . . . . . . . . . . 26

4 Bluetooth-Profile 274.1 Grundlegende Profile . . . . . . . . . . . . . . . . . . . . . . . 28

4.1.1 GAP – Generic Access Profile . . . . . . . . . . . . . . 284.1.2 SDAP – Service Discovery Application Profile . . . . . 294.1.3 SPP – Serial Port Profile . . . . . . . . . . . . . . . . 294.1.4 GOEP – Generic Object Exchange Protokoll . . . . . . 294.1.5 GAVDP – Generic Audio Video Transport Profile . . . 29

4.2 Abgeleitete Profile . . . . . . . . . . . . . . . . . . . . . . . . 29

5 NFC für Bluetooth 315.1 Grundlagen von NFC . . . . . . . . . . . . . . . . . . . . . . . 325.2 NFC Data Exchange Format . . . . . . . . . . . . . . . . . . 335.3 Connection Handover . . . . . . . . . . . . . . . . . . . . . . 35

5.3.1 Negotiated Handover . . . . . . . . . . . . . . . . . . . 355.3.2 Static Handover . . . . . . . . . . . . . . . . . . . . . 365.3.3 Nachrichtenformat . . . . . . . . . . . . . . . . . . . . 365.3.4 Carrier Configuration Record für Bluetooth . . . . . . 37

5.4 Ablauf von Pairing mit NFC . . . . . . . . . . . . . . . . . . 385.5 Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Literaturverzeichnis 40

Kurzfassung

Bluetooth ist eine weit verbreitete Funktechnologie, die geschaffen wurdeum Kabelverbindungen zu ersetzen. Es zeichnet sich durch einen geringenStrombedarf 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 zu2,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öglichteine gute Anpassung an eine bestimmte Anwendung. Um trotzdem eine hoheKompatibilität zwischen den Implementierungen verschiedener Hersteller zuermöglichen, fasst Bluetooth für einen Anwendungsfall benötigte Funktionenund Protokolle zu sogenannten Profilen zusammen.

Bluetooth umfasst ein Konzept, um sichere Verbindungen zwischen zweiGeräten herzustellen. Je nach verwendeter Methode muss der Anwender Zah-lenfolgen eintippen oder vergleichen, um eine Verbindung zu erhalten. Umdiese Prozedur zu vereinfachen, kann Near Field Communication (NFC) ein-gesetzt werden, ein Funkstandard der von kontaktlosen Chipkarten abgeleitetist. Damit wird ein schneller und intuitiver Verbindungsaufbau möglich, ein-fach indem die beteiligten Geräte in sehr kurze Distanz zueinander gebrachtwerden.

vi

Abstract

Bluetooth is a widely used wireless communication technology created toreplace cable connections. It is characterized by a low power consumptionand the ability to build up small networks without a base station. Thereforeit is mostly used by mobile devices. With a range of 10 to 100 meters anda 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. Amultitude of protocols that are optional to implement allow a good adaptionfor a specific application. To provide a high level of compatibility betweenthe implementations of differnt vendors, Bluetooth combines protocols andfunctions 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 orcompare 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 integratedcircuit 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, umKabelverbindungen, vor allem von mobilen Geräten, abzulösen. Sie wird vonder Bluetooth-SIG1 [5] entwickelt und spezifizert. Aktuell (2008) liegt dieSpezifikation in der Version 2.1 vor [4].

Die Reichweite liegt typischerweise im Bereich von wenigen Metern, kannjedoch 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ätemiteinander kommunizieren. Ein Gerät kann aber auch mehreren Pikonetzengleichzeitg angehören.

Die Rohdatenrate liegt typischerweise bei 1 Mbit/s, seit Version 2.0 istdurch 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ätebefinden sich die meiste Zeit in einem Stromsparmodus und aktivieren ihreSendestufe nur bei Bedarf.

Die Kernspezifikation von Bluetooth wird in Kapitel 2 behandelt. Darin sinddie Funktionen einer Bluetooth-Implementierung von der Funkschicht bis hinzur Abstraktion auf logische Kanäle und Verbindungsverwaltung beschrie-ben.

Darauf bauen Protkolle und Anwendungen auf, die dem Benutzer dieTechnologie 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.

1Special Interest Group2Enhanced Data Rate3Object Exchange Protocol4Internet Protocol

1

1. Einleitung 2

Eine Zusammenstellung von optional zu implementierenden Funktionenund Protokollen, um einen bestimmten Anwendungsfall zu ermöglichen, wirdbei Bluetooth Profil genannt. Alle typischen Bluetooth-Anwendungen wer-den durch eigene Profile abgedeckt. Beispiele sind Headsets, Mobiltelefoneals Modem, Synchronisation von Kontaktdaten und der Austausch von Visi-tenkarten. Auch diese Profile werden von der Bluetooth-SIG standardisiertund 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 sichBluetooth am Markt etablieren und wird in tausenden verschiedenen Ge-räten eingesetzt [8]. Bis zum Jahr 2008 wurden innsgesamt 1,5 MilliardenBluetooth-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 UserExperience immer noch zu wünschen übrig. So müssen Passschlüssel einge-tippt oder Verifikationsnummern verglichen werden. Die einzig komfortableMethode, nach dem sogenannten Simply-Works-Verfahren, leidet weiterhinan einer Sicherheitsschwäche. Sie ermöglicht Man-In-The-Middle-Angriffe.Hier kann NFC aushelfen, eine neue Funktechnologie die von kontaktlosenChipkarten abstammt. Mit NFC als alternativem, sicherem Kommunikati-onsmedium kann eine Bluetooth-Verbindung komfortabel aufgebaut werden.In Kapitel 5 ist beschrieben, wie sich das intuitive Anwendungsparadigmavon 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 stelltden 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 sichvon 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äleunterteilt. Um ein Übersprechen auf Frequenzen außerhalb des ISM-Bandes

1Industrial, 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. Sendeleistung1 100 mW2 2.5 mW3 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 oben3,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 HoppingSpread Spectrum (FHSS) zur Datenübertragung verwendet werden. Dazuwird die Zeit in sogenannte Slots eingeteilt, die jeweils 625 µs lang sind. DieKommunikationspartner senden abwechselnd für die Dauer eines Slots. JederSlot 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 vermindertund 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ätender anderen Leistungsklassen ist dies optional möglich. Die Anpassung derSendeleistung erfolgt durch Messung der empfangenen Signalstärke mittelsRSSI2 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.

2Receiver Signal Strength Indication, ein Indikator für die Empfangsfeldstärke3Gaussian Frequency Shift Keying


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 wiederum2 Varianten möglich:

• π/4-DQPSK5, eine Phasenmodulation bei dem jedes Sendesymbol 2Datenbits (ein Quadbit) kodiert. Sie liefert eine Rohdatenrate von2 Mbit/s.

• 8DPSK6 eine Phasenmodulation mit 8 Phasenlagen, bei der pro gesen-detem Symbol 3 Datenbits kodiert werden. Die Rohdatenrate liegt bei3 Mbit/s.

Diese beiden Varianten können optional implementiert werden. Zum Ein-satz können sie nur kommen, wenn der Kommunikationspartner die gleicheModulationsart 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 untereinanderkommunizieren, kennen diese Sprungsequenz und wechseln zur selben Zeitauf die gleiche Frequenz. Die Sprungsequenz wird durch die Geräte-Adressedes Masters bestimmt (siehe Abschnitt 2.2.3). Der Master und ein Slavesenden abwechselnd Datenpakete, wobei der Master die geraden und derSlave die ungeraden Zeitschlitze benutzt. Sollte es zu Kollisionen mit ande-ren Übertragungskanälen kommen, weil zufällig zur gleichen Zeit die gleicheFrequenz verwendet wird, wird die Kollision erkannt und das Datenpaketspäter wiederholt. Normale Pakete belegen einen Zeitschlitz. Daneben gibtes 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. Aneinem Pikonetz können maximal acht Geräte (Knoten) zur selben Zeit aktivteilnehmen. 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 aktiviertwerden. Geräte in Bereitschaft nehmen nicht am Pikonetz teil.

4Phase Shift Keying5Differential Quaternary Phase Shift Keying6Differential Phase Shift Keying


Bei Bluetooth kann grundsätzlich jedes Gerät Master oder Slave sein.Erst während ein Pikonetz aufgebaut wird, entscheidet sich, welche Rolle einGerät einnimmt. Meistens wird dabei der Initiator der Kommunikation zumMaster. 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 derMAC-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 undadressiert die aktiven Knoten in einem Pikonetz.

• PM_ADDR: Die geparkter-Teilnehmer-Adresse. Diese ist 8 Bit langund wird für inaktive (geparkte) Teilnehmer eines Pikonetzes verwen-det.

• AR_ADDR: Adresse für Zugriffs-Anfragen. Sie wird von geparktenTeilnehmern 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 beider Übertragung wären unmittelbar als Störung wahrnehmbar. Für dieseVerbindung 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

7Synchrounus Connection Oriented8Asynchrounus Connectionless Link


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 nichtgarantiert werden kann (Best Effort) [15]. Der zeitliche Bezug wird dabeidurch 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 derBasisbandschicht 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 bestimmtenGerätes. Dieser wird aus der Stationsadresse des aufgerufenen Gerätesgebildet.


• Der Inquiry Access Code (IAC) wird benutzt, um Anfragen an alleGeräte zu stellen. Damit werden andere Bluetooth-Geräte gefunden.

Der Paketkopf enthält die 3-Bit aktiver-Teilnehmer-Adresse, Bits zurFlusskontrolle 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 undder 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. Auchdie Serviceklasse des Gerätes wird gesendet. Damit teilt ein Teilneh-mer mit, welcher Geräteklasse er angehört (z.B. Laptop, Modem) undwelche 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 undohne Vorwärtsfehlerkorrektur (FEC), wobei die verwendete Variante je nachEmpfangsbedingungen gewählt wird [15]. Bis auf das AUX1-Paket enthaltenalle Datenpakete für ACL einen Prüfwert zur Fehlererkennung (CRC). DasAUX1-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 derForm 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)9Frequency Hopping Synchronisation


Tabelle 2.2: Pakettypen für ACL [25]

Typ Slots FEC CRC Maximale Nutzlast (Byte)DM1 1 2/3 ja 18DH1 1 nein ja 28DM3 3 2/3 ja 122DH3 3 nein ja 184DM5 5 2/3 ja 225DH5 5 nein ja 340AUX1 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 erFunktionen für den Verbindungsaufbau und die Verwaltung eines Pikonetzesbereitstellt. Er stellt den übergeordneten Schichten ein einfaches Kommuni-kationsmodell bereit. Die höheren Schichten Audio und Control greifen aberauch direkt auf die Basisbandschicht zu (Abbildung 2.1) [25]. Der Betriebs-zustand eines Bluetooth-Gerätes wird vom Link Manager verwaltet. Auchdie Sicherheitsfunktionen von Bluetooth sind auf Ebene des Link Managersimplementiert.

Der Link Manager ist typischerweise die höchste Protokollschicht, dienoch im Bluetooth-Controller implementiert ist. Dem Host-System bietet eseine 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 Formatder PDUs it in Abbildung 2.4 dargestellt: Die Transaktions-ID hilft bei derZuordnung von Abfragen und Antworten zu einer Transaktion. Das FeldOpcode spezifiziert den Typ der Nachricht. Darauf folgen die Paramter derNachricht, fals vorhanden.


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 Sequenzenunterstützen, nur grundlegende Funktionen sind zwingend zu implementie-ren. Jedes PDU wird bestätigt, wobei bei einer negativen Bestätigung derGrund 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 imBereitschaftszustand (Standby). In diesem Zustand wird sehr wenig Stromverbraucht, weil der Sende- und Empfangsteil vollständig deaktiviert werdenkann [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 einPikonetz vorhanden ist.

Um selbst ein Pikonetz zu gründen, wechselt das Gerät in den ZustandInquiry. 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 festgelegtenTrägerfrequenzen nach IAC-Nachrichten gelauscht. Sobald so eine Nachricht


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 berechneter 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 empfangenwerden können, reduziert. Dazu handeln Master und Slave das Intervall unddie Anzahl an Slots aus, die der Slave zuhört. Der Slave ist ab dann nurnoch in diesen aktiven Phasen erreichbar [25].

Im Modus Park wird die Kommunikation zu einem Slave vollständigausgesetzt und ihm die aktiver-Teilnehmer-Adresse entzogen. Stattdessenwird 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 indiesen 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ätB eine Zufallszahl. Dieses berechnet nach einem festgelegten Algorithmusaus der Zufallszahl, dem Verbindungsschlüssel und der eigenen Geräteadres-se den Sicherheitsschlüssel, der als Antwort gesendet wird. Die Antwort wirdvon Gerät A mit dem selbst ermittelten Sicherheitsschlüssel verglichen. Stim-men die Ergebnisse überein, ist die Authentifikation gelungen. Gerät A hatdamit 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 eineAuthentifizierung 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


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 privatenSchlü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 öffentlichenSchlü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 dieGerä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 einerKombination aus den öffentlichen Schlüsseln der beiden Geräte und sendetdas Ergebniss an den Kommunikationspartner. Nun teilen sich die Gerätedie Zufallszahlen mit. Das anfragende Gerät kann nun prüfen, ob sich ausder Zufallszahl des Anderen wirklich das zuvor mitgeteilte Ergebniss ableitenlä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 diesenVergleich der Verifikationsnummern ist dieses Protokoll anfällig gegen aktiveMan-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. Denkbarsind neben einem Display etwa ein Ausdruck bei einem Drucker oder eineSprachansage 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 Formdes Numeric Comparision Protocol. Der letzte Schritt, in dem die sechsstelli-ge Verifikationssnummer berechnet und verglichen wird, entfällt. Die Geräte

10Diffie-Hellman-Schlüsselaustausch mit Kryptographie auf Basis elliptischer Kurven [4]


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 Zeitpunktdes Pairings stattfinden.

Out Of Band Protocol: Für diese Form der Authentifizierung müssendie Geräte über eine andere Kommunikationsmöglichkeit als Bluetooth (Outof 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. DiesesVerfahren 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 gibtder Benutzer in beide Geräte einen Passschlüssel ein. Alternativ kann auchein Gerät einen Passschlüssel anzeigen, der in das andere Gerät eingegebenwird.Die bei Bluetooth Version 1 gängige Variante, bei einfachen Geräten ohneDisplay (zB. Headsets) den Passschlüssel unveränderlich festzulegen und inder Bedienungsanleitung abzudrucken, ist nach Bluetooth Version 2 nichtmehr gestattet.Nun wird ein Schlüsselaustausch ähnlich dem Numeric Comparison Protocolausgefü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 eineMö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 demgemeinsamen Schlüssel und allen vorher ausgetauschten Werten nach einemEinweg-Algorithmus ein Wert errechnet und verglichen. Schlägt der Vergleichfehl, wird der Pairing-Prozess abgebrochen.

Berechnung des Verbindungsschlüssels

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


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-Ebenedient. 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 immerunverschlü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 Hochfrequenzteilvom Bluetooth-Controller angesteuert. Auf diesem ist die Basisbandschichtund der Link Manager implementiert. Der Host Computer greift über dasHost 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-


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]. Abbildung2.7 stellt den gesamten Pfad der übertragenen Daten zwischen zwei Hostsdar. Horizontal ist die logische Kommunikation zwischen den einzelnen Schich-ten eingezeichnet.

Vor allem im Embedded -Bereich werden Bluetooth-Module eingesetzt, dieeinen größeren Funktionsumfang im Bluetooth-Controller implementieren,oder ganz ohne Host Controller funktionieren [25]. Solche Lösungen werdenin der Bluetooth-Spezifikation [4] nicht beachtet. Die Hersteller sind daherauf proprietäre Lösungen für ihre Schnittstellen angewiesen.

Die Kommunikation zwischen Host und Controller erfolgt durch dreiArten von HCI-Paketen.

2.4.1 Kommandopakete

Kommandopakete werden vom Host zum Controller gesendet und deckenden zentralen Funktionsumfang der HCI-Schnittstelle ab [25]. Die Detailsfinden sich in der Bluetooth-Kernspezifikation [4].

• Link Control Commands dienen der Kontrolle von Verbindungen zuanderen Geräten. Damit werden andere Geräte aufgefunden, Verbin-dungen erzeugt, authentifiziert und verschlüsselt.

• Link Policy Commands verwalten die Dienstgüte eines Kanals. Nebenden QoS-Parametern wird damit in die Stromsparmodi Sniff, Hold und


Parked gewechselt. Auch der Rollentausch zwischen Master und Slavewird durch Link Policy Commands ermöglicht.

• Host Controller & Baseband Commands parametrisieren und steuernden Bluetooth-Controller. Dazu gehört das Auslesen und Setzen desGerä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 überEreignisse und Anforderungen zu informieren [25].

Normalerweise ist die Kommunikation zwischen Host und Controller im-mer vom Host getrieben. Ein unerwartetes Ereignispaket kommt dabei inseiner 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ürACL- 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 denAnwendungen Kanäle zur Kommunikation zur Verfügung. Es ist die ers-te Schicht des Protokollstapels, die auf dem Host-System implementiertwird. Ü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 aufdem Link Manager auf, sondern greift über das HCI direkt auf die vom LinkManager konfigurierte Basisbandschicht zu [15]. L2CAP greift dabei nur auf


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 demAuf- und Abbau von Kanälen. Dieser besitzt die Kanal-ID 0x0001.

• Verbindungsorientierte Kanäle für die bidirektionale Übertragung vonDaten zwischen zwei Kommunikationspartnern. Dazu werden Kanal-IDs im Bereich von 0x0040 bis 0xFFFF dynamisch zugewiesen.

• Verbindungslose Kanäle für gerichtete Kommunikation in Form vonBroadcasts11 und Multicasts12. Der Absender benutzt eine dynamischzugewiesene Kanal-ID. Die Empfänger von Broadcasts bekommen dieDaten immer über den Kanal 0x0002 zugestellt. Für Multicasts wirdebenfalls eine Kanal-ID dynamisch zugewiesen. Diese muss für alleEmpfä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 undServer bei Bluetooth auch als Initiator und Akzeptor bezeichnet werden. DerInitiator 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 durcheine Confirmation beantwortet. Ein Ereignis aus der unteren Schicht nennt

11Eine Nachricht an alle Teilnehmer12Eine Nachricht an mehrere bestimmte Teilnehmer


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 derDienstgü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 Jitter13 können spezifziert werden. Die maxi-male Nutzdatengröße des Empfängers (MTU) sowie die Anzahl an Über-tragungswiederholungen im Fehlerfall sind ebenfalls wichtige Eigenschafteneines 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 zu64 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-Paketeaufgeteilt werden [4]. Der Paketkopf wird dabei nur im ersten Paket übertra-gen. Die Flusskontrolle der Basisbandschicht dient dazu, den Anfang einesneuen Paketes zu markieren und von einer fortgesetzten Übertragung vonL2CAP-Daten zu unterscheiden [4].

• Beim verbindungsorientierten Kanal besteht ein Paket aus den Nutz-daten mit vorangesteller Länge und Kanal-ID (Abbildung 2.8). EinKanal wird bei der verbindungsorientierten Kommunikation exklusivvon 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 ServiceMultiplexor, 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].

13Die Größe der Abweichung der Verzögerung


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 derverbindungsorientierte Kanal. Die Nutzdaten bestehen aus einem odermehreren 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 dientder Zuordnung von Request und Response. Im Datenfeld sind eventuellvorhandene 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 wirddieselbe Schnittstelle eingesetzt, wobei die ausgezeichnete Kanal-ID 0x0001für den Steuerungskanal verwendet wird. In Tabelle 2.3 ist die Funktion derexistierenden 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 maximalePaketgröß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äleDaten auszutauschen. Weiters definiert Bluetooth Profile. Damit könnenDienste für einen bestimmten Anwendungsfall über ein standardisiertes Pro-tokoll miteinander kommunizieren. Damit die angebotenen Dienste von an-


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

Command Reject Antwort auf ein unbekanntes oder fehlerhaftesSignal. 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 einesL2CAP-Kanals.

Configuration Response Damit wird die vorgeschlagene Konfigurationeines Configuration Request bestätigt oder ab-gelehnt. Die abgelehnten Eigenschaften werdenmarkiert 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ützungvon Dienstgüteklassen.

deren Geräten genutzt werden können, muss ein Gerät Informationen überdie verfügbaren Dienste bereitstellen. Diese Aufgabe übernimmt das ServiceDiscovery Protocol (SDP).

SDP arbeitet nach dem Client-Server -Modell. Ein Gerät, das Diensteanbietet, besitzt einen SDP-Server. Um Dienste abzufragen, wird der SDP-Client verwendet. Eine Applikation zum Auffinden von Diensten (ServiceDiscovery Application) nutzt einen SDP-Client, um über einen SDP-Serversogenannte Service Records abzufragen. Wenn die verfügbaren Dienste be-kannt sind, kann nach einem spezifischen Protokoll eine Verbindung zu einemDienst 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örigkeiteines Dienstes zu einem bestimmten Diensttyp. Serviceklassen sind hiera-


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 eineBeschreibung 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 abernur ein Bruchteil von TS 07.10 implementiert und Bluetooth-spezifische Er-weiterungen getroffen [3].

14European Telecommunications Standards Institute


RFCOMM bietet eine verlässliche Kommunikation und Flusskontrolle. Eskönnen bis zu 60 virtuelle serielle Verbindungen gleichzeitig geöffnet werden.Alle Verbindungen werden über den selben L2CAP-Kanal betrieben. DieseVerbindungen können also nur zum gleichen Gerät aufgebaut werden. UmRFCOMM-Verbindungen zu verschiedenen Geräten aufzubauen, sind meh-rere Instanzen des RFCOMM-Treibers nötig, was nicht von allen Gerätenunterstützt wird.

Die emulierte serielle Verbindung verhält sich komplett wie eine EIA-23215-Schnittstelle und implementiert dazu auch Hardware-Handshake undStatusleitungen. Die maximale Geschwindigkeit liegt bei 115 kBit/s. Es wirdeine 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 undein anderes Übertragungsmedium (z.B. eine physikalische EIA-232-Verbindung) zu einem Endgerät. Der Bluetooth-Gateway wird als Typ 2bezeichnet. Mit diesem Typ der Verbindung können Geräte mit Kabel-verbindung Bluetooth-tauglich gemacht werden.

15Ein Standard für eine serielle Schnittstelle, ursprünglich RS-232

Kapitel 3

Bluetooth imOSI-Referenzmodell

Das OSI1-Referenzmodell [10] beschreibt abstrakt die Aufgaben eines Kom-munikationssystems. Es wurde von der International Standard Organizationstandardisiert. Das OSI-Modell basiert auf sieben Schichten, wovon jede ei-ne Aufgabe erfüllt. Der Funktionsumfang einer Schicht ist genau definiertund sie ist klar von den anderen Schichten abgegrenzt. Die Schichten sindhierarchisch aufgebaut. Eine Schicht greift nur auf die Dienste der darunter

1Open 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 desISO-OSI-Referenzmodelles [25]

liegenden Schicht zu und stellt der darüber liegenden Schicht ihre Dienstezur Verfügung. Durch definierte Schnittstellen zwischen den Schichten lassensich diese austauschen und wiederverwenden.

Logisch kommunizieren die einzelnen Schichten von Teilnehmern mitein-ander, während physikalisch ein Informationsaustausch durch den Stapel ausSchichten stattfindet. In Abbildung 3.1 sind die vorhandenen Schichten undder Informationsfluss zwischen ihnen dargestellt.

Die Kernspezifikation von Bluetooth deckt nur einen Teil der Schichten imOSI-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 Diensteder RFCOMM-Schicht, ist das Sicherungsprotokoll PPP3 nötig. Alternativkann 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.

2Internet Protocol3Point to Point Protocol4Bluetooth Network Encapsulation Protocol


3.1 Bitübertragungsschicht

Die Bitübertragungsschicht beschreibt die bitweise Übertragung von Infor-mationen über ein physikalisches Medium. Dazu gehört die elektrische undmechanische 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 Endendes Übertragungsmediums zu transportieren. Die Aufgaben werden in zweiBereiche geteilt.

Die Medienzugriffskontrolle (MAC5) ist für den geregelten Zugriff auf dasKommunikationsmedium zuständig. Diese Aufgabe wird bei Bluetooth vonder 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 einemgewissen Grad durch Wiederholungen ausgebessert werden. Grundsätzlichist aber keine verlustfreie Kommunikation garantiert [10]. Diese Aufgabenwerden bei Bluetooth von den Verbindungsprotokollen LMP und L2CAPerfü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 dazukeine 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 nimmtein 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 implementiertwerden [4]. Adaptierte Protokolle, die Bluetooth als Transportprotokoll ein-setzen, können ihre eigene Vermittlungsschicht mit sich bringen.

5Media Access Control6Logical Link Control


3.4 Transportschicht

Die Transportschicht teilt den Datenstrom in Pakete und setzt diese inder richtigen Reihenfolge wieder zusammen. Sie ermöglicht eine gesicherteund 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. IhreAufgaben 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 vonDaten in eine unabhängige Form um. Damit ist der syntaktisch korrekteAustausch 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 abstrahiertsind [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ürbestimmte Einsatzzwecke eignen. Um die Komplexität und damit die Kos-ten und den Strombedarf von Bluetooth-Geräten gering zu halten, sind vieleProtokolle optional zu implementieren. Sogar innerhalb eines Protokolls sindbestimmte Funktionen oft nicht zwingend vorgeschrieben. Um trotzdem eineInteroperabilitä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 Protokollstapeldar [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 erweitertoder spezialisiert die Funktionen der Basis. In Abbildung 4.2 sind alle zurZeit 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 dieVoraussetzungen und eine Anwendungsschnittstelle für allgemeine Proze-duren [25]. Damit werden die Funktionen von Link Manager und L2CAPzur 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 zufinden [4].


4.1.2 SDAP – Service Discovery Application Profile

SDAP stellt eine Schnittstelle für eine Applikation zur Abfrage von Profilenbereit und spezifiziert die Funktionalität einer solchen Applikation. Es wirddas 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, basierenviele andere Profile darauf. SPP definiert eine Schnittstelle, um eine Ver-bindung nach dem RFCOMM-Protokoll auf dem Host als virtuelle serielleVerbindung 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 demOBEX1-Protokoll [2], das für Bluetooth adaptiert wurde und das von GOEPeingesetzt wird.

4.1.5 GAVDP – Generic Audio Video Transport Profile

Das GAVDP kommt zum Einsatz, wenn qualitativ hochwertige Audio- oderVideo-Datenströme übertragen werden sollen [1]. Als Grundlage dient dasAVDTP2-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 werdenständig um weitere Profile ergänzt. Tabelle 4.1 listet diese Profile und ihreAnwendungsszenarien auf.

1Object Exchange2Audio/Video Distribution Transport


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

A2DP Advanced Audio Dis-tribution Profile

Übertragung eines hochwertigen Audio-Datenstroms in Stereo oder Mono

AVRCP Audio/Video RemoteControl Profile

Steuerung von Audio/Video-Equipment

BIP Basic Imaging Profile Übertragung von BilddateienBPP Basic Printing Profile Drucken von verschiedenen Dokumenten-

formatenCTP Cordless Telephony

ProfileProfil für ein universelles Schnurlostelefon,das sich sowohl mit Mobilfunk als auch ei-ner Festnetz-Basisstation nutzen lässt

DI Device ID Profile Identifikation von Geräten auf Basis vonHersteller und Produktbezeichnung

DUN Dial-Up NetworkingProfile

Nutzung von Modem-Diensten über Blue-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 Anrufsteuerungfür Freisprecheinrichtungen

HCRP Hardcopy Cable Repla-cement Profile

Ersetzt Kabelverbindungen von Druckernund Scannern

HSP Headset Profile Vollduplex-Übertragung von qualitativhochwertigen Audiodaten

HDC Health Device Profile Übertragung von Sensordaten im Fitness-und Medizin-Bereich

HID Human Interface Devi-ce Profile

Übertragung von Daten von Eingabegerä-ten

ICP Intercom Profile Sprechverbindungen zwischen Bluetooth-Geräten (Walkie-Talkie)

OPP Object Push Protocol Dateien an andere Geräte sendenPAN Personal Area Networ-

king ProtocolErmöglicht mit Hilfe von BNEP denTransport von Paketen verschiedenerNetzwerkprotokolle

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-le

Synchronisation von PIM-Daten wie Tele-fonbucheinträgen oder Visitenkarten

VDP Video DistributionProfile

Übertragung von Videosignalen

Kapitel 5

NFC für Bluetooth

Near Field Communication (NFC) ist eine neue Funktechnologie für kurzeDistanzen. Sie basiert auf RFID1-Technik, verwendet also das magnetischeFeld von Spulen, um durch Induktion Daten zu übertragen. Bei einer Trä-gerfrequenz von 13,56 MHz sind damit Datenraten von bis zu 424 kBit/smöglich. NFC unterscheidet sich daher wesentlich von herkömmlichen Funk-technologien. Die extrem geringe Reichweite von etwa 10 Zentimetern ist dieBasis 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 einintuitives 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 Magnetfeldund 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 Kontaktdatenwird es auch für Zutrittskontrolle und Bezahlsysteme genutzt [22].

NFC wird durch das NFC-Forum spezifziert. Das NFC-Forum wurde1994 von NXP Semiconductors, Sony und Nokia gegründet, um NFC-Tech-nologie zu spezifizieren und zu verbreiten. Mittlerweile hat das NFC-Forum150 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-

1Radio Frequency Identification

31

5. NFC für Bluetooth 32

Tabelle 5.1: Vergleich zwischen Bluetooth und NFC [7]

NFC BluetoothNetzwerk-Konfiguration Peer to Peer Point to MultipointReichweite 10 cm 10 m bis 100 mFrequenz 13,56 MHz 2,4 GHzDatenrate bis 424 kBit/s bis 2,1 MBit/sSet-Up-Zeit kleiner 0,1 s ca. 6 sSicherheit Hardware, Protokoll ProtokollebeneKommunikationsmodi aktiv-aktiv, aktiv-passiv aktiv-aktiv

Verbindung werden die Geräte einfach aneinander gehalten. Dann sind dieBandbreite und Reichweite der Bluetooth-Verbindung verfügbar. NFC machtdamit 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 ProximityCoupling Device (PCD) bezeichnet. Für die passiven kontaktlosen Kartenwird der Begriff Proximity Integrated Circuit Card (PICC) verwendet. Eswird das ISM-Band bei einer Mittelfrequenz von 13,56 MHz genutzt. DieBandbreite beträgt dabei 2 MHz. Es werden zwei Typen unterschieden, dieunterschiedliche Modulationsarten verwenden.

Typ A: Typ A setzt für die aktive Kommunikation von PCD zu PICC eineASK2-Modulation mit 100% Abschwächung ein. Die Bits werden nach demModified-Miller -Schema codiert. Für die passive Kommunikation von PICCzu PCD wird OOK3 mit einer Manchester -Kodierung der Bits verwendet[13].

Typ B: Als Modulation von PCD zu PICC wird eine ASK-Modulationmit 10% Abschwächung eingesetzt. Für die Lastmodulation kommt BPSK4

zum Einsatz. Die Bits werden direkt in Signalpegel umgeformt (NRZ-L5-Kodierung) [13].

2Amplitude Shift Keying3On-Off Keying4Biplorar Shift Keying5Non-Return to Zero – Level


NFC stellt eine einfache Erweiterung dieses Standards dar. In ISO/IEC18092 [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 unddas Rahmenformat der Funkschicht. Es werden Initialisierungs-Prozedurenund Methoden zur Vermeidung von Kollisionen beschrieben. Weiters wirddas Protokoll zum Datentransport und Methoden zum Datenaustausch de-finiert.

Für die Implementation von passiven Tags bietet das NFC-Forum vier TagOperation Specifications. Diese Tags sind bereits kommerziell erhältlich oderkompatibel zu existierenden Technologien [22].

Typ 1: Der Tag vom Typ 1 basiert auf ISO/IEC 14443 Typ A und kanngelesen 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. DieDatenrate liegt bei 106 kBit/s [18].

Typ 2: Dieser ist identisch zu Typ 1, verfügt aber nur über 48 Bytes anSpeicher [19].

Typ 3: Der Tag vom Typ 3 basiert auf dem Japanese Industrial StandardJIS X 6319-4, besser bekannt unter dem Namem FeliCa. Bereits bei derHerstellung wird bestimmt, ob diese Tags geschrieben werden können. Derverfügbare Speicherplatz ist variabel, wobei das Limit bei 1 MByte liegt. DieDatenrate 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 passivenTags gelesen werden. NDEF ist ein simples binäres Nachrichtenformat, das


Abbildung 5.1: Format eines NDEF-Records [16]

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

0x01 NFC-Forum: wohlbekannter Typ0x02 MIME-Typ0x03 Absolute URI0x04 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 Nutzdatenfeldwird als Record bezeichnet. In Abbildung 5.1 ist das Format eines Recordsdargestellt. 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 FeldCF zeigt dazu an, dass der aktuelle Record nur ein Teil eines Datensatzesist.

Das Feld SR gibt an, ob das Feld für die Länge der Nutzdaten aus einemoder aus vier Bytes besteht. Damit ist eine effiziente Übertragung von kurzenDatensä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-

6Uniformal Resource Identifier, eine Zeichenfolge zur Identifizierung einer Ressource7Internet Media Type, klassifiziert die Daten im Rumpf einer Nachricht


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

penbezeichner werden für häufig genutzte und wohlbekannte Typen sowie fürproprietäre (sogenannte externe) NFC-Lösungen eingesetzt [16]. Die NFCRecord Type Definition (RTD) [17] spezifiziert den Aufbau dieser NFC-spezifischen Typenbezeichnungen. In Tabelle 5.2 sind die gültigen Werte fürdas 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, mitdenen ein NFC-Gerät bei seinem Kommunikationspartner den Aufbau einerVerbindung ü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 dieseMö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 desHandover Selectors.

Zur Zeit definiert die Connection Handover Specification die Verwendungvon Bluetooth und Wi-Fi. Die Spezifikation lässt sich aber leicht für andereFunktechnologien 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 anden 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,


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 derim Handover Selector gelisteten Möglichkeiten, wird eine leere Liste zurückgesendet. Bekommt der Handover Selector eine Liste mit Einträgen, ist dasHandover -Protokoll erfolgreich abgeschlossen. Der Handover Selector kannjetzt 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 einesBeispiels dargestellt.

5.3.2 Static Handover

Der Static Handover kommt zum Einsatz, wenn ein Gerät nicht über NFCverfü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 Kommunikationimmer empfangsbereit halten, um eine Anfrage zu erkennen. Beim NegotiatedHandover 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 Recordoder 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 zueinem alternativen Komunikationsmedium zusammen zu fassen. Der CarrierPower State gibt an, in welchem Modus sich das Medium befindet. Die Car-


Abbildung 5.4: Aufbau von Handover Select und Handover Request [23]

rier Data Reference verweist per Index auf einen NDEF-Record vom TypHandover Carrier Record oder Carrier Configuration Record.

Der Handover Carrier Record („Hc“) dient dazu, ein Kommunikations-medium zu identifizieren, ohne weitere Parameter anzugeben. Er wird meistbei Handover-Select-Nachrichten verwendet.

Der Carrier Configuration Record ist ein NDEF-Record von spezifischemTyp, der Paramter für den Verbindungsaufbau beinhaltet. Der Typ ist vomverwendeten Kommunikationsmedium abhängig und lautet bei Bluetooth„bluetooth.org:sp“.

Die optionale Auxilary Data Reference verweist auf NDEF-Records vonbeliebigem 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 Übertragungvon 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.5dargestellt. Die einzelnen Datenfelder sind nach dem TLV8-Schema abgelegt.Dieser Carrier Configuration Record kommt sowohl beim Handover Requestals auch beim Handover Select zum Einsatz. Ein Datenfeld besteht also auseinem Tag, der die Art der Information beschreibt, einer Längenangabe undden Daten. Die Felder mit den kryptographischen Informationen (P undC) sind optional [23]. Wenn sie nicht vorhanden sind, wird NFC nur zumAuffinden eines Bluetooth-Gerätes benutzt, und ein herkömmlicher Pairing-Machanismus über Bluetooth verwendet [4].

8Tag, Length, Value


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 zulassen, definiert das Generic Access Profile eine Schnittstelle, um über dasHost Control Interface mit dem Link Manager zu kommunizieren.

1. Die Anwendung zur Verwaltung von Bluetooth-Verbindungen fragt vonseinem 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 anderesGerät übermittelt.

3. Die Verwaltungs-Anwendung auf dem zweiten Gerät zeigt seinem LinkManager an, dass OOB-Daten zur Verfügung stehen. Dieser holt sichdie 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.


6. Bei geglückter Authentifizierung beginnt dieses Gerät nun damit, dieBluetooth-Verbindung aufzubauen und den Pairing-Vorgang abzuschlie-ßen.

Alternativ können die kryptograhischen Zahlen P und C auch einfach voneinem Tag in Form eines Handover Select abgefragt werden, um damit dasPairing 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 abzufangenund 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 aufder Immunität von NFC gegenüberMan-In-The-Middle-Angriffen. EinMan-In-The-Middle-Angriff ist bei NFC zwar prinzipiell denkbar, durch die ge-ringe Reichweite aber nur möglich, wenn sich der Angreifer direkt zwischenden 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 nichtvorgesehen [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: Identificationcards, 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.

Documents

Bluetooth und NFC