The Bluetooth Special Interest group has recently published version 2.1 of their specification. While the press mostly writes about the new easy pairing mechanisms, 2.1 contains a complete security overhaul.
It looks like this has become quite necessary since two attacks are now known that can break the security of the pairing process. While encrypted Bluetooth transmissions are still secure, intercepting the initial pairing sequence allows a passive attacker that just collects packets to compute the PIN used by both devices. A further attack for which specialized equipment is required can force a Bluetooth device into re-pairing so an attacker does not have to be present during the initial pairing. In practice, re-pairing means entering the PIN again. Users thus do get a warning when somebody tries such an attack.
BT 2.1 changes the pairing process fundamentally and now offers the following modes in what the standard referrs to as "Secure Simple Paring":
Numeric Comparison Protocol: The major difference of this pairing scheme compared to what has been done before is that instead of a PIN, a pair of public/private keys is used by each device together with the Elliptic Curve Diffie-Hellman one way cryptography algorithm. Each device sends its public key to the other side which then uses it to encrypt a secret to be returned. Once the encrypted secret is received, it is decrypted by using the private key. The encryption/decryption only works one way so an attacker intercepting the communication cannot decrypt the secret and thus cannot generate the link keys that identify the devices later on. This kind of authentication and ciphering key generation is very similar to what is done today to protect web pages with SSL/TLS and certificates. To protect against a man in the middle attack the pairing procedure then continues and a 6 digit number is then calculated on both sides and shown to the user. The 6 digit number will only be identical on both sides if the conversation has not been tampered and hence ensures that no third device has intercepted and modified the pairing messages. (Note that a man in the middle attack is not possible in SSL/TLS since it uses a certificate authority and trusted certificates in the browser)
Just Works Protocol: The same as the Numeric Comparison Protocol described above but the 6 digit number calculation process is skipped. While offering no protection against an active man in the middle attack some devices do not have a display to show a 6 digit number. Thus, such a pairing should only be performed when the user can be reasonably certain that no attacker can be close by. The encryption whenever a connection is established later on, however, is not impacted by this weakness and thus even this protocol offers enough protection for most applications. It’s also important to point out that the attacker has to be present each time the two devices start to communicate with each other as otherwise the connection establishment will fail.
Passkey Protocol: In this protocol a passkey (PIN) which has been entered by the user in both devices is used just as in the original Bluetooth specification. The way the PIN is used during the pairing process, however, is fundamentally different. Again public/private key pairs and random numbers are used by each device to generate the link keys. The PIN is just used to prevent a man in the middle attack as follows: For each bit a commitment message is generated by both devices by using a one way algorithm that takes the public keys of both sides, a random number generated individually by each side and the bit of the PIN to be committed as input parameters. Afterwards the commitments are exchanged between the devices. Once this is done, device A then sends the random number it has used to generate the commitment. This allows device B to verify that the commitment message was not tampered with. If the message was correct, device B sends its random number to device A so it can also check that the message was correct. For the following bit the order in which the random numbers are exchanged is reversed, i.e. device B has to send the random number first. A device in the middle can thus not forge commitments since it does not know the PIN and the random numbers are only exchanged after the commitment. Since commitments are given in an alternating fashion a device in the middle can only get one bit of the PIN from each side before it has to start guessing the value of the bit.
Out Of Band Protocol: And finally, Bluetooth 2.1 also allows using out of band exchange of security information such as via NFC (Near Field Communication) during the pairing process. This makes things even easier and more secure by only requiring two devices to come very close during the paging process. Both active and passive NFC is supported. In active mode, the NFC device is connected to the Bluetooth chip and can both transmit and receive authentication information. Some devices such as headsets do not have room for the extra NFC hardware. In such a case a passive NFC tag is used which could be attached to the manual or the box of the device. Pairing is then initiated by a device with an active NFC component which is held close to a passive NFC tag. The passive NFC tag then transmits all information required to start the pairing process.
Here are some links for the technical deep-dive: