- Mobile Application Security : Bluetooth Security - Bluetooth Security Features

6/16/2011 3:11:05 PM
Before getting into details on the security features and architecture of Bluetooth, it’s important to revisit and discuss some of the key characteristics of the technology and its intended user base. Bluetooth is designed to provide cable-free operation and interaction among a variety of devices, many of which tend to be consumer electronic devices. Because of the variety of devices in use and the situations for which Bluetooth is intended, no assumptions can be made about either the Bluetooth device or the technical sophistication of the device’s user. Bluetooth must be usable by novice consumers and on devices with limited or no visual display or input capabilities (headsets, keyboards, and so on). So, a key factor that complicates Bluetooth security is that many usage scenarios involve nontechnical users as well as devices that are incapable of the security mechanisms a developer may wish to use.

It is important that these issues remain at the top of mind as mobile application developers plan the design of their applications, as well as whether and how these applications will leverage or rely on Bluetooth security.


Pairing, the process whereby two Bluetooth devices establish a link and agree to communicate, is critical to the overall security architecture of Bluetooth and is tightly integrated with other Bluetooth security features. During the pairing process, the communicating devices agree on and generate keys that are used to identify and reference relationships with other devices. In addition to being used for these identification purposes, these keys are also used to generate additional keys used for both device authentication and communication encryption.

Device Pairing Prior to Bluetooth v2.1 + EDR

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. 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 (Bluetooth Security, p. 29). 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).

Secure Simple Pairing with Bluetooth v2.1 + EDR

In Bluetooth v2.1 + EDR, a new method of pairing called Secure Simple Pairing was introduced. The older method of pairing is supported when connecting to legacy devices, but the use of Secure Simple Pairing is mandated for communications between Bluetooth v2.1 + EDR devices.

From a user’s perspective, Secure Simple Pairing is meant to provide additional flexibility and ease of use when pairing compatible devices that have far-ranging display and input capabilities. However, from a security perspective, Secure Simple Pairing also improves security through the introduction of Elliptic Curve Diffie-Hellman (ECDH) for key exchange and link key generation.

Rather than relying on simple PIN/passkey entry and verification, Secure Simple Pairing offers four different means for pairing compatible devices (known as association models):


For more information on Secure Simple Pairing, see the “Bluetooth Simple Pairing Whitepaper” at the Bluetooth website.

  • Numeric Comparison This association model is designed for situations where both communicating devices can display a six-digit number and have inputs that allow the user to enter “yes” or “no.” A six-digit number from 000000 to 999999 is shown on both displays, and the user is prompted to respond whether the numbers are the same on both devices. If “yes” is entered on both devices, then the devices are paired successfully. Note that a primary difference between Numeric Comparison and the PIN model used in legacy pairing is the displayed number. In Numeric Comparison, this value is not used as an input to further key generation, so an attacker who can observe the displayed number cannot use it to calculate other keys. With the legacy PIN model, the PIN entered does factor into the generation of encryption keys, which makes PIN disclosure a real risk to the security of the communications.

  • Just Works This association model is intended for scenarios involving at least one device without the ability to display a six-digit number or to enter numbers. This mode uses the same key agreement protocol as Numeric Comparison (with protections against passive eavesdropping), but the actual method whereby the user accepts the Bluetooth connection is determined by the product manufacturer. This association model does not provide protection against man-in-the-middle attacks.

  • Out of Band This association model is intended for scenarios involving an out-of-band (OOB) mechanism (that is, non-Bluetooth) that is used to both discover the Bluetooth devices and exchange information during the pairing process. The actual OOB mechanism will vary, but a commonly specified use case involving a Near Field Communication (NFC) OOB mechanism is device “tapping.” This use case involves physically touching two devices together.

    Subsequent to the devices being tapped together, the user is asked to confirm whether the pairing request initiated by the tapping should be accepted. To provide security for the pairing process, the OOB mechanism used should provide privacy protections, including resistance to man-in-the-middle attacks.

  • Passkey Entry This association model is intended primarily for situations involving one device with input capabilities but no display capabilities while the other device has display capabilities. The device with a display presents a six-digit number from 000000 to 999999 on the display. The user then enters this number on the device with the input capability. If the values match, then the devices are paired successfully.

Traditional Security Services in Bluetooth

Developers and implementers are accustomed to having access to certain basic security services in the technologies they employ. Such basic security services include authentication, authorization, integrity, and confidentiality, among others. The availability of these services, the soundness of their implementations, and the extent to which the developer or implementer can customize these services for their unique requirements all help reveal the security capabilities of a given technology.

The Bluetooth specifications include a limited set of these basic security services, and as such, the level of security that can be implemented with native Bluetooth features is limited. The following security services are provided by the Bluetooth specification:

  • Authentication The ability to identify devices before and during connection and communication is provided by Bluetooth.

  • Authorization The ability to provide selected access to resources based on permissions is provided by Bluetooth.

  • Confidentiality The ability to protect communications during transmission over the network is provided by Bluetooth.

Noticeably absent are integrity protections and nonrepudiation services. In addition, native Bluetooth security services are provided at the device-to-device level; for instance, Bluetooth’s authentication service only authenticates a Bluetooth device. There is no provision for user-level authentication. Of course, this does not mean that user authentication services cannot be provided over a Bluetooth connection; instead, the developer must implement this service by other means at a different level in the communication stack. These limitations are important to consider as mobile developers architect their applications and consider which security options to employ.


Bluetooth authentication is the process whereby one device verifies the identity of another device. Bluetooth authentication is a one-way process, meaning that during any given authentication procedure, only one device’s identity is verified. In use cases requiring mutual authentication, this one-way process is simply repeated with the two devices’ roles reversed.

Bluetooth authentication involves the claimant device, which is the device that will have its identify verified by the authentication process, and the verifier device, which is the device that will verify the claimant’s identity. To perform this verification, a traditional challenge-response mechanism is used. The verifier sends a random number (the “challenge”) to the claimant. Upon receipt, the claimant generates a response to this challenge and returns the response to the verifier. This response is generated based on a function involving the random number, the claimant’s Bluetooth device address, and a secret key that was generated during device pairing (see page 240 of Core Specification v2.1 + EDR on the Bluetooth website).

The Bluetooth authentication mechanism has a simple protection to prevent repeated attacks in a limited timeframe. When an authentication attempt fails, the verifier will delay its next attempt to authenticate the claimant. This delay interval will be increased exponentially for each subsequent failed attempt (see page 880 of Core Specification v2.1 + EDR on the Bluetooth website).


Authorization in Bluetooth allows for decision making about resource access and connection configuration (that is, authentication and encryption requirements) to be made based on the permissions granted a given Bluetooth device or service. Two of the primary means of implementing authorization in Bluetooth are device trust levels and service security levels.

Device Trust Levels

Bluetooth devices can have one of two trust levels in relation to other Bluetooth devices: trusted or untrusted (refer to the “Wireless Security” page at the Bluetooth website).

  • Trusted devices have previously been paired with the device, and will have full access to services on the Bluetooth device.

  • Untrusted devices have not previously been paired with the device (or the relationship has been otherwise removed), and will have restricted access to services.

Service Security Levels

Bluetooth services (applications that use Bluetooth) have one of three security levels:

  • 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.

Although Bluetooth’s notions of device trust and service security levels are quite simple, the architecture of Bluetooth does provide for the implementation of more complex security and authorization policies.


Confidentiality is important for private communications over wireless links because the nature of wireless networking leaves the communication between nodes subject to eavesdropping by unauthorized parties. Confidentiality of network communications in Bluetooth is provided through the use of encryption, with the use of encryption being optional and determined by the selection of one of three encryption modes during communication.

The Bluetooth specification outlines three specific encryption modes. These modes are intended to limit encryption key ambiguity and speed processing of encrypted data in both point-to-point and broadcast traffic situations. 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 Encryption Mode 1 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.

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. And, a part of the packet called the access code must be available to all devices to allow the radio signal to be acquired properly (Bluetooth Security, p. 34).

Bluetooth Security Modes

The Bluetooth Generic Access Profile details the procedures associated with the discovery of Bluetooth devices and specifications related to device connection (Bluetooth Security, p. 38). In addition to these discovery and connection details, the Generic Access Profile also defines four security modes in which connectable Bluetooth devices may operate. The use of these various security modes controls how Bluetooth’s basic security services are employed for any given connection:

  • Security Mode 1 In Security Mode 1, no security procedures are used. There is no encryption or authentication, and devices in this mode will not use any controls to prevent other devices from establishing connections.

  • Security Mode 2 In Security Mode 2, security is implemented after the Bluetooth link is established. In this mode, security is enforced at the service level, so it is left to the Bluetooth application or service to request security. This flexibility allows for granular and specific security policies to be implemented that apply security selectively based on the services and applications requested. This, of course, also opens the door for flaws in the implementation of these security policies that could leave the device and data at risk.

  • Security Mode 3 In Security Mode 3, security is implemented when the Bluetooth link is established. This is an “always-on” policy that provides security for all uses and reduces the risks associated with faulty security policies and implementations. However, this will also increase inconvenience and decrease flexibility because devices will be unable to connect without authentication (Bluetooth Security, p. 39).

  • Security Mode 4 Security Mode 4 was defined in the v2.1 + EDR specification, and it’s required 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. However, service security requirements must be identified as one of the following:

  • Authenticated link key required

  • Unauthenticated link key required

  • No security required

Security “Non-Features”

In addition to reviewing the actual security features provided by Bluetooth, it is useful to acknowledge and refute two characteristics of Bluetooth communications that may be claimed as security features but do not provide any real protection:

  • Frequency hopping The frequency-hopping scheme that Bluetooth uses does not provide any protection against eavesdropping. There is no secret used to create the sequence of channels, and only 79 channels are used. Thus, using a series of receivers to monitor all channels would make an offline attack possible (Bluetooth Security, p. 31).

  • Device proximity The limited range of Bluetooth radios (up to approximately 330 feet with Class 1 radios) cannot be reliably used as a security feature. The supposed protection provided by limited signal strength can and has been defeated by attackers’ high gain antennas.

  •  Integrating Your Application with Windows Phone 7
  •  Introducing Windows Phone 7 Photo Features (part 2) - Using a Chooser to Open Photos & Saving Photos to the Phone
  •  Introducing Windows Phone 7 Photo Features (part 1) - Using a Chooser to Take Photos
  •  Mobile Application Security : Bluetooth Security - Bluetooth Technical Architecture
  •  Mobile Application Security : Bluetooth Security - Overview of the Technology
  •  Windows Phone 7 Development : Push Notifications - Implementing Cloud Service to Track Push Notifications
  •  Windows Phone 7 Development : Push Notifications - Implementing Raw Notifications
  •  Windows Phone 7 Development : Push Notifications - Implementing Tile Notifications
  •  Windows Phone 7 Development : Push Notifications - Implementing Toast Notifications
  •  iPhone Application Development : Creating a Navigation-Based Application
  •  Windows Phone 7 Development : Push Notifications - Introducing the Push Notifications Architecture
  •  Windows Phone 7 Development : Push Notifications - Understanding Push Notifications
  •  Windows Phone 7 Development : Handling Multiple Concurrent Requests with Rx.NET
  •  WAP and Mobile HTML Security : Application Attacks on Mobile HTML Sites
  •  WAP and Mobile HTML Security : Authentication on WAP/Mobile HTML Sites & Encryption
  •  iPhone Application Development : Displaying and Navigating Data Using Table Views - Building a Simple Table View Application
  •  iPhone Application Development : Understanding Table Views and Navigation Controllers
  •  Windows Phone 7 Development : Revising WeatherRx to Manage Slow Data Connections
  •  Windows Phone 7 Development : Handling Data Connection Issues with Rx.NET
  •  Windows Phone 7 Development : Handling Errors in Rx.NET
    Top 10
    Intel SSD 335 Series - Better Under The Hood
    Upgrade Your Mice & Keyboards – May 2013
    Printer Upkeep: Inkjet Printer Maintenance Tips
    Printers: Inkjet vs. Laser, And More
    WD Black 4TB - 4TB Storage Goes Mainstream
    Smart Phones: Bigger, Faster, And Better Than Ever
    Choice Exotica Well Tempered Versalex Turntable (Part 2)
    Choice Exotica Well Tempered Versalex Turntable (Part 1)
    Pre/ Power Amplifier - Nagra Jazz/ MSA (Part 2)
    Pre/ Power Amplifier - Nagra Jazz/ MSA (Part 1)
    Most View
    Hashing Algorithms: Extending the .NET Framework (part 1)
    Motorola Razr
    The Second BlackBerry Developers Conference Asia (Part 2)
    IIS 7.0 : Performance and Tuning - Network
    .NET Compact Framework : Font Selection
    Programming the Mobile Web : Mobile Rich Internet Applications (part 1) - JavaScript UI Libraries
    Windows 8 All-In-One PCs On Test (Part 1) - Dell XPS One 27, Samsung Series 7 All-in-One PC
    Learn How To … Boost Your Protection Against PC Viruses
    Visual Studio Team System 2008 : TFS reports for testing - Bugs
    Oracle Coherence 3.5 : Installing Coherence, Starting up the Coherence cluster
    Dell S2740L - A Beautifully Crafted 27-inch IPS Monitor
    Photoshop School: Use Cloning To Clean Up Coastal Scenes
    Processor Group Test (Part 6) - Intel Core i7-3930K
    Programming with DirectX : Game Math - Bounding Geometry (part 2) - Bounding Spheres & Bounding Hierarchies
    Windows 7 : Mapping Your Networking Infrastructure (part 1) - Using the Network and Sharing Center
    Microsoft Content Management Server : Building SharePoint Web Parts - The SharePoint MCMS Navigation Control, Creating the Web Part Project
    Cooler Master Hyper T4 - A Step Up In Budget Cooling
    SQL Server 2008 : Index design and maintenance - Managing statistics
    Acer Aspire 5560G
    Visual Studio 2010 : Managing Extensions with the Extension Manager, Managing Add-Ins with the Add-In Manager