Investigation of effective Bluetooth security features

Introduction

Bluetooth signals can be easily intercepted, as can any other type of wireless signals. Therefore, the Bluetooth specification calls for the built-in security to discourage eavesdropping and attempts to falsify the origin of messages, which is called “spoofing”. This section provides an overview of the security mechanisms included in the Bluetooth specifications to illustrate their limitations and provide a foundation for some of the security recommendations.

In this example, Bluetooth security is provided between the mobile phone and the laptop computer. IEEE 802.11 security protects the wireless local area network link which is between the laptop computer and the IEEE 802.11 AP. The communications on the wired network are not protected by the Bluetooth security.

1. Three Basic Security Services

The three basic security services specified in the Bluetooth standard are authentication, confidentiality and authorization.

Authentication

­Prevents spoofing and unwanted access to critical data and functions. It is the process of verifying the identity of the communication devices. User authentication is not provided natively by Bluetooth.

The Bluetooth device authentication procedure is in the front of a challenge-response scheme. The device attempting to prove its identity in an authentication process is the claimant and the device validating the identity of the claimant is the verifier.

The challenge-response protocol validates devices by verifying the knowledge of a secret key, which is the Bluetooth link key.

Steps in Authentication Process

Step 1: The verifier transmits a 128-bit random challenge (AU_RAND) to the claimant, which is obtained from the random number generator derived from a pseudo-random process within the Bluetooth device.
Step 2: The claimant uses the E1 algorithm to compute an authentication response using its unique 48-bit Bluetooth device address (BD_ADDR), the link key, and AU_RAND as inputs. The verifier does the same computation.
Step 3: The claimant returns the most significant 32 bits of the E1 output as the computed response, SRES to the verifier.
Step 4: The verifier uses a comparator to compare the SRES from the claimant and its own computed value from the E1 algorithm.
Step 5: If both the values are the equal, the authentication is considered successful. If not, the authentication has failed.

The 5 steps accomplishes one-way authentication. The Bluetooth standards allow both one-way and mutual authentication to be performed. For mutual authentication, the steps are repeated with the verifier and claimant switching roles.

Confidentiality

Preventing information compromise caused by ensuring that only authorised devices can access and view data.

To provide confidentiality to the user’s data, encryption technique is used by the Bluetooth technology. Bluetooth has three Encryption Modes.

The modes are as follows:

Encryption Mode 1: No encryption is performed on any traffic.
Encryption Mode 2: Individually addressed traffic is encrypted using encryption keys based on individual link keys. Broadcast traffic is not encrypted.
Encryption Mode 3: All traffic is encrypted using an encryption key based on the master link key.

The encryption key is produced using an internal key generator (KG). The KG produces stream cipher keys based on 128-bit link key, 128 bit EN_RAND and 96-bit ACO value which is the least significant bits from the E1 algorithm of authentication process. A key stream output is exclusive-OR-ed with the payload bits and sent to the receiving device. This stream key is produced using a cryptographic algorithm based on linear feedback shift registers (LFSR). The clock provides the slot number. The encryption function E0 output is exclusive-OR-ed with the sender data and transmitted. The received data is exclusive-OR-ed with the keystream and original data is retrieved.

Trust levels, Service levels, and Authorizations

The Bluetooth levels of trust are

Trusted device: fixed relationship with another device and has full access to all services.
Untrusted device: does not have an established relationship and hence restricted access to services.

The security services defined for Bluetooth devices are

Service level 1: requires authorization and authentication. Automatic access is granted to trusted device; untrusted devices need manual authorization.
Service level 2: requires authentication only; authorization is not necessary. Access to an application is granted only after an authentication procedure.
Service level 3: open to all devices, with no authentication required. Access is granted automatically.

2. Security Modes

The various versions of Bluetooth specifications define four security modes. Each Bluetooth device must operate in one of the four modes.

Security Mode 1: a non secure mode. Authentication and encryption are bypassed leaving the device and connections susceptible to attackers. This mode is only supported in v2.0 + EDR devices.

Security mode 2: a service level-enforced security mode. The security procedures are initiated after LMP link establishment but before L2CAP channel establishment. The authentication and encryption mechanisms in this mode are implemented at the LMP layer. All Bluetooth devices support this security mode 2.

Security Mode 3: link level-enforces security mode. The Bluetooth device initiates the security procedures before the physical link is fully established. This mode mandates authentication and encryption for all connections to and from the devics. This mode is supported only in v2.0 + EDR devices.

Security Mode 4: a service level-enforced security mode like the security mode 2. But the security procedures are initiated after link setup. Authentication and encryption algorithms are identical to the algorithms in Bluetooth v2.0 + EDR and earlier versions. This is mandatory for v2.1 + EDR devices.

Appendix D—Online Resources

References

Bluetooth Special Interest Group, Bluetooth 2.0 and 2.1 specifications, http://www.bluetooth.com/Bluetooth/Technology/Building/Specifications/

Bluetooth Special Interest Group, “Bluetooth Security White Paper”, May 2002, http://www.bluetooth.com/NR/rdonlyres/E870794C-2788-49BF-96D3- C9578E0AE21D/0/security_whitepaper_v1.pdf

Bluetooth Special Interest Group, “Simple Pairing Whitepaper”, August 2006, http://bluetooth.com/NR/rdonlyres/0A0B3F36-D15F-4470-85A6- F2CCFA26F70F/0/SimplePairing_WP_V10r00.pdf

Defense Information Systems Agency (DISA), “DoD Bluetooth Headset Security Requirements Matrix”, Version 2.0, 07 April 2008, http://iase.disa.mil/stigs/checklist/dod_bluetooth_headset_security_requirements_matrix_v2-

0_7april2008.pdf

Defense Information Systems Agency (DISA), “DoD Bluetooth Smart Card Reader Security Requirements Matrix”, Version 2.0, 01 June 2007, http://iase.disa.mil/stigs/checklist/DoD-Bluetooth- Smart-Card-Reader-Security-Requirements-Matrix.pdf

Y. Lu, W. Meier, and S. Vaudenay, “The Conditional Correlation Attack: A Practical Attack on Bluetooth

Encryption”, http://lasecwww.epfl.ch/pub/lasec/doc/LMV05.pdf