Bluetooth

Bluetooth

Unlike 802.11, Bluetooth is a technology that operates solely in ad hoc networks. Infrastructure mode is absent from Bluetooth discussions, as are long ranges among stations. Interestingly, Bluetooth gets its name from a Danish Viking king named Blatand, who was king of Denmark around the late 900s. He was responsible for Christianizing Denmark and uniting it with part of Norway. His name indicates nothing about the technology but rather signifies the importance of countries in this region of the world in the wireless industry. In 1998, a little more than one thousand years after his death, five companies, following Ericsson's lead, founded the Bluetooth consortium. These companies, including Intel, IBM, Nokia, and Toshiba, directed the development of Bluetooth specifications with the intention of Bluetooth's being a low-cost wireless transmission standard. Many more companies joined what is now termed the Bluetooth Special Interest Group (SIG); the membership totals around 1,000.

Bluetooth is a de facto standard, as well as a specification for small-form factor, low-cost, short-range radio links among devices. The Bluetooth SIG drives the development of the technology and is attempting to push it to the general telecom, networking, and computer industry markets.

The Bluetooth SIG goal is to integrate Bluetooth in everyday devices, not just cell phones and laptops. SIG operates under the premise that adding Bluetooth technology to a device should increase its cost by only $5 or so. Bluetooth should be capable of functioning in such basic implements as a pen and such complicated devices as a computer or PDA. Bluetooth spares expensive wiring and infrastructure costs but does require stations to be within close proximity of one another to communicate. It enables devices to interoperate with an approximate range of 10 meters. The Bluetooth SIG members intend for Bluetooth to be the dominant technology for connecting all consumer electronic devices. They envision the use of Bluetooth to connect a cordless handset to its phone, a peripheral to a computer, a PDA to a computer, two PDAs to each other, or perhaps even a remote control to a TV via a computer.

In general, devices similar to Bluetooth, which use infrared (IR) as a transmission medium, are reliable, and building the technology into a device requires little cost. These devices do, however, require a line of sight between them, which significantly limits their versatility. Bluetooth itself does not have this same line of sight restriction because it operates over radio instead of light, like other IR-capable devices.

Bluetooth Physical Layer

Bluetooth uses the 2.4GHz frequency band with a frequency-hopping scheme for transmission at a rate of 1,600 hops per second. The 2.4GHz frequency represents the range assigned by international agreement as the communications spectrum for industrial, scientific, and medical (ISM) devices. More familiar devices that operate in the ISM band include baby monitors, garage-door openers, and certain cordless phones.

One method some Bluetooth advocates see as a way to avoid Bluetooth devices' interfering with one another's communication is its frequency-hopping technique. This technique is similar to that employed in the 802.11b standard. The time between two hops in Bluetooth transmissions is called a slot. Each slot utilizes a different frequency, and each device hops among the 79 randomly chosen frequencies. In some countries, the available bandwidth is only 80MHz. In these countries, the hops are spaced out in 1MHz intervals of equal proportion. In countries with smaller bandwidth allowances, where regulations allow only 23 hop carriers, the frequencies are less spaced out from each other. Bluetooth transmits a weak signal, only 1 milliwatt. The most powerful cell phones transmit at about 3 watts. The low power dictates the short 10-meter range from which Bluetooth devices can communicate. The low power combined with frequency hopping is its native protection against security breaches and communication interference. Later in this book, flaws in this theory are discussed, as well as risks.

The Bluetooth technology is structured in ad hoc piconets, networks with two or more devices that don't require infrastructure frameworks (see Figure 3.6). In a Bluetooth piconet, devices are designated master or slave. In any given communication session, a device has the potential to be either a master or a slave. The default method for determining the master is that device which initiates a connection. As many as seven devices can be designated slaves to each master. In some special circumstances (for example, Bluetooth's implementation of profiles, discussed later in this section), devices may need the capability to toggle between master and slave. In such cases, master/slave switch operations have to be added to the basal devices.

Figure 3.6. A piconet

To establish a piconet, an initial device (by default, the master) must first initiate contact with a slave. If the master already knows the address of the intended station, it transmits a page message. This message simply alerts the potential slave that the master wants to connect and establish a communications link. If the master does not know the slave's address, it must first send an inquiry message to determine the station's address. The message requests the slave's MAC address and, after retrieving the information, transmits a page message.

The master in a Bluetooth piconet defines its frequency-hopping sequence. This frequency hopping is similar to the FHSS examined in the 802.11b section. The frequency hopping in this instance, however, is designed to reduce the likelihood of transmissions from one piconet impeding those of a neighboring piconet. It is possible for a master to address a specific slave with its communication and not broadcast a transmission to any active slaves in its piconet. This type of interaction is typically called point-to-point communication. If a master broadcasts a transmission to all active slaves in its piconet, this is termed point-to-multipoint communication. Slaves cannot initiate either type of communication. Slaves cannot even initiate communication with each other. A slave device would have to depart from its current piconet and begin another as a master, at which point it could contact another slave directly from the previous piconet (if that slave, too, has left the original group).

Recall that in 802.11, BSSs could be joined to form ESSs. This network expansion finds a parallel in Bluetooth as well. Piconets can join to form scatternets (see Figure 3.7). For BSSs to expand to ESSs, they must interconnect through an infrastructure, a connection to a similar access point or wired network. In Bluetooth, however, one device that is a member of two would-be joined networks must be simultaneously a slave and a master. This device is an active participant in more than one piconet. The Bluetooth consortium has identified several parameters for the existence of scatternets.

Figure 3.7. A scatternet

In a scatternet, there may be only ten fully loaded piconets (recall that a piconet can contain one master and as many as seven active slaves). If more than ten piconets are connected, communications can be damaged arbitrarily among any devices or piconets. Derivatives of this rule stipulate further limitations. A single device may link two or more piconets into a scatternet. A single device may act as a master in, at most, one piconet but as a slave in (as many as) the other nine. The safest and most common configuration for any given device is designated as a master of one piconet and a slave of another. When a device becomes a slave in more than one piconet, its role becomes increasingly problematic in that it must maintain the clock values of multiple masters. Coordinating these clocks is extremely difficult, and the Bluetooth specifications do not lend themselves to multiple-slave designations.

A limitation in the Bluetooth specifications themselves is that they are general and lacking in architectural and application-level recommendations. This generality makes application development and, subsequently, development of provisions for security exceedingly troublesome. For more technical information about Bluetooth, please see the Bluetooth specifications. For security concerns, the concepts outlined here provide ample grounds on which to identify risks and construct their mitigations at various levels.

Bluetooth Protocol Architecture

The Bluetooth SIG has identified and described core protocols for Bluetooth architecture systems. These protocols are designed to be used in conjunction with existing protocols used in other 802.x systems. The Bluetooth SIG defines four core protocols, as well as several others that support Bluetooth communication. The four core protocols are

1.       Baseband and Link Control (BLC)

2.       Link Manager Protocol (LMP)

3.       Logical Link Control and Adaptation Protocol (L2CAP)

4.       Service Discovery Protocol (SDP)

The BLC layer enables the combined physical links to form a piconet. This layer assists in organizing the frequency hopping by using page and inquiry messages to determine the best path available. Two types of physical links are available to Bluetooth devices: Asynchronous Connectionless (ACL) and Synchronous Connection-Oriented (SCO). In ACL mode, communication is faster because the device is either transmitting or receiving data at any one time and functions only with data packets. In SCO mode, a device can be transmitting and receiving at the same time and can use either audio or data packets. The audio and data packets can be encrypted and can use different levels of error correction.

The LMP layer establishes the physical links and manages encryption or authentication by negotiating baseband packet sizes and exchanging and checking link and encryption keys. The LMP also maintains the connection state of a device in a piconet.

The L2CAP layer operates in higher protocol layers than the BLC. It provides data services, both connection-oriented and connectionless, to the upper-layer protocols with the capability to partition data for sending and reassemble it upon receipt. L2CAP is defined only for ACL links; no support for SCO links is specified by the Bluetooth Specification 1.0.

The fourth core protocol defined in Bluetooth is particularly interesting. The SDP layer fosters the creation of Bluetooth usage scenarios. Bluetooth advocates tout SDP as extremely easy to use when you want to communicate with another Bluetooth device. SDP provides device information, services available, and specific information about querying services so that a device connection can be established. If SDP is configured in what is called discoverable mode, Bluetooth devices are available for other devices to detect. The intended usage model is that two people point their PDAs at each other and instantly communicate. The critical flaw in this example is the assumption that both users want to communicate with each other.

Immediately, security-minded professionals should be able to conceive of hundreds of situations in which this ease of connection is a distinct hindrance to security and privacy. If Barbara is taking the train from New York to D.C. and falls asleep with her Bluetooth-enabled PDA on her lap, she doesn't want Karen, the technical rep from her firm's biggest competitor, simply pointing her own Bluetooth-enabled PDA at Karen's and "communicating" unbeknownst to Karen. If Tom approaches a vending machine and is about to make a phone call on his Bluetooth-enabled cell phone, he doesn't want the vending machine to deduct 50 cents from his checking account simply because there was a direct line of sight between the Bluetooth-enabled cash handler in the vending machine and his cell phone.

These situations represent every security-conscious individual's worst nightmare. The likelihood that they will come to fruition is, as of yet, unknown. Attempts will be made. Of that we can be certain.

Other protocols implemented in a Bluetooth stack are

         Cable Replacement Protocol. Provides transport capabilities for upper-level services.

         Telephony Control Protocol Binary. Defines signaling for data and speech calls.

         Telephony Control Protocol AT commands. Defines fax and modem use in Bluetooth devices.

         A set of adopted protocols (PPP, TCP/UDP/IP, OBEX, WAP). Allows Bluetooth to interoperate with applications that reside in still higher layers on the protocol stack.

For more information on these protocols and Bluetooth's use therein, see the Bluetooth Specification 1.0.

Bluetooth Profiles

Bluetooth is designed to be specific at the lower layers of a protocol stack and more flexible and interoperable at higher levels. The physical and data link layers define Bluetooth's unique characteristics and operations. The Bluetooth SIG has developed several profiles to be used in assisting Bluetooth application development. These profiles are intended to capitalize on Bluetooth's features, as well as enable it to operate with other systems. One Bluetooth profile available enables developers to integrate WAP-compatible applications with Bluetooth devices.

Current SIG working groups are working on a profile to allow Bluetooth devices to be routable. Should this profile be approved and implemented, the 10-meter distance limitation could be eliminated. In this intended profile, if a user is more than 10 meters from an access point but within 10 meters of a user who is closer to the access point, the transmission from the first user can be routed through the second to the access point and back. This profile has not yet been published, so the relative security of the routing cannot be assessed. Assumedly, this could present many dangers. The second user, who is functioning as a router, must be open to receiving traffic and potentially has access to it, given the right equipment and applications.

Another profile worthy of note is the Generic Access Protocol. It is discussed next because it is inextricably linked to discussions of Bluetooth security.

Bluetooth Security

The LMP in the Bluetooth protocol stack handles link-level authentication and encryption mechanisms. These features are based on a shared secret between two devices. This shared secret key is supposedly generated the first time two devices forge a connection and communicate. Bluetooth profiles describe how to use the functions built in to the LMP and BLC protocols compatibly with other non-Bluetooth devices. Three security modes are possible under the instruction of the Generic Access Protocol:

         Security Mode 1. Non-secure. The device does not automatically initiate any security procedures.

         Security Mode 2. Service-level enforced security. The device does not automatically initiate security procedures before the L2CAP layer establishes a channel. This level facilitates ease of interaction with applications that have varied security requirements.

         Security Mode 3. Link-level enforced security. The device initiates security procedures before the link is established at the LMP level.

It almost goes without saying that mode 1 security is a poor solution for any operations or applications that require even the beginnings of security. For the purposes of this text, Security Mode 1 will be disregarded. Bluetooth recommends that either of the other two be implemented in designing Bluetooth architectures and applications. Security Mode 3 is more straightforward than Security Mode 2 in that it initiates security procedures before the link is established. Security Mode 3 does not allow for as much flexibility, so it may not be used as often in systems designed to accommodate different devices, applications, and topologies. Security Mode 2, therefore, provides the most salient topic for examination of Bluetooth security. This mode allows system architects and developers to construct security paradigms and requirements without eliminating the possibility of integrating with devices and applications that have different security requirements.

Before discussing security design paradigms in Bluetooth systems, several points need to be established. In Bluetooth's base form, its technology and specifications do not include inherent security functionality. Options for designing implementations do provide for more secure methods of protecting devices, applications, and architectures. However, each option requires significant expertise on the part of system architects and application developers.

You can design and produce an application without security features, to be used with Bluetooth-enabled devices. A device left configured at mode 1 security, for instance, with no additional security implemented, is wide open to attacks at many levels. A device with mode 2 security, however, can be constructed to limit the risk posed to its users.

Finally, it is important to note that the security paradigms set forth here are merely options available and are intended to provide guidelines for establishing appropriate security architectures in other wireless systems. A wireless architect would be remiss if he did not examine his system with respect to the security procedures explained in Chapter 2, "Security Principles." The system must be dissected before appropriate security methods can be determined. That said, the Bluetooth specifications do not provide for security design suggestions but do provide the foundation on which to build relatively secure systems and communications.

There are two types of relationships between devices. In the first type of relationship, devices can be configured to always trust and recognize each other, perhaps including unrestricted access to each other's available resources. Your cell phone, for instance, can be configured to always recognize and authenticate fully with your PDA and laptop. The second relationship type requires periodic or repeated authentication between your device and others because they do not operate under the same patterns of trust as yours, for instance. This second relationship between devices establishes nonpermanent trust. Access to services on these devices is restricted and subject to consideration for different contexts and resources. The choice between the properties of trust and nonpermanent trust is more or less appropriate in different system configurations.