Security modes

The GAP [4] defines the generic procedure related to the discovery of Bluetooth devices and the link management aspects of connecting to Bluetooth devices. The GAP also defines the different basic security procedures of a Bluetooth device. A connectable device can operate in three differentsecurity modes:

• Security mode 1:A Bluetooth unit in security mode 1 never initiates any security procedures; that is, it never demands authentication or encryp- tion of the Bluetooth link.

• Security mode 2:When a Bluetooth unit is operating in security mode 2, it shall not initiate any security procedures, that is, demand authentica- tion or encryption of the Bluetooth link, at link establishment. Instead, security is enforced at channel (L2CAP) or connection (e.g., Service Discovery Protocol (SDP), RFCOMM, TCS) establishment.

• Security mode 3:When a Bluetooth unit is in security mode 3, it shall initiate security procedures before the link setup is completed. Two dif- ferent security policies are possible: always demand authentication or always demand both authentication and encryption.

In the following sections we discuss the different modes and how they are used in Bluetooth applications.

Security mode 1

Security mode 1 is the “unsecured” mode in Bluetooth. A unit that offers its service to all connecting devices operates in security mode 1. This implies that

the unit does not demand authentication or encryption at connection establish- ment. For example, an access point that offers information services to anybody is a possible usage scenario for security mode 1.

Supporting authentication is mandatory and a unit in security mode 1 must respond to any authentication challenge. However, the unit will never send an authentication challenge itself and mutual authentication is never per- formed. A unit in security mode 1 that does not support encryption will refuse any request for that. On the other hand, if encryption is supported, the unit should accept a request for switching encryption on.

Security mode 2

Security mode 2 has been defined in order to provide better flexibility in the use of Bluetooth link-level security. In security mode 2, no security procedures are initiated until a channel or connection request has been received. This means that it is up to the application or service to ask for security. Only when the appli- cation or service requires it will the authentication and/or encryption mecha- nisms be switched on. A sophisticated authentication and encryption policy based on the baseband mechanisms can be implemented using this principle. Security mechanisms enforcement and policy handling must be taken care of by the unit. One possibility is to use a “security manager” to handle this. In Section 2.5.2, we further discuss the role and implementation of a security manager.

Security mode 2 comes at the price of higher implementation complexity and the risk of faulty security policies that might compromise the security of the unit.

Security mode 3

In security mode 3, on the other hand, security procedures (authentication and/or encryption) are enforced at connection establishment. This is a simple, always-on security policy. The implementation is easy and that reduces the risks of any security implementation mistakes. The drawback is the lack of flexibility. The unit will not be generally accessible. All connecting units need to be authenticated.

Security modes and security mechanisms

The different security modes define how a unit will act at connection establish- ment. Independent of the current security mode, a unit shall respond to security requests in accordance with what is specified in the link manager protocol (see Section 1.1.6). Hence, a security mode only defines the security behavior of the unit, but the security level for a connection is determined by the security modes of both units. Let one of two units be in security mode 3 and consequently demand encryption. Then the connection will be encrypted if both units sup- port encryption; otherwise the connection will be terminated.

Table 2.2 describes the different security mode options and the resulting security mechanisms, while in Figure 2.5 the channel establishment procedure for different security modes is illustrated. In the figure, the connection and serv- ice establishment procedure for a Bluetooth device is shown as a flow diagram. The process starts with the device that is in connectable mode. If the device is in security mode 3, it will try to authenticate and optionally encrypt the link directly after the link manager receives or makes a connection request. Specific host settings for access can be applied. For instance, devices that are not previ- ously paired may be rejected. A device that is in security mode 1 or 2, on the other hand, will continue with the link setup procedure without any authentica- tion or encryption request (see Chapter 6). Instead, the device in security mode 2 makes an access control check after a service connection has been requested. Access is only granted for authorized devices. Authorization is either given explicitly by the user or it can be given automatically (trusted and already paired device). For security mode 2, optional encryption can be requested before the connection to the service is finally established.

Service level access control can also be implemented by using security mode 3. Then authentication always takes place before the service request. Hence, security mode 2 gives better flexibility, since no security is enforced at

Table 2.2

The Different Security Mode Options for Master Respective Slave and Resulting Security Mechanism(s)

Slave Security

Mode Master Security Mode

1 2 3

1 No authentication, no encryption.

If the master application demands authentication (and encryption), then the link will be authenticated (and encrypted).

The link will be authenticated. If the master policy demands it, the link will be encrypted.

2 If the slave application demands it, the link will be authenticated (and encrypted).

If the master or slave application demands it, the link will be authenticated (and encrypted).

The link will be authenticated. If the master policy demands it, or if the slave application demands it, the link will be encrypted.

3 The link will be authenticated. If the slave policy demands it, the link will be encrypted.

The link will be

authenticated. If the slave policy demands it, or the master application demands it, the link will be encrypted.

The link will be authenticated. If the slave or the master policy demands it, the link will be encrypted.

Device in connectable mode Service request accepted Paging and link setup Link manager connection request Connection request accepted Connection request accepted Device rejected? Authorized? Check access control list Authentication <Encryption> Authentication <Encryption> Link setup complete Service request Security mode 3

Security mode 1 and 2

Security mode 2

Security mode 1 and 3 No

Yes

Rejected Yes, if auth.

Yes, no auth.

channel or connection request. Thus it is possible to allow access to some serv- ices without any authentication or encryption and a unit can be totally open to some services while still restricting access to other services.