Bluetooth technology: security features, vulnerabilities ...

Bluetooth technology: security features, vulnerabilities and attacks Pasquale Stirparo Jan Loeschner Marco Cattani

JRC 68414

The mission of the JRC-IPSC is to provide research results and to support EU policy-makers in their effort towards global security and towards protection of European citizens from accidents, deliberate attacks, fraud and illegal actions against EU policies.

European Commission Joint Research Centre Institute for the Protection and Security of the Citizen Contact information Address: Pasquale Stirparo, TP 361, Via E. Fermi 2749, 21027 Ispra (VA), Italy E-mail: [email protected] Tel.: +39-0332-789314 Fax: +39-0332-785145 http://ipsc.jrc.ec.europa.eu/ http://www.jrc.ec.europa.eu/ Legal Notice Neither the European Commission nor any person acting on behalf of the Commission is responsible for the use, which might be made of this publication. Europe Direct is a service to help you find answers to your questions about the European Union Freephone number (*): 00 800 6 7 8 9 10 11 (*) Certain mobile telephone operators do not allow access to 00 800 numbers or these calls may be billed.

A great deal of additional information on the European Union is available on the Internet. It can be accessed through the Europa server http://europa.eu/ JRC 68414 Luxembourg: Publications Office of the European Union © European Union, 2011 Reproduction is authorised provided the source is acknowledged Printed in Italy

TABLE OF CONTENT 1. Introduction ....................................................................................................................................... 4 2. State of The Art ................................................................................................................................. 5 2.1. Protocol Versions ....................................................................................................................... 5 3. Bluetooth Stack ................................................................................................................................. 8 3.1. Physical Layer ............................................................................................................................ 8 3.2. Baseband .................................................................................................................................... 8 3.3. LMP (Link Manager Protocol)................................................................................................... 9 3.4. HCI (Host/Controller Interface) ................................................................................................. 9 3.5. L2CAP (Logical Link Control & Adaptation Protocol)........................................................... 10 3.6. SDP (Service Discovery Protocol) ........................................................................................... 10 3.7. RFCOMM (Serial Port Emulation) .......................................................................................... 10 3.8. Profiles...................................................................................................................................... 10 4. Security Features and Architecture ................................................................................................. 12 4.1. Security of Bluetooth BR/EDR/HS.......................................................................................... 12 4.1.1. Pairing ............................................................................................................................... 13 4.1.2. Authentication ................................................................................................................... 14 4.1.3. Authorization..................................................................................................................... 15 4.1.4. Confidentiality................................................................................................................... 15 4.2. Security of Bluetooth LE.......................................................................................................... 15 4.2.1. Key Generation and Distribution ...................................................................................... 15 5. Bluetooth Threats and Vulnerabilities............................................................................................. 17 6. Known Attacks and Tools ............................................................................................................... 18 6.1. Blueprinting.............................................................................................................................. 18 6.2. Long Distance Snarf................................................................................................................. 18 6.3. Bluebug .................................................................................................................................... 18 6.4. BT Audit................................................................................................................................... 18 6.5. Blue Smack............................................................................................................................... 18 6.6. BT Class ................................................................................................................................... 18 6.7. Bluesnarf .................................................................................................................................. 18 6.8. Bluesnarf ++ ............................................................................................................................. 18 6.9. HeloMoto.................................................................................................................................. 18 6.10. Blue Bump.............................................................................................................................. 19 6.11. Blue Chop............................................................................................................................... 19 6.12. Car Whisperer......................................................................................................................... 19 6.13. Bluefish .................................................................................................................................. 19 6.14. BlueZ Arbitrary Command Execution Vulnerability............................................................. 19 6.15. Redfang .................................................................................................................................. 20 6.16. Tbear....................................................................................................................................... 20 6.17. Bluetooth Stack Smasher........................................................................................................ 20 6.18. Sony/Ericsson L2CAP Length Field DoS .............................................................................. 20 6.19. Blueline .................................................................................................................................. 20 6.20. Nokia N70 Malformed L2CAP Frame DoS........................................................................... 21 7. Conclusions and Recommendations................................................................................................ 22 8. Future Works................................................................................................................................... 23 9. References ....................................................................................................................................... 24 European Commission ........................................................................................................................... 25

1. Introduction Bluetooth wireless technology is a short-range communications system, intended to replace the cable(s) connecting portable and/or fixed electronic devices. The key features of Bluetooth wireless technology are robustness, low power consumption and low cost. 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 RS232 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). Still according to Bluetooth SIG [14], listed below there are numbers of Bluetooth products worldwide that give a more updated 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 said 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. The rest of this document is structured in the following way. Chapter 2 will give a quick overview on the general characteristics of Bluetooth technology, with a chronological list of its releases and related features. Chapter 3 will go a bit deeper in the analysis of Bluetooth stack’s main layers. In Chapter 4 are introduced the security features offered by Bluetooth, while Chapter 5 expose known vulnerabilities and potential threats. In Chapter 6 is presented a comprehensive list of known attacks. Chapter 7 and 8 conclude the document with recommendation and indication for future works.

2. State of The Art The Bluetooth technology operates in the frequency band 2400-2800 MHz, called ISM [7] (Industrial Scientific Medical) license free of any use. According to the standard, information is sent using a technology called FHSS radios [8] (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 (so 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. Class

Power (mW)

Power (dbM)

Distance (m)

1

100

20

~ 100

2

2.5

4

~ 10

3

1

0

~1

Sample Devices BT Access Point, dongles Keyboards, mice Mobile phone headset

Table 1: Bluetooth classes

Figure 1: Examples of Bluetooth piconet topologies [17]

2.1.

Protocol Versions

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 BR system offers synchronous and asynchronous connections with data rates of 721.2 kbps for Basic Rate, 2.1 Mbps for Enhanced Data Rate and high-speed operation up to 24 Mbps with the 802.11 AMP (Alternate MAC/PHYs). Introduced in Bluetooth version 2.0, Enhanced Data Rate (EDR) specifies data rates up to 3 Mbps and throughput of approximately 2.1 Mbps. BR uses Gaussian Frequency-Shift Keying (GFSK) modulation to achieve a 1 Mbps data rate. EDR uses π/4 rotated Differential Quaternary Phase Shift Keying (DQPSK) modulation to achieve a 2 Mbps data rate, and 8 phase Differential Phase Shift Keying (8DPSK) to achieve a 3 Mbps data rate.

Charachteristic

Bluetooth BR/EDR

Bluetooth LE

RF Physical Channels

79 channels with 1 MHz channel spacing

40 channels with 2 MHz channel spacing

Discovery/Connect

Inquiry/Paging

Advertising

Number of Piconet Slaves

7 (active)/255 (total)

Unlimited

Device Address Privacy

None

Private device addressing available

Max Data Rate

1–3 Mbps

1 Mbps via GFSK modulation

Encryption Algorithm

E0/SAFER+

Typical Range

30 meters

Max Output Power

100 mW (20 dBm)

AES-CCM 50 meters 10 mW (10 dBm)

Table 2: Key differences between Bluetooth BR/EDR and LE [18]

Note that EDR support is not required for devices compliant with the Bluetooth 2.0 specification or later. Therefore, there are devices on the market that are “Bluetooth 2.0 compliant” versus “Bluetooth 2.0 + EDR compliant.” The former are devices that support required version 2.0 features but only provide the BR data rate. Introduced in the Bluetooth 3.0 + HS specification, devices can support faster data rates by using Alternate MAC/PHYs (AMP). This is known as Bluetooth High Speed (HS). The LE system includes features designed to enable products that require lower current consumption, lower complexity and lower cost than BR/EDR. The LE system is also designed for use cases and applications with lower data rates and has lower duty cycles. Bluetooth LE was introduced in the Bluetooth 4.0 specification. Formerly known as “Wibree” and “Ultra Low Power Bluetooth,” LE is primarily designed to bring Bluetooth technology to coin cell battery- powered devices such as medical devices and other sensors. The key technology goals of Bluetooth LE (compared with Bluetooth BR/EDR) include lower power consumption, reduced memory requirements, efficient discovery and connection procedures, short packet lengths, and simple protocols and services. Following table summarizes the four main versions of the protocol that have been released until now [10][11][12][13]: Version

Year

1.1 1.2

2.0+EDR 2.1+EDR

2004 2007

3.0+HS

2009

Features Support for non encrypted channels Received Signal Strenght Indicator (RSSI) Faster connection Adaptive frequency hopping Enhanced error detection and flow control Enhanced synchronization capability Enhanced Data Rate Erroneous Data Reporting Encryption Pause and Resume Extended Inquiry Response Link Supervision Timeout Changed Event Non-Automatically-Flushable Packet Boundary Flag Secure Simple Pairing Sniff Subrating Security Mode 4 AMP Manager Protocol (A2MP) Enhancements to L2CAP including Enhanced Retransmission Mode and Streaming Mode Improvements to the L2CAP state machine for AMP channels Fixed channel support Enhancements to HCI for AMP Enhancements to Security for AMP 802.11 Protocol Adaptation Layer Enhanced Power Control Unicast Connectionless Data HCI Read Encryption Key Size command

4.0

2010

Generic Test Methodology for AMP Enhanced USB and SDIO HCI Transports Bluetooth Low Energy including Low Energy Physical Layer Low Energy Link Layer Enhancements to HCI for Low Energy Low Energy Direct Test Mode AES Encryption (128 bit) Enhancements to L2CAP for Low Energy Enhancements to GAP for Low Energy Attribute Protocol (ATT) Generic Attribute Profile (GATT) Security Manager (SM)

Table 3: Bluetooth protocol version summary

3. Bluetooth Stack Bluetooth is defined as a layer protocol architecture consisting of core protocols, cable replacement protocols, telephony control protocols, and adopted protocols [2][9]. Mandatory protocols for all Bluetooth stacks are: LMP, L2CAP and SDP. 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 [17].

Figure 2: Bluetooth stack

3.1.

Physical Layer

The lower layer is the physical layer and it handles the radio signal. Bluetooth uses a radio technology called frequency-hopping spread spectrum (1600 hops per second), which chops up the data being sent and transmits chunks of it on up to 79 bands (1 MHz each) in the range 2402-2480 MHz. This range is in the globally unlicensed Industrial, Scientific and Medical (ISM) 2.4 GHz short-range radio frequency band. The transmission method used by Bluetooth is the Gaussian Frequency Shift Keying (GFSK) [6].

3.2.

Baseband

The Baseband layer is in charge of formatting the packets and of the connections management via Link Manager Protocol In order to find other devices in range and their addresses, a Bluetooth device has to perform a scanning procedure called inquiry, questioning the devices around it and requesting their Bluetooth address. Such a procedure is completely anonymous; the requesting device does not reveal its address to the devices interrogated. The inquiring device, upon receipt of the response by the inquired device, can reach it with a page message. Only after this exchange of messages, frequency hopping (FH) synchronization procedure between devices is over. A Bluetooth device remains listening for page messages only if its status is set to page scan mode. By definition, the device sending the page message will be the master, while the other device will be the slave.

3.3.

LMP (Link Manager Protocol)

It 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. The Link Manager Protocol is used to communicate between the Link Managers (LM) on the two devices. The LM is also responsible for exchanging security-related messages. A large set of control messages or LMP protocol data units (PDU) have been defined. Many of these are security related and some PDUs are used to carry the information needed at pairing and authentication, and for enabling of encryption.

Figure 3: The LMP PDU format [15]

Figure 4: Connection establishment example, LMP PDU flow [15]

3.4.

HCI (Host/Controller Interface)

The HCI is an optional implementation component that can be used to separate higher- and lower-level functions on different processors. It standardized communication between the host stack (e.g., a PC or mobile phone OS) and the controller (the Bluetooth IC). When used, the HCI acts as a consistent interface between the two separate processors handling upper- and lower-level functions. An example where an HCI would be implemented is an external Bluetooth dongle on a laptop. The lower-level (Bluetooth module) functions are likely to be handled by the dongle, with upper-level functions managed by the laptop’s Bluetooth stack. The HCI handles communications between the two components. There are several HCI transport layer standards, each using a different hardware interface to transfer the same command, event and data packets. The most commonly used are USB (in PCs) and UART (in mobile phones and PDAs). In Bluetooth devices with simple functionality (e.g., headsets) the host stack and controller can be

implemented on the same microprocessor. In this case the HCI is optional, although often implemented as an internal software interface.

3.5.

L2CAP (Logical Link Control & Adaptation Protocol)

It 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. In Basic mode, L2CAP provides packets with a payload configurable up to 64kB, with 672 bytes as the default MTU, and 48 bytes as the minimum mandatory supported MTU. The MTU size is determined during channel configuration. In Retransmission & Flow Control mode, L2CAP can be configured for reliable or isochronous data per channel by performing retransmissions and CRC checks (called Frame Check Sequence).

3.6.

SDP (Service Discovery Protocol)

Service Discovery Protocol (SDP) allows a device to discover services supported by other devices, and their associated parameters. For example, when connecting a mobile phone to a Bluetooth headset, SDP will be used for determining which Bluetooth profiles are supported by the headset (Headset Profile, Hands Free Profile, Advanced Audio Distribution Profile (A2DP) etc.), and the protocol multiplexer settings needed to connect to each of them. A Universally Unique Identifier (UUID) identifies each service, 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.7.

RFCOMM (Serial Port Emulation)

Radio frequency communications (RFCOMM) is a cable replacement protocol used to create a virtual serial data stream. RFCOMM provides for binary data transport and emulates EIA-232 (formerly RS-232) control signals over the Bluetooth baseband layer and it’s based on ETSI standard TS 07.10. 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. It supports up to 60 simultaneous connections between two devices. Many Bluetooth applications use RFCOMM because of its widespread support and publicly available API on most operating systems. Additionally, applications that used a serial port to communicate can be quickly ported to use RFCOMM. Others protocols of the Bluetooth stack are BNEP (Bluetooth Network Encapsulation Protocol), AVCTP (Audio/Video Control Transport Protocol), AVDTP (Audio/Video Distribution Transport Protocol) and Telephony control protocol.

3.8.

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 5. 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). All other existing Bluetooth profiles make use of the GAP. For instance, the very original purpose of the Bluetooth standard was short-range cable replacement. Pure cable replacement through RS232 emulation is offered by the serial port profile. Several other profiles, like the personal area network (PAN) and local positioning profile make use of the serial port profile. 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.

Figure 5: Bluetooth profiles

4. Security Features and Architecture 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.

4.1.

Security of Bluetooth BR/EDR/HS

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. The security policy determines if a device demands authentication and/or encryption. One very simple approach is to demand maximum link-level security, that is, both authentication and encryption for all connections. This is an “always-on” link-level security policy. Such a simple policy has several advantages giving a high level of security for all local connections and being easy to implement. But such always-on security policy is not sufficient for all Bluetooth usage scenarios. A better flexibility link-level security mechanism enforcement is necessary. This can be achieved by service level–enabled security (aligned with the access control mechanism) [15]. The four security modes defined are the following: • 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 encryption of the Bluetooth link, at link establishment. Instead, security is enforced at channel (L2CAP) or connection (e.g., Service Discovery Protocol (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: Security Mode 4 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: o Authenticated link key required o Unauthenticated link key required o No security required In the following table a summary of the different security mode options for Master respective Slave, and the resulting security mechanism(s): Slave Security Mode 1

1 No Authentication, no encryption.

Master Security Mode 2 If the master application demands authentication

3 The link will be authenticated. If the master

2

If the slave application demands it, the link will be authenticated (and encrypted).

3

The link will be authenticated. If the slave policy demands it, the link will be encrypted.

(and encryption), then the link will be authenticated (and encrypted). If the master or slave application demands it, the link will be authenticated (and encrypted).

policy demands it, the link will be encrypted. The link will be authenticated. If the master policy demands it, or if the slave application demands it, the link will be encrypted. The link will be authenticated. If the slave or the master policy demands it, the link will be encrypted.

The link will be authenticated. If the slave policy demands it, or the master application demands it, the link will be encrypted. Table 4: Different security mode options and resulting configuration

4.1.1. Pairing Many of the services offered over Bluetooth can expose private data or allow the connecting party to control the Bluetooth device. For security reasons it is therefore necessary to control which devices are allowed to connect to a given Bluetooth device. At the same time, it is useful for Bluetooth devices to automatically establish a connection without user intervention as soon as they are in range. To resolve this conflict, Bluetooth uses a process called pairing, which is generally manually started by a device user, making that device's Bluetooth link visible to other devices. Two devices need to be paired to communicate with each other; the pairing process is typically triggered automatically the first time a device receives a connection request from a device with which it is not yet paired. Once a pairing has been established, it is remembered by the devices, which can then connect to each other without user intervention. When desired, the user can later remove the pairing relationship. During the pairing process, the two devices involved establish a relationship by creating a shared secret known as link key. If both devices store a link key, they are be paired or bonded. A device that wants to communicate only with a bonded device can cryptographically authenticate the identity of the other device, and so be sure that it is the same device it previously paired with. Once a link key has been generated, an authenticated (ACL) link between the devices may be encrypted so that the data that they exchange over the airwaves is protected against eavesdropping. Link keys can be deleted at any time by either device.

4.1.1.1. Pairing mechanisms Pairing mechanisms have changed significantly with the introduction of Secure Simple Pairing in Bluetooth v2.1. The following summarizes the pairing mechanisms: • Legacy pairing: This is the only method available in Bluetooth v2.0 and before. Each device must enter a PIN code; pairing is only successful if both devices enter the same PIN code. Any 16-byte UTF-8 string may be used as a PIN code, however not all devices may be capable of entering all possible PIN codes. • Limited input devices: The obvious example of this class of device is a Bluetooth Hands-free headset, which generally has few inputs. These devices usually have a fixed PIN, for example "0000" or "1234", that are hard-coded into the device. • Numeric input devices: Mobile phones are classic examples of these devices. They allow a user to enter a numeric value up to 16 digits in length. • Alphanumeric input devices: PCs and smartphones are examples of these devices. They allow a user to enter full UTF-8 text as a PIN code. If pairing with a less capable device the user needs to be aware of the input limitations on the other device, there is no mechanism available for a capable device to determine how it should limit the available input a user may use.

4.1.1.1.1.

PIN Pairing

In versions prior to Bluetooth v2.1 + EDR (released in July 2007), pairing between devices is accomplished through the entry of a PIN or passkey with a maximum length of 128 bits. For PIN pairing, two Bluetooth devices simultaneously derive link keys when the user(s) enter an identical secret PIN into one or both devices, depending on the configuration and device type. There are two types of such passkeys: variable passkeys, which can be chosen at the time of pairing via some input mechanism, and fixed passkeys, which are predetermined [17]. The type of passkey used is typically determined by a device’s input and display capabilities (for example, a Bluetooth-enabled phone with keyboard input and visual display may use a variable passkey, whereas a Bluetooth-enabled mouse may use a fixed passkey because it has

neither input nor display capabilities to enter or verify a passkey).

4.1.1.1.2.

Secure Simple Pairing (SSP)

This is required from Bluetooth v2.1 + EDR. A Bluetooth v2.1 device may only use legacy pairing to interoperate with a v2.0 or earlier device. Secure Simple Pairing uses a form of public key cryptography, and has the following association models [15][17][18]: • Numeric comparison: If both devices have a display and at least one can accept a binary Yes/No user input, they may use Numeric Comparison. This method displays a 6-digit numeric code on each device. The user should compare the numbers to ensure they are identical. If the comparison succeeds, the user(s) should confirm pairing on the device(s) that can accept an input. This method provides MITM protection, assuming the user confirms on both devices and actually performs the comparison properly. • Passkey Entry: This association model may be used between a device with a display and a device with numeric keypad entry (such as a keyboard), or two devices with numeric keypad entry. In the first case, the display is used to show a 6-digits numeric code to the user, who then enters the code on the keypad. In the second case, the user of each device enters the same 6-digits number. Both cases provide MITM protection. • Just Works: It was primarily designed for scenarios where at least one of the devices does not have a display nor does it have a keyboard to enter six decimal digits. A good example of this model is the cell phone/mono headset scenario where most headsets do not have a display. The Just Works association model uses the Numeric Comparison protocol, but the user is never shown a number and the application may simply ask the user to accept the connection (exact implementation is up to the end product manufacturer). When compared against today's experience of a headset with a fixed PIN, the security level of the Just Works association model is considerably higher since a high degree of protection against passive eavesdropping is realized. This method provides no man in the middle (MITM) protection. • Out of band (OOB): The Out of Band (OOB) association model was designed for devices that support a common additional wireless/wired technology (e.g., Near Field Communication or NFC) for the purposes of device discovery and cryptographic value exchange. In the case of NFC, the OOB model allows devices to pair by simply “tapping” one device against the other, followed by the user accepting the pairing via a single button push. It is important to note that to keep the pairing process as secure as possible, the OOB technology should be designed and configured to mitigate eavesdropping and MITM attacks. If it is not, security may be compromised during authentication. The user's experience differs a bit depending on the Out of Band mechanism. The OOB association model does not support a solution where the user has activated a Bluetooth connection and would like to use OOB for authentication only.

4.1.2. Authentication Authentication uses a challenge-response scheme in which a claimant’s knowledge of a secret key is checked through a 2-move protocol using symmetric secret keys. The latter implies that a correct claimant/verifier pair shares the same secret key, for example K. The verifier is not required to be the master. The application indicates which device has to be authenticated. Some applications only require a one-way authentication. However, some peer-to-peer communications should use a mutual authentication in which each device is subsequently the challenger (verifier) in two authentication procedures. The steps in the authentication process are as follows [18]: 1) The verifier transmits a 128-bit random challenge (AU_RAND) to the claimant. 2) The claimant uses the E1 algorithm to compute an authentication response using his or her unique 48bit Bluetooth device address (BD_ADDR), the link key, and AU_RAND as inputs. The verifier performs the same computation. Only the 32 most significant bits of the E1 output are used for authentication purposes. The remaining 96 bits of the 128-bit output are known as the Authenticated Ciphering Offset (ACO) value, which will be used later as input to create the Bluetooth encryption key. 3) The claimant returns the most significant 32 bits of the E1 output as the computed response, the Signed Response (SRES), to the verifier. 4) The verifier compares the SRES from the claimant with the value that it computed. 5) If the two 32-bit values are equal, the authentication is considered successful. If the two 32-bit values are not equal, the authentication fails. When the authentication attempt fails, a waiting interval shall pass before the verifier will initiate a new authentication attempt to the same claimant, or before it will respond to an authentication attempt initiated by a device claiming the same identity as the failed device. For each subsequent authentication failure, the waiting interval shall be increased exponentially. That is, after each failure, the waiting interval before a new attempt can be made, could be for example, twice as long as the waiting interval prior to the previous attempt. This

procedure prevents an intruder from repeating the authentication procedure with a large number of different keys.

4.1.3. Authorization Bluetooth allows two different level of trust related to the devices, and three levels of service security. A device is considered trusted if it has previously been paired with the device, and will have full access to services on the Bluetooth device. On the other hand, untrusted devices are those that have not previously been paired with the device (or the relationship has been otherwise removed), and will have restricted access to services. The Bluetooth specification specifies also three levels of security for Bluetooth services: • Service Level 1: These services require device authentication and authorization. Trusted devices will be granted automatic access to these services. Manual authentication and authorization will be required before untrusted devices are granted access to these services. • Service Level 2: These services require authentication, but do not require authorization. • Service Level 3: These services have no security and are open to all devices.

4.1.4. Confidentiality Bluetooth uses E0, a stream cipher, as the basis for the encryption processing associated with these encryption modes. The defined modes include: • Encryption Mode 1: No encryption. All traffic is unencrypted when this mode is used. • Encryption Mode 2: Traffic between individual endpoints (non-broadcast) is encrypted with individual link keys. Broadcast traffic is unencrypted. • Encryption Mode 3: Both broadcast and point-to-point traffic is encrypted with the same encryption key (the master link key). In this mode, all traffic is readable by all nodes in the piconet (and remains encrypted to outside observers). Note that the notion of privacy in Encryption Mode 3 is predicated on the idea that all nodes in the piconet are trusted because all nodes will have access to the encrypted data. Mode 2 and 3 uses the same encryption mechanism. Of importance to note is that when encryption is used in Bluetooth, not all parts of the Bluetooth packet are encrypted. Because all members of a piconet must be able to determine whether the packet is meant for them, the header of the message must be unencrypted.

4.2.

Security of Bluetooth LE

This is required by Bluetooth v4. Bluetooth LE has some differences in security aspects with respect to BR/EDR security features such as Secure Simple Pairing. The association models are similar to Secure Simple Pairing from the user perspective and have the same names, but have differences in the quality of the protection provided. One difference is that LE pairing results in the generation of a Long-Term Key (LTK) rather than a Link Key, which is determined by one device and sent over to the other device during pairing, instead of both devices generating the same key individually. Due to its very limited resources, the encryption through Elliptic Curves Diffie-Hellman could not be used here, thus passive eavesdropping protection is not present in LE. Therefore, if an attacker can capture the LE pairing frames, he/she may be able to determine the resulting LTK. LE uses Advanced Encryption Standard–Counter with CBC-MAC (AES-CCM). LE also introduces new cryptographic keys called the Identity Resolving Key (IRK) and Connection Signature Resolving Key (CSRK). The IRK is used to resolve public to private device address mapping. This allows a trusted device to determine another device’s private device address from a public (random) device address. This new feature provides privacy for a particular device meaning that, if the device remains discoverable, an adversary cannot track its location over the time. The CSRK is used to verify cryptographically signed data frames from a particular device. This allows a Bluetooth connection to use data signing (providing integrity and authentication) to protect the connection instead of data encryption (which, in the case of AES-CCM, provides confidentiality, integrity, and authentication) [18]. There is no separate authentication challenge/response step as with BR/EDR/HS to verify that they both have the same LTK or CSRK. Because the LTK is used as input for the encryption key, successful encryption setup provides implicit authentication. Similarly, successful data signing provides implicit authentication that the remote device holds the correct CSRK, although confidentiality is not provided.

4.2.1. Key Generation and Distribution As shown in Figure 6, LE pairing begins with the two devices agreeing on a Temporary Key (TK), whose value depends on the pairing method being used. The devices then exchange random values and generate a Short Term Key (STK) based on these values and the TK. The STK is then used to encrypt the link, and so it

becomes possible to proceed with the secure key distribution of the LTK, IRK, and CSRK. Before keys to be distributed they have to be generated. There are two possible options fro this: a. Database Lookup: a device simply generates random 128-bit values and stores them in a local database, hence the name; b. Key Hierarchy: a device uses a single 128-bit static random value called Encryption Root (ER) and a 16-bit Diversifier (DIV), unique to each trusted device, to generate the keys. At this point keys can be derived as follow: - LTK = d1(ER, DIV, 0) - CSRK = d1(ER, DIV, 1) - IRK = d1(IR, 1, 0) where d1 is a called a Diversifying Function and is based on AES-128 encryption. Using this Key Hierarchy method, the device does not need to store multiple 128-bit keys for each trusted device; rather, it only needs to store its ER and the unique DIVs for each device. During reconnection, the remote device sends its DIV. The local device can then regenerate the LTK and/or CSRK from its ER and the passed DIV. If data encryption or signing is set up successfully, it is verified that the remote device had the correct LTK or CSRK. If unsuccessful, the link is dropped.

Figure 6: LE Pairing and Key Distribution scheme [18]

5. 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-in-the-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 location-tracking threats. • 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. • 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 specification was implemented correctly. Implementation flaws have been at the root of many well-known Bluetooth security attacks (see Chapter 6). Following a summary of some of the 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 [18]: • 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 brute-force attack.

6. Known Attacks and Tools 6.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 [5].

6.2.

Long Distance Snarf

By attaching an external antenna to a Bluetooth dongle it is possible to extend its radio range. Bluetooth Class 2 radios that are used in mobile phones have a typical range of 10 meters. This experiment shows that it is possible to connect to such a class 2 device from about 170 times the range than specified [3].

6.3.

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 [3].

6.4.

BT Audit

BT Audit is a scanner for L2CAP and RFCOMM in order to find so-called open ports and possible vulnerable applications bound to them.

6.5.

Blue Smack

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 ship with the official Linux Bluez utility package [3].

6.6.

BT Class

Each Bluetooth device has a device class (type of device and services it provides) that is part of the responds to an inquiry. The device class has a total length of 24 bits and is separated in three parts. First there is the Service Class, which is a bit field (first 11 bits), and second and third are the Major (5 bits) and Minor (6 bits) device class. Some devices may lower their security settings for certain device types, as they are trustworthy. So through changing the device class is possible to gain more access to target devices [3].

6.7.

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 [3].

6.8.

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 [3].

6.9.

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 [3].

6.10.

Blue Bump

The BlueBump attack requires the attacker to be a social engineer. The way it works is that the attacker establishes a trusted connection to a certain device. This could be achieved by sending a business card and therefore forcing the receiver to authenticate (Mode-3-Abuse). The attacker keeps the connection open and tells the victim to delete the link key for the attacker's device. The victim is not aware of the connection that is still active. The attacker now requests a link-key regeneration. Doing so, the attacker's device gets a new entry in the list without having to authenticate again. The attacker is then able to connect to the device at any time as long as the key is not deleted again [3].

6.11.

Blue Chop

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 [3].

6.12.

Car Whisperer

The carwhisperer project intends to sensitize manufacturers of carkits and other Bluetooth appliances without display and keyboard for the possible security threats evolving from the use of standard passkeys. A Bluetooth passkey is used within the pairing process that takes place, when two Bluetooth enabled devices connect for the first time. Besides other public data, the passkey is a secret parameter used in the process that generates and exchanges the so-called link key. In Bluetooth communication scenarios the link key is used for authentication and encryption of the information that is exchanged between the counterparts of the communication. A scanner is repeatedly performing a device inquiry for visible Bluetooth devices of which the class matches the one of Bluetooth Headsets and Hands-Free Units. Once a visible Bluetooth device with the appropriate device class is found, the program connects to the found device (on RFCOMM channel 1), opens a control connection and connects the SCO links. The passkey that is required for the initial connection to the device is provided depending on the Bluetooth address that requests it. Depending on the first three bytes of the address, which references the manufacturer, different passkeys are returned. In quite a few cases the preset standard passkey on headsets and handsfree units is '0000' or '1234'. Once the connection has been successfully established, the program starts sending audio to, and recording audio from the headset. This allows attackers to inject audio data into the car. This could be fake traffic announcements or nice words. Attackers are also able to eavesdrop conversations among people sitting in the car [3].

6.13.

Bluefish

Bluefish is a surveillance system written for the Linux platform that constantly scans for Bluetooth enabled devices. Once a device is found Bluefish, using an attached webcam, takes a picture of the area the device was discovered in and retrieves all information available from the device. The picture and device information are then stored in a database. If the user enters the area being observed by Bluefish again, they will be sent the picture Bluefish took of them last time they were in the area. Each of these images contains a caption of the device's name and the last time it was observed [4].

6.14.

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 [4].

6.15.

Redfang

Redfang is a tool that brute-forces Bluetooth BD addresses in order to communicate with devices in nondiscoverable 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 [4]. This tool is at a proof-of-concept development stage.

6.16.

Tbear

T-BEAR, the Transient Bluetooth Environment AuditoR, is a suite of programs used to audit Bluetooth devices. T-BEAR currently consists of a graphical Bluetooth discovery tool called 'tbear' and a L2CAP layer ping DoS program called 'tanya'. In addition, it also features a tool to discover devices in non-discoverable mode called 'tbsearch'. This program works similarly to Redfang to brute-force BD addresses of non-discoverable devices in order to attack them. However, instead of scanning across a user supplied address range, it uses a list of known Bluetooth device OUIs and searches through the 3 byte address range of each of those. This improves its efficiency incredibly.

6.17.

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.

6.18.

Sony/Ericsson L2CAP Length Field DoS

Certain models of Sony/Ericsson phones are vulnerable to a DoS attack involving L2CAP frames with invalid header lengths. By sending a malformed L2CAP frame to certain models of Sony/Ericsson phones, it is possible to cause the device to lock-up. This is done by creating an L2CAP frame with an improperly set length field. For instance, it is possible to send an L2CAP echo frame to the device, which is 4 bytes in length but set the length field in the frame to 1 byte. When an affected device receives the frame its screen will either go blank or the device will halt. Known affected phone models are: • Sony/Ericsson K600i • Sony/Ericsson V600i • Sony/Ericsson W800i In addition, other Sony/Ericsson models may be affected. Currently a fix for this issue is unavailable. To protect himself from this issue, user should disable the affected device's Bluetooth functionality.

6.19.

Blueline

Blueline is the name given to a vulnerability that affects some models of Motorola phones. It allows an attacker to obscure information displayed in some connection request authorization dialogs. The Motorola PEBL, V600, and E398 cellular phones are vulnerable to an issue involving its user interface that may allow an attacker to trick a user into accepting a connection from a malicious device. These phones have two voice gateways. One of these, The "Headset Audio Gateway" profile operating on channel 3, does not require a device to be paired to connect to it. However, to connect to channel 3 the attacking device does need to be within the affected device's "Device History" list. This can be accomplished by performing a HeloMoto attack on the device. Once a connection to channel 3 has been made the device presents the user with a simple prompt asking if the remote device should be allowed to connect. This dialog takes the form of: Requests Voice Gateway? (Grant or Deny) The problem stems from the fact that control characters in the remote Bluetooth device's name are not sanitized. This can allow an attacker to affect how the prompt is displayed and obscure its intent. For example, an attacker can insert multiple '\n' characters to format the Bluetooth device name in such a way that the "Request Voice Gateway?" portion of the prompt is completely off-screen. Therefore the attacker can use a

Bluetooth device name that does this and also creates the appearance of another dialog prompt. Once the attacker has tricked the user into accepting the connection, they then gain AT command access to the phone.

6.20.

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.

7. Conclusions and Recommendations Bluetooth specifications offer several mechanisms to protect security and privacy to a certain extend. The major issues are caused by erroneous implementation of the protocol stack by vendors/manufacturers. This is proven by the fact that most of the vulnerabilities discovered are “vendor-related” and not general for a certain core version of the Bluetooth standard. Most of the vulnerabilities and attacks presented in this report go back to several years ago, to the core specification number 2 (which is still the most widespread). Since then the new versions have (almost) not introduced new security features (except for v4) and also not many new vulnerabilities have been discovered. In the mean time, vendors have patched those published. However, Bluetooth security should still considered not reliable for sensitive applications. It is important that mobile application developers provide appropriate security controls that offer identity-level security features (that is, user authentication and user authorization) for applications that require security above and beyond what Bluetooth natively offers. The following is a list of technical recommendations concerning Bluetooth security [17] (See NIST’s “Guide to Bluetooth Security” for a comprehensive checklist with additional recommendations): • Use complex PINs for Bluetooth devices. • In sensitive and high-security environments, configure Bluetooth devices to limit the power used by the Bluetooth radio. • Avoid using the “Just Works” association model for v2.1 + EDR devices. • Limit the services and profiles available on Bluetooth devices to only those required. • Configure Bluetooth devices as non-discoverable except during pairing. • Avoid use of Security Mode 1. • Enable mutual authentication for all Bluetooth communications. • Configure the maximum allowable size for encryption keys. • In sensitive and high-security environments, perform pairing in secure areas to limit the possibility of PIN disclosure. • Unpair devices that had previously paired with a device if a Bluetooth device is lost or stolen.

8. Future Works Since Bluetooth is becoming more and more pervasive as technology, security research activities should point the new types of “smart devices” instead of focusing only on the usual smartphone/tablets. This because the latter are becoming more and more powerful and vendors/manufacturers have experience from their previous vulnerabilities, while the former are new actors in this scenario and most of the times such devices have less capabilities or allow less interaction (i.e., no screen or no keyboard for typing passwords). Moreover, since one of the major issues has been identified as the bad implementation by manufacturer, Recommendations and Best Practices for developers, manufactures as well as for final users shall be developed.

9. References [1] Bluetooth specification, https://www.bluetooth.org/Technical/Specifications/adopted.htm [2] Stallings, W.; Wireless communications & networks 2e, Prentice Hall (2004) [3] Trifinite Group, http://trifinite.org [4] Wireless Vulnerabilities & Exploits, http://www.wve.org [5] Herfurt, M., Mulliner, C.; Remote Device Identification based on Bluetooth Fingerprinting Techniques, Trifinite Group White Paper, 2004 [6] Gaussian Frequency-Shift Keying (GFSK), http://en.wikipedia.org/wiki/Gaussian_frequency-shift_keying [7] ISM Band, http://en.wikipedia.org/wiki/ISM_band [8] Frequency-hopping spread spectrum, http://en.wikipedia.org/wiki/Frequency-hopping_spread_spectrum [9] Bluetooth, http://en.wikipedia.org/wiki/Bluetooth [10] Bluetooth Specification: Core Versione 2.0 + EDR, https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=40560 [11] Bluetooth Specification: Core Versione 2.1 + EDR, https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=241363 [12] Bluetooth Specification: Core Versione 3.0 + HS, https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=174214 [13] Bluetooth Specification: Core Versione 4.0, https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=229737 [14] Bluetooth SIG, http://www.bluetooth.com/Pages/network-effect.aspx [15] Gehrmann, C., Persson, J., Smeets, B.; Bluetooth Security, Artech House, Computer Security Series, 2004 [16] Bluetooth Special Interest Group, Specification of the Bluetooth System, Version 1.1, Profiles, Part K:1 Generic Access Profile, February 2001 [17] Dwivedi, H., Clarck, C., Thiel, D.; Mobile Application Security, McGraw Hill, 2010 [18] NIST, Guide to Bluetooth Security (Draft), Special Pubblication 800-121, Rev. 1, 2011

European Commission Joint Research Centre – Institute for the Protection and Security of the Citizen Title: State of The Art of Bluetooth Technology - technical characteristics, security features, vulnerabilities and attacks Authors: Pasquale STIRPARO, Marco CATTANI, Jan LOESCHNER Luxembourg: Publications Office of the European Union 2011 – 27 pp. – 21 x 29.7 cm Abstract Bluetooth wireless technology is a short-range communications system, intended to replace the cable(s) connecting portable and/or fixed electronic devices. Created by telecom vendor Ericsson in 1994, 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). In 2010 have been sold 906 million mobile phones Bluetooth enabled, in 2011 more than 40 million Bluetooth enabled health and medical devices were already in the market, as well as one third of all new vehicles produced worldwide in 2011 include Bluetooth technology. 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. The report will give first a quick overview on the general characteristics of Bluetooth technology (Chapter 2), with a chronological list of its releases and related features. It will go then deep in the analysis of Bluetooth stack’s main layers (Chapter 3) and the security features offered (Chapter 4) by the specifications. In the last part of the report known vulnerabilities and potential threats will be presented (Chapter 5), as well as a comprehensive list of known attacks (Chapter 6). The last two chapters (Chapter 7 and 8) will conclude the report with recommendation and indication for future works.

How to obtain EU publications Our priced publications are available from EU Bookshop (http://bookshop.europa.eu), where you can place an order with the sales agent of your choice. The Publications Office has a worldwide network of sales agents. You can obtain their contact details by sending a fax to (352) 29 29-42758.

JRC68414

The mission of the JRC is to provide customer-driven scientific and technical support for the conception, development, implementation and monitoring of EU policies. As a service of the European Commission, the JRC functions as a reference centre of science and technology for the Union. Close to the policy-making process, it serves the common interest of the Member States, while being independent of special interests, whether private or national.