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)
That means that the authorization mechanism is based only in the BD_ADDR of the devices, if the BD_ADDR exists in the trusted devices list, got 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)
That means that the authentication mechanism is based only in the BD_ADDR and the shared secret link key.
Some interesting questions show up... :)
- What happens if an attacker spoofs some trusted device's BD_ADDR? Is he autorized to connect the remote device?
- What happens if an attacker gets access to a 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 a remote mobile phone.
The BD_ADDR spoofing attack can be developed in two levels:
- Spoofing the BD_ADDR of some trusted device to access profiles requiring authorization.
- Spoofing the BD_ADDR and obtaining the shared secret link key generated during the pair up to access profiles requiring authentication.
Practical scenario.
Let's create a scenario with a Sony-Ericcson phone paired up with a a Dell Axim PDA. The HTC Shift will spoof the PDA's identity to attack the mobile phone.
First, you discover the devices.
If you try 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 HTC Shift can impersonate the PDA you need to spoof its BD_ADDR.
And obtain the secret link key shared between the PDA and the mobile phone.
At this time, we're not discussing ways to obtaining the link key, let's say you simply get (physical or virtual) access to it in the PDA. After, you install the key on Ubuntu.
Finally you gain free access to profiles requiring authorization/authentication.
For instance, the OBEX FTP Profile, which allows you to send files, get files and list directories in the mobile phone.
For instance, the Dial Up Networking Profile, which allows you to send AT Commands to the mobile phone.
3 comments:
y si no tenemos acceso a ninguno de los 2 dispositivos se podría sacar la clave??
Si, se puede sniffar durante el proceso de emparejamiento y crackear la clave de enlace, pero es un ataque que todavia no he probado.
Busca por internet que esta bien documentado este ataque.
Saludos.
Hola como saver quien me esta ollendo por Bluetooth cuando hago una llamada
Post a Comment