Bluetooth -...

Prof. Dr. W. Kowalk Rechnernetze II Seite 1

BluetoothBluetooth

Bluetooth


BluetoothBluetooth

Von Ericsson initiiertSIG (Special Interest Group) große Hersteller

IBM, Microsoft Siemens AG

Anwender Volkswagen DaimlerChrysler


BluetoothBluetooth

In verschiedenen Standards festgelegtURLhttp://www.bluetooth.com/dev/specifications.asphttps://www.bluetooth.org/foundry/adopters/document/Bluetooth_Core_Specification_v1.2

Kernstandard mit über 1000 Seiten Reihe weiterer Standards, u.a.

Network Encapsulation ProtocolIP, IPv6, IPX usw. über Bluetooth


BluetoothBluetooth

Core StandardTeil A: FunkspezifikationTeil B: Basisbandspezifikation

Link-ControllerBasisbandprotokolleandere elementare Link-Routinen

Teil C: Linkmanager-Protokoll (LMP)VerbindungsaufbauVerbindungskontroll


BluetoothBluetooth

Core StandardTeil D (L2CAP): LOGICAL LINK CONTROL AND ADAPTATION PROTOCOL SPECIFICATION

Multiplexen von höheren ProtokollenPaketsegmentierung und ReassemblierungÜbermittlung der Dienstequalität-InformationZustandsmaschinePaketformate und -aufbauTestschnittstelle

Bluetooth Test- und Zertifizierungsprogramm


BluetoothBluetooth

Core StandardTeil E: Service Discovery Protocol (SDP)

Lokalisierung von Diensten von/über Bluetooth-Geräte

Teil F: Schnittstellen zuseriellen BausteinenIrDATelefon WAP-Diensten


BluetoothBluetooth

Core StandardTeil H: technische Schnittstellen wie

HCI, USB, UART oder RS232

Teil I: Testumgebungen Übereinstimmungsprüfungen mit Standard (Compliance)


BluetoothBluetooth

Core Standard


BluetoothBluetooth

Radio Specification2,4 GHh ISM-Band (Industrial, Scientific, Medicine)

2.400 MHz bis 2.485,5 Mhzunteres Grenzband von 2 Mhzoberes Grenzband von 3,5 MHz

78 Nutzbänder von 1 MhzFrequenz-Hopping

in einigen Ländernkleinere BandbereichJapan, Frankreich, Spanien

verschiedene SendeleistungsklassenSendeleistung in Klasse 1: 100 mW,anpassbarSendeleistung in Klassen 2 und 3: ca. 1 mW


BluetoothBluetooth

BasisbandspezifikationFunkverbindung mit kurzen Reichweiten

Kabel ersetzen zwischen portablen elektronischen Gerätenfest installierten elektronischen Geräten

hohe Zuverlässigkeit hohe geringe Komplexität, hohe Leistung hohe Kosten


BluetoothBluetooth

BasisbandspezifikationISM-Band bei 2,4 GhzFrequenzsprung, binäre Frequenzmodulation

sollen Interferenzen und Komplexität verringernSymbolrate: 1 Ms/sSlotted-Channels mit Slot-Länge von 625 µsDuplexverbindungen mit TDD (Time Division Duplex)

Daten in Paketen übertragenJedes Paket mit anderer Hop-Frequenzi.d.R. ein Paket je Slot● bis zu fünf Slots bei langen Paketen


BluetoothBluetooth

BasisbandspezifikationKombination aus Leitungs- und Paktvermittlung

synchrone DatenkanalZeitschlitze reservierenbis zu drei synchrone Sprachdatenkanäle64 kb/s Sprachkanal in jeder Richtung

asynchroner Datenkanalbis zu 723,2 kb/s asymmetrisch (bis zu 57,6 kb/s in Gegenrichtung) 433,9 kb/s symmetrisch


BluetoothBluetooth

BasisbandspezifikationBluetooth-System besteht aus

einer Funkeinheit, Linkkontrolleinheit Unterstützungseinheit für

Linkmanagement Host-Terminal-Schnittstellenfunktionen


BluetoothBluetooth

BasisbandspezifikationPunkt-zu-Punkt-Verbindung

zwei Bluetooth-Geräte involviert

Punkt-zu-Mehrpunkt-VerbindungKanal zwischen mehreren Bluetooth-Einheiten aufgeteiltPiconet

ein Master des Piconetsanderen Einheiten Slavesbis zu sieben Slavesweitere Slaves durch Master in Parkzustand blockiertKanalzugriff durch Master


BluetoothBluetooth

BasisbandspezifikationScatternet

mehrere Piconets mit überlappendem Bereichje Piconet genau ein Master Slaves in verschiedenen PiconetsMaster in einem Piconet, Slave in einem anderen Piconet Piconets nicht frequenzsynchronisiert jedes Piconet hat eigenen Hopping-Kanal


BluetoothBluetooth

Physikalischer KanalKanaldefinition

Pseudozufallsfreqenzsprungverfahren 79 oder 23 FrequenzenSprungfolge für Piconetz eindeutig durch Bluetooth-Geräteadresse des Masters bestimmtPhase der Sprungfolge durch Bluetooth-Clock des Masters festgelegtKanal in Zeitschlitze unterteiltjeder Zeitschlitz entspricht einer Sprungfrequenzaufeinanderfolgende Sprünge entsprechen verschiedenen Frequenzennominale Sprungrate ist 1600 hops/sEinheiten je Piconet zu Kanal zeit- und sprungsynchronisiert


BluetoothBluetooth

Physikalischer KanalZeitschlitze

Zeitschlitze mit jeweils 625 µs LängeZeitschlitze nummeriert nach Clock des Piconetz-Masters

Slot-Nummer reicht von 0 bis 227-1 Zykluslänge von 227 je Zeitschlitz können Master und Slave Pakete übertragen

TDD-Schema Master und Slave senden alternierendMaster sendet nur in gerade nummerierten ZeitschlitzenSlave sendet nur in ungerade nummerierten Zeitschlitzen


BluetoothBluetooth

Physikalischer KanalZeitschlitz

TDD-Schema Paketstart beginnt mit ZeitschlitzstartPakete dürfen bis zu fünf Zeitschlitze überdeckenSprungfrequenz während der Dauer einer Übertragung festaus gegenwärtigem Wert der Bluetooth-Clock abgeleitet● mehr als einen Zeitschlitz● Sprungfrequenz aus erstem Zeitschlitz des Pakets berechnet,

während der Übertragung dieses Pakets unverändert● danach Sprungfrequenz wieder nach absoluter Clock


BluetoothBluetooth

Physikalische Verbindungen (Links)verschiedene Verbindungstypen

Synchrone verbindungsorientierte Verbindung(Synchronous Connection-Oriented: SCO)Asynchrone verbindungslose Verbindung(Asynchronous Connectionless: ACL)

SCO-VerbindungPunkt-zu-Punkt-Verbindung Master – Slave in Piconetreservierte Slots in regelmäßigen Intervallen


BluetoothBluetooth

Physikalische Verbindungen (Links)ACL-Verbindung

Punkt-zu-Mehrpunkt-Verbindung zwischen Master und sämtlichen Slaves im Piconet in nicht für SCO-Verbindungen reservierten SlotsACL-Verbindung auf Pro-Slot-Basis zu jedem Slaveauch mit SCO-Verbindung


BluetoothBluetooth

Physikalische Verbindungen (Links)SCO LINK

symmetrische Punkt-zu-Punkt-Verbindungzwischen Master und spezifischem SlaveSCO-Verbindung reserviert Zeitschlitze ● leitungsvermittelte Verbindung zwischen Master und Slave

typischerweise zeitkritische Dienste wie SpracheMaster● bis zu drei SCO-Verbindungen gleichzeitig● zu gleichen oder verschiedenen Slaves

Slave● bis zu drei SCO-Verbindungen zu gleichem Master● zwei SCO-Links zu verschiedenen Mastern

SCO-Pakete werden niemals wiederholt


BluetoothBluetooth


SCO-Intervall TSCO (in Schlitzen gezählt)regelmäßige Abständereservierte Master-zu-Slave-ZeitschlitzenSCO-PaketeSCO-Slave sendet SCO-Packet in folgendem Slave-zu-Master-Slot● außer wenn andere Slave in vorhergehendem Master-zu-Slave-

Zeitschlitzen adressiert● auch wenn Slave-Adresse nicht dekodierbar


BluetoothBluetooth


SCO-Verbindung wird von Master aufgebautSCO-Verbindungsaufbau-Nachricht im LM-Protokoll gesendet● Timing-Paramter wie

● SCO-Interverall TSCO ● Offset-DSCO, spezifiziert reservierte Zeitschlitze ● Initialisierungsprozedur 1 oder 2

● Uhr-Überlaufprobleme


BluetoothBluetooth

Physikalische Verbindungen (Links)ACL LINK

nur in nicht für SCO-Verbindungen reservierten Slots Master kann Pakete mit jedem aktiven Slave austauschenpaketvermittelte Verbindungennur eine einzige ACL-Verbindung je Slavesynchrone, isochrone DiensteACL-Pakete wiederholt zur Datenintegrität (ARQ)Slave antwortet nur in FogleschlitzBroadcast-Paketesonst keine Übertragung


BluetoothBluetooth

PaketformateStandardformat

72 Bits Zugriffscode (acces code)54 Bits Header0-2745 Bits Nutzdatenmit kleinstem Bit zuerst gesendet

Pakete können bestehen aus(verkürztem) ZugriffscodeZugriffscode plus Headerallen drei Teilen


BluetoothBluetooth

PaketformateZugriffscode

Preamble 4 Bits LängeTrailer 4 Bits LängeSYNC-Word

kodiert Adresse


BluetoothBluetooth

PaketformateHeader

Verbindungskontrolle (LC: Link Control) AM_ADDR: 3- bit active member address● Identifiziert Slave in Piconet ● beim Senden vom Master und Slave verwendet● 0 ist Broadcastadresse (außer FHS)● geparkter/abgemeldeter Slave verliert Adresse

TYPE: 4-bit type code● Typ eines Pakets● hängt von Verbindungstyp (SCO, ACL) ab

FLOW: 1-bit flow control● Flusskontrolle (FLOW=0: keine weiteren Paketen senden) ● nur für ACL-Verbindungen


BluetoothBluetooth

PaketformateHeader

Verbindungskontrolle (LC: Link Control) (ff.)ARQN: 1-bit acknowledge indication● positive (ARQN=1) oder negative Quittung (ARQN=0)

SEQN: 1-bit sequence number● Alternierende Nummerierung von Blöcken● mit CRC-Prüfsumme

HEC: 8-bit header error check● Header Error Correction-Prüfsumme für Header

HEC = 1101001112


BluetoothBluetooth

PaketformateHeader

Header besteht aus 18 BitsFehlerkorrekturverfahren (1/3 FEC)● sendet jedes Bit dreimal● insgesamt 54 Bits

nicht kontinuierliches ARQ-Verfahren mit alternierender Paketnummer● Empfänger kann mehrfach gesendete CRC-Blöcke unterscheiden● Sender muss auf ACK warten, ehe weiteres Paket senden


BluetoothBluetooth

PaketformateHeader

16 TypfelderVier für SCO- und ACL-VerbindungenNULL- Paket, POLL-Paket● Zustandsinformation

● Quittung (ARQN) ● Flusskontrolle

ID-Paket ● Anfrage ● Antworten


BluetoothBluetooth

PaketformateHeader

16 TypfelderFHS-Paket● spezielles Kontrollpaket● Bluetooth-Geräteadresse ● Clock des Senders


BluetoothBluetooth

PaketformateHeader

16 TypfelderSCO-Pakete besitzen kein CRC● zeitkritische Dienste wie Sprachübertragung● niemals wiederholt● einzelne Fehler hinnehmbar● unterschiedliche Datenrate

ACL-Pakete besitzen meistens CRC-Feld● wertekritische Daten● zusätzlich FEC (Forward Error Correction)● Daten sehr sicher übertragbar● ohne positive Quittung bei ACL-Paket mit CRC-Feld wird dieses

wiederholt


BluetoothBluetooth

Fehlerkorrekturdrei Fehlerkorrekturverfahren:

1/3 rate FECJedes Bit wird dreimal direkt hintereinander gesendetbei allen Headern und bei einem Sprachdienst verwendetbei einem Bitfehler korrekter Wert berechenbar: Entscheider (arbiter)

2/3 rate FEC15 Bit-Hammingverfahren● zu 10 Bits ein 5 Bit-Rest (Generator = 1101012)● Empfänger kann

● 1 Bit-Fehler korrigieren ● 2 Bit-Fehler erkennen


BluetoothBluetooth

Fehlerkorrekturdrei Fehlerkorrekturverfahren:

ARQ-Verfahren für Datennur bei gesicherten DatenpaktenSende- und Warte-ARQQuittung direkt im nächsten Slot nach DatenpaketWartezeit in der Regel geringmehrfach gesendete gleiche Pakete vom Empfänger unterscheidbar

Flushingsendet auch im Fehlerfall folgenden Datensatzbei zeitkritischen Daten notwendig● isochrone Daten● Befehle zum Steuern mechanischer Geräte


BluetoothBluetooth

FehlerkorrekturBroadcast-Nachrichten

können nicht quittiert werden sämtliche Broadcast-Nachrichten werden mehrfach gesendet

Fehlererkennung mit CRC-Verfahren

CCITT-CRC-Generatorpolynom G(D)=D16+D12+D5+D0==10001000000100001.Register mit speziellem Anfangswert initialisiert(UAP: upper address part)


BluetoothBluetooth

Logische KanäleLC control channel

Kontrollinformation ● ARQ● Flusskontrolle ● Nutzdatentyp● im Header der Pakete transportiert● in jedem Paket (außer ID-Paket)

LM control channelKontrollinformation zwischen Linkmanagernin DM-Paketen transportiert


BluetoothBluetooth

Logische KanäleUA user channel

asynchrone Nutzdatensichere Datenübertragung durch FEC und ARQPayload-Header● L_CH-Feld auf 102 (Start eines Fragments) ● L_CH-Feld auf 012 (Folgefragment)

UI user channelisochrone Nutzdatenwie UA auf der Baseband-Schichtinnerhalb einer bestimmten Zeit beim Empfänger eintreffen


BluetoothBluetooth

Logische KanäleUS user channel

synchrone Nutzdatenkein ARQ-Verfahrenoptional eines von mehreren Fehlerkorrekturverfahren verwendetin SCO-Paketen transportiert


BluetoothBluetooth

Senden und EmpfangenSende und Warte-ARQ-Verfahren

Master sendet DatenQuittung im nächsten Slot des SlavesMaster kann nächstes Paket sendenoder das vorherige Paket wiederholenalternierende Zähler unterscheidet gleiche PaketeNULL-Paket, wenn keine Daten gesendet werden● nur Kontrolldaten (ACK, NACK, Flusskontrolle)

Synchrone Datennur in bestimmten Zeitschlitzen gesendetbeim Verbindungsaufbau ausgehandelt nicht durch ARQ-Verfahren geschütztkeine Quittung


BluetoothBluetooth

Senden und Empfangenin einem Paket synchrone und asynchrone Daten (DV - data, voice)negative oder keine Quittung ● gleiche asynchrone, neue synchrone Nutzdaten

FlusskontrolleSenden eines STOP-Bits vom EmpfängerSender bewahrt letztes Datenpaket sendet NULL-Pakete, bis GO-Bit eintrifftkein Paket wird implizit als GO interpretiertfür jeden Slave unabhängig


BluetoothBluetooth

Senden und EmpfangenStandard empfiehlt

synchrone und asynchrone Daten in unterschiedlichen Puffern speichernfür jeden Link einen Puffer vorsehen● in Hardware umsetzbar

Kontrolldaten zunächst gescrambelt (Whitening)● möglichst zufällige Bitfolgen erzeugen● nach der HEC-Erzeugung ● vor der FEC

Nutzdaten gescrambeltandere Operationen optional ● z.B. Verschlüsselung,


BluetoothBluetooth

Timingausschließlich durch Clock des Masters sämtliche Slaves synchronisieren sich an Master

jedes Mal, wenn Master Paket an irgendeinen Slave sendetmaximale Abweichungen

hängen von der Genauigkeit der lokalen Uhren abMaster sendet unter gewissen Umständen eine Zeitlang nichtAbweichungen können teilweise angepasst werden


BluetoothBluetooth

ScatternetGruppe von Piconets, zwischen deren Einheiten Verbindungen bestehen

Mehrere Piconets können gleichzeitig existierenSlave kann in mehreren Piconets seinStation kann nur in einem Piconet Master sein

Master bestimmt Hopfolge Timer 'seines' Piconets sämtliche partizipierenden Slaves liegen im gleichen Piconet

jedes Piconet eigene HopfolgeWahrscheinlichkeit einer Kollision relativ geringKollision aber nicht ausgeschlossen


BluetoothBluetooth

ScatternetMaster 'paged' Master oder Slave in anderem Piconet

Einheit in einem Piconet keine eine in anderem Piconet pagendiese Station wird zum Master u.U. Vertauschung der Master-Slave-Rollen notwendig

Station will in anderem Piconet teilnehmen wechselt in Hold- oder Parkmodus kann auch im Sniff-Modus sein und entsprechend Zeit partizipierensynchrone Verbindung kann aufgrund Phasenverschiebung nur in der Hälfte der Slots eines anderen Piconets sendenin der Regel für jedes Piconet eigene Clock unterhalten


BluetoothBluetooth

Power Managementmöglichst geringe Leistungsaufnahme der Einheiten

Paketbearbeitung minimiert● nur nützliche Daten gesendet

● NULL-Pakete, wenn Quittungen zu senden sind● kein explizites NAK, da implizit ● Daten nur in der notwendigen Länge gesendet● Empfänger liest fremde Daten nicht weiter● ungültiges HEC beendet Empfang

● Daten über mehrere Slots abwarten, ehe Slave wieder liest● verschiedenen Betriebsmodi minimieren Leistungsverbrauch

● Sniff● Hold ● Park


BluetoothBluetooth

Kanalkontrolle (Channel Control)baut Piconet auffügt Einheiten hinzu bzw. entfernt diese aus Piconet

eine Station muss als Master ausgewählt werdenerste Station, die Verbindung aufbauen will, wird Masterim Prinzip jede Station als Master auswählbar

alle Stationen identische FunktionalitätenMaster bestimmt durch Polling, welcher Slave senden darf. Piconet durch Bluetooth-Adresse des Masters spezifiziertaus Adresse wird gemeinsame Hopfolge bestimmt


BluetoothBluetooth

Kanalkontrolle (Channel Control)Master muss seine Slaves finden

verschiedene Sendefrequenzen abfragen und abhorchen Hopfolge erst starten, wenn sich Slave(s) gemeldet habenClock des Piconets ebenfalls vom Master vorgegebenLink Supervision

mittels spezieller Timer wird überprüft, ob Kanal noch in Betrieb


BluetoothBluetooth

Kanalkontrolle (Channel Control)Zustände

2 Hauptzustände (Standby und Connection) 7 Unterzustände (Aufnahme neuer Einheiten in Piconet)

STANDBY STATE● Defaultzustand● nur die Clock läuft● Zustand verlassen

● zum Erlauschen von Page- oder Anfragenachrichten● Page-Anfrage

● Station geht in den Connectionstate als Slave● Page-attempt

● Connectionstate als Master


BluetoothBluetooth


PAGE SCAN● Slave versucht auf PAGE-Signal des Master zu reagieren● unterschiedliche Frequenzen (Hop-Frequency)

● komplexes Problem● horcht längere Zeit auf einzelnen Frequenzen, bis Master-

Frequenz gefunden● synchronisieren

PAGE● Master sucht nach Slave, dessen Adresse er kennt● Sendet auf unterschiedlichen Hop-Frequenzen in kurzen

Abständen● jeweiligen Slave möglichst schnell finden und synchronisieren


BluetoothBluetooth


Master Response und Slave Response● Master und Slave tauschen Anfangswerte aus ● beginnen mit geordnetem Datenaustausch● wechseln in Connection-Zustand

INQUIRY● sämtlich erreichbaren Einheiten abfragbar● insbesondere deren Funktionalitäten (Drucker, Fax, Telefon etc.)

INQUIRY-SCAN● abfragen, ob Einheit einen INQUIRY-SCAN vollführt ● entsprechend reagieren


BluetoothBluetooth


INQUIRY-Response● zu erkanntem Gerät Verbindung aufgebaut ● danach in Connection-Zustand gewechselt

Connection-State ● normale Datenübertragung

● als erstes wird POLL-Paket gesendet● Slave kann sich synchronisieren

● dann Kontrollinformation über Art der Verbindung ● durch Detach- oder Reset-Kommando wieder verlassen


BluetoothBluetooth

BetriebsmodiVier Betriebsmodi im Connection-State

Active ModeEinheit sendet DatenMaster teilt Slaves Zeitschlitze zuSlaves horchen, ob Paket für sie bestimmtSlave darf nicht senden, wenn Master längere Datenpakte überträgt ● an Typ des Pakets erkennbar


BluetoothBluetooth

BetriebsmodiSniff Mode

Master / Slave überprüfen nur in bestimmten Slots, ob Pakete für sie vorliegenSlave weniger aktiver ZustandAbstände zu Beginn ausgehandeltSlave kann evtl. Verbindung zu einem anderen Piconet aufbauen

Hold ModeSlave kann keine asynchronen (aber synchrone) Daten empfangenin Ruhezustand● beispielsweise anderem Piconet anschließen

Zeit zwischen Master und Slave vereinbartSlave behält dynamische Adresse: Active Member Address (AM_ADDR)


BluetoothBluetooth

BetriebsmodiPark Mode

Station kann keine Daten mehr empfangenStation verliert dynamische Adresse

erhält Parkadresse (PM_ADDR)mehr als sieben Slaves von einem Master in Piconet verwaltbarSlave wacht regelmäßig auf und prüft auf Broadcast-MessagesResynchronisation mit Master durch speziellen Beacon-Prozess


BluetoothBluetooth

Pollingaktiver ModusMaster hat vollständige Kontrolle über Piconet

Slaves dürfen nur asynchron sendenasynchron: wenn in vorhergehendem (Master-zu-Slave) Slot ihre dynamische Adresse genannt wurdebei der synchronen Übertragung in vorher vereinbarten Slorts● außer in vorhergehendem Zeitschlitz wurde explizit anderer

Slave adressiert.

ParkmodusSlaves dürfen nur nach Broadcastnachricht Zugrifssanforderung senden


BluetoothBluetooth

Link Management Protocol LMVerwendung

VerbindungsaufbauSicherheit Überwachung

Nutzdaten in Link Control Protocol reservierter Wert in L_CH-Feld (logischen Kanalfeld) Nachrichten werden ausgefiltertdurch Link Management des Empfängers interpretiertnicht an höhere Schichten weitergeleitet


BluetoothBluetooth

Link Management ProtocolLink Management-Nachrichten

höhere Priorität als BenutzerdatenLM-Nachrichten nicht durch Link Control-Protokoll verzögert Verzögert durch wiederholtes Senden individueller Baseband-Pakete


BluetoothBluetooth

Link Management ProtocolLink Management-Nachrichten

Link Control-Protokoll garantiert zuverlässigen Übertragungsdienst● keine expliziten Quittungen für LMP-Nachrichten nötig

garantiert keine Übertragungszeit für Nachricht oder QuittungZustandswechsel zwischen Master und Slave synchronisieren● Wiederverwendung der Adresse eines geparkten Slaves● auch Master-Clock (LM von LC)

LC garantiert kommuniziert mit jedem Slave einmal innerhalb eines Tpoll-Zeitschlitzs Zeit zwischen Empfang und Senden einer LMP-PDU und deren Antwort bis zu 30 s


BluetoothBluetooth

Logical Link Control and Adaptation Protocol (L2CAP)

oberhalb des Baseband-Protokolls innerhalb der Sicherungsschicht (Data Link Layer)

verbindungsorientierte und verbindungslose DatendiensteMultiplexen höherer Protokolle Segmentierungs- und ReassemblierungsfunktionenDatenpakete bis zu 64 kilobit Länge für höhere Schichten


BluetoothBluetooth

Logical Link Control and Adaptation Protocol (L2CAP)

Reassemblierung


BluetoothBluetooth

Service Discovery Protocol (SDP)findet verfügbare Dienste

Bestimmt deren Charakteristika

Dienste können wechselndrahtlose Umgebung

sehr schnell und häufig Diensteerkennung qualitativ anspruchsvoller SDP soll diesen Anforderungen genügen


BluetoothBluetooth

Service Discovery Protocol (SDP)

ServiceClassIDList Identifies the type of service represented by a service record. In otherwords, the list of classes of which the service is an instance

ServiceID Uniquely identifies a specific instance of a service

ProtocolDescriptorList Specifies the protocol stack(s) that may be used to utilize a service

ProviderName The textual name of the individual or organization that provides a service

IconURL Specifies a URL that refers to an icon image that may be used to representa service

ServiceName A text string containing a human-readable name for the service

ServiceDescription A text string describing the service


BluetoothBluetooth

Serial Port Emulation (RFCOMM)emuliert seriellen Port über L2CAP-Protokoll

ETSI-Standard TS 07.10verwendet nur Teilmenge dieses Standards

Bluetooth spezifische Adaptionen und Erweiterungen z.B. kreditbasiertes Flusskontroll-Schema


BluetoothBluetooth

Sicherheit in BluetoothBluetooth stellt zur Verfügung

Schutz der Dienstnutzung Vertraulichkeit

sämtliche Authentifizierungs- und Verschlüsselungsroutinen auf gleiche Weise implementiert● Herstellerunabhängigkeit

Für die Sicherheit auf dem Link Layer werden vier Zahlen verwendet:


BluetoothBluetooth

Sicherheit in BluetoothFür Sicherheit auf Link Layer 4 Zahlen verwendet

Bezeichnung Größe in Bits Bedeutung

BD_ADDR: Bluetooth device address 48 Bits Eindeutige Benutzerkennung; dieses istkein geschützter Wert

Privater Benutzerschlüssel zurAuthentisierung 128 Bits

Geheimer Schlüssel zur Authentisierungeines Benutzers

Privater Benutzerschlüssel zurVerschlüsselung

8, 16, ..., 128 Bits Geheimer Schlüssel zur Verschlüsselungvon Benutzerdaten

RAND 128 BitsZufallszahl, die für jede Transaktionverschieden ist


BluetoothBluetooth


geheimen Schlüssel werden bei Initialisierung erzeugtVerschlüsselungsschlüssel aus Authentisierungsschlüssel abgeleitet (Linkkey) ● häufiger geändert

Schlüsselgröße zur Authentisierung ist festfür (optionale) Verschlüsselung konfigurierbare Schlüsselgröße● gewisse rechtliche Regelungen ● mögliche Erweiterbarkeit in der Zukunft

Verschlüsselungsschlüssel völlig unabhängig vom Authentisierungsschlüssel● auch wenn aus diesem generiert

Jede neue Aktivierung der Verschlüsselung sollte (optional) neuen Verschlüsselungsschlüssel generieren


BluetoothBluetooth


RAND ist Zufallszahlvon zufälligem Prozess erzeugt odervon Pseudozufallszahlengenerator-Prozess erzeugt ändert sich häufig


BluetoothBluetooth

Sicherheit in BluetoothSchlüsselverwaltung

Linkkey zur Authentisierung zwischen zwei oder mehr Stationen

semi-permanenter Linkkey ● über mehrere Sitzungen (d.h. in mehreren Piconetzen) gleich ● in nicht-flüchtigem Speicher gehalten

temporärer Linkkey kann nur in einer Sitzung existieren● häufig benutzt, wenn mehr als zwei Stationen (Punkt-zu-

Mehrpunkt) untereinander Daten austauschen


BluetoothBluetoothSicherheit in Bluetooth

Schlüsselverwaltung Es werden vier Linkkeys unterschieden

Der Kombinationsschlüssel KAB

● aus Linkkeys zweier Einheiten A und B berechnet● gleiche Funktionalität wie Einheitenschlüssel

Der Einheitenschlüssel KA

● aus Linkkey der Einheiten A berechnet● gleiche Funktionalität wie Kombinationsschlüssel

temporäre Schlüssel Kmaster

● kurzzeitig als temporärer Linkkey verwendet● z.B. bei Punkt-zu-Mehrpunkt-Verbindungen

Der Initialisierungsschlüssel Kinit

● Wird nur bei der Initialisierung des Linkkeys benutzt.


BluetoothBluetooth


Initialisierung ausZufallszahlPIN-Code ● PIN-Code kann

● von Benutzern eingegeben werden oder● fest in Bluetooth-Einheit eingebaut sein

Initialisierungsschlüssel Kinit


BluetoothBluetooth


Initialisierung des Linkkeys1. Erzeugung eines Initialisierungsschlüssel Kinit

Der Initialisierungsschlüssel wird mit dem Algorithmus E22(BD_ADDR, PIN, |PIN|, IN_RAND) PIN muss frei gewählt sein (nicht fest installierte)Vertraulichkeit hängt also nur von PIN ab

2. Erzeugung eines Linkkeys Klink

KA (Linkkey für Station A)berechnet aus Zufallszahl RAND und Adresse BD_ADDRA nach Algorithmus E21


BluetoothBluetooth


Initialisierung des Linkkeys3. Austausch des Linkkeys

Der Linkkey KA wird an Station B übersandt, indem er zunächst mit Kinit xoder verknüpft wird. B kann, da er Kinit kennt, wieder KA daraus berechnen.Wird ein Kombinationsschlüssel KAB verwendet, so erzeugt jede Station eine eigene Zufallszahl und erhält die der Gegenstelle; dann verknüpft nach E21 jede Station ihre Zufallszahl mit ihrer Adresse und die der anderen mit deren Adresse und verknüpft die Ergebnisse mit xor.


BluetoothBluetooth


Initialisierung des Linkkeys4.Authentifizierung

Challenge-Response-VerfahrenA sendet an B eine Zufallszahl RAND (Challenge), B berechnet SRES=E1(RAND, BD_ADDRB,Linkkey) und sendet dieses an A zurück.

5.Optionale Erzeugung eines Verschlüsselungsschlüssel KCVerschlüsselungsschlüssel nach Algorithmus E3 berechnet aus- Linkkey, - Ciphering Offset (COF, 96 Bits) - ZufallszahlCiphering Offset ist entweder die zweimal konkatenierte Stationsadresse BD_ADDR oder eine Zahl (ACO) aus Authentisierung


BluetoothBluetooth


Initialisierung des Linkkeys

Bluetooth -...

Documents

Transcript of Bluetooth -...