Key Management Extensions	147

Table 9.1

RS-Code MAC Construction Examples with Probability for Successful Man-in-the-Middle Attack

Size of	Pass-Key Size	Pass-Key	Probability of
Message Hash	(Decimal Digits)	Size (Bytes)	Successful Attack
128	5	2	< 2−4
128	8	3	< 2−8
128	10	4	< 2−13
256	10	4	< 2−12
128	12	5	< 2−17
256	12	5	< 2−16

rapidly decreases with increased pass-key size for the chosen MAC. For small pass-key sizes like 2 bytes (5 decimal digits), the probability of a successful man-in-the-middle attack is less than 1/16. For most applications, a pass-key size of 4 bytes (10 decimal digits) provides a reasonable security level.

9.1.3Implementation aspects and complexity

In order to support the improved pairing procedure, there must be a transport protocol for transferring the key exchange messages. Currently, the Bluetooth specification does not contain any built-in support for the DH key exchange. Hence, no standard compliant implementation of a DH-based protocol can be implemented at the LMP level. There are several different higher layer candidates, though. When we look into the existing Bluetooth profiles, the most attractive candidates are the OBEX [15] or the PAN profile [16]. When using the PAN profile, several different possibilities exist. TCP is one rather natural choice. Another nice possible option in the PAN case would be to have it defined as the Internet Engineering Task Force (IETF) extensible authentication protocol (EAP) [17] mechanism and use the IEEE 802.1x port-based network access control framework [18]. We will discuss IEEE 802.1x in detail in Section 9.2, and we restrict the description here to the OBEX and TCP alternatives. Figure 9.2 illustrates the placement of the improved pairing protocol for the OBEX variant and Figure 9.3 shows the same thing for the PAN/TCP option.

From a protocol and usability point of view, there is no major difference between the two options, and other variants are possible as well. Independent of the chosen protocol solution, in order to be combined with the ordinary link security mechanisms, the agreed-on link key must be stored in the key database of the device. One can use the DH key as a long pass-key input to the “ordinary”

148	Bluetooth Security

Improved pairing protocol

OBEX

RFCOMM SDP

LMP L2CAP

Baseband

Improved pairing protocol

OBEX

RFCOMM SDP

LMP L2CAP

Baseband

Figure 9.2 The protocol stack and the placement of the improved pairing protocol using the OBEX option.

Improved pairing protocol						Improved pairing protocol
	TCP						TCP
	IP						IP
BNEP		SDP				BNEP		SDP

LMP L2CAP

Baseband

LMP L2CAP

Baseband

Figure 9.3 The protocol stack and the placement of the improved pairing protocol using the PAN/TCP option.