Bluetooth; What about Bluetooth´s security?

Information from
Johnson Consulting

Bluetooth - An Overview

What about Bluetooth´s security?

Security can mean two things in this context:

A) We want to be sure that transmitted data arrives in un-corrupted condition to the receiver.
B) We also want to feel that this data has not been eavesdropped by parties for whom it is not intended.

Both of these issues are (of course!) addressed by Bluetooth.

Safer transmission of data

Are transmissions secure in a business and home environment? Yes, they are supposed to be quite reliable. Bluetooth has built in sufficient encryption and authentication and is thus very secure in any environment. In addition to this, a frequency-hopping scheme with 1600 hops/sec. is employed. This is far quicker than any other competing system. This, together with an automatic output power adaption to reduce the range exactly to requirement, makes the system extremely difficult to eavesdrop.

Information Integrity in Bluetooth

Information Integrity is of vital importance. We don´t want outside parties to listen in. In Bluetooth, it has these components:

Random Number Generation
Encryption
Encryption Key Management
Authentication.

More information about these can be found on the Bluetooth website.

Bluetooth´s Error Correction Schemes

Bluetooth units often have to contend with electro-magnetically noisy environments. Thus, the need for some kind of error-detection and -correction. For error-detection, Bluetooth uses various checksum-calculations. When errors are detected, there are 3 error-correction schemes defined for Bluetooth:

1/3 rate FEC (Forward Error Correction)
2/3 rate FEC
ARQ unnumbered scheme (Automatic Repeat Request).

The purpose of the FEC scheme on the data payload is to reduce the number of re-transmissions. However, in a reasonably error-free environment, FEC gives unnecessary overhead that reduces the throughput. Therefore, the packet definitions have been kept flexible to use FEC in the payload or not, resulting in

the DM and DH packets for the ACL link, and
the HV packets for the SCO link.

The packet header is always protected by a 1/3 rate FEC; it contains valuable link information and should be able to sustain more bit errors.

The ARQ-scheme is illustrated at right. On 2 occasions, the transmitted data blocks get corrupted, which is detected by the recipient. So the next time that recipient get a chance to communicate with that sender (i.e. at the next appropriate timeslot), the recipient sends a Negative Acknowledgement (a NAK, depicted in red), which prompts the other party to re-transmit that data block.