Previous Up Next
OBEX Object Passing Home (PDF)

Kapitel 2  Technische Grundlagen

In diesem Kapitel werden die zur Umsetzung, bzw. zum Verst�ndnis der vorliegenden Arbeit, notwendigen Technologien bzw. Spezifikationen kurz angesprochen. Ist der Leser mit den folgenden Technologien bereits vertraut, kann dieses Kapitel problemlos �bersprungen werden. Die Technologien werden nicht in vollem Umfang diskutiert, lediglich der jeweils relevante Teil wird herausgegriffen und kurz zusammengefasst bzw. gegeneinander abgegrenzt. Ausgehend davon, dass die zuk�nftige Entwicklung im Bereich mobiler Endger�te nicht stagniert, wird speziell nur auf die zum Zeitpunkt der Drucklegung aktuelle Version der entsprechenden Spezifikation eingegangen. Die einzige Ausnahme stellt die Bluetooth-Spezifikation dar, die lediglich in der Version 1.2 vorgestellt wird, da die Mehrzahl der aktuell verf�gbaren Endger�te lediglich diese Version unterst�tzt. Die aktuelle Version (zum Zeitpunkt der Drucklegung v2.0) kann unter https://www.bluetooth.org/spec/ bezogen werden. Die �ltere Version 1.1 der Bluetooth-Spezifikation, auf die der JSR-82 aufsetzt, kann unter der selben URL angefordert werden.

Die angesprochenen Technologien und Spezifikationen umfassen dabei:

2.1  Bluetooth

Die im Folgenden beschriebenen Grundlagen beziehen sich auf die Bluetooth-Spezifikation in der Version 1.2. Die �nderungen im Vergleich zur Version 1.1 beziehen sich haupts�chlich auf die Reduktion der Interferenzen mit anderen Funktechnologien und sind deshalb minimal. Die Version 1.1 h�tte von der Bluetooth SIG speziell angefordert werden m�ssen, was somit vermieden werden konnte, da die Version 1.2 zum Zeitpunkt der Drucklegung ohne Registrierung verf�gbar war.

Die Bluetooth Funktechnologie ist ein Kurzstreckenfunkverfahren, das prim�r dazu entwickelt wurde mobile Endger�te kabellos zu verbinden. Das Bluetooth Grundsystem besteht aus Basisband, Sende-/Empfangseinheit und dem zugeh�rigen Protokollstapel1. Das Kurzstreckenfunkverfahren wird im weltweit lizenzfreien 2.4 GHz ISM2 Band betrieben. Um die Komplexit�t der Sende- und Empfangseinheit gering zu halten und somit die Kosten zu minimieren, wird als Modulationsverfahren dass Gaussian Frequency Shift Keying (GFSK)3 eingesetzt (Vgl. : [Blu03, Architecture, S. 13; PDF, S. 89]).

Die Reichweite des Bluetooth-Kurzstreckenfunks ist, wie bei jeder Funktechnologie, abh�ngig von der Sendeleistung des Ger�ts. Die Sendeleistung – und somit auch die Reichweite – des Funks wird in drei Klassen eingeteilt:

Klassifikation Reichweite Sendeleistung
Klasse 1 100 m 100 mW
Klasse 2 40 m 2.5 mW
Klasse 3 10 m 1 mW
Tabelle 2.1: Reichweiten der einzelnen Bluetooth Klassen (Vgl. : [Wik06b])

Die Daten�bertragungsraten sind abh�ngig von der Spezifikation bzw. der Bluetooth-Version des jeweiligen Produkts. Die �bertragungsrate hat sich w�hrend der ersten drei Versionen nicht gesteigert, sie wurde erst mit der Bluetooth-Spezifikation Version 2.0 erh�ht. Ein �berblick �ber die �bertragungsraten, sowie die grossen �nderungen/Probleme, der jeweilgen Bluetooth-Versionen ist in [Tab.: 2.2] dargestellt.

Bluetooth-Version Maximale Daten�bertragungsrate �nderung/Problem
1.0 und 1.0B 723.2 Kbit/s Enth�lt Sicherheitsprobleme
1.1 723.2 Kbit/s Indikator f�r die Signalst�rke hinzugef�gt Received Signal Strength Indicator (RSSI)
1.2 723.2 Kbit/s Adaptive Frequency-Hopping spread spectrum (AFH) eingef�hrt; reduziert Interferenzen mit anderen Funktechnologien (z. B. WLAN)
2.0 2.1 Mbit/s Etwa dreifache Daten�bertragungsgeschwindigkeit durch Enhanced Data Rate (EDR)
Tabelle 2.2: Daten�bertragungsraten von Bluetooth (Vgl. : [Wik06b, Versionen])

Der Datentransport innerhalb der Bluetooth-Architektur sowie s�mtliche Betriebsmodi folgen dem selben generischen Ansatz. Dieser generische Ansatz ist mit Hilfe einer Schichtenarchitektur realisiert, die in [Abb.: 2.1] dargestellt, und mit dem OSI-Schichtenmodell vergleichbar ist.

Abbildung 2.1: Allgemeine Datentransport Architektur von Bluetooth (Vgl. : [Blu03, Architecture, S.25; PDF, S. 101])

2.1.1  Physical Layer

Der Physical Layer bestimmt die Art und Weise wie die Daten �bertragen werden, bzw. wie die �bertragung der Daten stattzufinden hat. Er spezifiziert bspw. was notwendig ist um Kollisionen zu vermeiden, oder welches Verfahren verwendet wird um parallele Operationen zu unterst�tzen.

2.1.1.1  Physical Channel



Auf der untersten Ebene dieser Architektur befindet sich der Physical Channel. Er wird von zwei Bluetooth Ger�ten zur Kommunikation genutzt. Um miteinander kommunizieren zu k�nnen, m�ssen beide Sende- und Empfangseinheiten in Reichweite sein und auf die selbe Funkfrequenz eingestellt werden. Um unbeabsichtigte Kollisionen zu vermeiden wird der Kommunikation ein Zugriffscode angef�gt. Dies verhindert Kollisionen, w�rden mehrere Ger�te auf die selbe Frequenz eingestellt werden. In der Spezifikation sind vier physische Kan�le definiert, von denen jeder f�r einen bestimmten Anwendungszweck definiert und optimiert wurde. Um parallele Operationen zu unterst�tzen, wird das Time Division Multiplexing4 Verfahren verwendet. Durch diesen Mechanismus wird es erm�glicht, dass das Ger�t w�hrend einer bestehenden Kommunikation auffindbar und zug�nglich ist. Die Spezifikation nimmt weiterhin an, dass das Ger�t lediglich in der Lage ist, sich ausschliesslich mit einem �bertragungskanal zu verbinden (Vgl. : [Blu03, Architecture, S. 32; PDF, S. 108]).

2.1.1.2  Physical Links



Der Physical Link repr�sentiert die Basisbandverbindung5 zwischen den Endger�ten. Eine solche physische Verbindung ist immer mit genau einem physischen Kanal verkn�pft, obwohl ein physischer Kanal mehr als eine physische Verbindung unterst�tzen kann. Die physische Verbindung ist innerhalb eines Bluetooth-Systems lediglich ein virtuelles Konzept. Innerhalb eines Bluetooth-Pakets existiert kein Feld, welches es erm�glichen w�rde die physische Verbindung direkt zu identifizieren. Die physische Verbindung kann stattdessen �ber den logischen Transportkanal6 identifiziert werden. Physische Verbindungen haben �blicherweise gemeinsame Eigenschaften, die auf alle logischen Transportkan�le – die zu dieser Verbindung geh�ren – angewandt werden. Beispiele solcher Eigenschaften sind die Verschl�sselung und Leistungssteuerung (Power Control) des Ger�ts. Soll eine �bertragung �ber mehrere physische Verbindungen hinweg ausgel�st werden (Broadcast), werden die Sendeparameter entsprechend angepasst, sodass auf allen physischen Verbindungen gesendet werden kann (Vgl. : [Blu03, Architecture, S. 37; PDF: S. 113]).

2.1.2  Logical Layer

Der Logical Layer definiert, wie die logischen Transportverbindungen physisch zugeordnet werden.

2.1.2.1  Logical Transports

Zwischen Master und SlaveMaster und Slave ist das Analogon zum Client-/Server-Modell bei Protokollen wie z. B. FTP – k�nnen verschiedene Typen von logischen Transportverbindungen (Logical Transports) hergestellt werden. Dabei ist es jedem Ger�t m�glich, den Master oder Slave Status einzunehmen; der Status kann sogar w�hrend der bestehenden Verbindung gewechselt werden. Logische Transportverbindungen werden von aktiven physischen Verbindungen getragen und sind in der Lage, verschiedene Arten logischer Verbindungen zu beinhalten (Vgl. : [Blu03, Architectur, S. 39f; PDF, S. 115f]).

In der Spezifikation sind f�nf logische Transportverbindungen zwischen Master und Slave definiert: Die synchronen Transportverbindungen stellen hierbei Punkt-zu-Punkt-Verbindungen von einem Master zu einem Slave dar. Sie unterst�tzen typischerweise zeitabh�ngige Informationen wie z. B. Sprache. Das Master-Ger�t regelt hierbei die Verbindung indem es reservierte Slots in regelm��igen Abst�nden benutzt. Die ACL Verbindungen stellen ebenfalls eine Punkt-zu-Punkt-Verbindung zwischen einem Master und einem Slave dar. Der Master kann die ACL Verbindung zu einem beliebigen Slave – inklusive der Slaves die bereits eine bestehende synchrone Verbindung haben – herstellen, indem er die Slots benutzt, die nicht f�r die synchrone Verbindung reserviert sind. Eine genaue Beschreibung der einzelnen Transportverbindungen ist unter [Blu03, Baseband Specification, S. 85ff; PDF, S.243ff] zu finden.

2.1.2.2  Logical Links



Um die verschiedenen Anforderungen einer Applikation bez�glich dem Datentransport abzudecken, ist eine Vielzahl logischer Verbindungen (Logical Links) verf�gbar. Jede logische Verbindung wird mit einer logischen Transportverbindung assoziiert, die �ber verschiedene Charakteristika verf�gt. Diese beinhalten z. B. Flusskontrolle, Sequenznummerierung sowie die Ablaufkoordination (Scheduling). Innerhalb einer logischen Transportverbindung kann die logische Verbindung anhand des Logical Link Identifiers (LLID) erkannt werden, der im Header eines Basisbandpakets zu finden ist (Vgl. : [Blu03, Architectur, S. 46f; PDF, S. 122f]).

Die folgenden f�nf logischen Verbindungen sind in der Spezifikation definiert (Vgl. : [Blu03, Baseband Specification, S. 95ff; PDF, S. 253ff])
Link Control (LC)
Diese logische Verbindung tr�gt Kontrollinformationen der unteren Ebenen, wie z. B. Acknowledgement/Repeat Request (ARQ), Flusskontrolle und Nutzlastcharakterisierungen.
ACL Control (ACL-C)
Die ACL-C Verbindung tr�gt Kontrollinformationen, die zwischen den Link Managern (LM)7 der Endger�te ausgetauscht werden m�ssen. Der Austausch dieser Informationen geschieht �ber das Link Manager Protokoll (LMP).
User Asynchronous/Isochronous (ACL-U)
Die ACL-U Verbindung tr�gt asynchrone, sowie isochrone L2CAP Benutzerdaten. Diese Nachrichten k�nnen in einem oder mehreren Paketen �bermittelt werden. Bei fragmentierten Daten wird im Header der LLID auf den entsprechenden Wert gesetzt.
User Synchronous (SCO-S)
Die SCO-S Verbindung transportiert synchrone Benutzerdaten.
User Extended Synchronous (eSCO-S)
Die eSCO-S Verbindung transportiert ebenfalls synchrone Benutzerdaten.

2.1.3  L2CAP Layer



Das Logical Link Control and Adaption Protocol (L2CAP) unterst�tzt Multiplexing zu Protokollen h�herer Ebenen, Paketsegmentierung und -reassemblierung, sowie das �bermitteln von Quality of Service8 Informationen. Applikationen und Service-Protokolle kommunizieren mit dem L2CAP-Layer �ber ein sogenanntes Channel-Orientated Interface, um Verbindungen zu anderen Ger�ten herzustellen. Die entsprechenden Endpunkte werden �ber einen Channel Identifier (CID) gekennzeichnet, dessen Wert vom L2CAP-Layer zugewiesen wird. Das Hauptaugenmerk des L2CAP-Layers liegt aber auf dessen Multiplexing-F�higkeit. Er ist daf�r zust�ndig, dass die �ber das Channel Interface ankommenden Daten (Service Data Units [SDUs]) auf die ACL-U Verbindungen verteilt werden. Ist ein HCI9 vorhanden, hat der L2CAP-Layer ebenfalls daf�r Sorge zu tragen, dass die Daten entprechend der Puffergr�sse des Basisbands segmentiert werden (Vgl. : [Blu03, Architectur, S. 48; PDF, S. 124]).

2.1.4  Bluetooth Sicherheit

Die Bluetooth-Spezifikation beschreibt das Sicherheitssystem, das bereits auf der Verbindungsebene (Link Layer) angewendet wird, sehr ausf�hrlich. Verschl�sselung, Authentifizierung sowie Schl�sselerzeugungsschemata und die Erzeugung von Zufallszahlen sind spezifiziert. Die Authentifizierungs- und Verschl�sselungsalgorithmen m�ssen in jedem Ger�t eine �quivalente Implementierung aufweisen. Um die Sicherheit auf der Verbindungsebene zu realisieren, werden die vier in [Tab.: 2.3] aufgef�hrten Entit�ten verwendet.

Entit�t Gr�sse
Bluetooth Device Address (BD_ADDR) 48 Bit
Privater Schl�ssel des Benutzers (Authentifizierung) 128 Bit
Privater Schl�ssel des Benutzers (Verschl�sselung) 8-128 Bit
Pseudozufallszahl (RAND) 128 Bit
Tabelle 2.3: In Authentifizierung und Verschl�sselung involvierte Entit�ten (Vgl. : [Blu03, Security Specification, S. 749; PDF, S. 907 Tabelle 1.1])

Die Authentifizierung beider Ger�te erfolgt in zwei Schritten, das heisst es wird eine gegenseitige Authentifizierung beider Ger�te vorgenommen. In direktem Anschluss der Authentifizierung des Ger�ts A bei Ger�t B wird die Authentifizierung in entgegengesetzter Richtung vorgenommen10 (Vgl. : [Blu03, Security Specification, S. 758; PDF, S. 914]).

Benutzerdaten k�nnen mittels des angebotenen Verschl�sselungsalgorithmus gesch�tzt werden. Es werden jedoch lediglich die Nutzdaten des zu sendenden Pakets verschl�sselt. Der Header des Pakets bleibt unangetastet. Der Algorithmus implementiert eine Stromchiffrierung mit Hilfe der SAFER+ Methode, die frei erh�ltlich ist. Sie ist eine verbesserte Version des SAFER11 Algorithmus [Blu03, Security Specification, S. 777ff; PDF, S. 935ff].

2.1.5  Generic Access Profile (GAP)

Sinn und Zweck des Generic Access Profiles (GAP) ist es, Definitionen, Empfehlungen sowie allgemeine Anforderungen in Bezug auf verschiedene Betriebsmodi und Zugriffsprozeduren zu beschreiben, die von Transport- und Applikationsprofilen verwendet werden sollten. Es wird weiterhin beschrieben, wie sich die Ger�te im Ruhe- und im Verbindungsaufbauzustand verhalten sollten. Speziell wird der Fokus hierbei auf die Ger�tesuche, Erzeugung der Verbindung sowie die Sicherheitsprozeduren gelegt. Das Schichtenmodell des GAP folgt dem in [Abb.: 2.2] dargestellten Aufbau [Blu03, Generic Access Profile, S. 179ff; PDF: S. 1127ff].

Abbildung 2.2: GAP Schichtenmodell (Vgl.: Abbildung 2.1: Profile stack covered by this profile, S. 181 [Blu03])

Die Spezifikation des GAP besch�ftigt sich haupts�chlich damit, zu beschreiben, welchem Zweck die unteren Schichten des Bluetooth Protokollstapels dienen (LC und LMP). Um Sicherheitsbezogene Alternativen zu diskutieren, wurden ebenfalls h�here Ebenen mit einbezogen (L2CAP, RFCOMM und OBEX) [Blu03, Generic Access Profile, S. 181; PDF: S. 1129].



In Bezug auf eine Suchanfrage (inquiry) kann sich ein Bluetooth-Ger�t in drei verschiedenen Zust�nden befinden. Die m�glichen Zust�nde sind in [Tab.: 2.4] abgedruckt.

Auffindbarkeitszustand Beschreibung
Non-discoverable mode Ist das Ger�t in diesem Zustand, so kann es von einer Suchanfrage nicht gefunden werden. Ein Bluetooth-Ger�t in diesem Zustand wird als “Stilles Ger�t” (silent device) bezeichnet.
Limited discoverable mode (LIAC) Das Ger�t ist f�r einen beschr�nkten Zeitraum oder bis zum Eintritt eines bestimmten Ereignisses auffindbar. Es sollte allerdings nicht l�nger als eine vordefinierte Zeit in diesem Zustand bleiben (timeout). Ist ein Ger�t in diesem Zustand, antwortet es auf Suchanfragen die den Limited Dedicated Inquiry Access Code (LIAC) verwenden.
General discoverable mode (GIAC) Das Ger�t befindet sich in einem dauerhaft auffindbaren Zustand. Ist ein Ger�t in diesem Zustand, antwortet es auf Suchanfragen die den General/Unlimited Inquiry Access Code (GIAC) verwenden.
Tabelle 2.4: Auffindbarkeitszust�nde eines Bluetooth-Ger�ts [M+05, Generic Access Profile, S. 189ff; PDF, S.1137ff]

Die spezifizierten Werte der Zugriffskennzeichner LIAC und GIAC sind auf der Bluetooth Homepage12 zu finden [Blu06].

2.1.6  Bluetooth Implementierungen

Um Bluetooth auf einem Ger�t verwenden zu k�nnen ist es notwendig, dass eine – zur Hardware passende – Implementierung eines Bluetooth-Stacks bereitgestellt wird. F�r die mobilen Endger�te ist in den meisten F�llen eine Bluetooth Implementierung des jeweiligen Herstellers auf dem Ger�t vorhanden. Um allerdings auf einem Desktop-System Bluetooth-Unterst�tzung zu erhalten, muss i. d. R. ein entsprechender Stack nachtr�glich installiert werden.

2.2  Java 2 Micro Edition (J2ME)

Die Java 2 Platform, Micro Edition (J2ME ) ist eine Plattform, die speziell auf die Bed�rfnisse von Embedded Devices zugeschnitten ist. Die J2ME Architektur definiert Konfigurationen, Profile sowie optionale Pakete, mit deren Hilfe es m�glich ist, Java Laufzeitumgebungen zu entwickeln, die eine m�glichst breite Palette an Endger�ten des jeweiligen Zielmarktes abdecken. Konfigurationen bestehen aus der Kombination einer virtuellen Maschine (VM) sowie einem zugeh�rigen minimalen Set an Klassenbibliotheken. Um eine komplette Laufzeitumgebung f�r dom�nenspezifische Endger�te zu schaffen, muss die Konfiguration um ein Set zus�tzlicher Klassenbibliotheken erweitert werden, die in einem Profil oder optionalen Paket definiert sind. Die J2ME Plattform l�sst sich, wie in [Abb.: 2.3] dargestellt, im Java Umfeld einordnen (Vgl. : [Sun06]).

Abbildung 2.3: Einordnung von J2ME im Java Umfeld (Vgl. : [Sun06])

Die J2ME Architektur folgt also prinzipiell dem in [Abb.: 2.4] dargestellten Aufbau. Die einzelnen Schichten der Architektur (CLDC [Kapitel 2.3] und MIDP [Kapitel 2.4]) werden im Folgenden genauer beschrieben.

Abbildung 2.4: J2ME Architektur (Vgl. : [T+03, Abb. 1, S. 28])

2.3  Connected Limited Device Configuration (CLDC)



Die Connected Limited Device Configuration (CLDC) stellt, zusammen mit dem Mobile Information Device Profile (MIDP)13, die Grundlage der J2ME dar. Wie nahezu alle Standards rund um Java, ist die CLDC ebenfalls Ergebnis eines Java Specification Request (JSR). Die CLDC 1.0 wird als JSR-30 [T+00], die Version 1.1 als JSR-139 [T+03] gef�hrt14. Die CLDC 1.1 ist nicht als komplette Neuerung, sondern lediglich als Erweiterung der CLDC 1.0 zu sehen. Das bedeutet, dass die CLDC 1.1, mit ein paar wenigen Ausnahmen wie z. B. der Unterst�tzung f�r Gleitpunktoperationen, abw�rtskompatibel zur CLDC 1.0 ist. Die CLDC Spezifikation hat zum Ziel, eine Entwicklungsplattform f�r netzwerkf�hige, jedoch in ihren Ressourcen limitierte, portable, Ger�te zu standardisieren. Solche Ger�te sind bspw. ein Mobiltelefon oder ein Personal Digital Assistant (PDA). Eine Konfiguration der J2ME Plattform spezifiziert hierbei die Basismenge der Java Programmiersprache sowie die Funktionalit�t der zugeh�rigen VM. Sun Microsystems, Inc. bietet eine Referenzimplementierung einer solchen virtuellen Maschine an, die in der Spezifikation als K Virtual Machine (KVM) bezeichnet wird, aber mittlerweile unter der Bezeichnung CLDC HotSpot Implementation Virtual Machine15 bekannt ist, die die 8-10 fache Geschwindigkeit der KVM erreicht. Die CLDC dient als Basis f�r ein oder mehrere Profile, die ein dem Ger�t entsprechendes API anbieten (Vgl. : [T+03, S. xi]).

Da die CLDC darauf ausgerichtet wurde, eine m�glichst grosse Anzahl verschiedener Ger�te zu unterst�tzen, besitzt sie, ausser der Mindestanforderung an den Speicher, keine weiteren Anforderungen bzgl. der zu Grunde liegenden Hardware. Typischerweise besitzen die angesprochenen Ger�te jedoch limitierte Ressourcen: In keinem Fall ist die CLDC mit der Connected Device Configuration (CDC)16 zu verwechseln, die einen erheblich gr�sseren Umfang als die CLDC bietet. Innerhalb der CDC ist z. B. der Mechanismus der Serialisierung und Deserialisierung von Objekten implementiert, was in der CLDC nicht der Fall ist. Die CDC ist f�r portable High-End-Ger�te entwickelt worden.

Die Implementierung der CLDC kann keine Kenntnis eines Dateisystems auf dem Endger�t voraussetzen. Viele, in ihren Ressourcen eingeschr�nkte Ger�te, verf�gen nicht �ber die Kenntnis eines Dateisystems oder �hnlichem, welches es erm�glicht dynamisch bezogene Daten persistent auf dem Ger�t zu speichern. Die Implementierung muss lediglich in der Lage sein, die Applikation zu laden und sie direkt nach ihrer Ausf�hrung wieder zu verwerfen. Verf�gt das Ger�t allerdings �ber einen Persistenzmechanismus, ist es Aufgabe des Betriebssystems, einen Mechanismus zur Verwaltung der Applikationen zur Verf�gung zu stellen. Auf Grund der variablen Bandbreite verf�gbarer Ger�te, ist ein solcher Mechanismus allerdings stark abh�ngig vom Ger�t selbst und wird aufgrunddessen nicht von der Spezifikation behandelt (Vgl. : [T+03, S. 29]).

2.3.1  Generic Connection Framework (GCF)

In einer einheitlichen, erweiterbaren Art und Weise bietet das Generic Connection Framework (GCF) die M�glichkeit, auf Ein- und Ausgabeoperationen sowie Netzwerkressourcen zuzugreifen. Anstatt auf eine Vielzahl verschiedener Abstraktionsmechanismen f�r jeden Kommunikationstyp zur�ckzugreifen, wird eine Menge zugeh�riger Abstraktionen auf Ebene der Applikationsprogrammierung benutzt. Dieser generische Mechanismus besitzt folgende Form:

Connector.open(«protocol>:<address>;<parameters>");

Das GCF, das in der CLDC spezifiziert wird, definiert allerdings kein zwingend zu unterst�tzendes Netzwerkprotokoll. Sie fordert ebensowenig eine Implementierung bereits bestehender Protokolle. Sie bietet jedoch ein erweiterbares Rahmenwerk, das von J2ME Profilen, wie z. B. dem MIDP17 angepasst werden kann. Die tats�chliche Implementierung der entsprechenden Protokolle erfolgt also auf Ebene des Profils (Vgl.: [T+03, S. 56ff]).

2.3.2  CLDC Sicherheit

Das von der J2SE bekannte, sehr m�chtige, Sicherheitsmodell konnte aufgrund des Code-Umfangs nicht �bernommen werden, da es die spezifizierten Speichergrenzen der CLDC bei weitem �berschreitet. Das Sicherheitsmodell ist deshalb in drei verschiedene Ebenen eingeteilt.
Low-level security
Der Begriff low-level security ist auch unter der Bezeichnung Virtual machine security bekannt. Low-level security stellt sicher, dass Applikationen, die in der VM ausgef�hrt werden, die Semantik der Java Programmiersprache einhalten. Sie stellt weiterhin sicher, dass jedweder fehlerhafte oder sch�dliche Programm-Code nicht in der Lage ist, das Ger�t zu besch�digen oder es zum Absturz zu bringen (Vgl. : [T+03, S. 30]).
Application-level security
Application-level security bedeutet, dass die Applikation nur auf Ressourcen, Bibliotheken und andere Komponenten zugreifen kann, die von der Java Laufzeitumgebung und dem Ger�t genehmigt worden sind. Realisiert wird das durch ein sogenanntes Sandbox-Modell. Es muss gew�hrleisten, dass Java Applikationen nicht aus ihrer Sandbox ausbrechen k�nnen. Das CLDC Sandbox-Modell verbietet ebenfalls ein herunterladen beliebiger neuer Bibliotheken, die nicht zum Umfang der Java Bibliotheken der CLDC oder des Herstellers geh�ren. Das Ausf�hren nativen Codes ist ebenfalls verboten (Vgl. : [T+03, S. 31]).
End-to-end security
Mit end-to-end security bezeichnet man ein Modell, das gew�hrleistet, dass die �ber ein Netzwerk gesendeten Daten – w�hrend ihres Transports durch diese Netze – gesch�tzt werden. Um dies zu gew�hrleisten ist ein Verschl�sselungs- oder ein �quivalenter anderer Schutzmechanismus notwendig. Aufgrund des breiten Spektrums verf�gbarer Endger�te kann allerdings keine einheitliche L�sung des Problems geschaffen werden. Die Spezifikation deklariert die end-to-end security diesbez�glich als implementierungsabh�ngig (Vgl. : [T+03, S. 32]).

2.4  Mobile Information Device Profile (MIDP)



Das Mobile Information Device Profile (MIDP) spezifiziert ein Profil, welches auf die F�higkeiten eines kleinen mobilen Endger�ts – einem sogenannten Mobile Information Device (MID) – abgestimmt ist. Das MIDP 2.0 ist das Ergebnis des JSR-118, basiert auf dem MIDP 1.0 (JSR-37) und ist zu diesem abw�rtskompatibel, sodass MIDlets18, die f�r das MIDP 1.0 geschrieben wurden, ebenfalls auf dem MIDP 2.0 lauff�hig sind19. Das MIDP spezifiziert eine auf der CLDC20 aufgesetzte Schicht. MIDP 2.0 setzt mindestens die Version 1.0 der CLDC voraus, jedoch wird angenommen, dass die meisten MIDP 2.0 Implementierungen auf der CLDC 1.1 aufsetzen werden. Da MIDs typischerweise eine sehr breite Spanne an Ressourcen zur Verf�gung stellen, ist die Anzahl der Programmierschnittstellen auf das Wesentliche reduziert worden, um eine m�glichst hohe Portabilit�t zu gew�hrleisten. Aus diesem Grund sind einige Funktionsbereiche abgegrenzt worden. Die abgegrenzten Bereiche sind die systemnahen Programmierschnittstellen (System-level APIs) sowie die Sicherheit der virtuellen Maschine (Low-level security) (Vgl. : [VW02, S. 5f]).

Die spezifizierten Mindestanforderungen an das MID sind als zus�tzliche Anforderungen zur CLDC zu betrachten. Die Anforderungen sind unterteilt in Hard- und Softwareanforderungen. Die f�r die vorliegende Arbeit relevanten Spezifikationspunkte sind das Netzwerk sowie der spezifizierte Persistenzmechanismus:
Netzwerk
Die Netzwerkhardware muss eine Zwei-Wege-Funkverbindung (mit limitierter Bandbreite) zur Verf�gung stellen. Um das Netzwerk API zu unterst�tzen, muss der Software lesender und schreibender Zugriff auf die Funkverbindung gew�hrt werden.
Persistenzmechanismus
Ein Mechanismus, um auf den nichtfl�chtigen Speicher zu schreiben und von ihm zu lesen, um die Anforderungen des Record Management Systems21 abzudecken.
In der Spezifikation sind weitere Anforderungen an des Ger�t definiert, die weitere Punkte wie Anzeige, Eingabemechanismen, Speicheranforderungen und Audioeigenschaften festlegen. Es wird weiterhin festgelegt, wie die Software-Landschaft des Ger�ts auszusehen hat. Dies umfasst z. B. einen minimalistischen Kernel sowie einen Mechanismus, der den Lebenszyklus der Applikation auf dem Ger�t verwaltet (Vgl. : [VW02, S. 7ff]).

2.4.1  Record Management System (RMS)

Das Record Management System (RMS) ist ein Mechanismus, der es MIDlets erm�glicht, Daten persistent auf dem Ger�t abzulegen. Der Mechanismus ist wie eine einfache datensatzorientierte Datenbank modelliert (Vgl. : [VW02, S. 463]).

2.4.1.1  Record Store

Ein Record Store ist eine Ansammlung an Datens�tzen, die, �ber mehrere Aufrufe der Applikation hinweg, persistent erhalten bleiben. Die zu Grunde liegende Plattform ist f�r die Integrit�t der Datens�tze verantwortlich. Sie ist auch f�r das Erzeugen des Record Stores verantwortlich, der an einem der Plattform spezifischen Ort liegt. Dieser Speicherort darf dem MIDlet, aus Sicherheitsgr�nden, nicht bekanntgegeben werden. Der Name des Records Stores wird allerdings auf Ebene des MIDlets festgelegt. Dieser Name muss innerhalb eines MIDlets eindeutig sein. Das RMS-API definiert keinen Locking-Mechanismus. Schreiboperationen auf das Datenbanksystem werden automatisch synchronisiert, was bedeutet, dass das API Thread-Safe22 ist (Vgl. : [VW02, S. 463f]).

2.4.1.2  Records

Records sind als Byte-Arrays implementiert. Der Entwickler kann also DataInputStream und DataOutputStream sowie ByteArrayInputStream und ByteArrayOutputStream verwenden, um Daten in einen Datensatz zu schreiben bzw. von ihm zu lesen. Jeder Record kann innerhalb eines Record Stores anhand seiner eindeutigen Identifikationsnummer (ID) zugeordnet werden. Das bedeutet; wird ein Datensatz eingef�gt, erh�lt er die ID „n“. Der n�chste eingef�gte Datensatz erh�lt die ID „n+1“ (Vgl. : [VW02, S. 464]).

Dieses Konzept der Enumeration wird konsequent verfolgt. Wird z. B. ein Datensatz gel�scht, wird die ID nicht wiederverwendet. Das bedeutet; sind drei Datens�tze mit den IDs >>1<<, >>2<< und >>3<< eingef�gt worden und wird der Datensatz mit der ID >>2<< gel�scht, erh�lt der n�chste eingef�gte Datensatz die ID >>4<< und nicht wie evtl. angenommen werden k�nnte, die ID >>2<<.

2.4.2  MIDP Sicherheit

Da sich das MIDP auf die Bereitstellung eines APIs f�r die Applikationsentwicklung bezieht, wurden die System-level APIs nicht weiter spezifiziert. Das heisst sie unterliegen der korrekten Implementierung und den Sicherheitsanforderungen des Herstellers. Es werden seitens der Spezifikation explizit keine weiteren Low-level Sicherheitsmechanismen definiert (Vgl. : [VW02, S. 6]).

Da das MIDP jedoch auf der CLDC aufsetzt, erbt es die bereits in der CLDC vorhandenen Sicherheitsmechanismen. Das System-level API wird prinzipiell von der Application-level security, die Low-level Sicherheit von der gleichnamigen Sicherheit in der CLDC abgedeckt23.

Das MIDP 1.0 zwingt jedes MIDlet dazu, innerhalb einer Sandbox ausgef�hrt zu werden, die jeglichen Zugriff auf sensitive Schnittstellen oder Funktionen des Ger�ts unterbindet. Dieses Konzept wird vom MIDP 2.0 ebenfalls f�r jedes nicht vertrauensw�rdige (untrusted) MIDlet verlangt. Jede MIDP 2.0 Implementierung ist verpflichtet, Unterst�tzung f�r untrusted MIDlets anzubieten. Mit dem MIDP 2.0 ist das Konzept vertrauter (trusted) Applikationen eingef�hrt worden, das den Zugriff auf sensitive Schnittstellen erlaubt. Nicht vertrauensw�rdige MIDlets m�ssen innerhalb der vom MIDP 1.0 spezifizierten Sandbox ausgef�hrt werden. Findet beim Ausf�hren eines solchen MIDlets ein Zugriff auf nicht vertrauensw�rdige Schnittstellen statt, muss der Zugriff entweder verworfen, oder, nach einer explizit angeforderten Genehmigung des Benutzers, erlaubt werden. Das trusted Modell definiert im Gegensatz dazu drei verschiedene Interaktionsmuster, die als User Permission Modes bezeichnet werden. Sie erm�glichen es dem Benutzer, den Zugriff auf ein bestimmtes API zu erlauben oder zu verwehren (Vgl. : [VW02, S. 23ff]).

Die verschiedenen Zugriffsmodi, die vom Benutzer festgelegt werden k�nnen, sowie deren G�ltigkeitszeitraum sind in [Tab.: 2.5] festgehalten.

User Permission G�ltigkeitszeitraum
blanket G�ltig f�r jede Ausf�hrung der MIDlet-Applikation bis sie deinstalliert oder die Rechte vom Benutzer ge�ndert werden.
session G�ltig vom Start eines MIDlets, bis zu dessen Termination. Der “session” Modus ist verpflichtet, den Benutzer beim oder vor dem ersten Aufruf einer gesch�tzten Funktion einen Dialog anzuzeigen, in dem der Benutzer entweder den Zugriff gestattet oder ablehnt. Bei einem erneuten Start des MIDlets muss diese Abfrage erneut erfolgen.
oneshot Eine Interaktion mit dem Benutzer ist bei jedem Zugriff auf ein gesch�tztes API notwendig.
Tabelle 2.5: G�ltigkeitszeitraum der Rechte eines MIDlets (Vgl. : [VW02, S. 26])

2.5  Java API for Bluetooth (JSR-82)

Um die Bluetooth Funktionalit�t von einem MIDlet aus ansprechen zu k�nnen, ist ein entsprechendes API notwendig. Der JSR-8224 definiert ein solches API sowie dessen Architektur, um Drittherstellern die M�glichkeit zu geben, Programme zu entwickeln, die eine Bluetooth Funkverbindung zur gegenseitigen Kommunikation nutzen. Das mit dem JSR-82 entwickelte API, das auch unter dem Akronym JABWT (Java API for Bluetooth Wireless Technology) bekannt ist, baut auf der Grundlage der CLDC [Kapitel 2.3] auf und basiert auf der Bluetooth Spezifikation in der Version 1.125. Es ist als optionale Erweiterung eines MIDP [Kapitel 2.4] zu sehen (Vgl. : [M+05, S. 11]).

Mit der Spezifikation wurde beabsichtigt, eine Grundlage zu schaffen, mit der es erm�glicht wird, weitere Profile zu entwickeln. Dazu werden APIs f�r das L2CAP und OBEX26 Protokoll angeboten, auf deren Basis zuk�nftige Profile entwickelt werden k�nnen. Das API bietet folgende Dienste an:
  1. Registrierung eines Dienstes
  2. Ger�t- und Dienstsuche
  3. M�glichkeit, L2CAP und OBEX Verbindungen herzustellen.
  4. Sichere Ausf�hrung dieser Aktivit�ten.
Da nicht alle Profile und Ebenen der Bluetooth Spezifikation �bernommen werden k�nnen, beschr�nkt sich der Umfang des APIs lediglich auf Datendienste. Sprachdienste k�nnen nicht verarbeitet bzw. angesteuert werden (Vgl. : [M+05, S. 14]).

2.5.1  Anforderungen

Die vom JSR-82 definierten Anforderungen sind als Zus�tze zu den bereits bestehenden Anforderungen der CLDC zu betrachten. Sie umfassen Anforderungen an die Spezifikation selbst, wie z. B. eine alleinige Abh�ngigkeit zu den CLDC Bibliotheken. Auf die Spezifikationsanforderungen soll jedoch nicht n�her eingegangen werden. Es sind vielmehr die Anforderungen an das Ger�t sowie die des zu Grunde liegenden Bluetooth-Systems von Interesse.
Hardware-Anforderungen
Das JSR-82 API ist entwickelt worden, um auf Ger�te mit folgenden Hardware-Charakteristika eingesetzt werden zu k�nnen.
Bluetooth-Anforderungen
Die Anforderungen an das zu Grunde liegende Bluetooth-System sind folgende:
Die Unterst�tzung f�r das OBject EXchange (OBEX) Protokoll kann entweder bereits vom zu Grunde liegenden Bluetooth-System, oder durch Implementierung des JSR-82 APIs bereitgestellt werden [M+05, S. 14f].

2.5.2  Paketierung

In der Spezifikation sind zwei Pakete definiert: Auf Grund der Tatsache, dass das OBEX API unabh�ngig ist von Bluetooth, wird es in einem separaten Paket ausgeliefert. Eine CLDC ist somit in der Lage, entweder nur eines der beiden, oder beide auszuliefern. Das Paket javax.bluetooth beinhaltet die Bluetooth Basisbibliotheken, wohingegen das javax.obex Paket die Implementierung des OBEX APIs beinhaltet. Aus diesem Grund werden auch zwei verschiedene Technology Compatibility Kits (TCK) zur Verf�gung gestellt, mit Hilfe derer die Implementierung gegen�ber der Spezifikation getestet werden kann [M+05, S. 21].

2.5.3  Bluetooth Control Center

Bei Ger�ten die das JSR-82 API implementieren, kann es u. U. m�glich sein, dass mehrere Applikationen zeitgleich ausgef�hrt werden. Die Notwendigkeit eines Bluetooth Control Centers (BCC) ergibt sich aus dem Wunsch, zu verhindern, dass eine Applikation eine andere nachteilig beeinflusst. Es ist als zentrale Anlaufstelle des lokalen Bluetooth-Ger�ts zu sehen. Die Implementierung des BCC kann entweder als native Applikation bzw. als Applikation mit separatem API oder als fixe Gruppe von Eigenschaften, die nicht vom Benutzer ge�ndert werden k�nnen, umgesetzt werden. Das BCC ist nicht als Klasse oder Schnittstelle innerhalb des JSR-82 APIs spezifiziert, stellt jedoch eine wichtige Rolle f�r die Sicherheitsarchitektur des JSR-82 dar. Das BCC muss der JSR-82 Implementierung folgende Funktionen zur Verf�gung stellen: Keine dieser Informationen darf von einer Applikation aus ge�ndert werden k�nnen. Die einzige Applikation, die berechtigt ist dies zu tun, ist das BCC. Das BCC kann weitere Eigenschaften des Ger�ts zug�nglich machen, wie z. B. die Einstellung des Ger�tenamens (friendly name) oder die M�glichkeit, das Ger�t auf die Werkseinstellungen zur�ckzusetzen [M+05, S. 22].

2.5.4  Eigenschaften des Ger�ts

Da sich je nach Einsatzzweck die Konfiguration der Bluetooth-Ger�te unterscheidet, besteht die Notwendigkeit, bestimmte Eigenschaften des Ger�ts abzufragen. Das API definiert eine Reihe von Eigenschaften, die durch einen Aufruf der Funktion LocalDevice.getProperty() abgefragt werden k�nnen. Die Werte, die abgefragt werden k�nnen, sind in [Tab.: 2.6] dargestellt. Soll ein solcher Wert abgefragt werden, ist zu beachten, dass die Zeichenketten case sensitive28 sind. Ist die Eigenschaft nicht definiert, oder unbekannt, muss null zur�ckgegeben werden. S�mtliche Eigenschaften, die durch LocalDevice.getProperty() abgefragt werden k�nnen, m�ssen ebenfalls durch die von der CLDC bereitgestellte Funktion System.getProperty() zug�nglich sein [M+05, S. 23f].

Eigenschaft Beschreibung
bluetooth.api.version obex.api.version Version des Java APIs for Bluetooth wireless technology die unterst�tzt wird. F�r die Version 1.1 wird entsprechend “1.1” zur�ckgeliefert.
bluetooth.l2cap.receiveMTU.max Maximum Transfer Unit (MTU) in Empfangsrichtung, die von L2CAP unterst�tzt wird. Der zur�ckgelieferte Wert ist dezimal in einem java.lang.String kodiert.
bluetooth.connected.devices.max Maximale Anzahl verbundener Ger�te.
bluetooth.connected.inquiry Kann eine Ger�tesuche durchgef�hrt werden, w�hrend das Ger�t bereits verbunden ist?
bluetooth.connected.page Kann das lokale Ger�t eine Verbindung zu einem entfernten Ger�t herstellen, wenn das lokale Ger�t bereits verbunden ist?
bluetooth.connected.inquiry.scan Kann das lokale Ger�t auf eine Suchanfrage antworten, w�hrend es mit einem anderen Ger�t verbunden ist?
bluetooth.connected.page.scan Kann das lokale Ger�t eine Verbindung von einem anderen Ger�t annehmen, w�hrend es bereits mit einem anderen Ger�t verbunden ist?
bluetooth.master.switch Ist der master/slave Wechsel erlaubt?
bluetooth.sd.trans.max Maximale Anzahl zeitgleicher Dienstsuchen (Service Discovery)
bluetooth.sd.attr.retrievable.max Maximale Anzahl der Service-Attribute die mit einem Service Record empfangen werden k�nnen.
Tabelle 2.6: �bersicht der Eigenschaften des Ger�ts (Vgl. [M+05, S. 24, Tabelle 3-2 Device Properties])

2.5.5  Client-/Server Modell

Ein Bluetooth-Dienst (Service) ist eine Server-Applikation, die einem Client eine bestimmte Funktionalit�t erm�glicht. Ein Service zum Drucken �ber Bluetooth w�re bspw. eine solche Applikation. Entwickler, die mit Bluetooth arbeiten, k�nnen ihre eigenen Server-Applikationen schreiben, die sie anderen (Clients) zur Verf�gung stellen. Dies wird realisiert, indem der Service Discovery Database (SDDB) des lokalen Bluetooth-Ger�ts ein sogenannter Service Record hinzugef�gt wird, der den angebotenen Dienst beschreibt. Nachdem der Service registriert wurde, wartet der Server auf einen Client, der die Verbindung zu dem gew�nschten Service initiiert [M+05, S. 24].

2.5.6  Discovery

Da die meisten mit Bluetooth ausgestatteten Ger�te tragbar sind, wird ein Mechanismus ben�tigt, der es erm�glicht, dass sich zwei oder mehr Ger�te finden k�nnen. Dieser Prozess wird als Discovery bezeichnet. Es existieren hierbei zwei Discovery-Arten; Device- und Service-Discovery [M+05, S. 27].

2.5.6.1  Device Discovery

Ger�te k�nnen von einer Applikation mit Hilfe der Funktion startInquiry(), die nicht blockierend implementiert ist, oder mit ihrem blockierenden �quivalent retrieveDevices() gefunden werden. Die retrieveDevices() Methode ist jedoch nicht in der Lage, “neue” Ger�te zu finden, sondern liefert lediglich eine Liste der dem Ger�t bereits bekannten Ger�te. Das sind Ger�te, die bspw. in einer vorhergehenden Suche bereits gefunden wurden oder Ger�te die als Pre-known klassifiziert sind. Als Pre-known Ger�te bezeichnet man Ger�te, die im BCC definiert wurden. Die retrieveDevices() Methode f�hrt keine aktive Suche durch, stellt aber die M�glichkeit dar, eine Liste von Ger�ten zu erhalten, die sich im n�heren Umfeld befinden k�nnten. Wird die startInquiry() Methode verwendet, muss zus�tzlich ein Listener implementiert werden, der benachrichtigt wird sobald ein neues Ger�t gefunden wurde. Der zu implementierende Listener ist im Interface javax.bluetooth.DiscoveryListener definiert. Die Klasse javax.bluetooth.DiscoveryAgent bietet die entsprechenden Methoden zur Ger�te- und Dienstsuche an [M+05, S. 28f].

2.5.6.2  Service Discovery

Nachdem ein Ger�t mittels einer Device Discovery ausfindig gemacht werden konnte, ist es i. d. R. von Interesse herauszufinden, ob auf dem gefundenen Ger�t der gew�nschte Dienst vorhanden ist. Die Suche nach einem solchen Dienst wird als Service Discovery bezeichnet. Eine lokale Service-Suche wird vom JSR-82 API allerdings nicht unterst�tzt. Die in eine Service-Suche involvierten Klassen sind Folgende [M+05, S. 30f]: In der Spezifikation ist zu jeder der aufgelisteten Klassen Beispielcode zu finden, der die Anwendung der Klassen verdeutlicht.

2.5.7  Generic Access Profile (GAP)

Im Kapitel 7 der JSR-82 Spezifikation sind die Klassen aufgef�hrt, die dazu dienen, Eigenschaften des Ger�ts zu manipulieren, die Teil des GAPs29 sind. Die Standardmechanismen zur Manipulation des lokalen Ger�ts befinden sich in der Klasse javax.bluetooth.LocalDevice, die Methoden um Informationen von einem entfernten Ger�t zu erhalten befinden sich in der Klasse javax.bluetooth.RemoteDevice. Die Klasse javax.bluetooth.DeviceClass definiert Werte, mit Hilfe derer es m�glich ist den Ger�tetyp sowie den Typ des Angebotenen Dienstes zu identifizieren [M+05, S. 50f].

2.5.8  Kommunikation

Um den Dienst eines anderen Bluetooth-Ger�ts in Anspruch nehmen zu k�nnen, m�ssen beide Ger�te in der Lage sein miteinander zu kommunizieren. Dies erfordert die Kenntnis eines gemeinsamen Kommunikationsprotokolls, sodass verschiedene Applikationen miteinander kommunizieren k�nnen. Der JSR-82 stellt APIs zur Verf�gung, mit deren Hilfe man Verbindungen zu RFCOMM, L2CAP oder OBEX Diensten herstellen kann. Das Generic Connection Framework (GCF)30 der CLDC stellt dabei den Basismechanismus der Protokollimplementierung dar (Vgl. : [M+05, S. 63]).

2.5.8.1  Serial Port Profile

Das RFCOMM Protokoll emuliert mehrere RS-232 Ports zwischen zwei Bluetooth Endger�ten. Die Bluetooth-Adressen der beiden Endger�te identifizieren hierbei die RFCOMM Sitzung. Zwischen zwei Ger�ten darf immer nur eine Sitzung bestehen, die jedoch �ber mehr als eine Verbindung verf�gen darf. Die Anzahl gleichzeitiger Verbindungen ist hierbei abh�ngig von der jeweiligen Implementierung. Eine Applikation, die einen Dienst auf Basis des Serial Port Profiles (SPP) anbietet, wird dabei als SPP Server, eine die zu einem solchen eine Verbindung initiiert, als SPP Client bezeichnet. Nachdem eine Verbindung hergestellt ist, k�nnen Daten in beiden Richtungen ausgetauscht werden. Die Aushandlung der Verbindungsparameter sowie der Flusskontrolle muss hierbei automatisch zwischen den an der Kommunikation teilnehmenden Endger�ten von der SPP Implementierung gehandhabt werden (Vgl. : [M+05, S. 64ff]).

Innerhalb eines Code-Fragments sind SPP Verbindungen (Client- oder Serverseitig) am String "btspp://" innerhalb von Connector.open() zu erkennen. Stellt die Applikation einen Dienst zur Verf�gung, ist "btspp://localhost" zu Beginn des Strings enthalten.

URLs, die einen Verbindungsaufbau zu einem entfernten Ger�t erm�glichen, sind nach folgendem Schema aufgebaut:

{scheme}:[{target}{params}]

Um RFCOMM zu benutzen ist das Schema ({scheme}), das f�r Client und Server verwendet wird, btspp. Die beiden anderen Platzhalter ({target} und {params}) unterscheiden sich, je nachdem, ob die Applikation einen Client oder Server darstellt. Alle g�ltigen Parameter, die in einem RFCOMM, L2CAP oder OBEX �ber RFCOMM Verbindungskennzeichner vorkommen k�nnen, sind in [Tab.: 2.7] aufgelistet.


Name Beschreibung Zul�ssige Werte Client oder Server
master Gibt an, ob das Ger�t master der Verbindung sein muss. true, false Beide
authenticate Gibt an, ob das entfernte Ger�t authentifiziert werden muss bevor eine Verbindung hergestellt werden kann. true, false Beide
encrypt Gibt an, ob die Verbindung verschl�sselt werden muss. true, false Beide
authorize Gibt an, ob alle Verbindungen zu diesem Ger�t authorisiert werden m�ssen um den Dienst zu nutzen. true, false Server
name Der Name des angebotenen Dienstes, der in der SDDB gespeichert wird. Jeder g�ltige String Server
Tabelle 2.7: G�ltige Parameter f�r RFCOMM Verbindungskennzeichner (Vgl. : [BJJ04, S. 59, Tabelle 4.1 Valid Parameters for RFCOMM Connection Strings])

2.5.8.2  Object Exchange Protocol (OBEX)

Das OBEX Protokoll wurde urspr�nglich von der Infrared Data Association (IrDA)31 entwickelt, um Objekte auf einen Client oder Server zu “schieben” (push) oder sie von diesem zu “ziehen” (pull). Um Objekte zu transferieren, etabliert OBEX zun�chst eine Sitzung. Eine OBEX Sitzung beginnt mit einer CONNECT Anforderung und endet mit einer DISCONNECT Anforderung. W�hrend die Sitzung etabliert ist, kann der Client Objekte vom Server holen (GET) oder Objekte am Server ablegen (PUT). Diese Objekte k�nnen Dateien, Visitenkarten (vCards32) oder Byte-Arrays darstellen. Indem der Client das SETPATH Kommando sendet, kann er den Server dazu veranlassen, sein aktuelles Verzeichnis zu wechseln (Vgl. : [M+05, S. 93]).

OBEX skaliert sehr gut, egal ob es sich um grosse oder kleine Dateien handelt die �bertragen werden m�ssen. Erreicht wird dies dadurch, dass OBEX die zu �bertragenden Daten in mehreren Paketen schickt. Sobald der Client eine PUT oder GET Anforderung sendet, wird eine OBEX-Operation gestartet. Diese Operation besteht solange, bis die Datei vollst�ndig �bertragen ist oder ein Fehler eintritt. Um eine PUT Operation durchzuf�hren, bricht der Client (Applikation oder Protokoll-Stack) das zu sendende Objekt in kleine St�cke und sendet jedes einzeln an den Server. Der Client sendet das nachfolgende St�ck nicht bevor der korrekte Versand des Vorg�ngerst�cks best�tigt wurde (Vgl. : [M+05, S. 93]).

OBEX bietet, wie das Hypertext Transfer Protocol (HTTP)33, die M�glichkeit, zus�tzliche Informationen zwischen Client und Server auszutauschen. Diese zus�tzlichen Meta-Informationen befinden sich im OBEX-Header, der im vergleich zum HTTP-Header lediglich Byte-Werte akzeptiert34. OBEX bietet Standard-Header an, wie z. B. Name-, L�nge- und Beschreibungsfelder. Zus�tzlich existieren noch 64 Header die vom Anwender definiert – und belegt – werden d�rfen (Vgl. : [M+05, S. 93]).

Das vom JSR-82 definierte API erlaubt es einer Applikation OBEX-Operationen zwischen Client und Server auszuf�hren. Allerdings adressiert das API das verbindungslose OBEX nicht, wie dies in der OBEX Spezifikation der IrDA der Fall ist. Das bereitgestellte OBEX API stellt die in [Tab.: 2.8] dargestellten Operationen zur Verf�gung.


Operation Beschreibung
CONNECT Stellt die Verbindung zum Server her.
PUT �bertr�gt Daten vom Client an den Server.
GET �bertr�gt Daten vom Server an den Client.
SETPATH �ndert das Arbeitsverzeichnis auf dem Server.
ABORT Bricht eine PUT oder GET Operation ab.
CREATE-EMPTY Erzeugt ein leeres Objekt mit dem im Header angegebenen Namen auf dem Server.
PUT-DELETE L�scht das im Header angegebene Objekt auf dem Server.
DISCONNECT Beendet die Verbindung zum Server.
Tabelle 2.8: OBEX Operationen

Da das OBEX Protokoll �ber verschiedene Transportprotokolle verwendet werden kann, muss der String, der die Verbindung spezifiziert, das Transportprotokoll beinhalten. Die URL, um eine Verbindung zu einem entfernten Ger�t herzustellen, hat folgenden Aufbau:

{scheme}:[{target}{params}]

Um die zus�tzliche Verwendung des Protokolls bei OBEX deutlich zu machen, wird, mit Ausnahme von OBEX �ber RFCOMM, folgendes Schema verwendet:

{transport}obex://{target}{params}.

Wird RFCOMM als Transportprotokoll verwendet, ist der als {scheme} gekennzeichnete Teil mit btgoep zu ersetzen und {target} spezifiziert die Bluetooth-Adresse, sowie die RFCOMM Kanalnummer. Alle f�r RFCOMM g�ltigen Parameter ({params}) sind ebenfalls f�r OBEX �ber RFCOMM g�ltig35. Ein g�ltiger OBEX �ber RFCOMM Verbindungskennzeichner hat also die Form:

Client: btgoep://0123456789ab:1;authenticate=yes
Server: btgoep://localhost:DEADBEEFCAFEBABE5DADD115A1D1DEAD

Die von den anderen Verbindungskennzeichnern differente Schreibweise r�hrt daher, dass das OBEX Protokoll mit Hilfe des in der Bluetooth-Spezifikation definierten Generic Object Exchange Profiles (GOEP)36 realisiert wurde [M+05, S. 98].

2.5.9  JSR-82 Sicherheit

Im JSR-82 werden Methoden beschrieben, die es erm�glichen, eine gesicherte Bluetooth-Kommunikation herzustellen. Es ist m�glich, bereits beim Aufbau der Verbindung, durch einen entsprechend angepassten Connection String, die Sicherheitsparameter festzulegen. Methoden der javax.bluetooth.RemoteDevice Klasse k�nnen benutzt werden, um Sicherheits�nderungen der bestehenden Verbindung zu veranlassen. Die Definition und Belegung der Parameter ist sehr umfangreich und wird in Kapitel 8 des JSR-82 detailliert beschrieben. Die Beschreibung umfasst dabei, wie die Sicherheitsanforderungen bereits beim Verbindungsaufbau festgelegt oder Client und Server Authentifikations- oder Verschl�sselungsforderungen stellen k�nnen [M+05, S. 52ff].


1
Engl. : baseband, transceiver, protocolstack
2
Industrial, Scientific, and Medical Band [Wik06c]
3
Illustration: [Bec05, Folie 9]
4
Siehe [Wik06d]
5
Frequenzbereich des Nutzsignals (siehe [Wik06a])
6
engl.: Logical Transport, siehe [Kapitel 2.1.2.1]
7
Der LM ist verantwortlich f�r die Erzeugung, Modifikation und Freigabe logischer Verbindungen [Blu03, Architecture, S. 23; PDF, S. 99].
8
Kurz: QoS, bezeichnet ein Verfahren, das einem (Paket-)Dienst eine Mindestbandbreite zusichert.
9
Das Host Controller Interface (HCI) befindet sich zwischen logischem und L2CAP-Layer und stellt eine einheitliche Schnittstelle zum Bluetooth-Controller dar.
10
Sogenanntes Challenge-Response Verfahren (siehe [FS06, S. 56])
11
Siehe [Sch96, S. 392ff]
12
Siehe https://www.bluetooth.org/
13
Siehe [Kapitel 2.4]
14
Alle JSRs sind abrufbar unter: https://www.jcp.org/en/home/index
15
Siehe https://java.sun.com/products/cldc/
16
Siehe [C+05]; Einordnung siehe [Abb.: 2.3]
17
Siehe [Kapitel 2.4]
18
Programme, die auf einem MID ausgef�hrt werden k�nnen.
19
JSR-118: [VW02]; JSR-37 [Van00]
20
Siehe [Kapitel 2.3]
21
Siehe [Kapitel 2.4.1]
22
Parallele Aufrufe einer Funktion auf einen Datensatz/-block f�hren nicht zu Inkonsistenzen dessen.
23
Siehe [Kapitel 2.3.2]
24
Siehe https://www.jcp.org/en/jsr/detail?id=82
25
Version 1.1 kann unter https://www.bluetooth.org/spec/ angefordert werden.
26
Siehe [Kapitel 2.5.8.2]
27
Siehe [Kapitel 2.5.8.1]
28
Gross-/Kleinschreibung ist zu beachten.
29
Siehe [Kapitel 2.1.5]
30
Siehe [Kapitel 2.3.1]
31
Siehe https://www.irda.org/
32
Datenformat f�r eine elektronische Visitenkarte
33
Siehe https://www.ietf.org/rfc/rfc2616.txt
34
OBEX wird aus diesem Grund auch gerne als bin�res HTTP bezeichnet.
35
Siehe [Tab.: 2.7]
36
Spezifikation: [Blu05]
OBEX Object Passing Home (PDF) CCGLogo

Previous Up Next