Bluetooth Und Nfc

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 selbststä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 2.1 Funkschicht . . . . . . . . . . . . . . . . 2.1.1 Frequenzen und Kanäle . . . . . 2.1.2 Sendeleistung . . . . . . . . . . . 2.1.3 Modulationsarten . . . . . . . . . 2.2 Basisbandschicht . . . . . . . . . . . . . 2.2.1 Physikalische Kanäle . . . . . . . 2.2.2 Vernetzung . . . . . . . . . . . . 2.2.3 Adressierung . . . . . . . . . . . 2.2.4 Physikalische Verbindungen . . . 2.2.5 Datenpakete . . . . . . . . . . . . 2.2.6 Logische Kanäle . . . . . . . . . 2.3 Link Manager . . . . . . . . . . . . . . . 2.3.1 Nachrichtenformat . . . . . . . . 2.3.2 Verbindungssteuerung . . . . . . 2.3.3 Authentifizierung . . . . . . . . . 2.3.4 Pairing . . . . . . . . . . . . . . 2.3.5 Verschlüsselung . . . . . . . . . . 2.4 Host Control Interface . . . . . . . . . . 2.4.1 Kommandopakete . . . . . . . . 2.4.2 Ereignispakete . . . . . . . . . . 2.4.3 Datenpakete . . . . . . . . . . . . 2.5 Logical Link Control and Adoption Layer 2.5.1 Datenkanäle . . . . . . . . . . . . 2.5.2 Kanalverwaltung . . . . . . . . . 2.5.3 Datenpakete . . . . . . . . . . . . iv

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocol . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

3 3 3 4 4 5 5 5 6 6 7 8 9 9 10 11 11 14 14 15 16 16 16 17 17 18

Inhaltsverzeichnis

2.6 2.7

v

2.5.4 Signalpakete . . . . . . . . . . . . . . . . . . . . . . . Service Discovery Protocol . . . . . . . . . . . . . . . . . . . . RFCOMM-Protokoll . . . . . . . . . . . . . . . . . . . . . . .

3 Bluetooth im OSI-Referenzmodell 3.1 Bitübertragungsschicht . . . . . . 3.2 Sicherungsschicht . . . . . . . . . 3.3 Vermittlungsschicht . . . . . . . . 3.4 Transportschicht . . . . . . . . . 3.5 Weitere OSI-Schichten . . . . . .

19 19 21

. . . . .

. . . . .

. . . . .

. . . . .

23 25 25 25 26 26

4 Bluetooth-Profile 4.1 Grundlegende Profile . . . . . . . . . . . . . . . . . . . . 4.1.1 GAP – Generic Access Profile . . . . . . . . . . . 4.1.2 SDAP – Service Discovery Application Profile . . 4.1.3 SPP – Serial Port Profile . . . . . . . . . . . . . 4.1.4 GOEP – Generic Object Exchange Protokoll . . . 4.1.5 GAVDP – Generic Audio Video Transport Profile 4.2 Abgeleitete Profile . . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

27 28 28 29 29 29 29 29

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

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

31 32 33 35 35 36 36 37 38 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 Basisstation. 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 Spezifikation. 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 Zahlenfolgen eintippen oder vergleichen, um eine Verbindung zu erhalten. Um diese Prozedur zu vereinfachen, kann Near Field Communication (NFC) eingesetzt werden, ein Funkstandard der von kontaktlosen Chipkarten abgeleitet ist. Damit wird ein schneller und intuitiver Verbindungsaufbau möglich, einfach 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 between two devices. Depending on the methode used, the user has to enter or compare sequences of numbers to obtain a connection. To simplify this procedure, Near Field Communication (NFC) may be used. Near Field communication 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 Infrastruktur 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, wurde 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 beschrieben. Darauf bauen Protkolle und Anwendungen auf, die dem Benutzer die Technologie erst zugänglich machen. Vielfach werden einfach bestehende Protokolle, 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 Enhanced Data Rate 3 Object Exchange Protocol 4 Internet Protocol 2

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 werden durch eigene Profile abgedeckt. Beispiele sind Headsets, Mobiltelefone als Modem, Synchronisation von Kontaktdaten und der Austausch von Visitenkarten. Auch diese Profile werden von der Bluetooth-SIG standardisiert und machen damit Geräte unterschiedlicher Hersteller kompatibel. Sie werden in Kapitel 4 beschrieben. Die wichtigsten Eigenschaften sind also Stabilität, Kompatibilität, geringe Kosten und geringer Strombedarf. Mit diesen Eigenschaften konnte sich Bluetooth am Markt etablieren und wird in tausenden verschiedenen Gerä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 sicheren Verbindung zwischen zwei Geräten. Während Bluetooth in der Version 2 Schwächen der kryptographischen Verfahren beseitigt, lässt die User Experience immer noch zu wünschen übrig. So müssen Passschlüssel eingetippt 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 Kommunikationsmedium 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 Protokollstapels beschrieben (Abbildung 2.1) [4]. Dieser Protokollstapel stellt den Applikationen Kontroll- und Datenschnittstellen für die synchrone (Audio) und asynchrone (Daten) Kommunikation zur Verfügung.

2.1 2.1.1

Funkschicht 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 werden [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 1 2 3

Max. Sendeleistung 100 mW 2.5 mW 1 mW

zu vermeiden, ist am oberen und unteren Ende ein nicht verwendeter Bereich 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 kombinierten 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 (Hopping). Der Wechsel der Kanäle erfolgt in einer pseudo-zufälligen Reihenfolge. 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 Leistungsklassen eingeteilt, wie in Tabelle 2.1 dargestellt. Geräte der Leistungsklasse 1 müssen eine automatische Anpassung der Sendeleistung implementieren, 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 Abschnitt 2.3).

2.1.3

Modulationsarten

Es sind zwei Modulationsarten spezifiziert [4]: Grunddatenrate: Es wird die GFSK3 -Modulation verwendet. Dabei handelt es sich um eine binäre Frequenzmodulation, die sich mit geringem Aufwand implementieren lässt [25]. Dadurch werden die Kosten für die Sendeund Empfangseinheit gering gehalten. Dieser Modus wird von jedem BluetoothGerät unterstützt und liefert eine Rohdatenrate von 1 Mbit/s. 2 3

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

2. Bluetooth-Kernspezifikation

5

Verbesserte Datenrate (EDR): Sie ist seit Version 2.0 des BluetoothStandards [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 gesendetem Symbol 3 Datenbits kodiert werden. Die Rohdatenrate liegt bei 3 Mbit/s. Diese beiden Varianten können optional implementiert werden. Zum Einsatz können sie nur kommen, wenn der Kommunikationspartner die gleiche Modulationsart unterstützt.

2.2 2.2.1

Basisbandschicht Physikalische Kanäle

Ein Übertragungskanal wird durch die pseudo-zufällige Sprungsequenz innerhalb 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 anderen Ü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 SlaveKnoten. Weitere Geräte können geparkt sein, d. h. sie sind gerade vorübergehend deaktiviert, können jedoch innerhalb weniger Slot-Zyklen aktiviert werden. Geräte in Bereitschaft nehmen nicht am Pikonetz teil. 4

Phase Shift Keying Differential Quaternary Phase Shift Keying 6 Differential Phase Shift Keying 5

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 vergeben, ist 48 Bit lang und weltweit einzigartig, vergleichbar mit der MAC-Adresse bei Ethernet. Sie wird zum Verbindungsaufbau verwendet 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 verwendet. • AR_ADDR: Adresse für Zugriffs-Anfragen. Sie wird von geparkten Teilnehmern verwendet, um wieder die aktive Kommunikation aufzunehmen.

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 verwendet, 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 gleichbleibendem Abstand werden eine bestimmte Anzahl an Zeitschlitzen reserviert. Damit ist die benötigte Bandbreite zu jeder Zeit verfügbar [25]. Die ACL-Verbindung dient zur Übertragung von Daten in den übrig gebliebenen Zeitschlitzen. Weder eine bestimmte Bandbreite noch eine rechtzeitigte Zustellung der Daten kann garantiert werden. Jedes Bluetooth-Gerät 7 8

Synchrounus Connection Oriented 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 Steuerinformationen ü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 unterhalten. Die isochrone Verbindung stellt einen Sonderfall der asynchronen Verbindung dar. Hier wird versucht, Datenpakete möglichst gleichmäßig zu übertragen. 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 hergestellt [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) (Abbildung 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 Pikonetz 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, Teilnehmeradresse und Sprungreihenfolge mitzuteilen. Es dient dem Aufbau der Kommunikation und der Synchronisation während der Kommunikation. Auch die Serviceklasse des Gerätes wird gesendet. Damit teilt ein Teilnehmer mit, welcher Geräteklasse er angehört (z.B. Laptop, Modem) und welche Funktionen er unterstützt (Serviceklassen, z.B. Telefonie, Bildgebung, 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übertragung 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 Paket zur gleichzeitigen Übertragung von Daten und Sprache.

2.2.6

Logische Kanäle

Logische Kanäle sind verschiedene Typen von Kanälen, die über physikalische Verbindungen aufgebaut werden. Es sind verschiedene logische Kanäle zur Übermittlung von Steuerungsinformation und Benutzerdaten definiert [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 DM1 DH1 DM3 DH3 DM5 DH5 AUX1

Slots 1 1 3 3 5 5 1

FEC 2/3 nein 2/3 nein 2/3 nein nein

CRC ja ja ja ja ja ja nein

Maximale Nutzlast (Byte) 18 28 122 184 225 340 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 Kommunikationsmodell bereit. Die höheren Schichten Audio und Control greifen aber auch direkt auf die Basisbandschicht zu (Abbildung 2.1) [25]. Der Betriebszustand 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 Funktionen des Link Managers beschrieben.

2.3.1

Nachrichtenformat

Um ihre Aufgaben zu erfüllen, kommunizieren die Link Manager der Kommunikationspartner per Link Management Protocol (LMP). Die ausgetauschten 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 logische Zusammenhänge beschreiben [4]. Ein Gerät muss nicht alle Sequenzen unterstützen, nur grundlegende Funktionen sind zwingend zu implementieren. 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 Abschnitt 2.2.5) auf 32 festgelegten Trägerfrequenzen ausgesendet und auf Antworten 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 Zeitinformationen 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 damit, Verbindungen zu den erkannten Geräten aufzubauen. Dazu berechnet er aus den Geräteadressen die Frequenzsprungfolge des Pikonetzes (siehe Abschnitt 2.2.1). Der Master ruft die Slaves nun nacheinander auf und synchronisiert 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 wechseln. 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 Teilnehmer lauschen in regelmäßigen Intervallen auf eine Mitteilung vom Master. Der sogenannte Beacon-Kanal wird ausschließlich für die Aktivierung geparkter Teilnehmer verwendet [25]. Im Zustand Hold ist die Kommunikation über die ACL-Verbindung angehalten. 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 Verbindungsschlüssel verwendet, den beide Geräte kennen müssen. Der Verbindungsschlüssel wird nach einem Abfrage-Antwort-Schema geprü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äteadresse den Sicherheitsschlüssel, der als Antwort gesendet wird. Die Antwort wird von Gerät A mit dem selbst ermittelten Sicherheitsschlüssel verglichen. Stimmen die Ergebnisse überein, ist die Authentifikation gelungen. Gerät A hat damit sichergestellt, das Gerät B den Verbindungsschlüssel kennt. Will Gerä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 Bluetooth als Pairing bezeichnet. Pairing ist das zentrale Sicherheitskonzept

2. Bluetooth-Kernspezifikation

12

von Bluetooth und ermöglicht sichere Punkt-zu-Punkt-Verbindungen. Pairing 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 besondere Eigenschaft: Mit dem öffentlichen Schlüssel verschlüsselte Nachrichten können nur mit Hilfe des privaten Schlüssels wieder entschlüsselt werden (asymetrische Kryptographie) [4]. Die Geräte tauschen die öffentlichen Schlüssel aus. Authentifizierung Phase 1 Die erste Phase der Authentifizierung kann auf verschiedene Arten stattfinden, die sich in der Sicherheit und den Anforderungen an die Geräte unterscheiden. 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 zufä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 Zufallszahlen und den öffentlichen Schlüsseln eine sechsstellige Verifikationsnummer, die auf beiden Geräten angezeigt wird. Der Benutzer vergleicht die Verifikationsnummern 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öglichkeit 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 Verifikationsschlü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 sechsstellige 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 anfä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 PairingProzess durch das Übertragen der Out-Of-Band -Daten angestoßen. Dieses Verfahren ist grundsätzlich so sicher wie das verwendete alternative Kommunikationsmedium. Im Bluetooth-Standard [4] wird als Beispiel NFC genannt. Die weiteren Details dieses Verfahrens werden in einem späteren Kapitel besprochen. 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üssel mit ein. Dieses Verfahren bietet eine hohe Sicherheit, ist jedoch auch für den Benutzer 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 verwendeten 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üsselungscode 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 Verbindungsschlüssel generiert. Der ausgetauschte Verbindungscode wird permanent in den Geräten gespeichert. 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. Dazu 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 Verbindungsschlü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 BluetoothStandard [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 BluetoothModule 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 Schichten 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, Verbindungen 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 Versionsinformationen, unterstützte Funktionen und Geräteadresse aus. • Status Parameter zeigen Eigenschaften des Funkkanals wie Empfangsstärke und Verbindungsqualität an. • Testing Commands werden für Systemtests benutzt.

2.4.2

Ereignispakete

Ein Kommandopaket wird vom Bluetooth-Controller mit einem Ereignispaket beantwortet. Ereignispakete dienen auch dazu, den Controller über Ereignisse und Anforderungen zu informieren [25]. Normalerweise ist die Kommunikation zwischen Host und Controller immer 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 Versenden von Nutzdaten verwendet. Dabei wird zwischen Datenpaketen für ACL- und SCO-Verbindungen unterschieden. Um eine gleichzeitige Kommunikation mit verschiedenen Geräten zu ermöglichen, werden verschiedene virtuelle Kanäle durch ein Connection Handle identifiziert [25].

2.5

Logical Link Control and Adoption Layer Protocol

Das Logical Link Control and Adoption Layer Protocol (L2CAP) stellt den Anwendungen Kanäle zur Kommunikation zur Verfügung. Es ist die erste Schicht des Protokollstapels, die auf dem Host-System implementiert wird. Über einen HCI-Treiber greift es auf die Funktionen des BluetoothControllers zu [4]. Während der Link Manager sich um die Verbindung zwischen den Geräten kümmert, realisiert L2CAP einzelne Kommunikationskanä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 (Multicasts)

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 KanalIDs 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 bezeichnet. Ereignisse der oberen Protokollschicht heißen Request, und werden durch eine Confirmation beantwortet. Ein Ereignis aus der unteren Schicht nennt 11 12

Eine Nachricht an alle Teilnehmer 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. Eine 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 Datenrate, Puffergröße, Latenz und Jitter 13 können spezifziert werden. Die maximale Nutzdatengröße des Empfängers (MTU) sowie die Anzahl an Übertragungswiederholungen im Fehlerfall sind ebenfalls wichtige Eigenschaften eines L2CAP-Kanals [25]. Bei der Übertragungswiederholung wird unterschieden 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 unterschiedliche Paketformate. Die L2CAP-Pakete werden in Pakete der Basisbandschicht gekapselt. Nachdem die Pakete der Basisbandschicht nur maximal 340 Byte an Nutzdaten aufnehmen können, müssen die L2CAP-Pakete aufgeteilt werden [4]. Der Paketkopf wird dabei nur im ersten Paket übertragen. 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 Nutzdaten 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 Kommunikationsprotokolls ist also nicht nötig [25]. • Bei einem verbindungslosen Kanal enthalten die L2CAP-Pakete zusätzlich noch ein Feld zur Angabe des Protokolls (Protocol Service Multiplexor, PSM) (Abbildung 2.9). Dabei wird zwischen den darüberliegenden Protokollen SDP, RFCOMM und TCS unterschieden [25]. Die Kanal-ID ist für Broadcasts 2, für Multicasts wird der EmpfängerKanal 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 Request 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 L2CAPSchicht das Versenden und Empfangen von Datenpaketen nach dem in Abschnitt 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 enthaltenen Datenfelder ist in [4] zu finden. Eine weitere Form der Signale sind die sogenannten Optionen. Sie erweitern 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 Übertragungswiederholung, sowie verbesserte Dienstgüte-Klassen [4].

2.6

Service Discovery Protocol

Mit den bisher vorgestellten Protokollen ist es zwei Bluetooth-Geräten möglich, 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 Protokoll miteinander kommunizieren. Damit die angebotenen Dienste von an-

2. Bluetooth-Kernspezifikation

20

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

Command Reject

Connection Request Connection Response Configuration Request Configuration Response

Disconnection Request Disconnection Response Echo Request/Response

Information Request Information Response

Antwort auf ein unbekanntes oder fehlerhaftes Signal. Auch zu lange Pakete werden damit abgewiesen. Wird gesendet um einen L2CAP-Kanal zwischen zwei Geräten anzufordern. Antwort auf einen Connection Request. Im Fehlerfall wird die Fehlerursache mitgeteilt. Dient dem Aushandeln der Eigenschaften eines L2CAP-Kanals. Damit wird die vorgeschlagene Konfiguration eines Configuration Request bestätigt oder abgelehnt. Die abgelehnten Eigenschaften werden markiert und andere Werte dafür vorgeschlagen. Leitet den Abbau eines Kanals ein. Schliesst den Abbau eines Kanals ab. Dient dem Test der Verbindung oder der Übertragung Hersteller-spezifischer Konfigurationsdaten in einem optionalen Datenfeld. Fragt Details der L2CAP-Implementierung eines Verbindungspartners ab. Teilt Details der L2CAP-Implementierung mit. Diese betreffen Flusskontrolle, Übertragungswiederholung 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 SDPClient 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 bekannt sind, kann nach einem spezifischen Protokoll eine Verbindung zu einem Dienst aufgebaut werden [25]. Am Server sind die Service Records in einer Datenbank zusammengefasst. Ein Service Record fasst verschiedene Attribute eines Dienstes zusammen. 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 ServiceTyp. Eine Protokoll-Liste beschreibt die zur Verwendung nötigen ProtokollSchichten. 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 ursprüngliche Anforderung, bestehende Kabelverbindungen ersetzen zu können. RFCOMM baut auf dem ETSI14 -Standard TS 07.10 [6] auf, einem Multiplexing-Protokoll für Telefonie- und Datendienste. Von RFCOMM wird aber nur ein Bruchteil von TS 07.10 implementiert und Bluetooth-spezifische Erweiterungen 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 mehrere 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 EIA23215 -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-232Verbindung) zu einem Endgerät. Der Bluetooth-Gateway wird als Typ 2 bezeichnet. Mit diesem Typ der Verbindung können Geräte mit Kabelverbindung 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 Kommunikationssystems. Es wurde von der International Standard Organization standardisiert. Das OSI-Modell basiert auf sieben Schichten, wovon jede eine 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 miteinander, 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 Protokollen 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 aufsetzt und einen Transport von Netzwerkpaketen ermöglicht [2]. Abbildung 3.2 stellt einen Bluetooth-Protokollstapel mit aufgesetzter IPProtokollfamilie und eine mögliche Zurdnung zu den Schichten im OSIReferenzmodell dar. Im folgenden werden die untersten Schichten des OSIReferenzmodelles mit den Kernprotokollen von Bluetooth verglichen. 2

Internet Protocol Point to Point Protocol 4 Bluetooth Network Encapsulation Protocol 3

3. Bluetooth im OSI-Referenzmodell

3.1

25

Bitübertragungsschicht

Die Bitübertragungsschicht beschreibt die bitweise Übertragung von Informationen über ein physikalisches Medium. Dazu gehört die elektrische und mechanische Spezifikation des Übertragungsmediums [10]. Bei Bluetooth entspricht das der Funkschicht, also der Basisbandübertragung 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 Datenrahmen. Die Daten werden durch Prüfsummen abgesichert, um Übertragungsfehler 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 einem ausgedehnten Netzwerk und leitet Datenpakete über mehrere Netzwerkknoten weiter (Routing). In den Bluetooth-Kernprotokollen findet sich dazu keine Entsprechung. Dies ist auch nicht nötig, weil durch die Netztopologie von Bluetooth normalerweise keine Kommunikation über mehrere Knoten stattfindet. Eine Ausnahme ist das sogenannte Scatternetz. Hier nimmt ein Bluetooth-Gerät wechselweise an zwei Pikonetzen teil. Der BluetoothStandard 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 einsetzen, können ihre eigene Vermittlungsschicht mit sich bringen. 5 6

Media Access Control Logical Link Control

3. Bluetooth im OSI-Referenzmodell

3.4

26

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. Dabei wird eine Vermittlungsschicht angenommen, in der Paketverluste auftreten 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 Systemen. 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 Anwendungsschicht stellt Dienstleistungen zur transparenten Übertragung von Informationen zur Verfügung, die von den technischen Details vollständig abstrahiert sind [10]. Bei Bluetooth werden diese Schichten in der Anwendung zusammengefasst [25].

Kapitel 4

Bluetooth-Profile Bluetooth umfasst die Kernspezifikation [4] und optional zu implementierende Protokolle [2]. Weiters setzen darauf adaptierte Protokolle auf. Insgesamt 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 Kosten 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 verwirklichen, definiert Bluetooth Profile [1]. Ein Profil beschreibt, welche Protokolle und Fähigkeiten ein Gerät implementieren 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 (Abbildung 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 4.1.1

Grundlegende Profile GAP – Generic Access Profile

Das GAP ist die Grundlage für alle anderen Profile. Es spezifiziert die Voraussetzungen und eine Anwendungsschnittstelle für allgemeine Prozeduren [25]. Damit werden die Funktionen von Link Manager und L2CAP zur Verfügung gestellt. Es ermöglicht die Erkennung von Geräten, Verbindungsaufbau 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

4.1.2

29

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 Kabelverbindungen genutzt wird. Wie aus Abbildung 4.2 ersichtlich, basieren viele andere Profile darauf. SPP definiert eine Schnittstelle, um eine Verbindung 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 komplexen Objekten. Damit können Dateien über Rechner- und Betriebssystemsgrenzen 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 eines 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 2

Object Exchange Audio/Video Distribution Transport

4. Bluetooth-Profile

30

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

A2DP AVRCP BIP BPP

Advanced Audio Distribution Profile Audio/Video Remote Control Profile Basic Imaging Profile Basic Printing Profile

CTP

Cordless Profile

DI

Device ID Profile

DUN FAX

Dial-Up Networking Profile Fax Profile

FTP

File Transfer Profile

HFP

Hands-Free Profile

HCRP HSP

Hardcopy Cable Replacement Profile Headset Profile

HDC

Health Device Profile

HID

Human Interface Device Profile Intercom Profile

ICP

Telephony

OPP PAN

Object Push Protocol Personal Area Networking Protocol

SAP

SIM Access Profile

SYNC

Synchronization Profile Video Distribution Profile

VDP

Übertragung eines hochwertigen AudioDatenstroms in Stereo oder Mono Steuerung von Audio/Video-Equipment Übertragung von Bilddateien Drucken von verschiedenen Dokumentenformaten Profil für ein universelles Schnurlostelefon, das sich sowohl mit Mobilfunk als auch einer Festnetz-Basisstation nutzen lässt Identifikation von Geräten auf Basis von Hersteller und Produktbezeichnung Nutzung von Modem-Diensten über Bluetooth Nutzung von Fax-Diensten über Bluetooth Anzeigen, Verwalten und Ändern der Dateien in einem Verzeichnis Audio-Übertragung und Anrufsteuerung für Freisprecheinrichtungen Ersetzt Kabelverbindungen von Druckern und Scannern Vollduplex-Übertragung von qualitativ hochwertigen Audiodaten Übertragung von Sensordaten im Fitnessund Medizin-Bereich Übertragung von Daten von Eingabegeräten Sprechverbindungen zwischen BluetoothGeräten (Walkie-Talkie) Dateien an andere Geräte senden Ermöglicht mit Hilfe von BNEP den Transport von Paketen verschiedener Netzwerkprotokolle Zugriff auf die SIM-Karte eines Mobiltelefons über Bluetooth, nützlich für Freisprecheinrichtungen im Auto Synchronisation von PIM-Daten wie Telefonbucheinträgen oder Visitenkarten Übertragung von Videosignalen

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 Funktechnologien. Die extrem geringe Reichweite von etwa 10 Zentimetern ist die Basis von Anwendungsparadigma und Sicherheitskonzept. Eine Verbindung wird einfach dadurch hergestellt, dass Sender und Empfänger in Reichweite gebracht werden. Dadurch entsteht für den Benutzer ein intuitives Anwendungskonzept: „Touch And Go“. Gleichzeitig wird das unerwü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 Daten, indem sie das Feld des Kommunikationspartners abschwächen (Lastmodulation). 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 Datenmengen 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-Technologie zu spezifizieren und zu verbreiten. Mittlerweile hat das NFC-Forum 150 Mitglieder [24]. In Tabelle 5.1 werden NFC und Bluetooth verglichen. Durch die grundlegend verschiedenen Eigenschaften ist NFC keine Konkurrenz zu Bluetooth. Die unterschiedlichen Frequenzbänder ermöglichen einen störungsfreien Betrieb von Bluetooth und NFC zur gleichen Zeit. NFC bietet die Möglichkeit, die Pairing-Prozedur von Bluetooth zu vereinfachen, indem NFC als Out-ofBand -Übertragungsmedium genutzt wird. Zum Herstellen einer Bluetooth1

Radio Frequency Identification

31

5. NFC für Bluetooth

32

Tabelle 5.1: Vergleich zwischen Bluetooth und NFC [7]

Netzwerk-Konfiguration Reichweite Frequenz Datenrate Set-Up-Zeit Sicherheit Kommunikationsmodi

NFC Peer to Peer 10 cm 13,56 MHz bis 424 kBit/s kleiner 0,1 s Hardware, Protokoll aktiv-aktiv, aktiv-passiv

Bluetooth Point to Multipoint 10 m bis 100 m 2,4 GHz bis 2,1 MBit/s ca. 6 s Protokollebene 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 Eigenschaften von kontaktlosen Chipkarten. Die Kommunikation erfolgt über Ringspulen, die über ein magnetisches Feld per Induktion (aktiv) oder Lastmodulation (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 On-Off Keying 4 Biplorar Shift Keying 5 Non-Return to Zero – Level 3

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 Interface and Protocol (NFCIP) beschrieben. Es definiert aktive und passive Kommunikationsmodi, 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 definiert. 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 Datenrate von bis zu 424 kBit/s gelesen und geschrieben werden [21]. Neben dem aktiv/passiven-Kommunikationsmodus nach ISO/IEC 14443 ermö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. NDEFNachrichten 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 0x02 0x03 0x04

NFC-Forum: wohlbekannter Typ MIME-Typ Absolute URI NFC-Forum: externer Typ

mehrere unabhängige Sätze Anwendungs-spezifischer Nutzdaten von beliebiger 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 optionalen 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-spezifischen Typenbezeichner gegeben sein. Das Feld Type Name Format (TNF) gibt über den verwendeten Typenbezeichner Auskunft. NFC-spezifische Ty6 7

Uniformal Resource Identifier, eine Zeichenfolge zur Identifizierung einer Ressource 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 NFCspezifischen Typenbezeichnungen. In Tabelle 5.2 sind die gültigen Werte für das Feld TNF aufgelistet. Der optionale Bezeichner ermöglicht eine Identifikation einzelner Nachrichten 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 Handover 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 Handover zum Einsatz. Der Handover Requester sendet einen Handover Request an den Handover Selector. Der Handover Request stellt eine Liste der alternativen Kommunikationsmedien dar, über die der Handover Requester verfügt. Der Handover Selector vergleicht die empfangene Liste mit den für ihn verfü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 Handover 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-SelectNachricht dynamisch generieren. Ein vorgefertigter Handover Select ist statisch auf der Karte abgelegt. Durch die fehlende Verbindung zum HostProzessor 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 aufgebaut. Die NDEF-Nachrichten beginnen mit einem Handover Request Record oder einem Handover Select Record. Diese haben den externen Typenbezeichner „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 Kommunikationsmedium 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 Verbindung enthalten können.

5.3.4

Carrier Configuration Record für Bluetooth

Um Bluetooth-Geräte sicher miteinander zu verbinden, definiert die Bluetooth-SIG mehrere Pairing-Methoden [4]. Eine davon ist die Übertragung von Geräteeigenschaften und kryptographischen Daten über ein Out-OfBand -Kommunikationsmedium wie NFC. Zur Übertragung dieses OOB-Datenblocks wird vom NFC-Forum das Format 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 PairingMachanismus ü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 erzeugten 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 Algorithmus wird daraus wiederum eine Antwort, bestehend aus einem neuen P und C, generiert. 5. Die Antwort wird zusammen mit der eignenen Geräteadresse als Handover 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üsselaustausch 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 kompromittieren. Die Sicherheit des OOB-Pairings mit NFC beruht daher auf der Immunität von NFC gegenüber Man-In-The-Middle-Angriffen. Ein ManIn-The-Middle-Angriff ist bei NFC zwar prinzipiell denkbar, durch die geringe 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. bielefeld.de/~heiko/bluetooth/bluetooth.pdf.

www.rvs.uni-

[10] International Standard Organization: ISO 7498-1: Open Systems Interconnection - Basic Reference Model, Nov. 1994. http://www.iso.org/ iso/iso_catalogue.htm (kostenpflichtig). [11] International Standard Organization: ISO/IEC 18092: Near Field Communication – Interface and Protocol (NFCIP-1), 2004. http://www.iso. org/iso/iso_catalogue.htm (kostenpflichtig). [12] International Standard Organization: ISO/IEC 21481: Near Field Communication Interface and Protocol -2 (NFCIP-2), 2005. http://www.nfcforum.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. //www.nfc-forum.org/specs/.

http:

[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. forum.org/specs/.

http://www.nfc-

[21] NFC-Forum: Type 4 Tag Specification, März 2007. forum.org/specs/.

http://www.nfc-

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