Publication Date: June 2008
Table of Contents
- Effective Date
- List of Figures
- List of Tables
- List of Abbreviations and Acronyms
- 1 Introduction
- 2 Vulnerability Analysis
- 2.1 Physical Layer
- 2.2 Cryptography
- 2.3 Other Vulnerabilities
- 3 Beyond the Technology
- 4 Solutions
- 5 Future Work
- 6 References
The Bluetooth Vulnerability Assessment (ITSPSR-17A) is an unclassified publication, issued under the authority of the Chief, Communications Security Establishment Canada (CSEC).
This product review was prepared by CSEC for the use of the federal government. The review is informal and limited in scope. It is not an assessment or evaluation, and does not represent an endorsement of the product by CSEC. The material in it reflects CSEC's best judgement, in light of the information available to it at the time of preparation. Any use which a third party makes of this report, or any reliance on or decisions made based on it, are the responsibility of such third parties. CSEC accepts no responsibility for damages, if any, suffered by any third party as a result of decisions or actions based on this report.
Requests for additional copies or changes in distribution should be directed to the Head, IT Security Client Services at CSEC by calling 613-991-7654 or by email at firstname.lastname@example.org
This publication takes effect June 2008.
Director, IT Security Mission Management
© 2008 Government of Canada,
Communications Security Establishment Canada
This publication may be reproduced verbatim, in its entirety, without charge, for educational and personal purposes only. However, written permission from CSEC is required for use of the material in edited or excepted form, or for any commercial purpose.
List of Figures
- Figure 1: Bluetooth Device Class Ranges with Standard Antenna
- Figure 2: Bluetooth Cryptographic Suite
List of Tables
List of Abbreviations and Acronyms
- Bluetooth Device Address
- Bluetooth SIG
- Bluetooth Special Interest Group
- Communications Security Establishment Canada
- Elliptic Curve Diffie-Hellman
- Enhanced Data Rate
- Frequency Hopping Sequence
- Government of Canada
- Information Technology
- Information Technology Security
- National Institute of Standards and Technology
- Personal Digital Assistant
- Personal Identification Number
- Public Key Infrastructure
- Maximum power
- Minimum power
- Phase Shift Keying
- Random Number
- Radio Frequency
- Special Interest Group
- Wired Equivalent Privacy
Bluetooth technology is widely available to Government of Canada (GC) departments and agencies, and is being used by GC employees. Therefore, users should be aware of the security features and weaknesses associated with these products.
This report examines the security vulnerabilities of the Bluetooth technology. Emphasis is given to the physical layer and its cryptography, and other related security aspects of the technology. Special consideration is given to the way Bluetooth products are introduced by vendors, and the specification options that vendors may or may not choose to implement.
The release of the Bluetooth Specification reviewed in this report is version 2.1+EDR, ratified by the Bluetooth SIG in August, 2007, which provides for an improved secure pairing procedure between Bluetooth 2.1-compliant devices. Bluetooth version 2.1 is the latest public release of the Bluetooth standard; however, users should be aware that most devices on the market are only Bluetooth version 1.1 or 1.2 compliant. At the time of writing, there are very few devices on the market which are Bluetooth 2.1 compliant, and even Bluetooth 2.1 devices will operate in the original reduced security mode when paired with legacy Bluetooth devices (i.e., versions 1.0 through 2.0). Therefore, while an overview of the new version 2.1 security features will be presented, this report will continue to focus on vulnerabilities present in previous versions of Bluetooth.
There is considerable controversy about the inherent security of Bluetooth. The Bluetooth Special Interest Group (Bluetooth SIG) web site claims that "Bluetooth wireless technology has sufficient encryption and authentication built-in and is thus very secure in any environment." There have also been claims that the system was extremely difficult to eavesdrop due to two factors - employment of a frequency-hopping scheme with 1600 hops per second, and automatic output power adaptation to reduce the range exactly to requirement. Note that these latter claims are no longer published on the Bluetooth SIG website.
This report explores the validity of the current Bluetooth SIG claims and elaborates on security vulnerabilities associated with Bluetooth. It assumes that the reader has already been exposed to Bluetooth. Readers who are unfamiliar with Bluetooth, or want a good introduction to this technology, should read Bluetooth Revealed .
CSEC's IT Security Learning Centre provides details and practical demonstrations of common Bluetooth and other wireless vulnerabilities in its Wireless Security course. Individuals interested in this course or other ITS courses available from CSEC may contact the IT Security Learning Centre at email@example.com .
This report supersedes ITSPSR-17 produced by CSEC in October 2002 .
Bluetooth was originally designed for commercial applications only, and not to protect classified or protected information. Moreover, Bluetooth technology has been developed for implementation on a chip costing US $3 or less. Although the Bluetooth specification does allow for application-level security, few technical solutions have been developed as add-on layers to increase the security of Bluetooth to properly protect highly sensitive information. Such solutions are much more expensive than the $3 chip on which the core application is designed to work. However, Bluetooth does have some inherent security, which may be sufficient to protect low-sensitivity applications. This report attempts to present an objective analysis of the Bluetooth technology, regardless of its intended use.
1.5 Document Structure
Although the Bluetooth protocol stack is quite complex and extends from the physical layer (following the OSI model for layered network protocols) all the way up to the application layer, this document will focus primarily on the lower layers: the physical layer is examined first, with special attention to power adaptation and frequency hopping. The next section deals with cryptography as included in the link layer. A few other vulnerabilities are outlined in the following section. A more thorough analysis is then performed on the method by which Bluetooth products will be made available to consumers and the various security options that manufacturers have chosen when implementing Bluetooth. Finally, some security solutions are suggested to protect low-sensitivity applications against most of the vulnerabilities outlined in the previous sections.
2 Vulnerability Analysis
2.1 Physical Layer
Bluetooth exhibits most of the same vulnerabilities inherent to wireless systems in general. A Bluetooth transmitter sends signals across free space to any receiver, legitimate or not, located within range. Additionally, Bluetooth operates in the 2.4 GHz unlicensed band, and there are no restrictions on the sale of devices that transmit and receive in this band. Consequently, an unauthorized monitoring device that is not in direct contact with a Bluetooth transmitter can intercept its transmissions. Such a monitoring device is easy to conceal, undetectable when in use, and can be deployed much more rapidly than a wiretap.
However, Bluetooth uses three features that reduce (but not eliminate) the likelihood of interception:
- Low power
- Adaptive power control (optional)
- Frequency hopping
2.1.2 Low Power
Bluetooth devices are grouped into classes depending on their maximum transmitter power output. Most common consumer Bluetooth devices such as headsets, computer mice and keyboards are "Class 3" devices with a maximum 1 milliwatt effective radiated power output. "Class 2" and "Class 1" devices, with maximum effective radiated output power levels of 2.5 mW and 100 mW respectively are also available but are typically limited to industrial equipment with few commercial products available in these classes.
The standard Class 3 power output of 1 mW gives an effective range of approximately 10 metres between two devices with standard quarter-wave isotropic antennas. Increased range of up to about 100 metres, again using standard antennas, can be realized with higher powered Class 1 devices, however users should be aware that the use of additional amplifiers and/or high gain antennas at either the transmitter OR the receiver can increase the range of even Class 3 devices dramatically (Bluetooth reception over several kilometres using a commercially-available high gain antenna only at the receiver has been demonstrated).
2.1.3 Adaptive Power Control
A passive monitoring device normally needs to be within an effective range of the target device(s) to successfully intercept Bluetooth communications. Bluetooth includes adaptive power control which attempts to limit the output power to the minimum level necessary for successful communication. This provision helps conserve battery power as well as controlling the effective range of the transmission; however the following points regarding Bluetooth power control should be noted:
- The 10 metre range of a typical Class 3 device is only a nominal approximation of the reality. The land mobile radio channel is a harsh environment where obstacles (moving or fixed) in the radio line of sight path absorb the signal, and reflecting surfaces create additive or destructive inter-symbol interference, and neighbouring transmitters induce mutual interference. These impairments greatly affect the actual range achievable for any link. Moreover, this range varies greatly in time depending on many factors. A communication link engineered for a mobile application always has some interruptions in its service. The need to minimize range for security purposes is always counterbalanced by the need to increase the power and range of the transmitter to reduce service interruptions;
- A monitoring device equipped with some power amplification (including directional, high gain antennas) can pick up signals from much further away than the nominal 10 metres, even when power control is used;
- The Bluetooth technology aims at implementations within a single chip, costing US $3 or less. Thus, there is a high probability that an eavesdropping device can be built at a similar cost, using the same size advantages and located within range without being easily detected;
- A station does not have to be monitored continuously to provide some intelligence to an eavesdropper. Similarly, an eavesdropper may gather enough information about a
- complete Bluetooth piconet by monitoring only a few of the stations that make up the piconet;
- The adaptive power control feature is optional only. Moreover, the maximum step size for power control is 8 dB while the minimum step size is 2 dB. Consequently, the power used by a transmitter could be almost 8 dB higher than what is actually required to reach a particular station;
- The specification does not stipulate any power adaptation rate in time. Therefore, a link may have to rapidly increase the transmitting power due to an instantaneous disturbance in the radio channel, but may remain at this high level long after the channel quality has gone back to normal.
2.1.4 Frequency Hopping
The frequency hops used by a Bluetooth transmitter do not present a significant challenge for an eavesdropper, since the hopping can be tracked easily by any Bluetooth chip, whether this chip is the intended recipient or not. The only information needed for proper reception is the Frequency Hopping Sequence (FHS), which is transmitted by the master device in the clear at link establishment. If the monitoring device is within range at that time, it can capture the FHS and synchronize to the remainder of the communications.
If the monitoring device comes within range of the transmitter(s) after link establishment, it can always create a denial of service attack (by jamming, for instance) to cause piconet link failure, at which point the master device will try to re-establish connectivity. By forcing the master device to re-transmit the FHS, the eavesdropper has the opportunity to synchronize with the reestablished piconet. This whole procedure can be done within a few seconds. If service is quickly re-established, legitimate users could fail to be alerted by the resulting service interruption.
2.1.5 Other Features
In layers above the physical layer, other adaptive mechanisms optimize the link between the transmitter and intended recipient, such as error correction coding, automatic repeat request, etc. Since these adaptive features react to feedback from the recipient to the originator, they usually help the intended link, not the link to the eavesdropper. Therefore, these features increase the protection from eavesdropping, but only slightly.
Bluetooth 2.1 also introduces two different modulation schemes based on phase-shift-keying (PSK) technology to support the Enhanced Data Rate (EDR) feature. The additional modulation schemes increase the complexity of the RF circuitry and control systems, but have no impact on the security or ease of intercept of the signals.
The relative importance of these vulnerabilities at the physical layer depends on the application and the operating environment. For most situations, the lack of compulsory adaptive power control and lack of fine granularity in the power control setting is the most serious vulnerability, since it results in the device transmitting excessive power by orders of magnitude and needlessly extending the range at which a Bluetooth device may be intercepted.
Cryptography in Bluetooth is used to provide Authentication, Confidentiality and Authorization services. Bluetooth cryptographic mechanisms are described in Table 1.
Table 1 – Bluetooth Cryptography
Authentication to prevent spoofing and unwanted access to critical data and functions
Encryption to prevent eavesdropping and maintain privacy of individual links
Session key generation
Session keys can be changed at any time during a connection. 
Public key-based key exchange
Used in the Bluetooth 2.1, "Secure Simple Pairing" Protocol replaces challenge-response routine and allows PIN-less, secure pairing of devices.
At the application layer and the link layer, Bluetooth uses cryptography to provide confidentiality and authentication. Bluetooth uses two encryption algorithms, which are designated "E0" and "E1" in the Bluetooth standard. E0 is a simple XOR-based stream cipher and E1 is based on the well known SAFER+ encryption algorithm and is used for Bluetooth authentication. Neither encryption algorithm is Government of Canada approved: E0 has been broken  and SAFER+ was rejected as a candidate for the NIST Advanced Encryption Standard due to slow performance issues and vulnerabilities to side-channel attacks. Bluetooth specification version 2.1 adds Elliptic Curve Diffie-Hellman to improve the security of the link key exchange process only; once pairing is established, the existing ciphers continue to be used for data confidentiality.
2.2.2 Legacy Bluetooth Cryptographic Elements
The legacy Bluetooth cryptographic suite (Figure 2) is used as follows - the first time that two Bluetooth stations communicate, an initialization procedure, called pairing or bonding, creates a common link key. An initialization key is used as a temporary authentication key to protect the transfer of initialization parameters and is then discarded. The entities involved in maintaining security at the link layer include:
- Random numbers (RAND)
- A Bluetooth device address (BD_ADDR)
- A Personal Identification Number (PIN)
- Authentication keys
- An Encryption key
220.127.116.11 Random Numbers (RAND)
Random numbers (which are also called nonces in cryptography) are used throughout Bluetooth in an attempt to make sessions unique and resistant to replay attacks. There are several key instances of random numbers exchanged: two during communication link initialization (in_rand and lk_rand), another during authentication (au_rand) and one more used for generating the encryption key (en_rand). The random number in all cases is a 128-bit number derived from a pseudo-random process in each Bluetooth unit. As stated in the Bluetooth specification, "random" is taken to mean that it shall not be possible to predict the value with a chance that is significantly larger than 1/2L for a key length of L bits. This is a very loose specification, which gives much latitude to device manufacturers in the implementation of a pseudo random number generator. The "randomness" of a random number generator is essential to the security of Bluetooth, because if an attacker is able to predict the random number sequence, the link and encryption keys used may easily be calculated.
18.104.22.168 Bluetooth Device Address (BD_ADDR)
The BD_ADDR is a 48-bit IEEE address that is unique for each Bluetooth unit. The address is public and can be obtained via human-machine interactions or automatically through the inquiry procedure. The BD_ADDR is also used to generate a semi-permanent unit key for the device during its first operation. This unit key is stored in non-volatile memory and may be used as the link key in Bluetooth authentication and in fact may also be used to authenticate subsequent connections between the Bluetooth units that share them. Once created, a unit key is (almost) never changed. Actually, the specification stipulates that: "a link key based on a unit key can be changed, but not very easily". Such fixed unit keys are a serious Bluetooth vulnerability because they are not re-generated at each session but fixed for long periods of time (possibly the lifetime of the device), and if they become known, any devices using this unit key for security may be compromised. Because of this, their use has been deprecated (no longer recommended for use, but still supported) since Bluetooth version 1.2.
22.214.171.124 Personal Identification Number (PIN)
The PIN can be user defined, and ranges from 1 to 16 octets. The PIN is generated at the application layer and its origin could range from human input all the way to a Diffie-Hellman key exchange (note - this is unrelated to the ECDH used in the "Secure Simple Pairing" mode of Bluetooth 2.1). Some Bluetooth units may have little memory, while others may not have the interface required to input a PIN. In such cases, these devices may use a fixed PIN or a default PIN of zero (0x0000) with corresponding weaker security.
The PIN is used with a random number and the BD_ADDR to create an initialization key. If neither device has a fixed PIN, the BD_ADDR of the claimant device is used. If only one of the devices has a fixed PIN, the BD_ADDR used is that of the device without the fixed PIN. If both devices have fixed PINs, an authenticated link between them cannot be created. . To prevent exhaustive PIN searches, the Bluetooth specification calls for "a certain waiting interval to pass before the verifier initiates a new authentication attempt For each subsequent failure, the waiting interval shall be increased exponentially."  Tests have discovered that very few commercially available devices actually impose increasing waiting times; most allow unlimited consecutive authentication attempts with no penalty.
Because the random values used for key calculation must be exchanged, an attacker able to eavesdrop on the Bluetooth pairing procedure may utilize the intercepted random values and the various responses exchanged between the two Bluetooth devices to reverse the protocol and calculate the user PIN. This attack is extremely fast and effective, and an attacker can calculate a 4-digit PIN in well under a second on a standard PC; even 8-digit PINs can be calculated in about 10 minutes.
126.96.36.199 Authentication Keys
Two distinct authentication keys are used in Bluetooth: the initialization key and the link key. Both authentication keys are 128-bit entities that are shared between two or more parties but are not publicly available. The first authentication key derived during the initialization of a link between Bluetooth devices is called the initialization key and as described above, depends in part on the user PIN code. The next stage is the generation of the link key. As described above, a BD_ADDR-based unit key may be used as the link key, however due to vulnerabilities associated with a fixed key; a temporary, pairwise-generated key called a combination key is the preferred embodiment of the link key. In the combination key generation process, the initialization key protects a second exchange of random numbers between the devices which are used to generate a new key. As compared to the semi-permanent unit key, the lifetime of a combination link key is limited to one session between two or more Bluetooth devices. When the link is terminated, a temporary link key cannot be reused. According to the specification, the process of creating a link key depends on the nature and memory restrictions of the devices involved. The initialization key is always created before the link key.
Once the authentication keys are generated, a challenge-response mechanism is used between the two devices to verify that each knows the keys: the random number au_rand, the BD_ADDR, and the link key are encrypted on each device with the SAFER+ algorithm inside E1, and the results are compared. If the result is the same, this implies that the two devices share the same key.
188.8.131.52 Encryption Key
The encryption key KC is derived from another algorithm called "E3" which combines the previously calculated link key, a 96-bit ciphering offset number, and a random number generated by one of the two stations. The size of the KC encryption key is a multiple of 8 bits, ranging from 8 bits to 128 bits (nominally 128-bits, although Bluetooth allows for a negotiated key size that can be as short as 8-bits).
Once generated at each end, the encryption key is used by the E0 stream cipher algorithm along with the BD_ADDR of one of the stations and the frequency-hopping clock of the same station.
Note that if the key size is less than 128 bits, the E0 algorithm expands the key to 128 bits (by padding) in its encryption process.
2.2.3 Secure Simple Pairing
To simplify the pairing process and to improve security, Bluetooth version 2.1 introduces the "Secure Simple Pairing" mode. This mode does away with user PIN codes and utilizes ECDH (elliptic curve Diffie-Hellman) to securely exchange keys between devices.
In this mode, a public key cryptosystem based on elliptic curves is employed in place of the SAFER+ algorithm used in legacy pairing mode. With Secure Simple Pairing, pairing is initiated by an exchange of public keys, which are used with each device's own private key to calculate a shared Diffie-Hellman key. Following this, exchanges of random nonces which are unique to each session (to prevent replay attacks) are used to facilitate mutual authentication of the public keys.
The Secure Simple Pairing mode normally operates in a PIN-less mode, but also optionally allows use of out-of-band authentication exchanges (e.g. person-to-person authentication), as well as passkey exchanges. A passkey exchange is similar to a PIN exchange, but passkeys are not used in calculation of link or encryption keys, so knowledge of the passkey will not allow an attacker to determine the keys necessary to decrypt the session. The verification check functions used for authentication in the Secure Simple Pairing mode are based on HMAC-SHA-256, with a 128-bit key. In PIN-less modes, to reduce the risk of unauthorized devices automatically (but securely) pairing, devices may display the calculated check values for comparison and ask the user for a simple "yes/no" input to allow or disallow the pairing process from continuing. Bluetooth devices, such as headsets, which typically do not have displays or keyboards, would likely not implement this user validation step; this could permit unauthorized devices to silently attach to a piconet.
Once authentication is completed, both devices calculate a link key based on the previously exchanged public information as well as the calculated Diffie-Hellman key. This is followed by the final phase in Secure Simple Pairing, which is the generation of encryption keys and this proceeds in exactly the same way as in legacy pairing (see 184.108.40.206).
Vulnerabilities associated with the legacy Bluetooth cryptography have been known for a long time. They include the use of permanent keys (unit keys), use of short PINs to create keys, the use of hardcoded default PINs (usually 0x0000) and the ability to negotiate short encryption key lengths (as short as 8-bits). The use of permanent or semi-permanent unit keys is probably the weakest element of Bluetooth cryptography, and fortunately, their use has been deprecated since Bluetooth version 1.2. Since a Bluetooth device is intended to connect quickly with other devices, sharing the same key over many related or unrelated links offers opportunities to attackers. This weakness is probably more serious than the Wired Equivalent Privacy (WEP) weakness of 802.11 wireless networks that was the subject of much media coverage in 2001. 
Bluetooth 2.1 introduces the new "Secure Simple Pairing" which replaces the legacy Bluetooth pairing procedure with one based on Elliptic Curve Diffie-Hellman. While the cryptography of this new mode is certainly far stronger, it only applies to the pairing procedure itself; session data encryption is still performed in the same manner as before. Additionally, the fact that user validation of the pairing process may be dispensed with at the option of the developer may lead to instances where an unauthorized device may silently (and securely) attach to a piconet.
2.3 Other Vulnerabilities
In addition to the physical layer and the cryptography, Bluetooth technology has a few other vulnerabilities that are common with many telecommunication technologies.
2.3.2 User Authentication
As with most IT devices, the user of the device is not authenticated, only the device itself is. A user who does not safeguard his/her authentication mechanisms (by using a weak PIN or easily guessed password), or a user who misplaces or loses an authenticated device, risks being the victim of an impersonation attack, where an attacker can steal the device and assume the identity of the legitimate user. In such situations, the victim is not only the legitimate user of the stolen device, but also potentially anyone else who communicates with the stolen device.
2.3.3 Random Number Generation
As stated above, the random number generation specifications of Bluetooth are fairly weak. Therefore, one can expect many different implementations of Bluetooth using various degrees of randomness which can all potentially meet the definition of "random" in the specification.
2.3.4 Implementation Errors/Deficiencies
Many attacks against implementation errors or security deficiencies in Bluetooth are documented in public literature, and have been given colourful names, for example:
- Bluedumping - the aforementioned attack based on reverse calculating the user PIN based on intercepted pairing exchanges
- Bluesnarfing - allows an attacker to access phone directory and appointment database on target devices due to implementation errors in the OBEX Push protocol
- Bluebugging - utilizes hidden Bluetooth RFCOMM channels and allows an attacker to remotely control most aspects of a phone device, including making unauthorized calls and turning on microphones to turn a phone into an eavesdropping device (bug)
- Bluejacking - lack of security on OBEX profile on some devices allows an attacker the ability to add arbitrary entries onto the target device's phone list
- Bluestabbing - attacker modifies a Bluetooth device with a badly formatted device name which causes target device to crash when it tries to discover other devices in its vicinity
- Bluebumping - social-engineering attack which exploits the fact that a paired bond does not really disappear until both devices in a pair delete the connection; the attacker will use social-engineering to convince the target to pair with a device , after which the target will delete the pairing from his/her device afterwards, but the attacker will not, thereby allowing the attacker a hidden "back door" into the target's device
- Bluesmacking - badly formatted inquiry strings result in a "ping of death", crashing any devices that the message is sent to
Additional vulnerabilities such as the "Re-pairing Attack" discovered by Wool and Shaked  allow attackers to exploit implementation errors in Bluetooth exception handling during connection setup, causing devices to discard link keys and re-pair. The attack is of limited value on its own, but upon successful execution, an attacker can execute other attacks, such as the Bluedump attack (to recover the user's PIN).
3 Beyond the Technology
Previous sections of this report deal with Bluetooth technology as detailed in the specification, without regard to particular product or vendor implementations. Since the Bluetooth specification offers many options that influence the degree of security, one may assume that a wide array of these options is available to users. However, the reality is that users have very few options available to modify whatever security configuration vendors have made commercially available, and there is often a trade-off between ease of device connectivity and security.
3.2 Radio Frequency (RF) Communications
The peculiarities of the RF environment have to be closely examined. One big uncertainty about Bluetooth comes from the fact that it has been designed to establish ad-hoc networks as quickly as possible through the land mobile radio channel. Because this channel operates in a harsh environment filled with interference, fading, and shadowing, links are often interrupted momentarily. Lab tests have shown a high lack of stability of Bluetooth links in many commercial products. As a result, users must spend much time resetting networks because links have disconnected, and frequent link failures are accepted as normal disadvantages of RF communications. Because of this, a user may also incorrectly assume that attackers will also have difficulties in defeating the security of a link.
As products mature, vendors design their products so that link re-establishment is automatic and transparent to the user. This increases the vulnerability to attacks. For instance, an instantaneous denial-of-service attack followed by the re-establishment of the piconet can go undetected. In the same vein, if a device is under constant attempts of device discovery and service discovery from an attacker, it may not automatically alert the user, and will handle the discovery attempts in the background without triggering the user's suspicion (unless set to non-discoverable mode).
3.3 Connectivity Policies
The Bluetooth philosophy is that "it becomes a matter of a user-level (or, more generally, application-level) defined policy as to when a device enters any of [the inquiry and page] states. Similarly, a user-level defined policy also determines whether or not devices shall pair (authenticate) with each other. This is an important point: user-level decisions determine the degree to which a given device can be discovered, connected to and paired. One concern often expressed about Bluetooth technology is that all Bluetooth devices will automatically communicate with each other at any time, but this is a misconception. Users, or user-level applications, set the connectivity policies that determine which devices can communicate with each other, and when. These policies could be fixed by the manufacturers of Bluetooth devices or could be configurable by their users. Thus, device manufacturers could use the connectivity policies as a way to differentiate their products". [2, p213].
Unfortunately, this philosophy is not adhered to by many Bluetooth device vendors. For example, many commonly-used Bluetooth hands-free headsets are always in discoverable mode and cannot be disabled. Testing has shown that some models, particularly those that can be used with Bluetooth desktop base stations (to provide wireless features to standard desktop telephone sets), contain protocol deviations that allow the base station and the same brand of Bluetooth headset to automatically pair or re-pair without explicit user directive.
3.4 Technical Features
Bluetooth devices have penetrated the workplace by being mass-marketed to individual users with limited technical knowledge. Users make use of devices that display the Bluetooth logo without an understanding of Bluetooth. In some instances, a system administrator will provide these devices to users; this administrator may know more about IT than the user, but also has no Bluetooth or wireless expertise.
3.4.2 Battery-Saving Features
Efforts made by Bluetooth to save on the battery life of a device also lead to a potential vulnerability. Bluetooth developers have realized that among all features that mobile devices offer to users, long battery life and light weight are the most important ones. These aspects rank ahead of quality of link, coverage, reliability, look and, unfortunately, security. Because battery life and device weight are often contradictory (long battery life is usually achieved by using larger batteries which translate into additional weight), the Bluetooth specification has incorporated many functions designed to save on battery life. For instance, the park, hold and sniff modes are implemented exclusively for that purpose. Even when active, a device listens for the header of a packet and only if the header indicates that the packet is addressed to the specific device, will the device power up its circuitry fully to accept the packet payload.
Some vendors try to further enhance battery-saving features by reducing encryption key lengths or skipping verification steps that require extensive cryptographic calculations. The use of encryption demands computing power and drains the battery. With most algorithms, longer encryption keys require more energy for encryption and decryption operations. In Bluetooth, the supplied key is always padded to get an artificial 128-bit key, therefore the algorithm will always encrypt/decrypt over 128-bits no matter how long the user-supplied key is (note that this additional padding key does not increase security). Some vendors and users may not understand this, and input shorter encryption keys to save on battery life. Others may even turn encryption off for further power savings.
3.4.3 Bluetooth Keyboards
Special consideration must be given to use of the Bluetooth technology in keyboards. A keyboard that communicates wirelessly with a PC via Bluetooth presents a particularly higher risk. Users of a wired workstation can always assume some confidentiality of the keyboard data, and only data that is transmitted on the network may be subject to interception. However, with a Bluetooth keyboard, users should realize that all data that is typed is potentially exposed over a range of several metres.
3.4.4 Enhanced Data Rates
Bluetooth 2.1 introduces Enhanced Data Rates, up to 3 Mbps, and the "ultra-wideband" (UWB) technology proposed for the next generation Bluetooth 3.0 standard, which promises to increase data rates even more. This will lead to the development of more Bluetooth data-transfer applications (e.g., wired network replacements). The increased bandwidth and types of data transfer (e.g., video content, large documents) enabled by this technology will greatly increase the risk associated with the use of Bluetooth.
3.5 User Security Awareness
The lack of security awareness on the part of the user is probably the highest risk of using Bluetooth. Given the complexity of today's information technologies and the relatively little time that users have to devote to topics that go beyond functionality (such as security), many users will not take the initiative to familiarize themselves with security procedures and policies needed to protect the information that they process.
Solutions do exist to reduce the risks associated with the use of Bluetooth, and must be tailored to the risks involved. This is especially important for Bluetooth since the technology has been developed as a general replacement for wires over short distances without targeting any specific application. Before developing a solution, many factors have to be considered: the application, the environment, the threat, the user, etc. In essence, one must envision what the problems and solutions would be for a similar situation using wired technologies.
The obvious solution to eliminating all risk associated with the use of Bluetooth technology is simply not to use it. In such cases, a clear policy to disallow the use of such devices must be in put into place, and IT procedures to remove or disable such functionality on IT equipment must be developed. For example, on laptops, some models may employ an internal Bluetooth module that may be physically removed before deployment to the end users; on other models, a mechanical switch may be used to disable Bluetooth functionality and on still others, the Windows device manager may need to be used to disable the function in software. On devices like the Blackberry PDA, a policy on the Blackberry Enterprise Server may be implemented to disable Bluetooth functionality.
4.3 RF Enclosures
The most secure solution (although an extreme one) to overcome most potential Bluetooth (and other wireless) vulnerabilities is to surround the devices (e.g., computers using Bluetooth keyboards) with an RF-shielded enclosure or tent. If well designed and operated, such an enclosure eliminates all internal wireless communications from being transmitted externally. However, such a solution is extremely expensive and inconvenient; it is probably suitable only for classified or military applications where security is of the utmost importance. The number of Bluetooth applications that would find the use of an RF enclosure practical is minimal.
4.4 Cryptographic Applications
For current version of Bluetooth (versions 1.0 through 2.0), the use of additional approved cryptographic mechanisms at the application layer (above Bluetooth) is recommended to protect Protected information and provide the required confidentiality. A list of approved algorithms is available in CSE Approved Cryptographic Algorithms for the Protection of Designated Information and for Electronic Authentication and Authorization Applications within the Government of Canada (ITSA-11C) .
With the introduction of Bluetooth version 2.1, and the use of the Elliptic Curve Diffie-Hellman key exchange in the "Secure Simple Pairing" mode, some application-level cryptographic mechanisms may not be required, but this issue is still under discussion. Generally, since longer keys are needed for good cryptographic security, public key cryptography is also usually required to exchange these longer symmetric keys because of the difficulty of distributing them manually (i.e., having users enter them). Public key algorithms such as Diffie-Hellman, IKE, and many other schemes are available for this purpose, but may not always be suitable for the limited operational environment present in a mobile Bluetooth device. Unfortunately, even though ECDH may be a suitable key distribution mechanism, as described earlier in this document, the use of SAFER+ and E0 algorithms remains in Bluetooth version 2.1, neither of which are approved encryption algorithms for GC use.
In some cases, the use of a public key infrastructure (PKI) may be warranted in instances where a user is not in proximity to the partner at the other end of the connection, such as when the Bluetooth wireless link is only a portion of the whole connection.
4.5 Commercial Bluetooth Products Selection
The proper choice of a commercial Bluetooth product is also very important to minimizing security risks. The following features should be considered when looking for more secure Bluetooth products:
- Bluetooth 2.1 Secure Simple Pairing capability
- Frequent changes of unit keys are possible
- The power adaptation option is implemented
- A steep rise is present in the increase of the time-out period between successive authentication attempts
- Long encryption keys/PINs are used
4.6 Security Policy
Technology alone cannot ensure the security of an application; it must be accompanied by the development and use of sound organizational security policies such as:
- Perform Bluetooth pairing only in a secure, private setting. Do not pair devices in public.
- Use long PINs.
- Frequently change PINs.
- Use combination keys rather than unit keys.
- Keep the non-discoverable setting as the default for devices and services.
- Ensure that the encryption is activated.
- Safeguard PINs and passwords.
- Use different PINs for each device.
Readers interested in a more in-depth study of Bluetooth vulnerabilities and solutions may also wish to read NIST Special Publication 800-48 , available on the NIST web site (www.nist.gov), however a combination of all the measures described above represents the best and most practical solution to counter the security vulnerabilities associated with the use of Bluetooth technology. The exact combination depends on the threat and risk assessment of the business or government application, however in general, CSEC currently does not recommend the use of Bluetooth technology for the transfer of classified or protected information.
5 Future Work
Since the original development of Bluetooth, a wide variety of wireless devices have appeared on the market. The current release of Bluetooth (version 2.1) has introduced higher data rates and a significant new security feature in the form of the "Secure Simple Pairing" mode. At the time of writing, few Bluetooth 2.1-compliant products are available on the market; however, as with previous versions of Bluetooth, a steady growth of consumer products based on the new standard is expected.
Testing and reviews of certain Bluetooth products have been conducted in the past, and monitoring of the state of this technology will continue. Future plans by CSEC include testing of emerging Bluetooth version 2.1 products. The emphasis will be placed on products most commonly used by to GC personnel, including:
- Bluetooth headsets and multimedia devices
- Bluetooth keyboards and mice
- Bluetooth wireless LANs
- PC security devices
- Add-on cryptographic solutions operating at the upper layers.
- Specification of the Bluetooth System, version 2.1+EDR, July 26, 2007
- Miller, B. and Bisdikian, C., Bluetooth Revealed, Prentice Hall PTR, 2001
- Security of the WEP Algorithm. http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html
- ITSPSR-17 Bluetooth Vulnerability Assessment. CSE. October, 2002
- ITSA-11c - CSE Approved Cryptographic Algorithms for the Protection of Protected Information and for Electronic Authentication and Authorization Applications within the Government of Canada (ITSA-11c), CSE, 18 April 2006
- Shaked,Y. and Wool, A., "Cracking the Bluetooth PIN", MobiSys Conference 2005
- Lu, Y. and Vaudenay, S., "Faster Correlation Attack on Bluetooth Keystream Generator, E0", Crypto 2004
- Nechvatal, J. et al, "Status Report on the First Round of the Development of the Advanced Encryption Standard", Journal of the Research of the National Institute of Standards and Technology, Volume 104-435
- Karygiannis,T. and Owens, L., "Wireless Network Security: 802.11, Bluetooth and Handheld Devices", Special Publication 800-48, National Institute of Standards and Technology