The Bluetooth specification covers all aspects of
Bluetooth implementation, including radio operation, topology of
Bluetooth networks, individual Bluetooth device identification, and
modes of operation. Additionally, the specification defines the various
components of the Bluetooth stack and outlines the concept of Bluetooth
profiles for aggregating and packaging functions associated with common
Bluetooth use cases.
Radio Operation and Frequency
Bluetooth radios operate in the
unlicensed ISM band at 2.4GHz (also used by 802.11 networking equipment,
microwave ovens, and many cordless phones). Bluetooth radios implement
frequency-hopping spread spectrum for data transmission. Transmission
rates are up to 1Mbps for most devices, although devices running Enhanced Data Rate (available with Bluetooth versions 2.0 and 2.1) can have rates up to 2Mbps or 3Mbps.
The Bluetooth
specification defines three transmitter power classes. The class of
radio used for a Bluetooth device is determined primarily based on usage
and proximity requirements and power availability (that is, AC powered
versus battery powered). Table 1 summarizes the power classes defined by Bluetooth.
Table 1. Bluetooth Radio Power Classes
| Power Class | Maximum Output Power | Designed Operational Range | Sample Devices |
|---|
| 1 | 100 mW (20 dBm) | ~ 330 feet | Bluetooth access points, dongles |
| 2 | 2.5 mW (4 dBm) | ~ 33 feet | Keyboards, mice |
| 3 | 1 mW (0 dBm) | ~ 3 feet | Mobile phone headsets |
Note that in addition to the
maximums specified by each power class, communicating Bluetooth devices
can also negotiate the power of the radio link used for communication,
which can help conserve power and optimize connectivity for particular
links.
Bluetooth Network Topology
Much like 802.11a/b/g networking,
Bluetooth devices can connect in an infrastructure mode (via a
centralized Bluetooth access point/base station) or in ad hoc mode,
where Bluetooth devices make dynamic connections among themselves
without the aid or use of a centralized network infrastructure. Ad hoc
mode is much more common and better suited for Bluetooth’s WPAN
connectivity goals and is the networking topology that this article focuses on.
Bluetooth devices organize themselves dynamically in network structures called piconets.
Piconets contain two or more Bluetooth devices within physical range of
each other that share a frequency-hopping sequence and an operating
channel. Typical examples of Bluetooth piconets would be a mobile phone
with a wireless headset or a desktop computer with a Bluetooth keyboard
and mouse.
Each piconet has one device called the master
(which establishes the network’s operating parameters) and up to seven
active slave devices. Through various network and radio control
techniques, devices are able to belong to multiple piconets
simultaneously, although a device may only be a master in one piconet. A
scatternet is an
arrangement of piconets where one or more devices acts as a master in
one piconet and a slave in one or more additional piconets.
Figure 1 illustrates some typical piconet/scatternet arrangements.
Device Identification
Bluetooth
uses a 48-bit identifier, similar to a MAC address for an Ethernet
adapter, for device identification. This identifier is referred to as
the Bluetooth device address
(BD_ADDR). The first three bytes of the BD_ADDR are specific to the
manufacturer of the Bluetooth radio, with identification assignments
controlled by the IEEE Registration Authority (see page 232 of Core
Specification v2.1 + EDR on the Bluetooth website).
Modes of Operation
The Bluetooth specification
outlines a variety of operational modes, the configuration of which will
have a direct impact on device security. These operational modes
specify options for discoverability, connectability, and bondability
(often referred to as pairability).
Discoverability Modes
Discoverability
refers to whether or not the configured device will respond to
discovery inquiries from other Bluetooth devices. The defined
discoverability modes include:
Non-discoverable
Devices in this mode do not respond to inquiry scans from other
devices. Note that this does not mean that the devices cannot be
connected to (this characteristic is specified and controlled by the
Bluetooth connectability modes).
Limited discoverable mode This mode is used by devices that need to be discoverable for a limited amount of time.
General discoverable mode
This mode is used by devices that are continuously discoverable by
other devices. Devices in either limited or general discoverable mode
periodically listen to an inquiry physical channel and respond to
inquiry scans with a set of connection configuration information that
allows the scanning device to begin to initiate a connection with the
responding device.
Connectability Modes
Connectability refers
to whether or not the configured device will respond to paging from
other devices (that is, requests to initiate a Bluetooth connect). The
defined connectability modes include:
Non-connectable mode
Devices in this mode never enter the page scan state, meaning they will
never receive/acknowledge/respond to a page request and are not able to
establish connections based on inbound page requests.
Connectable mode
Devices in this mode will periodically enter the page scan state. This
means that the device listens for pages on the page scan physical
channel and will respond to pages (connection requests).
Pairability/Bondability Modes
Pairability refers to whether
a device is capable of bonding/pairing with another Bluetooth device.
The defined bondability modes include:
Non-bondable mode Devices in this mode do not respond to bonding requests and will not pair with other devices.
Bondable mode
Devices in bondable mode will allow pairing with another Bluetooth
device. Note that devices in bondable mode may require additional
security prior to pairing (that is, PIN entry/authentication).
Bluetooth Stack
The
Bluetooth specification organizes the technology in a layered stack
similar to the OSI and DoD TCP/IP models. This layered model supports
vendor interoperability and allows developers to encapsulate
functionality and services in a clean and predictable fashion. A
generalized version of the Bluetooth stack is shown in Figure 2
(for a more detailed discussion of the Bluetooth stack, see the “Core
System Architecture” section of the Bluetooth specification (see page 94
of Core Specification v2.1 + EDR on the Bluetooth website).
Bluetooth Module Layers
The Bluetooth controller
consists of the radio hardware radio components of the Bluetooth device.
Starting at the bottom of the stack is the Bluetooth radio. This is
where RF signals are processed. Moving a layer above is the
baseband/link controller level, which handles link synchronization and
data formatting between the radio and upper layers, among other tasks.
The link manager level is tasked with establishing and maintaining links
between Bluetooth devices.
Host Controller Interface (HCI)
The
HCI is an optional implementation component that can be used to
separate higher- and lower-level functions on different processors. When
used, the HCI acts as a consistent interface between the two separate
processors handling upper- and lower-level functions. An example where
an HCI would be implemented is an external Bluetooth dongle on a laptop.
The lower-level (Bluetooth module) functions are likely to be handled
by the dongle, with upper-level functions managed by the laptop’s
Bluetooth stack. The HCI handles communications between the two
components.
Bluetooth Host Layers
The Logical Link Control and
Adaptation Protocol (L2CAP) is the first layer above the HCI. L2CAP is
responsible for multiplexing across multiple higher-level protocols and
packaging and repackaging packets between the formats required by the
various upper and lower protocol layers.
A variety of protocols exists
above the L2CAP layer, including the Service Discovery Protocol (SDP), a
protocol used to locate and identify Bluetooth services, and RFCOMM, a
serial cable emulation protocol. At the top of the stack are the various
applications and profiles offered via Bluetooth.
Bluetooth Profiles
The Bluetooth specification
does not limit implementations to specific uses or applications, but is
instead available to any number of applications for WPAN connectivity,
limited only by the developer’s requirements and creativity. However,
there are a number of common uses that many Bluetooth devices and
applications are designed to fulfill, such as wireless headsets, file
transfer, wireless keyboards, and data synchronization. To address these
common use cases, the Bluetooth SIG has created and published a series
of Bluetooth profiles. These profiles specify the communication
interfaces between devices for a given service over Bluetooth.
The Bluetooth profile model
also allows for new profiles to be constructed on top of existing
profiles. This promotes efficiency and reuse and creates a kind of
profile hierarchy. An example of this hierarchy constructed by building
on existing profiles is shown in Figure 3.
In this example, we begin with
the Generic Access Profile (GAP), which is the basis of all Bluetooth
profiles. The GAP provides the lowest level and fundamental
specifications related to Bluetooth operation and device interaction.
Building on the GAP is the Serial Port Profile, which contains
specifications for serial cable replacement and RS232 emulation. Then,
building on the Serial Port Profile are a variety
of other profiles, including the Hands-Free Profile (which specifies
the operation of hands-free kits for mobile phones) and the Dial Up
Networking Profile (which specifies the provisioning of access to
Internet, dial-up, and other related services over Bluetooth). Note that
this example shows only a small sampling of available Bluetooth
profiles. The Bluetooth SIG publishes profile specifications separately
and out of cycle from the main Bluetooth specification; the currently
available profiles can be accessed via the Bluetooth SIG website (refer
to www.bluetooth.com/Bluetooth/Technology/Building/Specifications/).
From a security
perspective, profiles are a useful construct because each profile’s
services will have varying requirements. For example, devices using the
File Transfer Profile will have different security requirements than
devices using the Cordless Telephony Profile. Accordingly, developers
are then able to use these profiles to customize and determine the
Bluetooth security services that are implemented with their Bluetooth
applications. Several profiles are of particular interest from a
security perspective. These include the PAN Profile, which is provided
to support various types of network access, and the Phone Book Access
Profile (PBAP), which provides services phone book data between devices.
