112	Bluetooth Security

corrupts the content to make it into unintelligible garbage, the damage will be apparent when an authentication attempt is made. In Section 3.7.3, the way this is detected is discussed, depending on the current role as verifier or claimant. The specification does not mandate how to proceed when a corrupted database is detected. Clearly, one option is to alert the user, who can then initiate a new pairing to the devices that are affected.

A clever adversary who knows the format of the database may bypass detection by manipulating the key and a corresponding CRC (if present) such that this checks also for the corrupted key(s). This is analogous to what was discussed in Section 7.2. In this case, the error will not be detected until the authentication fails (i.e., the response SRES of the claimant does not match what the verifier calculated). At this point, the verifier aborts the link by sending the LMP detach PDU with the authentication failure error code. Furthermore, according to the specification, the LM of the verifier will not allow new authentication attempts from the claimant until a certain waiting interval has expired. For each failed authentication attempt, this waiting interval will grow exponentially. The purpose of this is to prevent an intruder from trying many keys in a short time. Unfortunately, in this case the effect is that a device that should have been granted access is locked out—for each failed attempt the user will see a longer waiting time without understanding what is going on. The only way to break this circle is to erase the old set of keys by requiring a new pairing.

One way to avoid the latter form of attack is to add some form of integrity protection to the key database. This comes in the form of extra parity bits that are computed as a nonlinear function, that is, a message authentication code of the stored information in the database and a secret key. An adversary has a very low probability of succeeding in changing any part of the information such that it will not be detected by the user, as long as the number of parity bits are large enough and the secret key is not disclosed. Clearly, it is important to protect the key sufficiently. In some systems, it may be feasible to hide the key in nonvolatile memory that is not accessible from any visible bus, such as on-chip ROM that cannot be read from external pins on the chip set.

7.5 Unit key

The authentication and encryption mechanisms based on unit keys are the same as those based on combination keys. However, a unit that uses a unit key is only able to use one key for all its secure connections. Hence, it has to share this key with all other units that it trusts. Consequently, a trusted device (a device that possesses the unit key) that eavesdrops on the initial authentication messages between two other units that utilize the unit key will be able to eavesdrop on any traffic between these two units. A trusted unit that has modified its own device