Contents |
| Bluetooth and authentication and authorization security mechanisms |
| The BD_ADDR spoofing attack |
| A practical scenario |
BD_ADDR Spoofing
Bluetooth and authentication and authorization security mechanisms
Authentication
Authentication is the procedure which ensures that a device attempting a connection is indeed who it claims to be.
All the security functions performed on the link layer are based on the 128 bit link key created after the pairing process. The authentication requires no user interaction, but is based on a Challenge-Response scheme between two Bluetooth devices sharing a secret link key. This scheme is based on the following procedure:
1) One of the devices, the claimant, sends its own BD_ADDR to the other.
2) The other device, the verifier, randomizes and sends the challenge, a 128 bit number called AU_RAND.
3) The claimant calculates a word called SRES using the E1 algorithm using its own BD_ADDR, the link key Kab stored and the challenge as inputs. The verifier performs the same calculations meanwhile.
4) The claimant sents the SRES response to the verifier.
5) The verifier verifies the response received with the word calculated on its own.
6) If the SRES words match successfully, the verifier and the claimant change roles and repeat the entire process.
Bluetooth protocol specifies that, in order to prevent a massive random link keys injection attack, any error occurring during the authentication process will cause the authentication phase to restart until certain number of failed attempts, then the master device will declare that the authentication process has failed, the link key is discarded and both devices must initiate pairing.
Authorization
Authorization is the procedure that determines whether a requesting device is allowed to access to specific services.
Three different levels of trust between devices are defined, each level establishes the capacity for a remote device to access to a particular Bluetooh service: trusted, untrusted or unknown.
- A trusted device has been previously authenticated and has access granted to all services.
- An untrusted device has been previously authenticated but does not have access to all or many services.
- An unknown device has not been previously authenticated and has access to no services.
Trusted devices are allowed to access to services automatically, no access approval is required before service access is granted.
Untrusted or unknown devices require manual authorization based on user interaction before access to services is granted. A service may be configured to require authorization but not authentication, so a temporary access can be granted for non-authenticated devices, like the Object Push Profile.
Usually, most devices allow users to mark authenticated devices as trusted devices, so connections can be performed automatically.
However...
Taking a look at the Bluetooth protocol spec you can see how simple are the security mechanisms implemented by Bluetooth technology: authorization and authentication.
3.2.1 Authorisation and
Authentication
Authorisation is the process of deciding if device X is
allowed to have access to service Y. This is where the concept of
‘trusted’ exists. Trusted devices (authenticated and indicated as
“trusted”), are allowed access to services.
3.2.2 Security Levels of Services
Authorisation Required: Access is only granted automatically
to trusted devices (i.e., devices marked as such in the device
database) or untrusted devices after an authorisation procedure.
Source: 3.2 Security Levels – Bluetooth Security Architecture
Version 1.0 (www.bluetooth.com)
It means that the authorization mechanism is only based on the BD_ADDR of the device, if the BD_ADDR exists in the trusted devices list, it will have access granted.
4.2.1 Authentication
The authentication procedure is based on a challenge-response
scheme […]. The verifier sends […] a random number (the challenge) to
the claimant. The claimant calculates a response, that is a function of
this challenge, the claimant’s BD_ADDR and a secret key. The response
is sent back to the verifier, that checks if the response was correct
or not. […] A successful calculation of the authentication response
requires that two devices share a secret key.
Source: 4.2 Security - Core v2.0 + EDR (www.bluetooth.org, available for SIG members)
It means that the authentication mechanism is only based on the BD_ADDR and the shared secret link key.
In summary:
- Authorization is only based on the BD_ADDR of the device.
- Authentication is based on the BD_ADDR of the device and the shared link key.
Since the Challenge-Response scheme is used for authenticating devices, not users, some interesting questions show up...
- What would happen if an attacker could spoof some trusted device's BD_ADDR? Is the attacker authorized to connect the remote device?
- What would happen if an attacker could obtain the secret link key shared between two devices? Can it be used to authenticate on both of them?
The BD_ADDR spoofing attack
The BD_ADDR spoofing attack allows an attacker to masquerade as some trusted/paired device and use the credentials to gain access to profiles requiring authorization/authentication in one another remote device.
The BD_ADDR spoofing attack can be perfomed in two ways:
- Spoofing the BD_ADDR of a trusted device to access profiles requiring authorization.
- Spoofing the BD_ADDR and obtaining the shared secret link key created during the pairing procedure to access profiles requiring authentication.
A practical scenario
Let's create a scenario with a Sony-Ericsson phone paired up with a a Dell Axim PDA. The HTC Shift will spoof the PDA's identity to attack the mobile phone.
First, the attacker needs to discover the devices.
If the attacker tries to establish any connection with the mobile phone, it's sure that the user will deny it since it's coming from an unknown device.
So, in order the PC can impersonate the PDA the attacker needs to spoof its BD_ADDR.
And obtain the secret link key shared between the PDA and the mobile phone.
The attacker may obtain the link key stored in the PDA through many ways:
- Social engineering.
- Stealing it from the Windows Mobile registry in the PDA.
- Eavesdropping the pairing procedure and cracking the temporary keys captured in order to obtain the PIN code and the link key.
After installing the link key on the device, the attacker will be able to gain free access to profiles requiring authorization/authentication.
For instance, the OBEX FTP Profile, which can be used to send files, get files and list directories in the mobile phone.
For instance, the Dial Up Networking Profile, which can be used to send AT Commands to the mobile phone.
