Authentication and key exchange procedure

Possessing trusted certificates is not enough for a complete key management architecture in Bluetooth. There must also be the means for the devices to authenticate each other and exchange keys to be used for encryption. Bluetooth’s built-in authentication and encryption mechanisms do not use certificates. Thus, what is primarily needed is an authentication and key exchange procedure based on certificates. The goal with such a procedure would be to equip the devices with a common Bluetooth link key. For this to work, it is required that the public keys in the certificates issued by the PCD can be used for authenticated key exchange. The algorithms and certificate requirement will depend on the protocol used for the authenticated key exchange. In Section 9.2, we discussed different higher layer key exchange procedures. Some of these procedures are certificate based. Hence, they can be used to achieve the authenticated key exchange we need. In particular, we described the TLS-based key exchange in Section 9.2.2. Since TLS also provides integrity and confidentiality protection through message authentication codes and encryption algorithms, TLS is also a good alternative to the Bluetooth link level encryption for communication protection.

9.3.3Group extension method versus public key method

The trust delegation based on the security group extension method in Section 9.3.1 only reduces the number of manual interactions needed for security association establishment; it does not make manual pairing superfluous. For a group of devices, the number of pairings required depends on the order of the pairings. One cannot require the user to make the pairings in a certain order. Hence, the number of pairings needed for a group with n devices will be between n − 1 and n(n − 1)/2. If users always pair their new devices with a certain initialization device, the number of initializations will equal n − 1. This is the same situation as when the public key–based key management described in Section 9.3.2 is used. According to these principles, all security initialization is done with the PCD. However, in that case the user has no other choice than to pair each device with the PCD and only a small number of pairing orders are possible. This particular pairing order corresponds to an optimal pairing order using the security group extension method. While this speaks in favor of public key–based key management, there are also drawbacks. The PCD must always be present when a security initialization is performed. Furthermore, the PCD approach can only be used when public keys are supported by the Bluetooth devices. In the secure group extension method, no device has any particular role, and any device can be used to delegate the trust relation to any other device. Moreover, the trust delegation method can be accomplished with only minor extensions to