Objectives of the Bluetooth Technology

Bluetooth

Origin of the name Harald I Bleutooth (in Danish, Harald Blåtand) (b. c. 910 d. c. 987), king of Denmark was credited with the first unification of Denmark and Norway Ericsson, inspired on the history of Harald I, proposed a new technology which aims at link different devices from different manufacturers, but at low-cost

Objectives of the Bluetooth Technology Cable replacement Ericsson decided to investigate the feasibility of a low-power and low cost radio interface between mobile phones and their accessories Today, the Bluetooth technology is supported by the Bluetooth SIG (Special Interest Group), founded by Ericsson, IBM, Intel, Nokia and Toshiba in 1998 Personal Area Networks Ad hoc networks

Advantages and Disadvantages Advantages Eliminate wires and cables between stationary and mobile devices Facilitates both data and voice communication It is inexpensive Possibility of automatically establish communication Automatically create ad hoc networks Disadvantages Low rate Low range? Security

The horizontal and vertical approaches of Bluetooth Bluetooth architecture is based on the OSI model (horizontal layered approach). The horizontal layered approach is used to standardize the physical and logical link related functions However, bluetooths add a vertical approach, which is based on an application viewpoint. Elimination of wires leads to the implementation of a large number of applications The vertical approach is used to tailor each Bluetooth device to its application The vertical approach gave birth to what is known as profile

Bluetooth architecture The Bluetooth protocol stack is divided in 2 parts, separated by the HCI (Host Controller Interface) The lower part is implemented in the Bluetooth device The transport layer The upper part is implemented in the host to which the Bluetooth device is attached The middleware layer The application layer

Bluetooth architecture The Bluetooth SIG has given seven different protocols that any Bluettoth device need to implement The Radio protocol The Baseband protocol The LMP protocol The HCI protocol The L2CAP protocol The RFCOMM protocol The SDP protocol

The Radio Layer Bluetooth operates in ISM band at 2.4 GHz Modulation technique is GFSK Bandwidth-bit period product, BT, = 0.5 Modulation index between 0.28 and 0.35 Other modulation techniques has been proposed pi/4-dqpsk and 8-DQPSK (Bluetooth 2.0)

The Radio Layer 3 power classes Class 1 maximum of 100mW and a minimum of 1mW Expected range of 100m This device is capable of controlling power, in steps of 2 to 8dB Class 2 Maximum of 2.5mW and a minimum of 0.25 mw Expected range 10m Power control is optional Class 3 Maximum of 1 mw Expected range 10cm Power control is optional

The Baseband Layer The baseband of Bluetooth defines the basic Bluetooth network The piconet The piconet is a collection of two or more devices sharing the same physical channel One master can control up to seven slaves One device can participate in several piconets

The Baseband Layer The baseband of Bluetooth defines the basic Bluetooth network The scatternet Interconnection of several piconets Device participating in two or more piconets can rely data, however, this relying mechanism is not supported by the official Bluetooth protocol stack

The Baseband Layer Bluetooth specification defines up to 4 physical channel A physical channel is a pseudo-random code that drives the frequency hopping sequence Time Division Duplex (TDD) scheme The hopping rate is 1,600 hops/s in the connection mode, and 3,200 hops/s in the inquiry and page modes The frequency band is divided in 79 channels of 1 MHz bandwidth

The Baseband Layer Each channel is divided in TS of 625 microsecs Packets can take 1, 3 or 5 TS and a maximum payload length of 2745 bits The master begins sending data in an odd-numbered TS, and the slave will send data in the next available even-numbered TS

The 4 physical channels The basic piconet channel Used by connected devices during normal operation The adapted piconet channel Used to avoid interference and easy coexistence with other systems working in the same band A subset of the 79 available channels is used (minimum 20) Slaves use the same frequency as the master in its preceding transmission The inquiry scan channel Used in inquiry mode in order for a device to be discovered The paging scan channel Used to page a connectable device

Physical Links There are two physical links The active physical link The parked physical link Physical links provide the following features Power control Multi-slot packet control Encryption

Logical Links There are 5 logical transports Synchronous Connection-Oriented (SCO) logical transport Extended Synchronous Connection-Oriented (esco) logical transport Asynchronous Connection-Oriented (ACL) logical transport Transmission employs an ARQ protocol Active Slave Broadcast (ASB) logical transport Control message for the whole piconet Parked Slave Broadcast (PSB) logical transport Control message for the whole piconet

Packet types TYPE NAME DESCRIPTION Control ID Carries Device Access Code (DAC) or inquiry access code (IAC). Occupies one slot. Control NULL NULL packet has no payload. Used to get link information and flow control. Occupies one slot. Not acknowledged. Control POLL No payload. Acknowledged. Used by master to poll the slaves to know whether they are up or not. Occupies one slot. Control FHS A special control packet for revealing Bluetooth device address and the clock of the sender. Occupies one slot. SCO HV1 Carries 10 information bytes. Typically used for voice transmission. 1/3 FEC encoded. Occupies one slot. SCO HV2 Carries 20 information bytes. Typically used for voice transmission. 2/3 FEC encoded. Occupies one slot. SCO HV3 Carries 30 information bytes. Typically used for voice transmission. Not FEC encoded. Occupies one slot. SCO DV Combined data-voice packet. Voice field not protected by FEC. Data field 2/3 FEC encoded. Voice field is never retransmitted but data field can be. ACL DM1 Carries 18 information bytes. 2/3 FEC encoded. Occupies one slot. ACL DH1 Carries 28 information bytes. Not FEC encoded. Occupies one slot. ACL DM3 Carries 123 information bytes. 2/3 FEC encoded. Occupies three slots. ACL DH3 Carries 185 information bytes. Not FEC encoded. Occupies three slots. ACL DM5 Carries 226 information bytes. 2/3 FEC encoded. Occupies five slots. ACL DH5 Carries 341 information bytes. Not FEC encoded. Occupies five slots.

Low-Power Modes Hold mode Physical link is only active during slots reserved for the operation of synchronous links. Either, the master or the slave can require to establish a hold mode Sniff mode Device wakes up periodically to communicate with the master or engage any activity on another physical channel SCO and esco are not affected Reserved for slaves Parked state Used to stay synchronized with the master without being an active member of the piconet All logical links are disable, except the PSB link

Host Controller Interface HCI provides an independent implementation of the hardware A standard interface to the Link Manager access over standard transport layer (e.g. USB) between the Bluetooth device and the host controller

Host Controller Interface HCI is composed by three main modules The HCI firmware, which implements the commands that will be executed by the Bluetooth hardware The host controller transport layer, which is responsible for transferring commands and data over an specific transport layer (e.g. USB) The HCI driver, which provides the interface between the HCI firmware and the Bluetooth upper layers

Host Controller Interface Bluetooth host Higher Layer Driver HCI Driver Physical bus (USB, etc.) driver Physical bus (USB, etc.) firmware Bluetooth controller HCI firmware Link Manager firmware Baseband controller hardware

Logical Link Control and Adaptation Protocol (L2CAP) L2CAP provides L2CAP (logical) channels, mapped to L2CAP logical links, mapped on ACL transport Multiplexing Up to 64 kb service data unit (payload) Segmentation and reassembly operations Per-channel flow control and retransmission The endpoint of a L2CAP link is known like the CID

Logical Link Control and Adaptation Protocol (L2CAP) L2CAP does not transport voice or synchronous data, although VoIP would be carried by L2CAP L2CAP provides asynchronous connectionoriented and connectionless channels, with some QoS support Basic L2CAP mode, which is the default mode Basic flow control Flow control mode Retransmission mode

Higher Layer Protocols The main higher layers are RFCOMM. This provides serial port emulation over L2CAP. It can emulate up to 60 connections between two Bluetooth devices The Bluetooth Network Encapsulation Protocol (BNEP). It offers support for IP-based networking protocols (including Ipv6) BNEP works over RFCOMM Telephony Control Protocol Specification-Binary. Used for telephony applications. It provides call control, group, management, etc

Higher Layer Protocols The main higher layers are Audio. Support for audio applications, offering a 64 Kbps link. Payload can be protected by FEC and packets. OBject Exchange Protocol (OBEX). Synchronization and file transfer Audio Video Distribution (Control) Transfer Protocol (AVDTP and AVCTP). It works over L2CAP

Service Discovery Protocol SDP enables a Bluetooth device to Inquire what services are available in its environment and their characteristics. Inform the list of services provided by itself Each Bluetooth device maintains a list of Service Records. Each record contains the list of attributes of a given application that characterize the provided service Interoperability between Bluetooth devices is enabled with the introduction of Profiles

Generic Access Profile GAP defines the generic procedures to Discover Bluetooth devices Connect Bluetooth devices Use different levels of security GAP describes the use of the lower layers of the Bluetooth protocol stack, as well as some higher layer protocols GAP defines the generic terms that can be presented to the customers

Generic Access Profile The Bluetooth device address (BD_ADDR) The baseband address coded on 48 bits The Bluetooth device name Coded on 248 bytes maximum The Bluetooth passkey (Bluetooth PIN) Used to authenticate two Bluetooth devices Maximum length = 16 bytes The class of device Types of services supported by the device

Generic Access Profile Bluetooth defines 3 types of discoverability modes Nondiscoverable mode It will not respond to inquiry requests Limited discoverable mode Devices that will respond during only specific periods of time or specifics Inquiry Access Codes (IAC) General discoverable mode The Bluetooth device will always respond to inquiry requests Connectability modes Connectable mode Device periodically enters the PAGE_SCAN state Non-connectable mode

Generic Access Profile Pairing modes Non-pairable mode. Devices is non-bondable. A link cannot be established between two devices Pairable mode. Device is bondable User initiate the bonding procedure and enter the passkey 5 procedures to initiate a connection General/Limited inquiry. Get the BD_ADDR, clock and class of discoverable devices Name discovery. Get the name of Bluetooth devices Device discovery. General/Limited inquiry + name discovery Bonding. Create a relation between two Bluetooth devices

Generic Access Profile After discovery, 3 different procedures can take place Link establishment. Establishes a physical link between two devices (ACL) Channel establishment. Establishes a Bluetooth logical link using L2CAP Connection establishment. Establish a connection between applications on two Bluetooth devices 3 security modes Mode 1. non security Mode 2. service level enforced security Mode 3. link level enforced security

Addresses of Bluetooth Devices LSB Company Assigned Company_Id LAP UAP NAP MSB Bluetooth Device Address (BD_ADDR) Lower Address Part (LAP) 24 bits Upper Address Part (UAP) 8 bits Non-significant Address Part (NAP) 16 bits Active Member Address (AM_ADDR) Identify active piconet members (3 bits) Broadcast address = 000 Parked Member Address (PM_ADDR) Identify parked devices (8 bits) Access Request Address (AR_ADDR) The parked device use this address to become an active member

Packet format 3 types of access code Device AC (page, page scan) Channel AC (identify the piconet) Inquiry AC General IAC (GIAC) 0x9E8B33 Dedicated IAC (DIAC) from 0x9E8B00 to 0x9E8B3F

Packet format Header AM_ADDR. Active Member ADDR TYPE. (SCO, ACL or commands) FLOW (flow control) ARQ 0 = stop; 1 = continue 1 Packet successfully received. 0 otherwise SEQN Sequence bit Header Error Control (HEC) G(X) = X^8 + X^7 + X^5 + X^2 + X + 1

ACL packets Payload header. Single slot = 8bits, multi-slots = 16bits LLID. Logical channel Flow. Flow control at the L2CAP level Length. Payload size (in bytes)

FHS packet PARITY BITS [34] LAP [24] UNDEFINED [2] SR [2] SP [2] UAP [8] NAP [16] CLASS [24] AM_ADDR [3] CLK_(27-2) [26] PAGE SCAN MODE [3] PARITY BITS LAP UNDEFINED SR The 34-bit parity bits form the first part of the sync word of the access code. The LAP of the unit that sends the FHS packet. Undefined as of now. Scan repetition. Interval between two consecutive page scan windows. SP UAP NAP CLASS OF DEVICE AM_ADDR CLK_(27-2) PAGE SCAN MODE Scan period. Period in which mandatory page scan mode is applied after transmission of inquiry response message. UAP of the unit which sends the FHS packet. NAP of the unit which sends the FHS packet. Class of device has not been defined yet. This 3-bit field contains the member address the recipient shall use This field contains the value of the native clock unit that sends the FHS packet. Scan mode used by default

Discovery and Connection Inquiring and paging Master: 3200 hops/s Slave: 1.28 hops/s

Bluetooth synchronization Every device has its own native clock (CLKN) The clock is implemented with a 28-bit counter driven by a low power oscillator when in STANDBY, Park, Hold and Sniff mode Driven by a crystal oscillator In a piconet, the master's CLKN (known like CLK) synchronizes the network A paging device estimated the CLKN of the receiver (known like CLKE) The slaves must estimate CLK to synchronize with the master

Security considerations In [Shaked05], the authors describes a passive attack to find the PIN used during the pairing process (Security Mode 3) Bluetooth initialization procedure Creation of an initialization key (Kinit) Creation of a link key (Kab) authentication # Y. Shaked and A. Wool. Cracking the Bluetooth PIN. In Proc. 3rd USENIX/ACM Conf. Mobile Systems, Applications, and Services (MobiSys), pages 39-50, Seattle, WA, June 2005.

Security considerations In [Shaked05], the authors describes a passive attack to find the PIN used during the pairing process (Security Mode 3) Bluetooth initialization procedure Creation of an initialization key (Kinit) Creation of a link key (Kab) authentication # Y. Shaked and A. Wool. Cracking the Bluetooth PIN. In Proc. 3rd USENIX/ACM Conf. Mobile Systems, Applications, and Services (MobiSys), pages 39-50, Seattle, WA, June 2005.

Security considerations In [Shaked05], the authors describes a passive attack to find the PIN used during the pairing process (Security Mode 3) Bluetooth initialization procedure Creation of an initialization key (Kinit) Creation of a link key (Kab) authentication # Y. Shaked and A. Wool. Cracking the Bluetooth PIN. In Proc. 3rd USENIX/ACM Conf. Mobile Systems, Applications, and Services (MobiSys), pages 39-50, Seattle, WA, June 2005.

Security considerations # Src Dst Data Length Notes 1 A B IN_RAND 128b plaintext 2 A B LK_RANDa 128b XORed with Kinit 3 B A LK_RENDb 128b XORed with kinit 4 A B AU_RANDa 128b plaintext 5 B A SRES 32b plaintext 6 B A AU_RANDb 128b plaintext 7 A B SRES 32b plaintext # Y. Shaked and A. Wool. Cracking the Bluetooth PIN. In Proc. 3rd USENIX/ACM Conf. Mobile Systems, Applications, and Services (MobiSys), pages 39-50, Seattle, WA, June 2005.

Bluetooth & Linux

Bluetooth stacks for Linux Implementations of the Bluetooth protocol stack for Linux OpenBT Affix BlueDrekar BlueZ BlueZ, initially developed by Qualcomm, is now an open source project under the terms of GPL (http://www.bluez.org/) Available in several Linux distributions

BlueZ tools BlueZ provides six command-line tools that allow to configure a Bluetooth device and debug the applications hciconfig Configure the basic properties of Bluetooth adapters If is invoked without arguments, it will display the status of the current adapters attached to the computer Bluetooth devices are usually identified by hcix, where X is the number of the device hcitool Search and detect nearby bluetooth devices Test and show information about low-level Bluetooth connections

BlueZ tools sdptool Browsing and searching services advertised by nearby devices Basic configuration of the SDP services offered by the local machine hcidump For low-level debugging of connection setup and data transfer l2ping The ping tool for Bluetooth devices uuidgen Generates UUIDs Useful to advertise applications with non standard UUID

References Linux Unwired. Roger Weeks, Brian Jepson, Edd Dumbill. O'REILLY. 2004 From WPANs to Personal Networks. Technologies ans Applications. Ramjee Prasad et Luc Deneire. Artech House. 2006