Updated: July 23, 2009
Bluetooth security is one of the most under-rated security topics today. While most of us possess at least one blue-capable device, we hardly ever pay attention to what they do and how they're configured. On our mobile devices, Bluetooth is usually switched on by default and we never bother with changing the default PIN code from its default four-digit combination, usually something like 0000, 1234 or alike.
It kind of reminds you of people who leave their wireless routers with default password and no encryption. Thse devices are quite often abused, sometimes even by accident as computers auto-connect to the most convenient network available, which are usually unsecured, unecrypted, free-for-all access points.
Indeed, in this regard, Bluetooth is much like router security, only even more so. Why? Well, our routers stay home, but our phones, palm devices and laptops go everywhere, suffering a much greater exposure to threats.
In this article, I will try to address some of the basic aspects of Bluetooth security and how the potential risks can be assessed and negated by following some very simple practices. I'll try to do this without getting too technical.
So let's what you can do to keep your Bluetooth devices from exposing their proverbial digital throats to the wicked fangs of the web.
This is the most important - and the most vulnerable - part of Bluetooth communications: the initial exchange of keys between two devices that want to talk to one another.
To make a good analogy, think of your router's wireless security. You want to encrypt the wireless traffic so that no one can decipher the contents of data flowing between your router and various devices connected to your router's internal network, including desktops, laptopbs, mobile devices, etc.
To make your router's wireless communications secure, you create a password. And this password is inserted into the router Web interface in plain text! Think about it. You connect to your router through a browser, usually using an address like 192.168.x.x or 10.x.x.x and provide the required credentials. This is often done using a simple wired connection, unecrypted.
In theory, if you had malicious hosts on your internal network, it would be possible to sniff out the administrative password you use to connect to your router, as well as any other bit of information you exchange with the router, including IP ranges, MAC filtering, port forwarding, and also the precious passphrase used to encrypt the wireless communications.
But since most people have no rogues listening on their home network, this initial configuration stage is done safely, after which radio transmissions emitted by your wireless devices, while easily detected and captured by possible rogues, are encrypted and thus unreadable, maintaining the confidentiality of your communications.
Back to Bluetooth. The initial key exchange is the weakest link of your entire Bluetooth security. And to make things worse, while you can use wired connections to secure your routers, Bluetooth devices must transmit wireless signals, which are receivable by any Bluetooth-capable device within the range.
Therefore, your Bluetooth security begins by making sure your key exchange is safe.
The best way to pair devices is to do this in isolated rooms, far from prying eyes and ears. Most Bluetooth devices have a very short range, so if there are no antennas within a few meters of your location, you should be fine.
Pairing devices in crowded public places like airports is not recommended.
Like routers, most Bluetooth devices use generic identifiers, usually based on their vendor name and model type, making identification a bit difficult in the presence of multiple choices. You should give meaningful but not too descriptive names to your Bluetooth devices, so you know which ones belong to you.
For instance, Dedo is much better than RG4453C, whichever brand and firmware revision this might refer to. Similarly, you do not address people by their ID numbers or Social Security Numbers, as they are too generic to remember - you use names.
This is another important factor in the overall security scheme. While your Bluetooth traffic will be encrypted no matter which key you choose, the difficulty of cracking the encrypted messages will depend on the key length.
In theory, every encrypted messages can be cracked. All you need to do is take the entire time of the Universe and then some and run just about any possible combination of keyboard symbols against any possible combination of text on a huge grid of computers.
In reality, what makes encrypted messages secure is the time required to crack their algorithm or the key used. If this time exceeds a reasonable period, the brute force attempts will be useless.
This is what you want to protect your communications against - automated guesswork against your network. You don't have to have a perfect solution. It just has to be adequate enough to defeat most common attack methods in common situations over a reasonable exposure time, of let's say, several hours or days. That's it.
Choosing a strong PIN code will ensure your device communications will remain safe. The SANS Institute recommends a 12-digit pin code.
Let's take another look at the screenshot we posted above:
The screenshot was taken on an Ubuntu Jaunty Jackalope operating system, during a pairing attempt with a Nokia cell phone. I have named it Dedo, in accordance with the previous rule. Another thing I have to choose is the PIN code.
As you can see, the Bluetooth wizard on Ubuntu offers me the most common, known PINs used by vendors, usually revolving around easily guessable set - 0000, 1111, 1234, etc. This is no different from routers, which ship with the usual admin/12345 username/password combo.
These combinations are always the first choice of any Blue attacker, an easy picking of low-hanging fruit, if you will. Even if you use a non-default four-digit code, you will have instantly increased your security, although the choice pool is small and can be easily worked through by attackers.
Another interesting example is the approach offered by Fedora, in their Leonidas release. When pairing with an external device, Fedora cooks a random PIN that you will have to input into your other device to make the pairing successful. This approach automatically increases your security, both because the key is random and because it is much longer than standard four-digit combinations.
A 12-digit PIN is recommended. It could be bothersome to remember or input into desired devices, but it has to be done only one for each pairing attempt.
Once you successfully and safely pair the device, you're good to go. Now, we will see what you should do once you have configured your gadgets.
We shall now review the few simple common-sense rules that should help you maintain the security of your Bluetooth devices. The principle is similar to any type of data exchange and sharing. Do you wish the other party to have access to your files? How much access? Read only or maybe write, too? Which files do you wish to share? All these questions are valid for any type of data exchange over a wired or wireless network, be it Peer-to-Peer (P2P) sharing, Samba, NFS, Bluetooth, FTP, or any other protocol.
First of all, this saves battery life. Second, there is no reason to advertise your presence to the wide world, now, is there? Activate the Bluetooth device when you need to transmit data and then turn it off. Most people use Bluetooth very sparingly, if at all. Keeping it on is simply unnecessary.
This is the most basic security principle of all - default deny. It means, do not let anything through except only a small whitelist of trusted connections. It applies equally well to Bluetooth.
Whenever a new, unknown device asks to connect to your own, you should carefully examine the situation. Do you know this other hosts? Is the connection expected? If you can't answer these questions with 'yes' - you should deny the attempts . It is that simple.
You may notice that may cellphone offers Accept as the default choice, in big, bold font. In general, this means the phone is geared toward usability, but for most people, this also means less security.
Similarly, when a device tries to send you data, even if you have already paired with it, make sure you actually accept the data transfer. Or the attempt to browse your files. Bluetooth connections are usually deliberate, therefore any unexpected surprise is probably not desired.
For example, when I click on Send files to device ...
My phone will prompt me about this attempt. Since this is an expected contact, I will allow it. On the other hand, if you get these kinds of nudges out of the blue, they are probably undesired.
And then we can see a fancy screenshot I've taken when writing my VMware secrets article, on the tiny display of my cellphone.
The same applies when trying to browse the device. If you allow the connection, your files will be visible to the other party. This is something you should carefully consider. For instance, you may want to let a colleague at work send you some photos he's taken with his 0.1Kp phone camera, but you may not to want to expose your phone contents.
How your Bluetooth devices will behave depends on the exact model and type you're using. I cannot give you the exact recipe, but I can definitely recommend general settings.
Regardless of what device you use, try to keep it off when not used, make sure you activate securty features if available, including some way to monitoring (and reject) incoming Bluetooth connections. Your device should prompt you for any individual data transfer attempt, even if you have just allowed it. Why? Well, what if the device you have just paired with has been stolen? What is someone has pinched your friend's cell phone and is now trying to harass anyone they can? Here's a crude example, but a definite possibility, since lightweight, small mobile devices are easily misplaced, forgotten, lost, and stolen.
This may sound like a nuisance, having to authorize every single connection, but the truth is, there are not that many of them, anyway. How often do you Blue with your friends?
For this exact reason, the scarcity of Bluetooth connections, most people simply forget about security precautions involved with this protocol, potentially exposing their data to unwanted third parties. In most cases, your phone will contain mainly junk and a few important phones, but it might also list more sensitive data.
Similarly, you can configure your computers for Bluetooth sharing. For instance, Fedora 11 Leonidas has a dedicated menu to File Sharing Preferences, which also covers the Blue devices.
Take a look at the menu. Lots of options. For instance, you can share files only with bonded devices. Or disallow remote devices to delete files, forcing them into a read-only mode. Similarly, you may want to accept files only for bonded devices and receive notifications.
The next step in this tutorial would be to overview different Bluetooth tools available, some for Linux, some for Windows, which can be used to scan for active Bluetooth devices, sniff connections and so forth. But I'm not going to do that yet.
We will have a dedicated network analysis tutorial in the future. Furthermore, using this kind of tools requires expertise and responsibility. Abusing the security skills even for innocent pranks is so easily done.
Stay tuned for the sequels, where we will ethically learn about security scanning, so we can assess the risks, audit own our networks for vulnerabilities and develop the right countermeasures to possible threats.
That's all. Just a few simple rules and your Bluexperience can be a joyful matter. For most people, Bluetooth is something akin to the first image in this tutorial, a sort of an oral ornament worn by rappers or suchlike. Bluetooth, while popular and practical, is very obscure when it comes to usage models and security practices. Most people are completely unaware how their devices work and what their air to the wide world.
Luckily, configuring Bluetooth devices is not different than any radio-happy device. The basic principles remain the same. Use encryption to make the transmitted data unreadable by anyone save the intended parties. Make sure the initial exchange of encryption keys is done privately. Use strong keys, i.e. strong password. Turn off your devices when not in use. Individually accept/deny incoming pairing requests, while clearly identifying the other device. Use caution when sharing files, both ways.
I hope this tutorial was useful for you. Have fun and see you around.