pairing, or use it directly as the link key. The latter approach is preferable, being straightforward and less complex. There must then be a mapping between the agreed-on key (derived from the DH key) and the device address (or in the case of anonymity mode, the alias address of the other device). If the key database resides on the host, in the nonanonymous case, the address can be obtained using the HCI command HCI Read BD_ADDR. In the anonymous case, the alias address is generated when the devices pair in private pairable mode (see Chapter 8). Hence, in this case, alias addresses needs to be exchanged after the improved pairing. If the improved pairing is implemented on higher layers as in the two options we have discussed, then it is not possible to use security mode 3. This is because, in security mode 3, the pairing is initiated before a connection has been set up, and the units are not able to exchange any information at a higher layer. However, an improved pairing protocol implemented at a higher layer works fine with security mode 2. In that case, both units must be configured not to initiate any security procedures until an OBEX or TCP channel (PAN case) has been established. If security should be maintained, it is important that the implementation only allows the pairing protocol to run over the OBEX or TCP transport until the other device is authenticated. Using the suggested improved pairing with a DH key agreement over a large integer prime order group causes considerable increase in bandwidth compared to the Bluetooth 1.2 pairing mechanism. If this is considered a problem, other DH groups are available. The most suitable to use in that case would be Elliptic-Curve Diffie-Hellman (ECDH) [14]. Using ECDH, the key exchange can be implemented in software with quite a small footprint for the protocol. For an elliptic curve over a field of around 2160 in size (i.e., with the underlying field size of 160 bits), we have a public key size also of about 160 bits (20 bytes). This implies that not more than 20 bytes of key information need to be sent (in each direction) over the radio channel at the pairing. The choice of elliptic curve parameters can be of any standard type like the one proposed by the IEEE 1363 group [19] or ANSI X9.63 [20]. 9.2 Higher layer key exchange So far we have only discussed a particular pass-key-based alternative to the Bluetooth 1.2 pairing mechanism. Pass-key-based solutions fit well into situations where connections are created ad hoc and under control by people. However, in several different situations, this is not the case. Sometimes, we would like to be able to create Bluetooth link keys fully automatically without any user interaction at all. In this section we discuss a couple of such approaches, showing how the methods can be implemented in combination with the existing Bluetooth Key Management Extensions 149 security mechanisms. Higher layer key exchange for Bluetooth was first presented by Blake-Wilson in [21]. As in Section 9.1, some methods for the establishment of a unique, strong shared secret data item between two Bluetooth devices will be discussed. Clearly, this data item can be directly used as a combination link key and, thus, can be stored in the link key database of the host or module (the one applicable). Alternatively, it can be used as a high-entropy Bluetooth pass-key in the ordinary Bluetooth 1.2 pairing procedure. However, if the higher layer key exchange is used, there is no extra benefit of using the shared secret as a pass-key for conventional pairing compared to using it as the link key. The IEEE 801.1x [18] authentication and key exchange framework defines several different authentication options for LAN and wireless local area network (WLAN) systems. This framework utilizes EAP [17] for the transfer of authentication information. The EAP has been standardized by the IETF as a protocol to support multiple authentication mechanisms by encapsulating the messages used by the different authentication methods. Since IEEE 801.1x is defined over Ethernet frames, it can be used in Bluetooth directly on the Bluetooth Network Encapsulation Protocol (BNEP) [22], which is part of the PAN profile [16]. This fact and the flexibility and wide support of the IEEE 801.1x framework make it most useful also for Bluetooth applications. The higher layer key exchange mechanisms to be described here are based on ideas and concepts from the IEEE 802.1x. The authenticated key exchange methods supported are, for example, Kerberos [23], TLS [24], and even a pass-key protocol. For example, one can think of defining an EAP variant of the protocol we described in Section 9.1. The list of supported IEEE 802.1x authentication methods is expected to grow to accommodate future needs. Many of these authentication schemes produce session key material that in our setting can be used as the strong shared secret data item. 9.2.1 IEEE 802.1x port-based network access control In this section we first give a brief introduction to the IEEE 802.1x authentication framework. Next, we address how these ideas can be used in Bluetooth, and finally we focus on some exemplary higher layer key exchange mechanisms. In IEEE 802.1x, the term port is used for a point of attachment to a LAN, and the standard defines mechanisms for port-based network access. The term refers to the fact that until a peer has been successfully authenticated and authorized, all services on the other peer except the authentication service itself are locked—the port is closed. Once the peer is successfully authenticated, the LAN port is opened and the peer is granted access to the authorized services. Three different roles are defined in the standard: 150 Bluetooth Security 1. The Authenticator is the port that wants to authenticate the connecting device before allowing access to services provided by that port. 2. The Supplicant is the connecting device that tries to access some service provided by the port. 3. The Authentication server provides the actual authentication function, that is, verifies the identity of the peer and performs the necessary cryptographic operations needed to make the verification. Typically, one does not need to separate the authenticator and authenticator server roles—they may well be colocated on the same physical device. However, in a network access case, it makes sense to have the actual verification performed on a dedicated network server that can serve several different access points (the ports). The authenticator makes use of two ports: an uncontrolled port for authentication messages and a controlled port for the subsequent connection. The controlled port does not let any traffic through until there is successful authentication over the uncontrolled port. In IEEE 802.1x, the actual authentication is based on EAP. EAP defines several different mechanisms and IEEE 802.1x can be used with any of them. The EAP packets are encapsulated in Ethernet frames as defined by the standard. The EAP messages are transferred between the supplicant and the authentication server. If the authentication server is a special device separated from the authenticator, the authenticator only acts as a pass-through for the EAP messages. Once the authentication has been finalized, the authenticator gets information of the outcome through the EAP-success or EAP-failure messages. When IEEE 802.1x is used in Bluetooth, the supplicant role can be taken by the paging device, while the role of the authenticator can be taken by the paged device (think of an access point scenario). The authentication server is either located directly in the paged device or implemented as a backed server. This will be application dependent and is no different from the LAN usage case. The EAP packets are encapsulated in Ethernet frames using BNEP, defined in the Bluetooth PAN profile. Figure 9.4 illustrates the encapsulation principles. IEEE 802.1x uses the EAP encapsulation over LANs (EAPOL) frame format when carrying EAP information over Ethernet. In addition to transferring pure EAP messages, EAPOL also carries some signaling messages and is used to transport keys. Since the EAP messages only can be exchanged once a BNEP connection has been established, it is not possible for Bluetooth to use IEEE 802.1x directly together with security mode 3. This follows from the fact that security mode 3 requires the security procedures to be run before the link setup is completed. Then the authentication (and encryption) protocol(s) must use the legacy methods provided by the specification. However, security mode 2 fits nicely together
Posted on: Fri, 31 Oct 2014 13:44:11 +0000
Trending Topics
Recently Viewed Topics
© 2015