database, since it will be easy for anybody familiar with the system to decrypt the keys. A possible solution to this is to derive the key from a password-based key derivation function. A key derivation function produces a key from a password and other parameters. This requires a user password input. Hence, indirectly, one will get a form of user authentication. Only the legitimate user will (hopefully) be able to derive the database encryption key. A widely used scheme for password-based encryption is the RSA PKCS#5 “Password-Based Cryptography Standard” [3]. The standard suggests encryption based on the DES or RC2 block cipher algorithms3, but other block ciphers like SAFER+ or the Advanced Encryption Standard (AES) are useful too.

Finally, a third (even less secure) storage alternative for the host is to have no explicit protection of the key database at all. If there is a login procedure required to activate the host, one might consider that this also gives enough protection for the Bluetooth link key database.

3.7.4Semipermanent keys for temporary use

In some situations, one Bluetooth unit is temporarily connected to another unit. Examples of such situations are public access points, public printers, or the exchange of documents between two business people. Even if these connections will only be used once, there is a need to protect the communication. Hence, the units must derive the necessary link and encryption keys. The Bluetooth standard does not make any distinction between temporary connections and other connections. Thus, it is up to the host implementation to take care of temporary link keys in a proper way. There is no need to store these keys, since it is highly probable that they are not going to be used anymore. Furthermore, depending on the host (link key) security policy, there might be a security risk if the temporary link keys used will automatically provide the unit access at a later occasion. It is good security practice for the user to be able to decide whether a link key should be stored in the link key database or not (and in some circumstances also for how long a time). Clearly, each implementation must provide some means for the user to remove stored link keys.

References

[1]Bluetooth Special Interest Group, Specification of the Bluetooth System, Version 1.1, Profiles, Part K:1 Generic Access Profile, February 2001.

3. DES and RC2 are two block ciphers; see [2] for more details.