Bluetooth Resource Center

Home
Search
Market Research
Add a Link

What Is Bluetooth?

Members

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

           "untrusted device"

    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 defined:

1. Services that require authorisation and authentication. Automatic access is only granted to trusted devices. Other devices need a manual authorisation.
2. Services that require authentication only,  Authorisation is not necessary.
3. 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 policies.

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

    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 and synchronisation.

    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 .

Example Bluetooth Security Architecture

    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:

1. Store security-related information on services & devices
2. Answer access requests by protocol implementations or applications (either access granted or refused)
3. Enforce authentication and/or encryption before connecting to the application.
4. Initiate or process input from  the device user to set-up trusted relationships on device level.
5. 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 [2], 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 other parts.

Security Implementation within the Architecture

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

    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 attributes:

• 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 & Conclusion

Security Part 1  |  Security Part 2  |  Security Part 3  |  Cathal's Corner  |  Bluetooth Articles