Bluetooth enabled devices can operate basically in one of three different security modes as per the Bluetooth specifications, which is set up ba the end user who determines the level of security:

	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 (explained later in this article) usually enforces this onto the LMP.

Bluetooth allows for these security levels to be defined for by both devices and services.

For devices there are two possible security levels. A remote device could either be a:

Trusted device- Such a device would have access to all services for which the trust relationship has been set.

OR

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.

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

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

	Access to Services would need Authorization (Authorization always includes authentication). Only trusted devices would get automatic access.
	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.
	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 (as I stated before), that Bluetooth core protocols can only be used to authenticate devices and not individual users. This isn't to say that user based access control is not possible. The Bluetooth Security Architecture (through the Security Manager) which 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 Security Manager component is the entity that decides what policies are to be enforced when a connection request is made (both for inbound and outbound connections). Based on the service, device type and whether the device is trusted or untrusted the security manager can enforce application level authentication, encryption of the session and any other specific access policies.

The Service database stores information regarding the authentication, authorization and encryption requirements for the services. It also stores other routing information for the services.

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:

	Remote device requests access
	Connection request comes to L2CAP (Logical Link Control and Adaptation Protocol)
	L2CAP requests security manager to grant access
	Security Manager queries both device and service databases
	If device is trusted, then security manager may or may not (depending on the implementation) ask for authentication or authorization
	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.
	The Security manager will then decide if the service access requires link encryption. If it does, the keys will be negotiated and exchanged at the L2CAP protocol level and the connection will continue.

The Security Manager is the active component that manages and enforces security policy in the Bluetooth Security Architecture. In a way, the Security Manager acts as a bridge in terms of bringing together the application level and core Bluetooth protocol level (Link Layer) security controls and thus helps in providing end to end security across these layers.

There are a number of weaknesses in the current Bluetooth architecture (both directly and indirectly) that can be potentially exploited. Like any protocol out there, nothing is 100% safe.

A simple example, though not so simple to implement in practice is the man-in-the-middle attack for stealing identification and encryption keys before the start of a session and using the same identification to impersonate and/or eavesdrop on communications. This problem is however not specific to Bluetooth alone. Most key exchange systems are prone to this type of attack and is how many hackers get into websites as we hear on the news every day. One way to mitigate this issue would be to build in support for digital certificate based authentication systems. Another way might be to make it very difficult for an attacker to lock onto the frequency used for communication.

The frequency hopping intervals and patterns should be made reasonably unpredictable instead of fixed (to keep transmissions from breaking up, Bluetooth employs frequency hopping, a practice of skipping around the 2.45GHz 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 - this may help to prevent an attacker from locking onto the device signal.) These considerations have been factored in to some degree in the Bluetooth specifications. However as the paper by the Bell-Lab researchers point out, this is not so difficult to break into.

The other "big" security issue deals with the acutal PIN itself. Most devices have extremely short (usually 4 character) PINs. This is itself is a security weakness, though it is implementation and not specification related. Short PINs can be searched exhaustively by attackers. If BT devices were able to use longer password lengths like 16 charcters or even Hex codes this would be another way to strengthen security.

Security seems to be something hard for the average user to understand, (I know when I first looked at it my eyes rolled in my head a few times and it took using the technology to get a better understanding of it) and should be easier to implement. There is some talk of implementing the use of smartcards for encryption keys and realtime rolling code servers similar to RADIUS servers to keep Bluetooth secure.

There are a few security issues to still be worked out and the slow introduction of these devices using this standard may be a blessing in disguise - both for Bluetooth and wireless consumers in general, but as the devices are starting make their way into mainstream market devices, I hope we see more sooner than later. Wireless security seems to be big thing these days, especially in the field of Healthcare with the new HIPAA deadlines looming, one of which started recently on April 14th, but again generally falls on the shoulders of the IT staff for proper implementation and understanding of the technology and protocols.

Copyright © BluetoothNews.com 2003-06-21 23:21