1. Introduction
The Bluetooth wireless technology is a short-range communication system (see Table 1) intended to replace the cable(s) connecting portable and/or fixed electronic devices. The key features of Bluetooth wireless technology are robustness, low cost and device discovery support. Many features of the core specification are optional, allowing product differentiation [1].
Created by telecom vendor Ericsson in 1994, it was originally conceived as a wireless alternative to RS-232 data cables. In 1998, Ericsson, IBM, Intel, Nokia, and
Toshiba formed a trade association known as Bluetooth SIG (Special Interest Group) to publish and promote the Bluetooth standard. From the first Bluetooth enabled device in 1999 to 2008, more than 2 billion devices were using the Bluetooth technology (according to a press release from Bluetooth SIG dated May 2008). It is therefore clear the high level of pervasiveness and ubiquity of this technology, which justify the need of a deep analysis related to the State of The Art of its security and privacy features as well as possible threats and vulnerabilities. Still according to Bluetooth SIG [2], listed below there are numbers of Bluetooth products worldwide that give a clearer picture of the dimension of this technology:
• 906 million mobile phones sold in 2010, almost 100 percent with Bluetooth technology.
• 171 million laptops shipped in 2010, including 77 percent with Bluetooth technology.
• More than 50 million game consoles shipped in 2010, including 62 percent with Bluetooth technology.
• More than 40 million Bluetooth enabled health and medical devices were already in the market in early 2011.
• One third of all new vehicles produced worldwide in 2011 include Bluetooth technology, growing to 70 percent by 2016, according to Strategy Analytics.
Having stated that, it is immediately clear the high level of pervasiveness and ubiquity of Bluetooth technology, which justify the need of a deep analysis related to the State of The Art of its security and privacy features as well as possible threats and vulnerabilities.
This paper is structured in the following way: Section 2 will give an overview on the general characteristics of the Bluetooth technology. Section 3 will go a deeper in the analysis of Bluetooth stack’s main layers. In Section 4, known vulnerabilities and potential threats are presented, while in Section 5 is presented a list of known attacks. Section 6 is the security features offered by Bluetooth specifications introduced. Section 7 presents the design of the Secure Architecture for Bluetooth-Enhanced Mobile “Smart” Commerce Environments. Section 8 concludes the document with security recommenddations.
2. Bluetooth Protocol: State of the Art
The Bluetooth technology operates in the frequency band 2400 - 2800 MHz, called ISM (Industrial Scientific Medical) license free of any use. According to the standard, information is sent using a technology called FHSS radios (Frequency-hopping spread spectrum), which allows sending pieces of information using 79 different bands (1 MHz, 2402 - 2480 MHz in the range) included in frequency band used.
The Bluetooth protocol uses a packet-based paradigm with a Master/Slave structure (different from clientserver protocols used by others). A device in master mode can communicate with up to seven devices in slave mode thus forming a piconet, a network of computers connected in ad-hoc mode. Each device connected to a piconet is synchronized with the master clock, which determines how packets are exchanged between devices of the piconet. Figure 1 shows an example of Bluetooth piconet topology.
There are two forms of Bluetooth wireless technology systems: Basic Rate (BR) and Low Energy (LE). Both systems include device discovery, connection establishment and connection mechanisms. The Basic Rate system includes optional Enhanced Data Rate (EDR), alternate Media Access Control (MAC) and Physical layers extensions (PHY). The LE system includes features designed to enable products that require lower current consumption, lower complexity and lower cost than BR/ EDR. LE is primarily designed to bring Bluetooth technology to coin cell battery-powered devices such as medical devices and sensors.
The key technology goals of Bluetooth LE (compared with Bluetooth BR/EDR, see Table 2) include lower power consumption, reduced memory requirements, efficient discovery and connection procedures, short packet lengths, and simple protocols and services. Four main versions of the Bluetooth protocol have been released until now [4- 7].
3. The Bluetooth Stack
Bluetooth is defined as a layer protocol architecture consisting of core protocols, cable replacement protocols, telephony control protocols, and adopted protocols [9].
Figure 1. Example of Bluetooth piconet topology [3].
Table 2. Key differences between Bluetooth BR/EDR and LE [8].
Mandatory protocols for all Bluetooth stacks are: LMP, L2CAP and SDP (Figure 2). Additionally, these other two protocols are almost universally supported: HCI and RFCOMM. The lower layer is the physical layer and it handles the radio signal. The second layer is the Baseband, which is in charge of formatting the packets before they are sent out; specifically it builds the header, computes the checksum, data encryption and decryption, etc. The Link Controller manages the implementation of the Baseband protocol, while the Link Manager manages the Bluetooth connections via Link Manager Protocol.
Bluetooth uses a 48-bit identifier, for device identification. This identifier is referred to as the Bluetooth device address (BD_ADDR). The first three bytes of the BD_ADDR are specific to the manufacturer of the Bluetooth radio, with identification assignments controlled by the IEEE Registration Authority [3].
3.1. Link Manager Protocol
The Link Manager Protocol (LMP) is used to control and negotiate all aspects of the Bluetooth connection between two devices. This includes the set-up and control of logical transports and logical links, and for control of physical links.
3.2. Logical Link Control & Adaptation Protocol
The Logical Link Control & Adaptation Protocol (L2CAP) is used to multiplex multiple logical connections between two devices using different higher-level protocols. It provides segmentation and reassembly of packets, as well as quality of service (QoS) related features.
3.3. Service Discovery Protocol
Service Discovery Protocol (SDP) allows a device to discover services supported by other devices, and their associated parameters. A Universally Unique Identifier (UUID) identifies each services, with official services (Bluetooth profiles) assigned a short form UUID (16 bits rather than the full 128). There are two different ways to perform service discovery:
• Searching: it refers to a specific service and it can be performed only knowing one or more attributes of the service;
• Browsing: it is performed by sending a request for the root browse group UUID. The inquired device reply with the list of all UUID related to the services available. At this point the inquiring device can perform the searching as described before, one for each service/UUID.
3.4. Serial Port Emulation
Radio frequency communications (RFCOMM) is a cable replacement protocol used to create a virtual serial data stream. RFCOMM provides a simple reliable data stream to the user, similar to TCP. It is used directly by many telephony related profiles as a carrier for AT commands, as well as being a transport layer for OBEX (Object Exchange) over Bluetooth.
3.5. Profiles
Profiles have been developed in order to offer interoperability and to provide support for specific applications. A profile defines an unambiguous description of the communication interface between two units for one particular service. A new profile can be built on existing ones, allowing efficient reuse of existing protocols and procedures. This gives raise to a hierarchical profiles structure as outlined in Figure 3. The most fundamental definitions, recommendations, and requirements related to modes of operation and connection and channel setup are given in the generic access profile (GAP). Profiles are linked to the services a given device offers/supports. Therefore from a security point of view, since Bluetooth enabled devices broadcast the list of supported services list upon request, each profile that is “advertised” could be seen as another potential door opened, more or less like tcp/upd ports for PCs.
4. Bluetooth Threats and Vulnerabilities
Due to its wireless nature, the Bluetooth communication channel is already subject to several threats like eavesdropping, impersonation, denial of service and man-inthe-middle. Other than the general wireless protocols’ issues, there are the following threats specific to the Bluetooth enabled devices:
• Location tracking: Bluetooth devices broadcast their unique address, being therefore subject to locationtracking threats [10].
• Key management: Like many technologies that use cryptography for features such as authentication and encryption, Bluetooth devices are subject to threats related to key management, including key disclosure or tampering.
• Bluejacking: It involves the sending of unsolicited messages to a victim’s Bluetooth device. This can be leveraged as a social-engineering attack that is enabled by susceptible Bluetooth devices. It can be also exploited for malware propagation, as demonstrated in [11].
• Incorrect protocol implementation: The quality of security on Bluetooth devices is determined to some degree by product-specific implementations. When a product manufacturer incorrectly implements the Bluetooth specification on its device, it makes the device or communications subject to security issues that would not exist if the specifications were implemented correctly. Implementation flaws have been at the root of many well-known Bluetooth securities attacks (see Section 6).
Here follows a summary of well-known security vulnerabilities associated with Bluetooth. Some of them are version specific while others common to all versions. For a more comprehensive list refer to [8]:
• Bluetooth Versions Prior to v1.2
o The unit key is reusable and becomes public when used. The unit key is a type of link key generated during device pairing, and has been deprecated since Bluetooth v1.2. This issue allows arbitrary eavesdropping by devices that have access to the unit key.
• Bluetooth Versions Prior to v2.1
o Short PINs are permitted. Because PINs are used to generate encryption keys and users may tend to select short PINs, this issue can lower the security assurances provided by Bluetooth’s encryption mechanisms.
o The encryption keystream repeats. In Bluetooth versions prior to v2.1, the keystream repeats after 23.3 hours of use. Therefore, a keystream is generated identical to that used earlier in the communication.
• Common to all Bluetooth versions:
o Unknown random number generator (RNG) strength for challenge-response. The strength of the RNG used to create challenge-response values for Bluetooth authentication is unknown. Weaknesses in this RNG could compromise the effectiveness of Bluetooth authentication and overall security.
o Negotiable encryption key length. The Bluetooth specification allows the negotiation of the encryption key down to a size as small as one byte.
o Shared master key. The encryption key used to key encrypted broadcast communications in a Bluetooth piconet is shared among all piconet members.
o Weak E0 stream cipher. A theoretical known-plaintext attack has been discovered that may allow recovery of an encryption key much faster than a bruteforce attack.
5. Known Attacks
This section contains a list of few of the well-known attacks successfully carried against Bluetooth devices. The Trifinite Group published [12] detailed descriptions of Bluetooth attacks along with downloadable audit and demonstration software.
5.1. Blueprinting
Blueprinting is a method to remotely find out details about Bluetooth-enabled devices. Blueprinting can be used for generating statistics about manufacturers and models and to find out whether there are devices in range that have issues with Bluetooth security [13].
5.2. BlueBug
BlueBug is a security loophole on some Bluetooth-enabled cell phones. Exploiting this loophole allows the unauthorized downloading of the phone books and the calls list, the sending and reading of SMS messages from the attacked phone and many more things.
5.3. BT Audit
BT Audit is a scanner for L2CAP and RFCOMM in order to find open ports and possible vulnerable applications bound to them.
5.4. BlueSmack
BlueSmack is a Bluetooth attack that knocks immediately out some Bluetooth-enabled devices from the piconet they are connected. This Denial of Service attack can be conducted using standard tools that are shiped with the official Linux Bluez utility package.
5.5. BlueSnarf
This attack allows access to a victim Bluetooth device because of a flaw in device firmware. In order to perform a BlueSnarf attack, the attacker needs to connect to the OBEX Push Profile (OPP), which has been specified for the easy exchange of business cards and other objects. In most of the cases, this service does not require authentication. Missing authentication is not a problem for OBEX Push, as long as everything is implemented correctly. The BlueSnarf attack connects to an OBEX Push target and performs an OBEX GET request for known filenames such as “telecom/pb.vcf” for the devices phone book or “telecom/cal.vcs” for the devices calendar file. In case of improper implementation of the device firmware, an attacker is able to retrieve all files where the name is either known or guessed correctly.
5.6. BlueSnarf++
BlueSnarf++ gives the attacker full read/write access when connecting to the OBEX Push Profile. Instead of a less functional OBEX Push daemon, these devices run an OBEX FTP server that can be connected as the OBEX Push service without pairing. Here the attacker can see all files in the file system (ls command) and can also delete them (rm command). The file system includes eventual memory extensions like memory sticks or SD cards.
5.7. HeloMoto
The HeloMoto attack takes advantage of the incorrect implementation of the “trusted device” handling on some Motorola devices. The attacker initiates a connection to the unauthenticated OBEX Push Profile pretending to send a vCard. The attacker interrupts the sending process and without interaction the attacker’s device is stored in the “list of trusted devices” on the victim’s phone. With an entry in that list, the attacker is able to connect to the headset profile without authentication. Once connected to this service, the attacker is able to take control of the device by means of AT-commands.
5.8. BlueChop
BlueChop is an attack that disrupts any established Bluetooth piconet by means of a device that is not participating the piconet. A precondition for this attack is that the master of the piconet supports multiple connections (a feature that is necessary for building up scatternets). In order to BlueChop a piconet, a device that is not participating to the targeted piconet spoofs a random slave out of the piconet and contacts the master. This leads to confusion of the master’s internal state and disrupts the piconet. This attack is not specific to any device manufacturer and seems to have general validity.
5.9. BlueZ Arbitrary Command Execution Vulnerability
Hcid utility spawns a helper program to request a PIN from the user when it receives a pairing request from a remote device. One of the arguments for calling the PIN helper application is the name of the remote device. However, when doing this, hcid does not escape shell characters. Thus an attacker can give a device a name containing commands to execute enclosed within characters. In addition, it is possible for an attacker to cause the PIN helper application to automatically pair with the remote device by adding “>/dev/null&echo PIN:
“ to the device name.
5.10. Redfang
Redfang is a tool that brute-forces Bluetooth BD addresses in order to communicate with devices in non-discoverable mode. Redfang accomplishes this by iterating through a user supplied range of device addresses and attempting to do a read_remote_name() on each one. If an address belongs to a Bluetooth device in the area, then the read_remote_name() call will return the device’s name. A malicious person can then use this information to attack the device even if it’s non-discoverable. To speed up the process, Redfang supports the user of multiple Bluetooth adapters to scan the supplied address range. Each adapter then scans disjoint portions of the address range. This tool is at a proof-of-concept development stage.
5.11. Bluetooth Stack Smasher
Bluetooth Stack Smasher (BSS) is a L2CAP protocol fuzzer designed to identify implementation weaknesses in Bluetooth devices. BSS is designed to transmit malformed L2CAP frames with a standard Bluetooth dongle on Linux systems. The malformed frames are designed to trigger and identify vulnerabilities in Bluetooth stack implementations, often resulting in denial of service conditions. Through the use of BSS, several L2CAP implementation weaknesses have been discovered in common devices.
5.12. Nokia N70 Malformed L2CAP Frame DoS
The Nokia N70 is vulnerable to a Denial of Service involving malformed L2CAP frames with unknown properties. The Nokia N70 contains a vulnerability that causes a DoS condition when a malformed L2CAP frame is received by the device’s Bluetooth interface. This can cause the device to become unresponsive and to display a “System Error” message.
6. Security Features and Architectures
Bluetooth wireless technology provides peer-to-peer communications over short distances. In order to provide usage protection and information confidentiality, the system provides security measures both at the application layer and the link layer. These measures are designed to be appropriate for a peer environment. This means that in each device, the authentication and encryption routines are implemented in the same way. The encryption key is entirely different from the authentication key. A new encryption key shall be generated each time encryption is activated. Thus, the lifetime of the encryption key does not necessarily correspond to the lifetime of the authentication key. The authentication key will be more static in its nature than the encryption key: once established, the particular application running on the device decides when, or if, to change it. To underline the fundamental importance of the authentication key to a specific link, it is often referred to as the link key. Three basic security services are specified in the Bluetooth standard:
• Authentication: verifying the identity of communicating devices based on their Bluetooth device address. Bluetooth does not provide native user authentication.
• Confidentiality: preventing information compromise caused by eavesdropping by ensuring that only authorized devices can access and view transmitted data.
• Authorization: allowing the control of resources by ensuring that a device is authorized to use a service before permitting it to do so.
The security policies of a device determine when and how to use security mechanisms. The Bluetooth standard provides some basic principles for enforcing link-level security and building more advanced security polices through four defined security modes:
• Security Mode 1: A Bluetooth unit in security mode 1 never initiates any security procedures; that is, it never demands authentication or encryption of the Bluetooth link.
• Security Mode 2: When a Bluetooth unit is operating in security mode 2, it shall not initiate any security procedures, that is, demand authentication or encrypttion of the Bluetooth link, at link establishment. Instead, security is enforced at channel (L2CAP) or connection (e.g., SDP, RFCOMM, TCS) establishment.
• Security Mode 3: When a Bluetooth unit is in security mode 3, it shall initiate security procedures before the link setup is completed. Two different security policies are possible: always demand authentication or always demand both authentication and encryption.
• Security Mode 4: it was defined in the v2.1 + EDR specification. It requires encryption for all services except Service Discovery, and it’s compulsory between v2.1 + EDR devices (essentially making Modes 1 through 3 legacy modes once v2.1 + EDR becomes widespread). Like Security Mode 2, security in Security Mode 4 is implemented after link setup, at service level, and it uses Secure Simple Pairing (SSP), in which Elliptic Curve Diffie-Hellman (ECDH) replaces legacy key agreement for link key generation. However, the device authentication and encryption algorithms are identical to the algorithms in Bluetooth v2.0 + EDR and earlier versions. Under Security Mode 4, service security requirements must be identified as one of the following: a) authenticated link key required, b) unauthenticated link key required or c) no security required.
Table 3 contains a summary of the different security mode options for Master respective Slave, and the resulting security mechanism(s).