Abstract

This paper attempts to explain the Bluetooth technology by giving a brief background
and then explaining its vulnerabilities. It shows users the dangers of Bluetooth, leaving
Bluetooth devices in “discoverable” mode, and goes briefly into how hackers can exploit
Bluetooth and what users can do to protect themselves.

Introduction
Since its inception in 1998 [Miller, 2], Bluetooth has taken off and gained popularity,
mainly thanks to its combination in cellular phones, laptops, mobile phone accessories
and numerous devices serving thousands of purposes. With popularity came an
unavoidable exploit of Bluetooth’s vulnerabilities and an exploit of the users of the
technology. In recent years, a number of experiments have been conducted to see how
far the technology can be exploited and how both technological flaws as well as social
engineering can allow for a hacker to gain a user’s personal information, use a cell phone
as their own, and track users over great distances due to their Bluetooth enabled devices.

Background
Bluetooth origins are traced back to research in Lund, Sweden in which Sven
Mattisson and Jaap Haartsen with the goal of developing a wireless connection
between an ear-piece and phone. This research was invested in by Ericsson, a
Swedish technology company and took the research to the next level. The
Bluetooth Special Interest Group (SIG) was composed of major technology
companies, IBM, Ericsson, Nokia, Intel and Toshiba and founded in 1998. The
next year the 1.0 implementation of Bluetooth was published. [Miller, 2]
Bluetooth being an over the air radio system operates on the unlicensed
2.4 GHz, which the FCC terms Industrial Scientific Medical band. The frequency
of the band is 2400 - 2483.5 HMz in which 79 RF channels are ordered starting
with 0, ending with 78. Each channel is spaced 1 MHz apart starting at 2402
GHz. To prevent interference with the different laws in different countries, a 2
MHz guard is used at the bottom of the spectrum, and 3.5 MHz at the top. The
protocols of how data is transferred over this radio selection are defined in the
Bluetooth Core Specification. The specification consists of a well defined
protocol stack. [See Miller Figure 7.5 & Table 7.2] The stack is split into four
layers. Each layer then contains details on the layer and specific protocols. The
first layer is the core.
The Bluetooth Core stack includes four separate protocols. The Baseband
Specification[2] which enables a physical link radio frequency(RF) link between
different devices to form a piconet. The system revolves around a Frequency-
Hopping-Spread-Spectrum in which packets are transmitted at specified time-
slots. To that end, it also provides procedures to synchronize the hopping
frequency and deal with potential clock differences between separate physical
devices. Two specific kinds of physical links are defined, Synchronous
Connection-Oriented (SCO) and Asynchronous Connectionless( ACL). Both links
can be transmitted over a single RF link. ACL packets are limited to data only
where the SCO packets can contain audio alone or together with data. SCO are
typically transactions between a single master and slave device, where ACL
packets allow for single master, multiple slave connection setup. The core also
contains a Link Manager Protocol (LMP) [3] which defines the link setup between
different devices. The LMP is also responsible for security aspects such as
authentication and encryption by checking the encryption key, link status, and the
control and negotiation of packet sizes. Lastly, it also defines the power modes
and connection states of each device in the piconet. The third protocol, Logical
Link Control and Adaptation (L2CAP) [See Figure 1.1], is the bridge between the
upper layers and the baseband. In the initial 1.0 Specification there is no support
for SCO links, and only ACL is defined even though the baseband contains
support for it. The last protocol in the core stack, Service Discovery Protocol
(SDP) [5], contains the discovery services which enable to devices to find each
other and discover each others capabilities. After all these protocols bridging the
gap between already established data communication protocols and the radio
came next.
The second protocol, Cable Replacement Protocol, stack consists of only
a single specification, RFCOMM, which covers the emulation of data typically
sent over serial or non-wireless links. RFCOMM emulates RS-232 serial
connection between the device and the radio systems. The RFCOMM is not
completely unique to Bluetooth as it is based on a subset of an existing protocol.
[Miller, 7]
Telephony Control Protocols is the third set of protocols, Telephony
Control Specification - Binary (TCS-BIN) and AT Command protocol. The TCS-
BIN is similar to RFCOMM in that it is also based off of another protocol, ITU-T
Q.931. It defines how telephone calls should be transmitted in Bluetooth links.
TCS-AT is included in the Telephony Control stack but is not an actual separate
protocol. AT commands provide for modem control mostly for legacy application.
[Ganguli, 6][Harte Figure 1.8].
The last protocol stack in the Bluetooth group is the Adopted Protocols
stack. The adopted stack contains various protocols developed outside of the
Bluetooth SIG which have been adopted to work with the Bluetooth protocol
stack. Point-to-Point Protocol (PPP) works with the RFCOMM protocol to
establish point to point serial links. PPP is mostly used with Dial-Up networking
as well as Fax and sometimes LAN access. The most well known network
protocols today are also included in the protocol stack. TCP, Transport Control
Protocol, IP, Internet Protocol, and UDP, User Datagram Protocol are the three
protocols which dominate the internet and their inclusion allows Bluetooth
devices to interact with other devices connected to the internet. Several other
content driven protocols are also included to allow interoperability with other
previously produced standards and protocols, including OBEX, IrMC, Infrared
Mobile Communications, WAP, Wireless Application Protocol, and WAE,
Wireless Application Environment. [Miller 7]
 With the core protocol now covered, the inherit problem with all data
transferred over the air is still left unaddressed. The Bluetooth Specification
defines three possible security modes for a device. (1) Non-Secure, (2) Service-
Level Enforced Security, and (3) Link-Level Enforced Security. The first mode,
Non-Secure, is as straight forward as it sounds. There are no security methods
and the device is completely insecure. Service-Level Enforced Security begins
security after a connection is established. To that end, only data sent directly
between the two devices, properly addressed, is subject to security protocols.
Data sent out in any part of the pairing process which is not addressed to any
specific client is not encrypted. Lastly, Link-Level Enforced Security maintains
security measures throughout the entire transaction between any other device.
The security measured laid out in the Bluetooth specification contains three
separate components.
Key management is central to the pairing process. Three steps are
required when the device is in mode two or three. First, the user enters a
personal identification number (PIN); second the device generates a private link
key and authenticates it with the other device. Lastly, the first device generates a
private encryption key from the link key, and then authenticates it with the second
device. Three types of keys are used in this process. First a PIN code, which is
always 4 digits. The Private Link Key is generated based by the device for each
transmission session. Lastly the Private Encryption Key is derived from the link
key currently in use. When encryption is required to make a transmission, the
encryption key is automatically changed. [See Miller Figure 7.6] If all keys match,
then the connection is established, otherwise it is aborted.
The second of the three components, Device Authentication, is an
additional security control mechanism that allows a challenge and response
system to verify that the other device knows a shared key. If two devices match
the same key, then authentication is successful. This is implemented by the
Bluetooth applications running over the already created connection. The
application can be setup to ask for authentication from only one side of the
connection, others require both devices to authenticate. Lastly, a hammering
prevention system is also apart of the device authentication system. If an
authentication fails, there is a waiting period before one can attempt to
authenticate again. This is to prevent someone from attempting to figure out the
key with many attempts making any such attempt so time consuming that it is not
practical. [Miller 7]
The last part of the security section of the Bluetooth protocol defines
Packet Encryption. The three authentication modes match up to the three
different security levels. Mode one being that no packets are encrypted and all
are able to view their full contents. Mode two, all point-to-point traffic is
encrypted, but broadcast like traffic is not. The final mode, three, is full encryption
on all traffic.
Covered Topics:

Creation of Bluetooth.
Bluetooth Protocol Stack (4)
High level security overview, modes 1,2,3.

Bluetooth How It Works. (n.d.). Retrieved September, 2008, from Bluetooth SIG, Inc
Web site:
http://bluetooth.com/Bluetooth/Technology/Works/
Ganguli, M. (2002). Getting Started with Bluetooth . Cincinnati, OH: Premier Press.
Retrieved
September, 2008, from Books24x7 database (4222):
http://library.books24x7.com.ezproxy.rit.edu/
toc.asp?bookid=4222
Gehrmann, C., Persson, J., & Smeets, B. (2004). Bluetooth Security . Norwood, MA:
Artech House.
Retrieved September, 2008, from Books24x7 database (10252):
http://library.books24x7.com.ezproxy.rit.edu/toc.asp?bookid=10252
Harte, L. (2004). Introduction to Bluetooth: Technology, Market, Operation, Profiles, &
Services.
ALTHOS Publishing. Retrieved September, 2008, from Books24x7 database (8916):
http://library.books24x7.com.ezproxy.rit.edu/toc.asp?bookid=8916
Mettala, R. (1999, August 25). Bluetooth Protocol Architecture: Version 1.0. (Bluetooth
White Paper
Document No. 1.C.120/1.0) Retrieved September, 2008, from
http://www.bluetooth.com/Bluetooth/
Technology/Building/Research/Bluetooth_Protocol_Architecture.htm
Miller, M. (2001). Discovering Bluetooth. Alameda, CA: SYBEX Inc. Retrieved
September, 2008, from
Books24x7 database (3249): http://library.books24x7.com.ezproxy.rit.edu/toc.asp?
bookid=3249
Muller, N. J. (2001). Bluetooth demystified. New York: McGraw-Hill. Retrieved
September, 2008, from
http://albert.rit.edu/record=b2178821~S3
Muller, T. (1999, July 15). Bluetooth Security Architecture: Version 1.0. (Bluetooth
White Paper
Document No. 1.C.116/1.0) Retrieved September, 2008, from
http://www.bluetooth.com/Bluetooth/
Technology/Building/Research/Bluetooth_Security_Architecture.htm

[Bluetooth Tools]
BlueSniffing
Eavesdropping is a major concern for many communications protocols in the
world. Be it a private conversation between two people in a lobby, secret military
communications or even an email to a friend; there’s always a desire to ensure that one
can be confident that someone else will not be able to intercept the information. Wireless
communications introduce additional challenges when attempting to ensure the
confidentiality of transmitted information. While the transmitted data is bound by the
communications medium, in the case of wireless communications, that medium is air.
This means the data is able to travel both where it needs to go and many places it does
not. It also means that the two devices must use some sort of information to ensure they
can trust the data that they receive over the air is in fact genuine. Without this trust, the
protocol can no longer be deemed secure.
There are various commercially available Bluetooth sniffing software packages
available today. Most of these have been thought to be cost-prohibitive for your average
person to be able to get their hands on, however, recently security researchers have
discovered that the hardware used with the commercial packages is identical to that of
consumer-available devices that sell for approximately $30. [Moser 1] The only
difference between the two is the firmware that is actually loaded on the Bluetooth
dongle. The vendor provides firmware updates for their dongles, and these same
firmware updates can be used to re-flash the $30 dongle. Since there’s no special
hardware required, it means anyone with access to an illegal copy of the software can
simply buy the $30 device and begin sniffing. Max Moser, author of Busting The
Bluetooth Myth – Getting RAW Access, details his research on utilizing consumer
hardware with a popular “unnamed” vendor Bluetooth sniffing software. The article
attempts to conceal the identity of the Bluetooth sniffing software company, however,
many others have published information online about the specific vendor, commands
required and where one can purchase a compatible Bluetooth dongle to modify. Those
who are interested in maliciously sniffing/manipulating Bluetooth data will not be as
concerned with the legality of obtaining the software without actually purchasing it and
this simply means that $30 and 30 minutes of your time will result in a commercial
Bluetooth sniffer. [Tanakinami 1]
If one were able to read all Bluetooth packets between endpoints, the security that
is believed to be built-in to the technology would be severely affected. By being able to
read the Bluetooth packets, the technology suffers from some of the same design flaws of
802.11’s WEP security. A freely available tool, BTCrack [n.runs 1], is able to decipher
the PIN and encryption key used between the two devices during pairing. Since the
encryption key and PIN are the shared secrets associated with Bluetooth communication,
making them public eliminates the security provided by the protocol. Bluetooth relies on
the secrecy of these two items in order to ensure that the data isn’t accessible by others.
Passively sniffing common areas, such as local electronics stores where sales technicians
may assist consumers in pairing their Bluetooth devices, can yield attackers the packet
exchange as devices are paired. BTCrack can then be used to easily crack the link key
and PIN within a matter of seconds. Once these two items are known, it’s possible to
read the data being transmitted between the devices. The ramifications of this ability
include being able to listen to phone conversations of anyone using a Bluetooth headset,
sniffing data transmitted between a cell phone being used as a wireless modem and
monitoring keystrokes being sent by a Bluetooth keyboard to a computer.
Passive sniffing of data sent over the air is not the only risk associated with being
able to read the Bluetooth packets. Remote control and manipulation of the data being
transmitted over Bluetooth exposes the endpoints to additional security risks. Since the
easiest opportunity to obtain the encryption key/PIN is during pairing, it would be
beneficial to be able to force a victim to attempt to re-pair their devices. A victim may
decide to re-pair their devices in the event an attacker utilizes a frequency jammer to
disrupt communications on the frequencies the Bluetooth clients are utilizing for
communication. After the victim has completed re-pairing (with the attacker sniffing the
entire pairing transaction), the attacker now has the information required to read the
packets between the two endpoints. As soon as one is able to read the packets, it’s quite
trivial to inject packets into the air. It then becomes quite possible and easy to take
control of the data stream between two Bluetooth endpoints. A Bluetooth keyboard
paired with a machine becomes a target for an attacker. Having keyboard access to a host
could easily enable an attacker to automatically send a sequence of keystrokes to
download and execute a Trojan on the machine. From there, one just needs to utilize
existing methods for taking control of a vulnerable system. The Trojan could be
configured to automatically connect out to a remote server (utilizing SSL over 443/tcp to
blend in with normal web traffic) and provide an interface for an attacker to manipulate
the system. Bluetooth keyboards are increasingly popular and Apple Computers has
various models available. An additional security risk of Bluetooth keyboards is the
ability for an attacker to monitor keystrokes sent over the air. Since a user uses their
keyboard to enter in various passwords, create confidential documents and emails, an
attacker may be able to read this data right out of the air. By obtaining the users
password via sniffing the Bluetooth packets, the attacker may then be able to access
resources using the newly sniffed credentials. With the popularity of Bluetooth devices
and taking into consideration how widespread their use is some of the security
architecture of the technology will require additional review.
Some devices make sniffing even easier than others. Many headsets and small
embedded devices do not have a user interface to enable the owner to choose a PIN as the
device is paired with another. This means that these devices end up with hardcoded
default PINs, most of which are frequently set to 0000. These devices remove part of the
security that Bluetooth attempts to introduce into the protocol. Devices with hardcoded
and publically available PINs have significantly weaker security as Bluetooth security
relies on this information being private. Without a PIN, Bluetooth keys are derived from
the physical address of the Bluetooth device. [Shaked 1] This leaves one less piece of
information an attacker must obtain in order to access the data transmitted over the air.
When one combines the power obtained with the ability to read, inject and control
Bluetooth devices with the ability to do it at long range, the risks of the technology are
further increased. At a 2004 DefCon meeting, Flexilis unveiled its BlueSniper Bluetooth
antenna, which is capable of receiving Bluetooth packets about 1km away. [Cheung 9]
At the conference, the antenna was able to easily see packets coming from a pre-
determined MAC address that was located about 1km from the user with the BlueSniper
gun. Sniffing Bluetooth packets at long range also introduces interesting possibilities.
The number of devices that one can monitor during the initial pairing process greatly
increases as well as the amount of data freely available via the air.
Cheung, Humphrey. 9/18/2008. How To: Building a BlueSniper Rifle.
http://www.tomsguide.com/us/how-to-bluesniper-pt1,review-408.html
ehe@heise-online.co.uk. 9/15/2008. Bluetooth sniffing for all. http://www.heise-
online.co.uk/security/Bluetooth-sniffing-for-all--/news/87718
FTE. 9/15/2008. FTS4BT Specifications. http://www.fte.com/products/FTS4BT-02.asp
Moser, Max. 9/15/2008. Busting the Bluetooth Myth. http://www.remote-
exploit.org/research/busting_bluetooth_myth.pdf
nRuns. 9/15/2008. http://www.nruns.com/_en/security_tools_btcrack.php
Shaked, Yaniv., Wool, Avishai. 9/15/2008. Cracking the Bluetooth PIN.
http://www.eng.tau.ac.il/~yash/shaked-wool-mobisys05/
Tanakinami, Aiwe. 9/15/2008. Bluetooth sniffing for less.
http://bluetoothsecurity.wordpress.com/2007/05/12/bluetooth-sniffing-for-less/
trk@heise-online.co.uk. 9/15/2008. New Hacker Tools for Bluetooth. http://www.heise-
online.co.uk/security/23C3-new-hacker-tools-for-Bluetooth--/news/83045

BlueTracking
Tracking and location detection through Bluetooth is one of the foremost
concerns for any user with a Bluetooth handset, and is able to give personal information
about travel, personal whereabouts, habits and can even lead to other types of attacks
including information interception and business attacks. The act of an attacker using a
Bluetooth device to connect and track another Bluetooth device is called BlueTracking.
The BlueTracking attack is mostly used for espionage and can be used for
blackmail but is less effective than a number of other Bluetooth attacks, mostly because
of the Bluetooth chipset that is used in most phones and devices. Bluetooth chips come
in three classes or types which mainly determine the range at which they are effective.
Class 1, used in many Bluetooth dongles to be used on personal computers, have a range
of about 100 meters. Because of the small form factor and portability of these types of
devices, experiments have been done and successfully have extended the range of these
devices up to 1 kilometer with special equipment, the author of [2] confirmed that he
could extend the range up to 230 meters with an average 5 dbi antenna, and up to 500
meters with a 14dbi antenna, both being soldered to the antenna contacts. This means
that it would be used as the primary attack media for such a BlueTracking attack, mainly
because it has the largest area it is able to cover. Because Bluetooth was meant to be a
relatively close distance wireless technology, the attacker, even with a class 1 Bluetooth
device, would have to be relatively close, but this topic will be covered later in this
section.
Class 2 chipsets are the chipsets that are used in most mobile phones and smaller
devices, giving the user a range for communication of approximately 10 meters [2].
Using these devices in a BlueTracking attack implies that the attacker would have to be
within a relatively close range to the victim, giving the attacker a larger likelihood of
being seen or discovered. No attempts at extending the range of class two devices could
be found in the given sources or within research.
Class 3 chipsets follow in suit from the class 1 and class 2 chipsets, and are said to
have the best range when used “well within 10 m” [3]. The same authors later estimate
the best range for class 3 devices to be up to 3 meters, giving them the least likelihood to
be victims of attack due to the attacker having to be right on the victims heals or only to
detect them while the victim were walking by at a close distance. The types of devices
that utilize the class 3 chipsets are mainly Bluetooth earpieces for wireless
communication between the ear piece and phone.
For any type of attack, using any class of Bluetooth chipset, the most common
vulnerability and allowance for attackers to exploit the device is when the victim device
is left in a discoverable mode. The first problem with leaving a device in discoverable
mode is the fact that if a phone or similar device can be found, some of its basic
Bluetooth abilities are not guarded and do not require that the user acknowledge them to
be used. For example, the address book, calendar information and business card info are
all stored in the phone’s memory as files, all with similar naming schemas among all
phones [1]. If an attacker gets within range for even a minute, the amount of time that it
takes a person to check out in the grocery store or stand in line to get a ticket or board a
train, the attacker can get their address book or calendar, two pieces of a personal nature
which may not seem like an overly bad thing for others to see, but two files that can help
the attacker plan further attacks or blackmail the owner of the victim device. A set of
phone numbers for personal contacts can very easily contain information for relatives,
coworkers and supervisors, all of which could be compared with the calendar.
Overall, this vulnerability has been mostly corrected with newer phones, newer
firmware for the phones, and an overall education being passed onto the consumer about
how to change or fix this problem. At the same time, many people who get used a single
phone or Bluetooth device and do not have the technical knowledge of how to switch it
between discoverable Bluetooth mode and non-discoverable Bluetooth mode, do not
want to switch to a newer phone or have the knowledge to upgrade the firmware [1].
This seems to be one of the most vulnerable and dangerous parts of BlueTracking.
The main issue in tracking and in leaving a device in discoverable mode is the
way Bluetooth actually works. Bluetooth is similar to other wireless networking schemas
in that it works on a server-client relationship [3]. When the client, or victim device, is
left in discoverable mode, it constantly allows for the broadcast and receipt of
broadcasted messages, which allow for it to be “seen” in what seems like an endless sea
of electromagnetic waves. When a message is received by the attacking devices and
from the victim device, the victim device provides its hardware address, commonly
referred to as its BD_ADDR, its internal clock, CLKN, and its frequency hop
synchronization, FHS [3]. If an attacker has all three of these, they have the “keys to the
castle” wherein they are able to now break any sort of encryption put on the phone by
hacking the encryption based on the hardware address. It also does not have to listen and
analyze the hop sequence that the victim device uses to avoid interference, but already
has it to use for listening in on broadcasted or sent messages.
The BD_ADDR or hardware address of a device is most important, to allow for
accessing or cracking a device, even when a victim device is not in discoverable mode
[7]. If an attacker, based on previous observation or other means, knows that a device is
within range, even if the device is not in discoverable mode, the attacker can try to
directly connect using the hardware address of the device. If the device has an access or
personal identification number (PIN) that is required to access the information on the
device, this can be found in a brute force attempt at hacking the code. Since most people
only use the common 4 digit combination for a personal identification number on
devices, this means that the brute force attack would take a maximum of 4^10 tries to
discover a personal identification number and this has been developed to be done in
parallel between a number of Bluetooth devices [7].
A number of experiments have been done to prove most of the points given in this
paper. The first, done by the author of [4] was a discovery experiment using 3 Bluetooth
devices arranged in an overlapping triangular area to attempt to discover as many other
devices in a crowded area as possible. It was conducted over a 6 month period and was
done within a university setting, one time in a university building, and second at an
exhibition stand for the CeBIT 2004 conference. This situation could be compared to a
similar situation in which an attacker goes to a conference with malicious intent, rather
than just an experimental detection. Within just the conference time period, a total of
seven days, 5294 devices were detected as people merely walked by with their phones or
other Bluetooth devices set on discoverable mode. The most frightening detail in the
report on the results is that approximately 70% of all the devices found in the conference
experiment were “Vulnerable again SNARF attacks”, SNARFing being the ability for the
attacker to steal a victims phone numbers and calendar information as defined above.
Another disturbing fact within the [4] report was the sentence “1% of users chose
their real name as [the] device name. At that point profound threats arise, because
BlueTrack traces can be linked to natural persons.” This furthers the main point of this
section, being the idea that if these people walking by the exhibition were being tracked,
rather than just recorded, one could associate their phones with times and, given enough
sensors or calculations, successfully track the persons movements, having their device
identity and real name to use for this purpose.
A second experiment, as done by the author of [3] used the open connection
ability of Bluetooth devices and a number Bluetooth nodes placed in an office building to
triangulate positions of employees within the office building, down to the area of a
specific office. Though the author comments that “Bluetooth might be a viable
technology for triangulations, but not for calculating or measuring accurate distance”, the
experiment shows the true danger of leaving a Bluetooth device in discoverable mode,
being the idea that within a given range, i.e. a 10 meter radius in the case of a class 2
Bluetooth device, a person can be located, and when more than on sensor is used, for
example 3 with over lapping radiuses of 3 meters each, a person can be even more
accurately tracked.
Though the concept may be different, this was similar to what a set of students did
in a number of Dutch train stations, specifically the Amsterdam Amstel, Utrecht Central
Station, and Amsterdam Central Station. The students in [5] set up a number of
Bluetooth laptops within the train station, and eventually boarded the train to continue
their journey and study, alike, onto Utrecht. While still in the station they began scanning
for open Bluetooth devices. Their results were quite telling of the vulnerabilities and
very real abilities for Bluetooth devices to be tracked. Over the course of their
observations, within two hours and twenty minutes, on the train and in the station, they
were able to pick up a total oh 1877 devices within the vicinity of the laptops. A
frightening detail of only 1712 of these were unique was also presented in the paper, thus
showing the audience that 165 devices could have their hardware addresses recorded and
eventually tracked. With further studies into this, 44 of those devices were actually
tracked between Amsterdam Amstel and Amsterdam Central Station, proving that
without much effort, and without a real desire to do so, the hardware addresses could be
tracked only based on how long and where they were picked up and eventually went out
of range.
In addition to the observations as to passengers that the authors made, they also
discovered that all members of the Dutch railways staff have their phones set to constant
discovery mode [5]. Though the authors may not have been able to use this and this
author can’t use it any time soon, it can be pointed out that “fare dodgers” as they called
them, could very easily go between one train station and another, using a similar
Bluetooth device as what they were, and track the movements of train conductors. This
would allow them to roughly time when the conductor would come by to check for
tickets and allow them to hide so that a ticket would not be needed.
This brings up an additional point that could be considered the worst case
scenario of this section. Currently there are viruses and worms that are available for
mobile devices, such as laptops, personal digital assistants and cell phones alike [2].
Dutch railway staff having their cell phones in discoverable mode at all times could
possibly allow for the transmission of either of these malicious programs to be transferred
the to the cell phone without the owners knowledge and, with the right coding, allow for
it to be spread to any device that it was able to successfully contact over its Bluetooth
link. Assuming that the conductors at some point all come within contact range of each
other and then must check the tickets of each and every passenger on the train, this would
mean that 1877 devices could be infected with the virus or worm all within 2 hours and
twenty minutes. This could feed a potential hacker, who decides to walk down the train
on an “innocent walk”, every persons address books, calendars, or without even coming
in contact with any of the users, could cause a denial of service. Another worst case
scenario would be newer handsets which include GPS tracking devices, could have
information sent to the hacker over mobile internet, thus tracking the user so long as they
have their GPS enabled phone and no knowledge of the mobile virus.
Tracking so far has been seen in a negative light, but there are positive uses for it.
One of which has been implemented at Aalborg Zoo in Denmark, where parents can be
issued Bluetooth tracking devices for children as they browse the zoo. Bluetooth sensor
nodes are placed at different point within the zoo and allow for text messages to be sent
to the parents’ phones when they fear they have lost their child. A message is sent to the
phone based on a triangulated position from a number of nodes [3].
The question most will ask when reading this section is “What can be done to
protect the average person from BlueTracking?” Thankfully a number of steps are
already being taken by many device manufacturers, specifically phone manufactures, to
prevent attackers from being able to track and steal data from users. The first is that most
phones, such as the Motorola Razr v3xx, now come with a default setting of being non-
discoverable, and only being discoverable when the user specifically tells the phone to
be. In addition to this safety feature, the phone has one more in which it only allows
itself to be discoverable for 3 minutes, and also requests that the user explicitly
acknowledge the connection of any unknown device with a pin pairing technique.
As safe as a pin pairing technique sounds, additional experiments have been done
in crowded malls in which the author of [1] did an experiment to see how many devices
he could connect to based on the error of users. The author sat in a mall with a device
scanning open Bluetooth connections and attempted to connect every time he found one.
The catch was that the device’s name that he was using was “pin1234”, a name that users
took to be literal and entered the pin of 1234.
Furthermore, the pin pairing technique and the algorithm to synchronize the two
pins has been found to be flawed in the ways of a brute force attack on a four digit pin
number would take just over 1 million tries, a feat that the average computer with a
Bluetooth adapter could easily accomplish in a relatively short period of time. The
author of [7] discusses the idea of Bluetooth having the problem of the pairing algorithm,
and the idea that it will be the same code entered on both ends of the connection, creating
a symmetrical link. In contrast, to defeat this vulnerability, as Wong puts it, “could be
relatively easily resolved by recourse to asymmetrical key establishment techniques at the
cost of slightly increased computation.” The algorithm could be developed in a similar
way to the authentication of WEP, in that the receiving device could send a response to a
challenge sent by the sending device.
Suggestions have also been made to, rather than using the minimum 4 digit pin
required by most modern phones, to use 8 digits instead. This makes a brute force attack
much harder, raising the number of combinations from 4^10, or over 1 million
combinations, to 8^10 or just over 1 billion combinations. This technique is now
required by a number of companies, whose users use Bluetooth devices, including the US
Department of Defense and the National Institute of Standards and Technologies
claiming that 4 digit PINs should be used strictly in “low-risk situations” [6]

[1] Bialoglowy, Marek. "Bluetooth Security Review, Part 1." Bluetooth Security
Review, Part 2. 25 April 2005. Security Focus. 16 Sept. 2008
<http://www.securityfocus.com/infocus/1830>.
[2] Bialoglowy, Marek. "Bluetooth Security Review, Part 2." Bluetooth Security
Review, Part 2. 26 May 2005. Security Focus. 16 Sept. 2008
<http://www.securityfocus.com/infocus/1836>.
[3] Dawson, Chris. "Device Tracking on a Scattered, Bluetooth-Enabled Network."
Thesis14.pdf. May 2005. University of Bristol. 16 Sept. 2008
<http://www.cs.bris.ac.uk/teaching/resources/coms30500/exampletheses/thesis14.
pdf>.
[4] Haase, Marc, and Matthias Handy. "BlueTrack – Imperceptible Tracking of
Bluetooth Devices." Haase.pdf. University of Rostock. 16 Sept. 2008
<http://ubicomp.org/ubicomp2004/adjunct/posters/haase.pdf>.
[5] Pels, Martin, Jelmer Barhorst, Maarten Michels, Remco Hobo, and Jeffrey Barendse.
"Tracking people using Bluetooth." Bluetoothreport.pdf. 5 June 2005. Universiteit
van Amsterdam. 16 Sept. 2008
<http://homepages.alumni.os3.nl/~martin/papers/bluetoothreport.pdf>.

[6] Scarfone, Karen, and John Padgette. "Guide to Bluetooth Security (Draft)." Draft-
SP800-121.pdf. July 2008. National Institute of Standards and Technology - U.S.
Department of Commerce. 16 Sept. 2008
<http://csrc.nist.gov/publications/drafts/800-121/draft-sp800-121.pdf>.
[7] Wong, Ford-Long, and Frank Stajano. "Location Privacy in Bluetooth." 2005-
WongSta-location.pdf. 2005. University of Cambridge, Computer Laboratory. 16
Sept. 2008 <http://www.cl.cam.ac.uk/~fms27/papers/2005-wongsta-
location.pdf>.