| CATHAL'S
CORNER |
|
Cathal Mc Daid
March 2001 |
|
|
|
|
|
|
Nothing has caused more concern and confusion in Bluetooth than the
nature of Bluetooth security implementation. From those who insist that
its security is a disaster area, prey to any half-capable opportunist,
to the contrary view that’s its security is second to none. The nature
of its microwave link, as opposed to a fixed cable connection means that
it is especially vulnerable to attack. We examine the nature of the
security features implemented and their effectiveness.
As shown in parts 1 & 2 of this article,
Bluetooth has a comprehensive set of security features, at both upper and
lower levels. However for all of it's security features, Bluetooth does
have some security issues. These have been thorough documented elsewhere,
most notably in [3]. The following is a list of the major outstanding
problems:
The major problem is likely to be a partial user
one. The atypical 4-digit PIN code, is used in combination with other
variables to generate the Link Key and Encryption Key. In fact it is the
only truly secret key generation variable, the only one (a random number)
is transmitted over the air. Add to this the fact that the same PIN has to
be inputted in both Bluetooth devices to initialize a secure connection.
Obviously users are going to get sick of this, and either store the PIN
within both devices, or use an easy to remember number ('0000') being the
obvious example. Thus the PIN code is subject to a litany of attacks
One way to solve this would to use the option of the
longer 16 octet PIN code, or a key exchange system.
Another problem arises with the use of the Link key.
Authentication and encryption are based on the assumption that the link
key is the participants' shared secret. All other information used in the
procedures is generally public. However this can lead to fundamental
problems:
- Assume that devices A and B use
A's unit key as their link key.
- Later on, or at the same time, device C may
communicate with device A and use A's unit key as the link key.
- B uses A's Link key to decrypt the communication
between A & C

As shown above, device B, having obtained A's unit
key earlier, can use the unit key with a faked BD_ADDR (see below) to
calculate the encryption key and therefore listen to the traffic. It can
also authenticate itself to device A as device C and to device C as device
A. This attack is not as easy as it's sounds though, and requires some
work, but was shown to be possible by Lucent Technologies - Bell Labs [8].
-
Spoofing Bluetooth Device Address (BD_ADDR)
The Bluetooth Device Address, is unique to each and
every Bluetooth device. However due to its uniqueness it introduces
another problem. Once this ID is associated with a person, individuals can
be traced and their activities easily logged, thus privacy is violated.
All of these problems might lead one to believe that
Bluetooth security is highly suspect, however one major factors :The
nature of the data being transmitted across the Bluetooth link,
is often not taken into account
Bluetooth was never originally designed for truly
sensitive data transmission. Bluetooth is not a true competitor of
WLAN (such as IEEE 802.11), where security is
paramount, but rather Bluetooth was intended to form PANs (Personal Area
Networks), where security is desirable but not absolutely essential, as
shown by Bluetooth's goal to facilitate for cordless applications instead
of being used for networking purposes.
In this case, who would really want to intercept
your mp3 transfer ? Also one fact rarely mentioned is that the range for
Bluetooth is only 10 meters (for the standard popular power class), and in
a real environment, the range is most likely shortened to 5 meters, in
this case a hacker is across the room from you, a bit closer that most
hackers have been observed.
However it seems that due to the apparent Bluetooth
success and uptake, it is being extended to become a higher end wireless
standard (such as multimedia transmission), and become a real competitor
to WLAN. To accommodate this one could either seek to improve existing
security or implement new versions. Both are being pursued:
- Improving Existing Security:
Users requiring stalwart protection are encouraged to use stronger
security mechanisms available in network transport protocols and
application programs. i.e to use Security Mode 2 (Service Security),
the security protocols on adopted protocols, such as PPP, and security
application designed to improve general or specific security.
- Implement New Security: There is
no getting away from the fact that no matter how more secured
transmission can be made in the application level, Bluetooth still has
the fundamental problems as featured above. If the Bluetooth SIG is
pushing Bluetooth towards 2 and 10Mbit speeds, evidently in opposition
to 802.11, then it must also be working on security comparable to
802.11, rather than being exposed as a 'poor man's' version of WLAN
It seems (to me at least), that Bluetooth has come
into a lot of undeserving attack, from those who assume its security is
not up to the job. The problem here is that that the job in question is
not shared by all. If the required use for Bluetooth is to transmit highly
confidential data between your Bluetooth-enabled mobile phone and a credit
card machine, then perhaps more rigorous security is needed (nevermind
that you're much more likely to be ripped off by nefarious store clerks
taking credit card details, rather than devious technical masterminds
struggling to crack your codes).
However if you're simply want access to a Bluetooth
equipped building, or browse the web, then the level of security on
Bluetooth is perfectly adequate. No method of communicate is entirely
safe, if a malicious entity wishes to obtain information there is always
the possibility it will succeed. The most we can do is make its as
difficult as possible,and Bluetooth in it's current state is quite capable
to resist most attacks. However its security does have some major issues,
and thus Bluetooth should not generally be used to transmit highly
confidential/sensitive data, unless the above issues are corrected.
With thanks to Vincent Ma
References:
[1] Bluetooth, The Bluetooth Specification, v.1.1 http://www.bluetooth.com/dev/specifications.asp
[2] Müller T., Bluetooth Security Architecture, 1999-07-15
http://www.bluetooth.com/developer/download/download.asp?doc=174
[3] Vainio J., Bluetooth Security, 2000-05-25
http://www.niksula.cs.hut.fi/~jiitv/bluesec.html
[4] InfoTooth Knowledge Base
http://www.palowireless.com/infotooth/knowbase.asp
[5] Träskbäck M, Security in Bluetooth: An overview of Bluetooth
security, 2000-11-2
http://www.cs.hut.fi/Opinnot/Tik-86.174/Bluetooth_Security.pdf
[6] Ullgren T. Security in Bluetooth: Key management in
Bluetooth
http://www.cs.hut.fi/Opinnot/Tik-86.174/sectopics.html
[7] Sutherland E. Bluetooth has Security Issues that cannot be
Ignored, 2000-11-28 http://www.mcommercetimes.com/Technology/41
[8] Jakobsson M., Wetzel S. Security Weakness in Bluetooth: RSA 2001 http://www.bell-labs.com/user/markusj/bt.html
Security Part 1
| Security Part 2 |
Security Part 3 | Cathal's
Corner | Bluetooth
Articles
|