Figure 3.5 Process of transferring the master key Kmaster to slave device B using the overlay key Kovl.

fall back to the previous link key. A replacement for the ACO is needed, which will be detailed in Section 3.6.1.

3.5 User interaction

The procedure for generating the link key is likely to include some manual user interaction in order to enter the pass-key. There are some issues involved that need to be considered when implementing this. One of the devices may lack a keyboard or keypad, so there is no practical means available for the user to enter the pass-key. In that case, this device must decide which pass-key to use. It can be a fixed pass-key (see Section 2.2), or, if it is possible for the device to announce the pass-key over another interface (e.g., a display), it can be a randomly chosen pass-key that changes for every pairing the Bluetooth device takes part in.

Another issue is the mapping of keyboard strokes to the actual pass-key, PKEY. Clearly, both ends must generate the same value. The internal key codes may differ between devices of different types (such as a computer and a mobile phone). Therefore, a standardized mapping is defined in the GAP [1]. The character representation of the pass-key at the user interface level is transformed according to the standard character encoding scheme UTF-8, and all decimal digits are within the Unicode range 0x00-0x7F. Another requirement is that all devices capable of handling variable pass-keys (i.e., pass-keys entered at the user interface level) must support pass-keys consisting of decimal digits. Being capable of handling general characters is optional. In Table 3.1 we have listed an example of the mapping from a user-entered string to an actual pass-key.

Yet one problem becomes apparent when considering an example of pairing a Bluetooth-enabled keyboard with a desktop computer. Keyboards have different sets of characters for different alphabets. Moreover, the mapping of many common keys differs between languages (e.g., the U.S. QWERTY versus