inappropriate to use the broadcast encryption key for unicast traffic also, since all devices within the piconet are able to decipher this. Broadcast encryption will be discussed in Chapter 5.

2.5 Communication security policies

Security always comes at the prize of higher complexity. Hence, the security mechanisms should only be used when they are really needed. When and how to use the mechanisms is determined by the security policies of a device. The Bluetooth standard provides some basic principles for enforcing link-level security and building more advanced security polices through the three defined security modes.

One obvious choice for protecting Bluetooth communication is using the built-in link-level security mechanisms. Authentication and encryption is provided at baseband level. Using the built-in mechanisms has the advantage of protecting all layers above the link level (including control messages). The linklevel security mechanisms can be switched on or off. The security policy determines if a device demands authentication and/or encryption. One very simple approach is to demand maximum link-level security, that is, both authentication and encryption for all connections. This is an “always-on” link-level security policy. Such a simple policy has several advantages. First, the complexity is low. Furthermore, it gives a high level of security for all local connections and it is easy to implement. Finally, it is easy for the user to handle and understand the security policy. This kind of always-on policy and security enforcement is supported by Bluetooth security mode 3 (see Section 2.5.1). In order for this policy to be user convenient, the necessary keys must be present. If one can assume or actually demand that this is the case, the simple, always-on policy can be used and the security mechanisms are very easy to handle. Obviously, this policy also has some drawbacks:

•If the necessary link keys are not present, either a connection cannot be established or the keys need to be generated and exchanged at connection creation.

•If the necessary link keys are not present and the key exchange cannot be done automatically, the users must be involved and they must understand what is happening.

The latter implication can be a serious drawback, when the actual service does not demand any security. In this case, the user will be forced to handle a security procedure for a service that may need to be fast and convenient. Some device might only run services with high security requirements, and consequently

the unit does not demand authentication or encryption at connection establishment. 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 performed. 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 application or service requires it will the authentication and/or encryption mechanisms 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 establishment. 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 support 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 service 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 previously 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 authentication 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)