T 4.80 Poor-quality or missing Bluetooth security mechanisms
The security mechanisms described in the Bluetooth specifications and implemented by the manufacturers have several design weaknesses. Some of these weaknesses are presented briefly in the following.
Encryption is not mandatory
Independent of the security mode used, encryption of data to be transmitted via Bluetooth is optional and has to be requested explicitly by the applications.
Unsafe default settings
The manufacturer configuration of the default settings is often unsafe. Security functions such as authentication and encryption are often turned off and passwords and PINs are set to default values ("0000", "1234", etc.). If the devices do not have input devices (e.g. headsets), changing the default settings is very difficult or even impossible.
Guessing weak PINs with Bluetooth without Secure Simple Pairing (SSP)
If two Bluetooth devices are paired, a connection key is generated that is permanently stored in both devices. Its generation is based on the device addresses and a PIN, among other things. The Secure Simple Pairing (SSP) procedure establishes a safe connection channel. If SSP is not used, the authentication information is transmitted without encryption.
If a weak PIN is used in a device pairing, an attacker may guess the PIN and calculate the pairing connection key. For this purpose, the attacker only needs to intercept the pairing and then the authentication. If SSP is not used, the attacker may check if the guessed PIN is correct using the recordings of the intercepted protocols.
The fact that the PIN is the only secret parameter used to generate the connection key if Bluetooth is used without SSP poses a security risk. From experience we know that it is hard to change the users' or manufacturers' habit of employing weak security settings. Indeed, there are rarely Bluetooth devices that prescribe a minimum length and complexity for the PIN. It is usually up to the user to select a PIN.
Re-initialisation of semi-permanent connections if Bluetooth is used without SSP
The Bluetooth specifications provide the possibility of re-authentication, e.g. if one of the devices lost the connection key. This allows an attacker to introduce a package with a connection re-initialisation request into the communication of two devices at the right moment. This provokes a new pairing that can then be intercepted.
No obligatory minimum key length
In addition to the length and complexity of the PIN used for authentication (Bluetooth without SSP) the length of the encryption key used to encrypt the transmitted data is also security-relevant. In the Bluetooth specification, a length of 128 bits is obligatory for authentication keys; the length of the key used to encrypt the other package contents may vary. Both devices negotiate the actual key length used when establishing the connection. The Bluetooth specification provides a length of 8 to 128 bits, i.e. a minimum key length of 8 bits could be used without violating the specification.
The specification even expressly excludes the possibility of the user changing the minimum key length. It can only be defined via the factory settings of the manufacturer. The achievable encryption quality thereby solely depends on the manufacturer's decision.
Weak protection of integrity
A Cyclic Redundancy Check (CRC, method to detect transmission errors using a checksum) is used to protect the integrity. This reliably detects random errors during the transmission of data packages, but CRC methods provide no protection against the deliberate manipulation of data packages.
Quality of the random generator
For random generation, the Bluetooth specifications 1.x and 2.0 + EDR stipulate the use of a pseudo random number generator. However, its implementation is not specified. Therefore, it cannot be excluded that the random number generators used have weaknesses that can be used to overcome the cryptographic methods. Bluetooth specification 2.1 + EDR requires the use of a random number generator according to the standard FIPS 140-2.
Shortened initialisation vector
Each transmitted data package is encrypted with a new initialisation vector. The vector is calculated from the time interval of the master and other values. However, the most significant bit of the time interval is omitted. Due to this vulnerability, man-in-the-middle attacks are possible even with encryption, as there are always two different offsets in the jump sequence to an initialisation vector. But a man-in-the-middle attack on an encrypted connection only allows an attacker to manipulate the data stream, not to decrypt it.
Manipulation of encrypted data
Due to the characteristics of stream ciphers in connection with the CRC used to protect integrity, it is possible to change the cipher text in such a way that the receiver still regards the package as valid. In this way it is possible to manipulate IP headers using a man-in-the-middle attack if Bluetooth is used without SSP.