Attacks, Strengths, and Weaknesses	109

BD_ADDR_A A1 PKEY’

E22

RAND_A’ = A2

K’INIT

RAND_B’ = A3

K’INIT

K’INIT

BD_ADDR_A RAND_A’

BD_ADDR_B RAND_B’

E21

E21

A4

BD_ADDR_claimant E1 SRES’

A5 = SRES’?

Figure 7.2 Pass-key test attack against the Bluetooth pairing.

National Institute of Standards and Technology (NIST) report [1], the problem with short pass-key values was listed as one of the main Bluetooth security vulnerabilities (together with unit key usage and privacy attacks). Vaino [20] also briefly discusses the short pass-key problem. In a more recent paper by Kügler [21], the passive eavesdropping attack on the pairing is described. To circumvent the attack, the author suggests the usage of long pass-keys. In Chapter 9 we describe alternative pairing methods that are not vulnerable to the attack we described in this section.

7.4 Improper key storage

In Section 3.7.3, different options for how to store the link key database are discussed. This section will discuss some possible consequences if the key database is not stored in a proper way.

110	Bluetooth Security

7.4.1Disclosure of keys

If a secret key is disclosed to an adversary, there is an obvious risk of an impersonation attack—simply use the stolen key and the BD_ADDR of the device from which the key was stolen. Therefore, the key database should not be readable to anyone in addition to the rightful owner. For small personal devices such as headsets and phones, the risk of losing keys to nonauthorized persons is rather small. To get such information out of these devices requires very good knowledge not only of where to find the information, but in many cases also special equipment to be able to read the device’s nonvolatile memory. If that equipment is available, the adversary is most likely faced with the problem of finding the keys within a memory dump, as thin devices often lack a proper file system.

For more advanced gadgets that use Bluetooth, the risk of key disclosure increases. For instance, a network-connected desktop computer at the office may be equipped with a Bluetooth USB plug to facilitate convenient calendar synchronization to a mobile phone. If the key database is stored in plaintext on a file of that computer, there are many ways of getting hold of that file. In the worst case, it is possible to connect remotely (via the intranet) and simply read the content of the file. Alternatively, someone may sit down in front of the computer while the owner is having lunch and quickly copy the file to a diskette or mail it.

A variation on this theme involves a malicious USB plug or Personal Computer Memory Card International Association (PCMCIA) card (also known as PC-card). The rightful Bluetooth device attached to the computer may be exchanged for a false one, whose only purpose is to “suck” out link keys from the host. To accomplish this attack, a Link Key Request event is issued by the false device. Normally, this event indicates to the host that the link manager needs a link key for a particular device (the BD_ADDR is a parameter of this event) in order to perform authentication. However, in this scenario the false device simply does this to read the link key for a particular BD_ADDR. If there is a match in the database, the key will be returned in the HCI Link Key Request Reply command. In case there is no match in the database, the

HCI Link Key Request Negative Reply will be sent. Clearly, the false Bluetooth device can repeat this for several addresses of interest. Upon completion, the adversary removes the false device containing valid link keys—its content may be used for impersonation attacks later on.

In case the link key database is stored in the module rather than on the host, a similar attack may take place. The rightful USB plug or PCMCIA card is removed from the owner’s computer and inserted into a corresponding slot of the adversary’s computer. On this computer, a program runs that issues the HCI Read Stored Link Key command to the attached Bluetooth device. This HCI command is used to read out one or more keys stored on the Bluetooth controller. The controller responds with a list of known link keys/address pairs

Attacks, Strengths, and Weaknesses	111

in the Return Link Keys event. Once the list of keys has been read out, the USB plug (or card) is returned to its proper owner, who may be completely unaware that the device went missing for some time.

The two last examples illustrate the importance of protecting the interface between the Bluetooth host (computer) and the Bluetooth controller (module) whenever these are physically separated. Ideally, every removable Bluetooth device should be paired with the host(s) it is allowed to run on. Conversely, the host should only communicate with controllers to whom it has a trusted relationship.

Another advanced attack involves malicious software. A Trojan horse disguised as something quite innocent can send the key database to some place where the adversary can access it. If this malicious code is distributed through a virus or worm, the attack can quickly spread to a large number of computers. In fact, the adversary need not know a priori who has Bluetooth installed and is therefore a promising victim; if the virus infects a good percentage of the desktop computers at an enterprise site, chances are good that at least some candidates are found.

Once the link key of a computer and phone (and the BD_ADDR of the computer) is known, the adversary can “silently” connect to the mobile phone, impersonate the computer, and make use of any service the phone offers over Bluetooth (e.g., voice and data calls).

7.4.2Tampering with keys

A possible way to gain unauthorized access to a Bluetooth-equipped device is by adding a link key to its key database without proper pairing. Then, when a connection attempt is being made, the link manager of the device under attack will assume that a valid bonding to the intruder exists, as there is a link key stored in its database. In case the link key is marked as belonging to a trusted device (see Section 6.1.1), the adversary will gain unconditional access to all Bluetooth services running on the host of the attacked device. In principle, the same conditions apply as were discussed in Section 7.4.1 for being able to deploy this attack. Thin devices are not very susceptible, as the practicalities of tampering with their key databases are quite complex. Regular computers are a more likely target. Again, having the key database writable for anyone in addition to the rightful owner is a bad thing. Encrypting the file will help, as it will be much harder to plant known link keys there, even if the adversary is capable of writing to or exchanging the key database file. One may also choose to integrity protect the key database.

7.4.3Denial of service

An attacker has different options when it comes to destroying the content of the key database. If an attacker wipes out the file, removes one or more keys, or