Security Threats Measures In Bluetooth Enabled Systems Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Bluetooth is an open industry standard for the unlicensed short-range radio communication of voice and data between IT devices, it helps in eliminating any need for wires and cables and permitting ad hoc networking. Earlier it was thought that this type of networking will be the most secure in all but it is not true, through this paper we present an analysis of present scenario of Bluetooth security, security architecture, reasons for the vulnerabilities and recent attacks on Bluetooth enabled systems.

Introduction: Bluetooth is a short-ranged wireless technology operating in free 2.4 GHz ISM band (Industrial Scientific Medicine Band). Bluetooth requires no special components for its implementation, which makes it low cost wireless solution & affordable publicly. Bluetooth is nurtured by SIG (Bluetooth Special Interest Group), initially there were five companies Ericsson as lead and following INTEL, IBM, Nokia and Toshiba. Later many other companies joined and now there are more than 1000 companies. Bluetooth spares expensive wiring and infrastructure costs but does require stations to be within close proximity for communication with one another. Bluetooth's communication typically ranges from 10m to 100m and provides data rate of up to 3mbps. Bluetooth technology can now be seen everywhere it is not just restricted to mobile phones, PDAs, Laptops but it has gained its popularity in various other fields such as Automobile industry (Keyless entry, hand- free systems & many others) and its growing. Big moguls are investing more and more in Bluetooth projects, making it more promising technology.

Overview of Bluetooth Technology: Bluetooth is short range radio frequency (RF), open standard communication technology. It works by establishing short Wireless Personal Area Networks (WPAN). These small networks are referred to as Ad-hoc or peer-to-peer networks and are also known as Piconets. As Bluetooth technology is integrated in almost everything now a days, user can make ad-hoc network to transfer data or voice easily. These networks/piconets are established on temporary and changing basis which provide the ease of flexibility and scalability between Bluetooth devices.

Bluetooth is in records with IEEE as 802.15 Working Group for Wireless Personal Area Networks, formed in early 1999 as IEEE 802.15.1-2002. Bluetooth is limited to 2.4GHz ISM (Industrial Scientific Medical) band. This band reserves radio frequency for Industrial, Scientific or medical purposes. Bluetooth uses Frequency Hopping Spread Spectrum technology for transmission and reception of data and to minimize interference with other microwave operating devices. Each Bluetooth device has globally unique 48 bits MAC addresses. The first 24 bits are of Bluetooth network MAC address is vendor specific.

Figure 1 Bluetooth Mac Address

Bluetooth networking has no fixed infrastructure connection and follows a master-slave topology. It can have any number of passive slaves but only 7 active slaves and only one master. Active salves are referred to those devices which are in synchronization with master and are ready for communication. This network of master-slave configuration is referred to as piconet and two or more piconets sharing one common Bluetooth node forms a scatternet.

Figure 2 Bluetooth Scatternet

Bluetooth (FHSS) use 79 different radio channels by hopping frequencies about 1600 times/second for data/voice links and 3200 times/second during page & inquiry. Each channel is used for only microseconds, followed by next hop.

Communication via Bluetooth:

Bluetooth uses three types of connections:

ACL (Asynchronous Connection-Less): These links are for symmetric (Up/Down- 1306.9kbps), asymmetric (Up- 2178.1kbps, Down- 177.1kbps) data transfer. Retransmission of packets is used for integrity.

SCO (Synchronous Connection- Oriented): These links are symmetric (Up/Down- 64kbps) and are used for transferring real time two-way voice. In these links there is no retransmission to check the integrity of data and when BER is high voice is distorted.

eSCO (extended Synchronous Connection Oriented):These links are also symmetric and are used for real-time two way voice (Up/Down: 864kbps). Retransmission checks the integrity of data (Voice). Because of retransmission can also carry data packets. Bluetooth versions 1.2 or later devices can use eSCO links but the must also be compatible with SCO to provide backward compatibility.

Figure 3 a) Bluetooth topology when ACL links are used. b) Bluetooth topology when SCO or eSCO are used.

Bluetooth Protocols: Protocols below the HCI (Host Controller Interface) are built-in to the Bluetooth microchip, and protocols above the HCI are located as a part of the host device's software package. A HCI is needed between the hardware and software protocols. The purpose of the HCI is to enable the manufacturer-independent combining of Bluetooth chips (Host Controller) and the actual host device. The

HCI takes care of security communication between the host and the Bluetooth module.

Baseband and LMP (Link Manager Protocol): together enable the physical RF connection.

LC (Link Controller): is a state machine that defines the current state of the Bluetooth device. The LC has a pseudorandom number generation capability, methods for managing security keys, and the capability for providing the mathematical operations needed for authentication and encryption.

The LM (Link Manage): acts as a liaison between the application and the LC on the local device, and it also communicates with the remote LM via PDUs (Protocol Data Units) using the LMP, i.e. the LM communicates with three different entities during a Bluetooth session: the local host through the HCI, the local LC (local operations), and the remote LM (link configuration, link information, and link management operations).

SCO and eSCO links: as discussed above.

The L2CAP (Logical Link Control and Adaptation Protocol) is a software module that normally resides on the host. It fits upper layer protocols to the Baseband, i.e. it acts as a conduit for data on the ACL link between the Baseband and host applications. The L2CAP also offers CO (Connection-Oriented; from master to one slave and from slave to master) and CL (Connection-Less; from master to multiple slaves) services, and it is defined only for ACL links.

The SDP (Service Discovery Protocol) is used to find the services of Bluetooth devices in the range.

RFCOMM (Radio Frequency Communication) emulates serial ports over the L2CAP, and therefore it is possible to use existing serial port applications via Bluetooth.

The OBEX (Object Exchange Protocol) is used to exchange objects, such as calendar notes, business cards and data files, between devices by using the client-server model. The OBEX supports six simple and self-explanatory operations: Connect (choose your partner, negotiate capabilities and establish connection), Disconnect (terminate connection), Put (push objects to the server), Get (pull objects from the server), Abort (abort an object exchange that is in progress), and Set Path (set server's directory path to a new value).

The TCS (Telephony Control protocol Specification) binary defines the call control signaling for the establishment/release of speech and data calls between Bluetooth devices. It also provides functionality for exchanging signaling information that is unrelated to ongoing calls.

The BNEP (Bluetooth Network Encapsulation Protocol) is used to provide networking capabilities for Bluetooth devices. It allows IP (Internet Protocol) packets to be carried in the payload of L2CAP packets. The IP is a network layer protocol in the TCP/IP (Transmission Control Protocol/Internet Protocol) protocol suite. TCP and UDP (User Datagram Protocol) are transport layer core protocols used in the TCP/IP protocol suite. PPP (Point-to-Point Protocol) can also be used to provide TCP/IP networking capabilities for Bluetooth devices, but it is slower, i.e. it works over RFCOMM whereas BNEP works directly over the L2CAP, and therefore PPP is rarely used now.

Bluetooth Versions: Several Bluetooth specification versions have been released since Bluetooth technology was introduced in 1998. Related information is given in Table 1.

Bluetooth Security Architecture: Basic configuration of a Bluetooth device is done by user regarding its implementation of connectability and discoverability. The connectability and discoverability is divided into three Security levels:

Silent: Device will never accept any Bluetooth connection from any device. It just monitors Bluetooth traffic flow.

Private: The device cannot be discovered an will accept connection from known user or registered user with the device. This mode is also known as un-discoverable mode.

Public: In this mode the device is totally discoverable and can be connected to any Bluetooth device in the proximity.

These Security levels can further be divided into four different Security modes:

Non-Secure: No Bluetooth security is initiated.

Service-level enforced security mode: Two Bluetooth devices can establish a non-secure ACL link. Security procedures, namely authentication, authorization and optional encryption, are initiated when an L2CAP CO or an L2CAP CL channel request is made.

Table 1 Bluetooth Versions





July 1999

Interoperability problems.


Dec 1999

Interoperability problems fixed.


Feb 2001

Fixed many problems of 1.0b, added support for unencrypted communication & RSSI (Received Signal Strength Indicator)


Nov 2003

Improvements such as AFH (Adaptive Frequency Hopping), eSCO (extended Synchronous Connection Oriented) & Optional QoS.


Nov 2004

EDR, increase in speed up to 3mbps.


July 2007

Encryption Pause Resume, Extended Inquiry Response, SSP, Near Field Communication, Sniff Subrating, Enhanced QoS.



480mbps speed adopting UWB.Link-level enforced security mode: Security procedures are initiated when an ACL link is established.

Authentication: The process of verifying 'who' is at the other end of the link. Authentication is performed for devices. In

Bluetooth, this is achieved by the authentication procedure based on the stored link key or by pairing (entering a PIN).

Authorization: This is the process of deciding if device X is allowed to have access to service Y. This is where the concept of "trusted" exists. The results of authentication are used for determining the client's authorization level, which can be implemented in many different ways: for example, access can be granted to all services, only to a subset of services, or to some services while other services require additional authentication.

Encryption is used for encoding the information being exchanged between Bluetooth devices in a way that eavesdroppers cannot read its contents.

Bluetooth Network Security Threats: Security threats in Bluetooth networks can be divided into three categories: disclosure threat, integrity threat and DoS threat. Disclosure threat means that information can leak from the target system to an eavesdropper that is not authorized to access the information. Integrity threat concerns the deliberate alteration of information in an attempt to mislead the recipient. DoS threat involves blocking access to a service, making it either unavailable or severely limiting its availability to an authorized user.

Disclosure Threats:

BlueSnarfing attack (also referred to as BlueStumbling attack) means that an attacker connects to the target device without alerting its owner and steals some sensitive information such as entire phonebook, calendar notes and text messages. At least three BlueSnarfing applications exist: Adam Laurie's BlueSnarf, Ollie Whitehouse's RedSnarf 1.0 and Bluediving Project's Bluediving 0.8. BlueSnarfing is normally only possible and dangerous if the target device's security level is set as public, i.e. the target device is discoverable, but there are also ways to find non-discoverable devices, for example by using a Bluetooth protocol analyzer.

An Off-Line PIN Recovery attack is based on intercepting and calculating the correct SRES value by guessing different PIN values until the calculated SRES equals the intercepted SRES. It is worth noting that SRES is only 32 bits long. Therefore, a SRES match does not necessarily guarantee that an attacker has discovered the correct PIN code, but the chances are quite high especially if the PIN code is short. An Off-Line PIN Recovery attack is dangerous only if the PIN code is short and has no case sensitive alphanumerical characters.

An Enhanced implementation of Off-Line PIN Recovery attack is an average of 30% faster than the original Off-Line PIN Recovery attack described in. It is based on the optimization of SAFER+ using the algebraic manipulation of the SAFER+ round.

An Off-Line Encryption Key Recovery attack: is based on intercepting all the required encryption values, an Off-Line Encryption Key Recovery attack is dangerous only when an Off-Line PIN Recovery attack or its enhanced implementation has been completed successfully.

A BluePrinting attack is used to determine the manufacturer, device model and firmware version of the target device. An attacker can use Blueprinting to generate statistics about Bluetooth device manufacturers and models, and to find out whether there are devices in the range of vulnerability that have issues with Bluetooth security.

Integrity threats:

Reflection attacks: (also referred to as Relay attacks) are based on the impersonation of target devices. An attacker does not have to know any secret information, because he only relays (reflects) the received information from one target device to another during the authentication. Reflection attacks are possible only when the target devices do not hear each other, i.e. the communication between the target devices is not possible because they are out of each other's range.

One-Sided Reflection attack and Two- Sided Reflection attack. Only one target device is impersonated in a One-Sided Reflection attack, while a Two-Sided Reflection attack requires that both target devices are impersonated. An attacker can successfully perform authentication using a Reflection attack, but he cannot continue the attack if the target devices want to have encrypted communication, i.e. the attacker does not know the secret PIN code, link key or encryption key. Therefore, Reflection attacks are dangerous only when encryption is not used.

A very dangerous form of integrity threat takes place when an attacker uses a stronger RF signal in order to displace the active piconet device. The main principle for successfully completing an Exploitation of a stronger RF signal attack is to send the target device's receiver an RF signal that is at least 11 dB stronger than the signal that the legitimate piconet device is sending.

A Backdoor attack means that an attacker establishes a trusted relationship with the target device through authentication, and ensures that this trusted relationship no longer appears to be in the target device's register of paired (authenticated) devices. When the backdoor is installed in the target device via a backdoor attack, the attacker can continue the attack in many different ways: for example, trying to exploit the resources of the target device via a trusted relationship, trying to perform a BlueSnarfing attack or trying to slip a virus or worm to the target device.

Denial-of-Service threats

DoS threats can be roughly divided into two parts: attacks against the PHY (Physical Layer) and attacks against protocols above the PHY (Physical Layer).

Duplication attack is based on the idea that an attacker places a bug in the range of susceptibility. When any Bluetooth device tries to make a connection with the target device, either the target device or both devices, i.e. the target device and the bug, will respond and jam each other. In this way, the attacker has denied access from the legitimate device

A SCO/eSCO attack is based on the fact that a real-time two-way voice reserves a great deal of a Bluetooth piconet's attention so that the legitimate piconet devices are not getting the service within a reasonable time. The most effective way to perform this type of attack is to establish a SCO or an eSCO link with the piconet master.

A Big NAK is based on the idea of putting the target device on an endless retransmission loop so that the legitimate piconet devices have considerably slowed throughput. In this attack, an attacker requests any information from the target device and every time the requested information is received, the attacker sends NAK (Negative acknowledgement), i.e. the transmission has failed.

A L2CAP Guaranteed Service attack is based on the idea that an attacker requests the highest possible data rate or the smallest possible latency from the target device so that all other connections are refused, and all throughput is reserved for the attacker.

A Battery Exhaustion attack is based on the idea of occupying the target device in such a way that it also consumes rather quickly the battery of the target device.

Multi-threats & Spreads:

A BlueBugging attack means that an attacker connects to the target device (typically a Bluetooth mobile phone) without alerting its owner, steals some sensitive information, such as an entire phonebook, calendar notes and text messages, and has full access to the GSM (Global System for Mobile communications) AT command set, i.e. a BlueBugging attack is based on the exploitation of AT commands. It means that the attacker can, in addition to stealing information, send text messages to premium numbers initiate phone calls to premium numbers, write phonebook entries, connect to the Internet, set call forwards, try to slip a Bluetooth virus or worm to the target device, and many other things.

Blooover and its successor Blooover II are derived from Bluetooth Hoover, because they run on handheld devices, such as PDAs or mobile phones, and are capable of stealing sensitive information by using a BlueBugging attack. A Blooovering attack can be done secretly, by using only a Bluetooth mobile phone with Blooover or

Blooover II installed on it.

A Brute-Force BD_ADDR Scanning attack uses a brute-force method only on the last three bytes of a BD_ADDR, because the first three bytes are publicly known and can be set as fixed. A Brute-Force BD_ADDR Scanning attack is perhaps the most feasible when target devices are Bluetooth mobile phones, because millions of vulnerable Bluetooth mobile phones are used every day all over the world.

Man in the Middle Attacks: In a man in the middle attack, an attacker seeking (unauthorized) access to a Bluetooth device inserts himself "in between" two authorized devices Communications between the two devices then pass through the man in the middle, who intercepts and manipulates data packets.

First Bluetooth virus, Series 60 affected Jun 15 2004: Symantec warns of a worm for Series 60 mobile phones that transmits itself through Bluetooth. It's just a proof-of-concept (doesn't do any damage), but it's a scary concept. The worm spreads as a .SIS file, which is automatically installed into the

"APPS" directory when the receiver accepts the transmission. Upon execution, it will display a message then copy itself to a directory that is not visible by default. The worm runs from this directory whenever the phone is rebooted, so it continues to work even if the files are deleted from the APPS directory.

Virus: METAL Gear.a for Series 60 Dec 21 2004: Another new security notice for Series 60 owners--avoid a file claiming to be the game Metal Gear Solid with the file name METAL Gear.sis. According to security firm SimWorks, the virus looks for and then disables anti-virus software. The METAL Gear trojan uses the same icon disabling technique pioneered by the recent Skulls trojan, this time to disable specific anti-virus and file browsing applications. Once on your phone, the METAL Gear Trojan will install a version of the Cabir virus. Another file called SEXXXY.sis is spread via Bluetooth to all phones in the area- -this file in turn disables the Symbian application selection button on the target phone.

Bluetooth trojan leaves mobile users out of pocket $5 charge for leaving your phone open to attack "The trojan gets your phone to send an SMS to a premium rate number and then sends an authority that they can charge you without you knowing about it," said Richard Hales, country manager for UK and Ireland at F-Secure. F-Secure warned that users are still leaving their mobile devices and laptops open to attack by using unsecured Bluetooth connections, despite the company's warnings at trade shows such as CeBIT. The security firm's honeytrap system at Infosec picked up 1,142 open Bluetooth products in the first three hours of the security show, and had 183 devices in range as it was demonstrated to Hales said that the new attack is similar to the CommWarrior mobile virus which originally spread itself over mobiles without causing anything more than a higher bill for sending itself to contact via MMS as well as Bluetooth. User ignorance is still the main reason for the spread of CommWarrior type viruses, according to F-Secure. "If someone's phone is infected with CommWarrior, all of these phones in range would be getting a message saying: 'Install CommWarrior, yes or no?'," said Hales "If you say no it immediately pops the message back up again if you're still within range. So you press no, no, no, oh for goodness sake, yes."

Cabir virus: is the first verified example. The virus was created by a group from the Czech Republic and Slovakia called 29a, who sent it to a number of security software companies, including Symantec in the United States and Kapersky Lab in Russia. Cabir is considered a "proof of concept" virus, because it proves that a virus can be written for mobile phones, something that was once doubted. Cabir was developed for mobile phones running the Symbian and Series 60 software, and using Bluetooth. The virus searches within Bluetooth's range (about 30 meters) for mobile phones running in discoverable mode and sends itself, disguised as a security file, to any vulnerable devices. The virus only becomes active if the recipient accepts the file and then installs it. Once installed, the virus displays the word "Caribe" on the device's display. Each time an infected phone is turned on, the virus launches itself and scans the area for other devices to send itself to. The scanning process is likely to drain the phone's batteries. Cabir can be thought of as a hybrid virus/worm: its mode of distribution qualifies it as a network worm, but it requires user interaction like a traditional virus.

Gavno.a virus disables calls on Symbian phones Jan 24 2005 Symbian security firm SimWorks has sounded the warning for a new mobile phone virus, Gavno.a. Gavno.a is the first mobile virus to cause serious damage--Gavno leaves Symbian 7 handsets unable to make calls. The threat, Gavno.a is spread via a file called patch.sis and induces mobile phone users to install it on their devices by masquerading as a patch for their phone, a concept familiar to mobile phone users from other computing platforms such as Microsoft Window Gavno affects Series 60 phones using Symbian OS v7 such as the Nokia 6600 and 7610, not popular models like the Nokia 3650 that use Symbian 6.

Symantec warns of three new Symbian Trojans Jan 20 2006 Symantec has issued an alert over three new trojan horse applications for Symbian powered phones. These will affect Nokia's S60 line of Smartphones. The trojans are being called: SymbOS.Bootton.E,SymbOS.Pbstealer.D and SymbOS.Sendtool.A. To be affected you will have to install an application, so use general precautions before installing software on your phone (e.g. know who it's from). Filenames to watch out for include: Fspreader.SIS, ChattingYuk.SIS, PBC ompressory.SIS and Restart.S60.SIS.

Management Countermeasures: The first step is to develop a focused attitude towards Bluetooth. This attitude must demand that every employee that uses Bluetooth understand their rights and responsibilities: what they can and cannot transfer over the network and what will happen if they do not follow the rules.

Operational Countermeasures: The operational countermeasures depend heavily on the required security across the network, but the basic recommendation seems to be to limit the electric power itself to keep the range of the network within the physical area of, for example, an office. This seems to be the only way to counter users not having to register when joining a network, because there is little to no way a hacker can sit outside the building and still be within the range of the network. If an admin can limit their list to who they know is in the building, they can know who is (potentially) on the network.

Software Countermeasures: Bluetooth's strength lies in the Bluetooth PIN, provided at the link level. The PIN is used heavily in the authentication procedure as a variable in the process that generates an initialization key allowing two devices to communicate. For key generation, Bluetooth has two options: use the PIN from one device or the

PIN of two devices. The weakness of PINs comes from two things: the ability to set them to automatically retrieve themselves when a connection is initialized and the ability to keep them at four simple digits. Some simple Bluetooth devices come with a PIN built in, called a fixed PIN that must be used in a pairing procedure. Otherwise, the same PIN is used in both devices. It is important that there be both device authentication and user authentication. So far, device authentication is standard practice, but user authentication by way of a password is new and necessary to a fundamental level of security. There are other possible software solutions for Bluetooth besides specific protocols of PIN use, but these are similar solutions to those found for the 802.11 standard for WLANs. These are things like application security tool kits, and robust Ipsec VPN overlay. However, none of these software solutions currently exist for Bluetooth and could provide too costly for the benefits they confer.

Hardware Countermeasures: Many of the hardware countermeasures that the NIST recommends are already present within Bluetooth, at the Link layer. The Link layer provides the 6-bit device address, from which 128-bit link keys and encryption keys can be derived. There is also a key generation algorithm that takes a randomly generated number and the device address to create the unit and the combination keys. The aforementioned link keys are used three ways: as a master key, which only a master device can set up, as a unit key and as a combination key. Unit keys are strongly frowned upon, especially by the Bluetooth SIG Security Expert Group and instead it is recommended that combination keys be used. Combination keys are pair-wise unique, which means that they are based on the communication between the two devices, not the individual link keys, so even if the link key is discovered the combination key is kept safe. Frequency hopping is a useful part of the Bluetooth hardware as well. It allows two devices to communicate, even amidst interference, potentially from jamming techniques. The errors that come from hopping to a frequency that is being interfered with can be fixed with an error correcting application called FEC. While many believe frequency-hopping throws off hackers by pseudo-randomly changing the frequency, this is not true. Only minimal protection is given and it should not be relied upon. The lack of user authentication could be remedied by biometrics, or voice authentication. This could be used as a chain in a multi-step identification process. Mobile phones and PDAs with Bluetooth technology already employ this technique. This would keep the network from falling prey to the wrong hands merely by misplacing a device on the network. Lastly, the best sources of authentication we can expect will probably come from third-party sources for authentication, much like VeriSign does for online transactions. One such technology is an application called Jini. This could allow devices to connect to a network and immediately be identified and used, regardless of operating system, making Bluetooth ad hoc networks resemble a giant, amorphous computer. Jini hypothetically solves the problem of anonymity on the Bluetooth network, if it can identify each device as it joins the network.

Conclusion: Jini is the perfect example of where the next advancements in Bluetooth will come from in the future: from third party developers that have an investment in Bluetooth's success. It is a tribute to Bluetooth's accessibility that it has made it this far and has become the foremost name in wireless ad-hoc networking. Unfortunately, that accessibility could be its downfall. Without the proper security protocols in place, Bluetooth's competitors could easily replace it in the marketplace. In the next five to ten years, it will be interesting to see if Bluetooth manages to take note of the NIST recommendations and its own observations and fix the problems, however difficult they may be. My bet is that they will, but I would not put money on it.