| You saw in Chapter 4 that wireless security is always a concern to administrators. You have also seen the flaws inherent in 802.11's WEP security. What about Bluetooth? Is it any more secure than 802.11? The short and quick answer is no, Bluetooth is no more secure than 802.11. Because Bluetooth is often used in short-distance communications, its security aspects aren't well publicized, but it has certainly had its share of security woes. In Windows XP, to enable secure Bluetooth communication using encryption, right-click on the Bluetooth icon located in the Tray and select Advanced Configuration. Click on the Local Services tab, and select the services that you want to enable encryption. For example, you can select the Bluetooth Serial Port service and click on Properties. Check the Secure Connection checkbox to enable encryption (see Figure 6-62). Figure 6-62. Enabling encryption for the Bluetooth serial port  In this and following sections, I explain how security is implemented in Bluetooth and some of the security concerns of which you need to be aware. As shown in Figure 6-63, Bluetooth has three security modes: Security Mode 1 doesn't provide security. A Bluetooth device in this mode allows any device to connect to it. This is useful for applications that don't explicitly require security, such as the exchange of business cards. Security Mode 2 works at the service level. It is secured at the application layer (in other words, it is secured after a connection has been established). An application can be written to allow access to certain services (by another device) while restricting certain services. Security Mode 3 works at the link level. It is secured before a connection is established between two devices. The use of a link key (or PIN code, as seen in earlier sections) is used to authenticate the identity of another device.
Figure 6-63. Security modes in Bluetooth  6.7.1 Authentication Authentication verifies the identity of a device. First, some definitions are in order: a claimant is the device that needs to be authenticated, and a verifier is one that verifies the identity of the claimant. Here is the sequence of the authentication process: The user enters a PIN code (on both the claimant and the verifier). The two devices use the PIN code to generate a 128-bit link key. The claimant transmits its address (a 48-bit address, similar to the MAC address of a wireless card) to the verifier. The verifier transmits a 128-bit random challenge to the claimant. Both the claimant and the verifier use the SAFER+ algorithm (Secure and Fast Encryption Routine) to generate a 32-bit authentication response. The SAFER+ algorithm takes in as input the link key, claimant's address, and the 128-bit random challenge. The claimant transmits the 32-bit authentication response to the verifier, which then compares it with its own. If the two authentication responses are identical, the authentication is successful; otherwise, it fails.
When an authentication fails, a Bluetooth device has to wait for an interval of time before it can be authenticated again. This is a security measure against hackers using a rapid trial-and-error approach. Figure 6-64 shows the authentication process. Figure 6-64. Bluetooth authentication process  6.7.2 Encryption Encryption protects the confidentiality of data transmitted between two Bluetooth devices. The Bluetooth specification supports three modes of encryption:
- Encryption Mode 1
-
No packets are encrypted in this mode.
- Encryption Mode 2
-
Data transmitted to a specific device is encrypted, but data broadcast to multiple devices is not.
- Encryption Mode 3
-
All the data transmitted is encrypted.
Here is the sequence for the encryption: A Key Generator generates an encryption key using as input the 96-bit Authenticated Cipher Offset (a result returned by the earlier authentication process), the Link key, and the 32-bit random challenge. The size of the encryption key ranges from 8 to 128 bits, and is negotiated between the master and the slave. A key stream is produced using a cryptographic algorithm based on LFSR (Linear Feedback Shift Registers). The LFSR takes in as input the encryption key generated, the master's address, the 32-bit random challenge, and the slot number to be used for the current packet.
 | The key stream produced for each packet is different, since the slot number varies with each packet (due to frequency hopping). In a way, this is a security feature of Bluetooth. |
|
The key stream produced is then XOR'ed with the plaintext, which is then transmitted to the master.
Figure 6-65 illustrates the process of encryption. Figure 6-65. Bluetooth encryption process  6.7.3 Bluetooth Security Concerns A detailed survey of Bluetooth security issues is beyond the scope of this book. However, based on what I have discussed, the following are some of the concerns with regards to Bluetooth security: The PIN code used for establishing a link is usually short and thus easy to guess. Longer PIN codes could be used. However, users normally prefer a shorter PIN code for convenience. Distribution of PIN codes in a large network is difficult. Fortunately, this is not a major concern, as Bluetooth is commonly used for ad-hoc networking. The 32-bit random challenge may generate numbers that follow a certain pattern. This reduces the effectiveness of the encryption. Authentication is only at the device level; user-level authentication must be explicitly implemented.
As Bluetooth is a relatively new standard, the Bluetooth specifications are still undergoing changes. Over time, you can expect to see more security measures being put in place. At the moment, it is appropriate to apply some of the techniques used for securing network communications on some types of Bluetooth connections. For example, you could use a VPN or SSH (see Chapter 4) in conjunction with a Bluetooth network connection. |
