||Cathal Mc Daid
Bluetooth Security - Part 2
Nothing has caused more concern and confusion in Bluetooth than the
nature of Bluetooth security implementation. From those who insist that
its security is a disaster area, prey to any half-capable opportunist,
to the contrary view that’s its security is second to none. The nature
of its microwave link, as opposed to a fixed cable connection means that
it is especially vulnerable to attack. We examine the nature of the
security features implemented and their effectiveness.
Recall (from last month), that there are 3 Security modes defined
within Bluetooth:Security Mode 1: non-secure, Security Mode 2:
service level enforced security & Security Mode 3: link level
enforced security. Last month we examined the lower level of Bluetooth
security (Link Level security). This month we will examine the Security
Mode 2 ( the service level enforced security ) and a possible
implementation of it. This section is based on the Bluetooth
Security White Paper by T Müller, due to it's clarity and
availability. We also evaluate the overall merits/drawbacks of Bluetooth
in the security arena.
Security Mode 2 Settings
Two possibilities exist for Device’s access to services:
"trusted device" and
The trusted device has unrestricted access to all
services. The untrusted device doesn’t have fixed relationships and its
access to services is limited. For services, 3 security levels are
- Services that require authorisation and
authentication. Automatic access is only granted to trusted
devices. Other devices need a manual authorisation.
- Services that require authentication only,
Authorisation is not necessary.
- Services that are open to all devices. Neither
Authorisation nor authentication is required, no access approval is
required before service access is granted.
Note: one possible refinement is to set the trust level of a device
specifically for service or a group of services. The interaction with the
remote device does not exclude the implementation of such refined access
Flexibility and Usability Possibilities
For a successful security system, flexibility and
usability are top priorities. Examples of these are:
The possibility to grant access to some services
without providing access to other services: For example: On a cellular
phone, Service Discovery records shall be generally accessible, whereas
dialup networking shall only be available for specific devices.
Also the security architecture should support
security policies for devices with some services communicating with
changing remote devices (example: File Transfer or Business Card
Exchange). Access granted to a service on one such device should
not open up access to other services on the device, nor grant
future access automatically or in an uncontrolled way to services on the
Finally, user intervention for access to
services should be avoided as much as possible. It is only needed to allow
devices limited access to services or for setting up
trusted relationship with devices allowing unlimited access to services.
Implementation and Bluetooth-specific Matters
Note the Security Architecture here accounts for
security at and above L2CAP. Below L2CAP Securioty mode 3 (link-level
security) is used. There also exist propriety security used in some of the
adopted standards (PPP etc.) which exist above the L2CAP layer.
It is important to remember that this security
architecture allows different protocols to enforce the security policies.
For example, L2CAP will enforce the Bluetooth security policy for cordless
telephony, RFCOMM will enforce the Bluetooth security policy for dialup
networking, and OBEX will use its own security policy for file transfer
It is envisaged that this architecture should
completely work using security mode 2 of the Generic Access Profile.
Especially since there are no changes to Baseband and LMP functions for
authentication and encryption.
Final points: Authentication and encryption are set for a
physical connection (i.e., on the Baseband level). Also lower layers are
not aware of service/application layer security, nor should they be.
Finally the enforcement policy for authentication, authorisation or
encryption might be different for client and server role. Thus the
security level of peer entities running an application need not be
symmetric. i.e a server may conceivable and quite probably have a higher
security level requirement that a client .
Figure 1 below, gives the general architecture of a
possible Bluetooth security architecture.
As can be see the key component is a Security
Manager. This has several key tasks, including:
- Store security-related information on services & devices
- Answer access requests by protocol implementations or applications
(either access granted or refused)
- Enforce authentication and/or encryption before connecting to the
- Initiate or process input from the device user to set-up
trusted relationships on device level.
- Initiate pairing and query PIN entry by the user. Note: PIN entry
might also be done by an application.
The security architecture presented in Thomas
Müller's paper , provides a very flexible security framework. This
framework dictates when to involve a user (e.g., to provide a PIN) and
what actions the underlying BT protocol layers follow to support the
desired security check-ups. Within this framework, a number of
realizations of the presented architecture can be instantiated, some of
them simpler and some of them more advanced than the one discussed in
detail in his paper, without moving outside the scope of the architecture.
This approach with a centralised security manager allows
easy implementation of flexible access policies, because the interfaces to
protocols and other entities are kept simple and are limited to
query/response and registration procedures. The policies for access
control are encapsulated in the security manager. Therefore,
implementation of more complex policies would not affect implementation of
The two key security concepts within Bluetooth are recapped below:
Authentication : Who is it?
is the process of verifying ‘who’ is at the other end of the link.
Authorisation : What is it
allowed to do ? is the process of deciding if device X is
allowed to have access to service Y. Authorisation always includes
The 3 Device level trust levels are handled as so:
- Trusted Device: The device has been previously
authenticated, a link key is stored and the device is marked as
"trusted" in the Device Database.
- Untrusted Device: The device has been previously
authenticated, a link key is stored but the device is not marked as
"trusted" in the Device Database
- Unknown Device: No security information is
available for this device. This is also an untrusted device.
This information is stored in the Device database
table maintained in the security manager
The security level of a service is defined by three
- Authorisation Required: Access is only granted
automatically to trusted devices (i.e., devices marked as such in the
device database) or untrusted devices after an authorisation
procedure. Authorisation always requires authentication to verify that
the remote device is the right one.
- Authentication Required: Before connecting to the
application, the remote device must be authenticated
- Encryption Required: The link must be changed to
encrypted mode, before access to the service is possible
This information is stored in the service database
of the security manager.
Bluetooth Security Part 3 - Evaluation
 Bluetooth, The Bluetooth Specification, v.1.1 http://www.bluetooth.com/dev/specifications.asp
 Müller T., Bluetooth Security Architecture, 1999-07-15
 Vainio J., Bluetooth Security, 2000-05-25
 InfoTooth Knowledge Base
 Träskbäck M, Security in Bluetooth: An overview of Bluetooth
 Ullgren T. Security in Bluetooth: Key management in
 Sutherland E. Bluetooth has Security Issues that cannot be
Ignored, 2000-11-28 http://www.mcommercetimes.com/Technology/41
 Jakobsson M., Wetzel S. Security Weakness in Bluetooth: RSA 2001 http://www.bell-labs.com/user/markusj/bt.html
Security Part 1 |
Security Part 2 | Security Part 3
Corner | Bluetooth