Bluetooth Report (draft 20080927)

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 FrequencyHopping-Spread-Spectrum in which packets are transmitted at specified timeslots. 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 TCSBIN 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) ServiceLevel 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 predetermined 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 [email protected]. 9/15/2008. Bluetooth sniffing for all. http://www.heiseonline.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.remoteexploit.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/ [email protected]. 9/15/2008. New Hacker Tools for Bluetooth. http://www.heiseonline.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 nondiscoverable, 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 . [2] Bialoglowy, Marek. "Bluetooth Security Review, Part 2." Bluetooth Security Review, Part 2. 26 May 2005. Security Focus. 16 Sept. 2008 . [3] Dawson, Chris. "Device Tracking on a Scattered, Bluetooth-Enabled Network." Thesis14.pdf. May 2005. University of Bristol. 16 Sept. 2008 . [4] Haase, Marc, and Matthias Handy. "BlueTrack – Imperceptible Tracking of Bluetooth Devices." Haase.pdf. University of Rostock. 16 Sept. 2008 . [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 . [6] Scarfone, Karen, and John Padgette. "Guide to Bluetooth Security (Draft)." DraftSP800-121.pdf. July 2008. National Institute of Standards and Technology - U.S. Department of Commerce. 16 Sept. 2008 . [7] Wong, Ford-Long, and Frank Stajano. "Location Privacy in Bluetooth." 2005WongSta-location.pdf. 2005. University of Cambridge, Computer Laboratory. 16

Sept. 2008 .