90 |
Bluetooth Security |
6.2 Security manager architecture
This section will describe an architecture that fulfills the objectives set forth in the previous sections.
6.2.1Overview
A security manager architecture working along the lines discussed so far is depicted in Figure 6.1. The main tasks it has to accomplish consist of:
•Store security-related information for services;
•Store security-related information for devices;
•Accept or reject access requests by protocols or applications;
•When required, enforce authentication/encryption before connecting to the application;
Application
Application
RFCOMM (multiplexing layer)
L2CAP
User interface
Application 
Security manager
HCI
LM
General management entity
Service
database
Device
database
Query:
Register:
Figure 6.1 The proposed security manager architecture.
Security Policies and Access Control |
91 |
|
|
•Initiate the setup of trusted relationships on device level;
•Query the user or an application for pass-keys when needed.
The security manager architecture offloads from applications the burden of implementing all these details themselves. A well-defined and consistent link level security policy is automatically available for all applications utilizing Bluetooth connectivity. The protocol to interface with the security manager consists of simple query/response and registration procedures. As the security policy is encapsulated within the security manager, modifications to this can take place without the need for updating the entities that interact with it. This structure also means that legacy applications without inherent support for direct communication with the security manager can benefit from device access control via the multiplexing layer (e.g., RFCOMM) and L2CAP. One can notice that security policies apply to inbound as well as outbound traffic. It is quite natural that incoming requests need adequate permissions before they are accepted. However, if a user has requested a specific application to run over an encrypted link, the security manager should also make sure that the encryption is switched on before such a connection request is sent to a remote device. The application running locally cannot know for sure if the remote device has applied the same security requirements for this application. Consequently, the security manager will enforce encryption just to be certain that a more relaxed setting at the remote end will not override the local settings.
6.2.2Device trust level
From the security manager’s point of view, each remote device connecting to it falls within one of three defined device trust levels:
1.Trusted device: A previously authenticated device for which a link key is stored and which is labeled trusted in the device database.
2.Untrusted device: A previously authenticated device for which a link key is stored but which is labeled untrusted in the device database.
3.Unknown device: No security information is available for this device. By definition this device is untrusted.
The security manager will maintain a device database (see Section 6.2.5) of all known devices and act according to the policy for the trust level of the remote device and the service it tries to connect to. A trusted relationship is usually established during the pairing procedure. The user can be notified and given the option to add the remote device to the list of trusted devices. It is also possible to add untrusted devices later on when they are being granted access to a service
92 |
Bluetooth Security |
requiring authorization running on the local host. Again, the user will be notified and asked if the remote device should change status from untrusted to trusted. Whenever a remote device has an associated link key, authentication is performed according to the procedure specified in the LMP and baseband specification. To be verified as trusted, the authentication must succeed and the trusted flag must be set in the internal database. For unknown devices, a pairing is necessary before authentication can take place.
6.2.3Security level for services
Analogously to the case of a device database, the security manager has a service database for settings related to specific services rather than devices. The security level of a service is defined by three attributes:
1.Authorization required: Trusted devices are automatically granted access, while untrusted devices need user-assisted authorization before an access right is granted. Authorization requires authentication in order to verify the claimed identity of the remote device.
2.Authentication required: The remote device must be authenticated before access to the application is granted.
3.Encryption required: The link must be switched to encrypted mode before access to the service or application is granted.
These attributes can be set independently for incoming and outgoing connections. By definition, each service must be handled by some application. It is the responsibility of each application to register with the security manager and define its security level. To be more precise, the application itself is not required to do this—some other entity may do it on behalf of the application (such as the entity responsible for setting the path in the Bluetooth protocol stack). Not only do applications need to register, but multiplexing protocols above L2CAP must also do this.
If no service database record exists for a particular incoming or outgoing connection request, the following default settings apply:
•Incoming connection: Authorization (thus, implicitly also authentication) required.
•Outgoing connection: Authentication required.
6.2.4Connection setup
In the following we will differentiate between channel establishment and connection establishment. The former is defined as creating an L2CAP channel, that is,
Security Policies and Access Control |
93 |
|
|
the logical connection between two end points in peer devices at the L2CAP level, characterized by their respective channel identifiers (CID). The L2CAP channel is serving a single application or higher layer protocol. The connection establishment is defined as a connection between two peer applications or higher layer protocols mapped onto a channel. The decision on what security measures to enforce is taken after determining the security level of the requested service. This will minimize unnecessary user interaction, as authentications and authorizations can be initiated on a strictly as-needed basis. It also implies that authentication cannot take place when the ACL link is established, but rather when the request to a service is submitted.
Generally, the flow for an (accepted) incoming L2CAP channel establishment is as follows (depicted in Figure 6.2):
1.Connection makes request to L2CAP;
2.L2CAP requests access from the security manager;
3.The security manager looks up the security policy for the requested service in the service database;
4.The security manager looks up the security policy for the connecting device in the device database;
5.If necessary, the security manager enforces authentication and encryption;
6.The security manager grants access to the service;
7.L2CAP continues to establish the connection.
Application
7 |
|
manager |
|
6 |
Security |
|
|
L2CAP
2
1 |
5 |
HCI
LM
3
Service database
4
Device database
Figure 6.2 Access control procedure for L2CAP channel establishment.
94 |
Bluetooth Security |
For incoming connection requests, the access control may end up being duplicated. First, the L2CAP layer will query the security manager. The query contains a parameter identifying which protocol submitted the query and the BD_ADDR of the remote device. Based on this information, the security manager decides whether to grant or refuse the connection and if there is a need to enforce authentication and encryption. Should this be the case, the security manager will make sure this is carried out before it grants access to the submitted request. The simplest way to achieve this for the security manager is by interfacing to the lower Bluetooth layers through designated HCI link control commands. Of course, this is only possible if the HCI is present in the device implementation, but in any case some means of equivalent functionality must be available. For some submitted requests, the user may be asked to authorize the connection.
In addition to this, the multiplexing protocol above L2CAP (e.g., RFCOMM) may also do an access control query. The protocol handling entity will query the security manager with all the available multiplexing information (including protocol identification for the submitter and corresponding channel identifications associated with that particular protocol) it received with the connection request. As is the case for L2CAP queries, the security manager will make a decision whether the request is granted or not based on the registered security policy settings for the protocol and remote device in question, and inform the protocol handling entity of the result.
Clearly, the duplicated security manager requests may lead to repeated authentication events, causing unnecessary signaling over the air or repeated authorization requests requiring user interaction. To avoid this, the security manager should store a temporary value concerning the status of the request. If an authentication with the remote device has been successful when triggered by the L2CAP interaction, the result can simply be reused for the second query originating at the multiplexing layer. The same holds for connection request that have already been granted access through the authorization process.
Duplicate (or even triplicate) requests can result from outgoing connection requests as well. First, if built with the necessary means, the application itself may submit a query to the security manager and ask it to enforce the security policy associated with the corresponding service. Then the multiplexing protocol will do the same, as will the L2CAP layer. Unnecessary actions in response to these redundant requests are easily avoided if the security manager tracks the status for the connection request and reuses the result. Naturally, for outgoing connections authorization is less likely to take place, as one would expect applications on the local host to be granted access to the Bluetooth radio by default. However, enforcing authentication and encryption are valid requirements for many outgoing connection requests. Figure 6.3 illustrates how the