Bluetooth

The Bluetooth specification includes security features at the link level. It supports authentication (unidirectional or mutual) and encryption. These features are based on a secret link key that is shared by a pair of devices. To generate this key a pairing procedure is used when the two devices communicate for the first time. Bluetooth devices transmit on the heavily used unlicensed 2.45GHz radio band (the same used by microwaves). To keep transmissions from breaking up, Bluetooth employs frequency hopping, a practice of skipping around the radio band 1600 times each second. This improves clarity and also reduces what Bluetooth proponents call "casual eavesdropping" by allowing only synchronized devices to be able to communicate. Each Bluetooth device has a unique address, allowing users to have some trust in the person at the other end of the transmission. Once this ID is associated with a person, by tracking the unscrambled address sent with each message, individuals can be traced and their activities easily logged.

For Bluetooth devices to communicate, an initialization process uses a PIN. While some devices allow users to punch in an ID number, the PIN can also be stored in the nonvolatile memory of the device.

Bluetooth enabled devices can operate in one of three different security modes as per the Bluetooth specifications:

• Security Mode 1- This is the most insecure security mode in which the Bluetooth device does not initiate any security procedure. It is in a "promiscuous" or "discovery" mode, allowing other Bluetooth devices to initiate connections with it.
• Security Mode 2- This mode enforces security after establishment of the link between the devices at the L2CAP level. This mode allows the setting up of flexible security policies involving application layer controls running in parallel with the lower protocols.
• Security Mode 3- This mode enforces security controls such as authentication and encryption at the Baseband level itself, before the connection is set up. The security manager usually enforces this onto the LMP.

Bluetooth allows security levels to be defined for both devices and services. For devices there are two possible security levels. A remote device could either be a:

1. Trusted device-Such a device would have access to all services for which the trust relationship has been set.
2. Untrusted device-Such a device would have restricted access to services. Typically such devices would not share a permanent relationship with the other device.

For services, three levels of security have been defined.

1. Services that require authorization and authentication. Automatic access is only granted to trusted devices. Other devices need a manual authorization.
2. Services that require authentication only. Authorization is not necessary.
3. Services open to all devices; authentication is not required, no access approval required before service access is granted.

The Bluetooth Architecture allows for defining security policies that can set trust relationships in such a way that even trusted devices can only get access to specific services and not to others.

Fundamentally, the core Bluetooth protocols can be used to implement the following security controls to restrict access to services:

1. Access to Services would need Authorization (Authorization always includes authentication). Only trusted devices would get automatic access.
2. Access to Services would need only authentication. I.e. the remote device would need to get authenticated before being able to connect to the application.
3. Access to Services would need encryption. The link between the two devices must be encrypted before the application can be accessed.

What is important to understand here is that Bluetooth core protocols can only authenticate devices and not users. This is not to say that user based access control is not possible. The Bluetooth Security Architecture (through the Security Manager) allows applications to enforce their own security policies. The link layer, at which Bluetooth specific security controls operate, is transparent to the security controls imposed by the application layers. Thus it is possible to enforce user-based authentication and fine grained access control within the Bluetooth Security Framework.

The typical process (steps) followed by the security manager in granting access to a remote device to connect to a particular service is as follows:

1. Remote device requests access
2. Connection request comes to L2CAP
3. L2CAP requests security manager to grant access
4. Security Manager queries both device and service databases
5. If device is trusted, then security manager may or may not (depending on the implementation) ask for authentication or authorization
6. If the device is untrusted, the security manager may either terminate the connection (if so desired) or enforce authorization. Authentication at the core Bluetooth protocol level will happen when link keys are exchanged. Depending on the security policy governing access, the security manager might call upon an application protocol to enforce application level security such as a username/password scheme for authentication. Support is also built in for other authentication schemes through the security manager interface.