Editing Bluetooth (section)

==== Pairing mechanisms ====
Pairing mechanisms changed significantly with the introduction of Secure Simple Pairing in Bluetooth v2.1. The following summarizes the pairing mechanisms:
* ''Legacy pairing'': This is the only method available in Bluetooth v2.0 and before. Each device must enter a [[Personal identification number|PIN code]]; pairing is only successful if both devices enter the same PIN code. Any 16-byte UTF-8 string may be used as a PIN code; however, not all devices may be capable of entering all possible PIN codes.
** ''Limited input devices'': The obvious example of this class of device is a Bluetooth Hands-free headset, which generally have few inputs. These devices usually have a ''fixed PIN'', for example "0000" or "1234", that are hard-coded into the device.
** ''Numeric input devices'': Mobile phones are classic examples of these devices. They allow a user to enter a numeric value up to 16 digits in length.
** ''Alpha-numeric input devices'': PCs and smartphones are examples of these devices. They allow a user to enter full UTF-8 text as a PIN code. If pairing with a less capable device the user must be aware of the input limitations on the other device; there is no mechanism available for a capable device to determine how it should limit the available input a user may use.
* ''Secure Simple Pairing'' (SSP): This is required by Bluetooth v2.1, although a Bluetooth v2.1 device may only use legacy pairing to interoperate with a v2.0 or earlier device. Secure Simple Pairing uses a form of [[public-key cryptography]], and some types can help protect against [[Man-in-the-middle attack|man in the middle]], or MITM attacks. SSP has the following authentication mechanisms:
** ''Just works'': As the name implies, this method just works, with no user interaction. However, a device may prompt the user to confirm the pairing process. This method is typically used by headsets with minimal IO capabilities, and is more secure than the fixed PIN mechanism this limited set of devices uses for legacy pairing. This method provides no man-in-the-middle (MITM) protection.
** ''Numeric comparison'': If both devices have a display, and at least one can accept a binary yes/no user input, they may use Numeric Comparison. This method displays a 6-digit numeric code on each device. The user should compare the numbers to ensure they are identical. If the comparison succeeds, the user(s) should confirm pairing on the device(s) that can accept an input. This method provides MITM protection, assuming the user confirms on both devices and actually performs the comparison properly.
** ''Passkey Entry'': This method may be used between a device with a display and a device with numeric keypad entry (such as a keyboard), or two devices with numeric keypad entry. In the first case, the display presents a 6-digit numeric code to the user, who then enters the code on the keypad. In the second case, the user of each device enters the same 6-digit number. Both of these cases provide MITM protection.
** ''Out of band'' (OOB): This method uses an external means of communication, such as [[near-field communication]] (NFC) to exchange some information used in the pairing process. Pairing is completed using the Bluetooth radio, but requires information from the OOB mechanism. This provides only the level of MITM protection that is present in the OOB mechanism.

SSP is considered simple for the following reasons:
* In most cases, it does not require a user to generate a passkey.
* For use cases not requiring MITM protection, user interaction can be eliminated.
* For ''numeric comparison'', MITM protection can be achieved with a simple equality comparison by the user.
* Using OOB with NFC enables pairing when devices simply get close, rather than requiring a lengthy discovery process.