2. Background and Overview
2.4 Bluetooth technology and security
2.4.2 Bluetooth security
Generic Access Profile defines a generic authentication procedure that specifies how the LMP-authentication and LMP-pairing procedures are used. It also describes 4 security modes (3 of them are legacy modes) that provide different levels of security [55, 56]. The legacy security
Baseband [Link Controller (LC)] Link Manager Protocol (LMP)
L2CAP
RFCOMM Telephony Control Protocol (TCS) Service Discovery Protocol (SDP) Object Exchange Protocol (OBEX)31 modes are for devices that support Bluetooth v2.0 + EDR and earlier:
Security mode 1: is a non-secure mode that does not use any security mechanisms
Security mode 2: is a service level enforced security mode in which services request security mechanisms. Device does not initiate any security procedures before the start of the L2CAP channel establishment procedure. Bluetooth device can specify the following security requirements:
• Authorization required • Authentication required • Encryption required
In case no security requirements are specified, this mode is equivalent to the first mode [55, 56].
Security mode 3: is a link level enforced security mode. It means that security procedures are initiated before LMP completes link setup [55, 56]. This mode supports shared secret key authentication and encryption [60].
Security modes 1 and 3 are excluded in Bluetooth Core Specifications v2.1 + EDR and v3.0 +HS. Security mode 2 is used for backwards compatibility with legacy devices [55, 56]. Security mode 4 is the only non-legacy security mode defined in these specifications. It is a service level enforced security mode. Services can specify the following security requirements [55, 56]:
Authenticated link key required
Unauthenticated link key required
No security required
The first two options utilize Secure Simple Pairing (SSP) procedure to create the connection. The Authenticated link key required uses either the numeric comparison, out-of- band, or passkey entry SSP association model. The Unauthenticated link key required uses just works SSP association model. By default, GAP chooses the unauthenticated link key and enabling encryption if both pairing devices support SSP.
Secure Simple Pairing
Secure Simple Pairing was designed to provide more user-friendly pairing procedure and improved security [55, 56]. It provides protection against passive eavesdropping and against man-in-the-middle attacks (in some association models) [55, 56]. Protection against passive eavesdropping is provided by Elliptic Curve Diffie Hellman (ECDH) public key cryptography used by SSP.
SSP procedure consists of five phases:
Phase 1: Public key exchange
Phase 2: Authentication Stage 1
Phase 3: Authentication Stage 2
Phase 4: Link key calculation
Phase 5: LMP Authentication and Encryption
During phase 1 pairing devices generate ECDH public-private key pair, exchange public keys, and compute common Diffie Hellman key. The authentication stage 1 differs among SSP association models, all the rest phases are similar [55, 56].
32 Authentication Stage 1 (Numeric Comparison Protocol): It is used for scenarios when both pairing devices have a display and both are capable of having the user enter "yes" or "no" [55, 56]. In this stage each device generates a 128-bit nonce, and then devices publicly exchange them. Nonces are needed to prevent replay attacks [55, 56]. Then the commitment value, which cryptographically binds these nonces to the public keys exchanged in phase 1, is computed on each side. If commitment check succeeds, each device computes a 6 -digit confirmation value and shows it to the user. Both devices should have displays to use this mode. The user should check whether the numbers are the same on both devices. If the values are the same it means that nonces were successfully exchanged between intended devices. This association model provides limited protection against man-in-the-middle attacks [55, 56].
Authentication Stage 1 (Just Works): used in scenarios when one of the pairing devices neither has a display nor a way to enter a 6-digit number [55, 56]. This association model utilizes Numeric Comparison Protocol, but never displays any numbers to confirm. The user may be just asked to confirm the connection. The Just Works protects only against passive eavesdropping. It is susceptible to the man-in-the-middle attack.
Authentication Stage 1 (Passkey Entry): the user inputs the same 6-digit passkey on both pairing devices. The other option is to generate the passkey on one of the devices and display the value to the user. The user is then required to enter this value into another device. This mode provides protection against the man-in-the-middle attack.
Authentication Stage 1 (Out of Band Protocol): this association model is used when some out-of-band mechanism is used to both discover the devices and to exchange cryptographic values used in the pairing process. In-band discovery of the peer device followed by the usage of out-of-band channel for transmission of authentication parameters is not supported [55, 56].
Authentication stage 2 is used to ensure that peers successfully completed exchange in Authentication stage 1 and to confirm the peering between devices. Unlike in Authentication stage 1, there is no user intervention in stage 2. The pairing devices generate two values based on the exchanged nonces in authentication stage 1 and the common Diffie Hellman key generated as a result of the first phase. Devices mutually exchange values and check whether they match.
In phase 4 devices compute common link key based on the Diffie Hellman key and the publicly exchanged data. In phase 5 pairing devices generate encryption key from the link key. This phase is the same as in legacy pairing.
In legacy security modes 2 and 3 the authentication is performed based on the PIN code. PIN is used as an input to compute initialization key that in turn is used to compute the link key. The PIN can either be a fixed number or a value selected by the user. The user can select the PIN and then enter it in each of the devices that are to be paired.
Authenticated link keys are stronger than Unauthenticated, and Unauthenticated link keys are considered to be stronger than legacy link keys [55, 56].
LMP authentication and encryption
Bluetooth LMP authentication is a simple challenge-response scheme. LMP authentication starts after the link key was derived. LMP authentication uses the link key as a shared secret to perform authentication. The verifier sends the claimant a 128-bit random value. The claimant takes received random value, its own Bluetooth address, and the shared link key and uses them as input to the block cipher SAFER-SK128 to produce authentication code [55, 56]. This code is sent to the verifier. For mutual authentication verifier and claimant switch rolls.
33 Bluetooth utilizes a stream cipher algorithm E0 for encryption. Each packet payload is encrypted separately. The keystream generation algorithm is based on the linear feedback shift registers (LFSRs). Three modes are available for baseband encryption [55, 56]:
1. No encryption: no messages are encrypted;
2. Point-to-point only encryption: broadcast messages are not encrypted; 3. Point-to-point and broadcast encryption: all messages are encrypted.
Bluetooth provides a basic data integrity check using 16-bit CRC code [55, 56]. The data integrity check is optional. The CRC field is appended to the end of the packet. CRC is computed over every octet of the packet header and packet payload. The payload is ciphered after the CRC is appended, thus the CRC field is encrypted [55, 56]. Although Bluetooth has a basic data integrity check, it is much weaker than cryptographically protected data integrity check with message authentication codes (MACs).
Another Bluetooth security problem is that the stream cipher algorithm E0 has some security flaws [60] and is considered weak [98].
Summary
Bluetooth Security mode 4 with SSP is the most secure solution for device pairing. Besides, this mode, unlike legacy modes, does not require the knowledge of the shared secret PIN from both sides. The “Just works” association model being susceptible to the man-in-the- middle attack cannot be used in environments where high security is required. Thus, we consider the SSP “Numeric comparison” and “Passkey entry” association models to be a suitable solution to establish a secure Bluetooth channel.
Bluetooth provides authentication and protection of user data by encryption of the packet payload. However, it does not provide cryptographic integrity protection and the encryption algorithm has some security flaws.
34