Slashdot Mirror
Bell Labs Researchers Spot Bluetooth Insecurities
Kyobu writes: "There's an article by John Markoff in [Saturday's] New York Times about insecurities in Bluetooth. The defects allow eavesdropping and caller identification." Markus Jacobson and Susanne Wetzel, both of Bell Laboratories, discovered weaknesses in the key exchange protocol currently implememented by Bluetooth. From the article: "The researchers are suggesting that the Bluetooth standard be altered so that the identity numbers are masked by a constantly changing pseudonym when transmitted." Considering the ubiquity many people expect Bluetooth devices to achieve, perhaps it's a good thing that this kind of attention starts early rather than late. (Complete with gratuitous Bruce Schneier quote.)
No shit! It has been rather obvious that Bluetooth is insecure for quite awhile now.
Now we get to watch them backpedal and spin while the techs scramble to kludge some kind of security into the protocol.
What would be better would be if someone started over FROM SCRATCH and designed a new wireless protocol, with security in mind from square one.
--
The recent Times article by John Markov brought attention to a recent attack on Bluetooth. Two attacks are discussed in the article: one which allows an attacker to obtain the key established between two other users, to be used for encryption and authentication. The other allows an attacker to recognize the identities of Bluetooth devices.
Somebody suggested that since Bluetooth is a broadcast protocol, it cannot be secure. That is not quite fair. First of all, it is known how to make key establishment protocols secure against an adversary who sees all transcripts, and it is known that the man-in-the-middle attack can be avoided by means of certification and other public key methods - which can be run on the application layer to enhance the security of the Bluetooth key exchange. (This is not the same as saying that it will practical, or econimically feasible for a product like Bluetooth to imcorporate such methods.) On the other hand, some security is better than none - as long as everybody understands exactly what "some" means.
The second attack allows an attacker to recognize and locate Bluetooth devices, whose identities can be linked to user identities by means not related to Bluetooth. This could allow companies to determine where competitors' CEOs are travelling (by bugging airport gates, for example), and may also allow for quite nasty types of blackmailing (starting, for example, by determining what politicians frequent what establishments.) While it does not appear that this problem can be remedied on the application layer, the use of pseudonyms, as noted in the Times article, can disassociate user sessions from each other, and would avoid these problems.
One should therefore be hopeful that appropriate changes are made, and that a careful analysis of the de-facto standard results in an improved product that is safe for both individuals and society.
The Bluetooth specs are available at
http://www.bluetooth.com
Markus Jakobsson's homepage is
http://www.bell-labs.com/user/markusj/
Susanne Wetzel's homepage is
http://www.bell-labs.com/user/sgwetzel/
Actually, they are, just head over to the BlueTooth web site and look around. The code API is a 6 Mb pdf file and they also offer an additional add-on pdf describing higher-level interaction protocols. A highly technical but very good read.
An excellent overview of Bluetooth security, enumerating potential flaws that aren't discussed in the Markoff article, can be found here.
"The Bluetooth device address (BD_ADDR) is the 48-bit IEEE address which is unique for each Bluetooth unit. The Bluetooth addresses are publicly known, and can be obtained via MMI interactions, or, automatically, via an inquiry routine by a Bluetooth unit."
It's no great surprise that the identity of a Bluetooth tranceiver can be discovered.
I cannot believe the number of folk who are posting 'remember this thing only has a range of 10 metres, eavesdropping isnt an issue'. Bluetooth does not suddenly stop 10 metres from you. Bluetooth receivers must be certified to work at this range, but you can obviously build something much more sensitive.
This was exactly the point Bruce Schneier was making, which a lot of people seem to have missed: if you can pick up transmissions from a monitor from outside a building, just how much easier will it be in a bluetooth environment, where the devices are _intended_ to be transmitters.
Although the absence of a good set of crypto is bad to begin with, the designers made matters worse still by using a PIN code system. To establish an adhoc connection, you can use PIN codes on both sides to establish a new link. This will probably work fine if you are connecting two PDAs with each other, and neither of those devices will normaly accept new connections.
:)
However, this will probably be RARE, to say the least. A lot of devices, like the Blue Tooth ear phone/mic for your mobile will have a hard to modify (from a user point of view) fixed pin.
By default a lot of devices will be shipped with pin codes of 0000 or 1234 or whatever. Most users will not change that PIN, or when they do choose something like 1111...
In an automated world, 10000 tries (5000 on average) is not much. It won't take long before someone writes a Palm-Blue Tooth scanner.
Even if some people are a bit more sensible and change their PINs to 8 digits (or even the maximum of 16) this will leave a LOT of mostly unprotected devices. Just imagin, walking past someone's house, and you will be able to start the Blue-Tooth coffee machine... Or better still, you see someone with the ear-mic thingie, you'll be able to whisper in his ear
I mean if they have to be within 10 meters, they can just watch where you are going with their eyes (whoever 'they' are).
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
Susanne Wetzel home page
The funny thing is, I can't find any papers on their sites (nor at Secure Systems Research Department) at bell labs
Just how many hackers (or their equipment) could you get connecting to your fax machine within 10 meters from you? Calculate the probability and take measures. It does not apply if you are paranoid, though. In the latter case you'd eliminated every chance for anyone to crack your agenda/VISA/phone (and would be right, too).
Eriksson's main task now would be to clean out the errors and bugs (or even certain concepts) from their code and give the world something very secure. Besides, that's what the market wants, anyway. I wonder when they go opensource and ask Slashdotters for help...
Actually, the whole concept of a peer-to-peer local area wireless network raises a host of issues. As I understand it, by default any Bluetooth device can "see" any other Bluetooth device in its vicinity. The point of this is that your cellphone/PDA can connect to everything from a wireless ISP server in your local Starbucks to the printer in your office, or simply trade info with another cellphone/PDA.
Obviously you will be able to set allowed access rules on the individual device, but can you hide the fact that you're carrying a Bluetooth device altogether?
To be useful for local-area communications (messaging across a classroom, for instance) the device would have to be as openly addressable as a telephone number. The difference being that, unlike a cellphone, the device itself automatically broadcasts that addressability (its phone number, as it were), which makes unwanted communications more of a risk. For instance: you're driving down the highway and some jerk cuts you off. You check your PDA and sure enough he's got a Bluetooth device in range. So you flame him! Far better than shaking your fist, huh?
Does anyone know what's being done to balance the privacy issue with the comminucations need for open accessibility?
1) This is a protocol issue. It's basically saying that in the current form of the protocol, a machine's identity could be marked. Big deal. This is a completely new technology which is still being developed. When holes are discovered in technologies in wide use, there's a problem. When they are discovered in a yet-to-be released product, the problems can be fixed. Bruce is premature in his attack on Bluetooth.
2) Kudos to the Lucent team who discovered the problem. Not only did they search and find the problem, showing they are dedicated to this project and its security, but they told the world. It would have been all too easy to hide the problem and fix it, but they spread the word, even though the technology is not really in active use. This says to me again that they are dedicated to fixing the problems and keeping Bluetooth secure, which makes me more interested in using it. I'm not paranoid, nor do I feel like I'm a particular target for espionage, however, I enjoy my freedoms just as much as anyone else, including my right to privacy, and if Lucent and the rest of the developers are working to make sure I continue to enjoy that privacy, I'm just a little bit happier. Congratulations to the Lucent team and keep up the good work.
Joe User cares when his identity is stolen and his bank account is wiped
yes, but he won't blame the technology. he'll know from the media that evil hax0r5 are to blame. and legislation to require licensing of all internet access tools and regulations to control internet content will have won a new lifelong supporter.
"I will gladly pay you today, sir, and eat up
Sacred cows make the best burgers.
"Patience is a virtue, afforded those with nothing better to do." - I don't remember
I posted about this a while back on slashdot and the implications of a network to track bluetooth devices, but know one seemed to be interested Do you always have a cell phone on you? Bluetooth negotiations are automated. Imagine a scenario of a building filled with bluetooth devices in certian locations like doorways ect. Every person carrying a phone has a unique identifier and could be tracked room to room in the building. You can take this to any level you want, I think it is pretty scary to say the least. As each person becomes networked, I'd say with almost any wireless scheme, not just bluetooth, there will be ways of tracking the devices. Triangulation comes to mind as a last resort, cell phone tracking ect. It's becoming easier and easier to do...
There are some subtle security issues since you can control the physical security of an ethernet lan and anyone can jack in to a bluetooth simply by walking in to range.
The simple answer is that this stuff is too useful not to have. The solution is not to store secure data locally. Yahoo probably devotes more effort to security than 99% of individuals can. In future, computer data security won't matter because everyone will just keep their stuff on some hardened remote server. (Program security, like getting viruses, will still matter.)
How do you plan to get your data off a "hardened" server via an insecure client without compromising those data? If someone can get access to your device, then he can impersonate you; or if not, then he can just grab the data off your device as you grab them off your server.
There's *Got* to be a better reference on security with bluetooth devices than that web page.
Basically, the guy says "Oo! Radio waves! Anyone with a paperclip and a sheet of aluminum foil can listen to radio waves! The sky is falling! And i don't know *ANYTHING* more about it!"
The problem of securing data that will be heard by unwanted recipients is very, very old. It may surprise you to learn that your connection is no more secure through an ethernet hub than it is over a bluetooth link.
Or honestly, any information that's transmitted over the internet. Traceroute to something. Every host it lists between here and there can snoop your connection.
The problem is not in the encryption per se, but how it exchanges keys. This can be fixed.
Sure, no data transmission protocol is ever truly 100% secure. But there's "somebody maybe might find a way to get the inverse of my public key" and then there's "Any scriptkiddie can flip their device into promiscuous mode and have all the data fly into their lap."
A lot of people argue that mediocre encryption systems give people a false sense of security. In a mission critical operation, this is true, you shouldn't trust it just because it's not cleartext. But for me, for personal use and casual corporate use, I'll take any system that's difficult to snoop over any other system that's flat out easy to snoop. Wouldn't you?
This is just like television, only you can see much further.
1) The "MMI" interactions take place on the local device. There is reason a user can't see his own BD_ADDR.
2) Bluetooth units can ONLY be inquired if they are in Inquiry Scan mode. If some developer wishes his device to do this all the time then so be it, but this is NOT a requirement of the Bluetooth spec. In fact a device may never be inquired but could still be connected to.
bah.. not high IQ.. just an IQ higher than that of a peanut. Unfortunately this seems to be a rarity.
//rdj
No one can understand the truth until he drinks of coffee's frothy goodness.
--Sheikh Abd-Al-Kadir, 1587
Schneier's 8/15 Cryptogram newsletter touched on these issues weeks ago.
Namely, if capability like the US government's Tempest technology (reads electro magnetic pulses, CRT, keyboard radiation, etc. - spy craft stuff) is available, it's a matter of time before such tactics are _readily_ used on commonplace bluetooth devices doing private or delicate matters in public. After all, reading your OpenSSH-downloaded, and GnuPG encrypted email privately to yourself in the back booth might seem secure, but, what if a black hat type is capturing your radiating emissions quite easily? Illusory protection. Treat Bluetooth as a broadcast protocol, because that's what it is, says Schneier.
What amazes me is the dearth of information about the security of this protocol. I'm sure someone has thought about it, a team designed some security into Bluetooth, and that those designers believe it to be secure. But has anyone reputable examined the protocol? Is the implementation known to be correct? Are there any programming errors? If Bluetooth is secure, it will be the first time ever that a major protocol has been released without any security flaws. I'm not optimistic, continues Schneier.
Check out some of these articles on Bluetooth, and it's lack of discussion on it's possibly inherent security shortcomings.
Bluetooth
A list of Bluetooth articles, none of them about security
One mention of security
An essay about the Bluetooth hype
Recent article on TEMPEST
Me pican las bolas, man!
Thanks
--
Me pican las bolas, man!
Thanks
Jaco
Hmmm. Perhaps there are MDTs still in use in some major centers. But many policing agencies using mobile devices are very concerned with security issues. I would hope that any CIO for any PD of size in the US is investigating options for the support of encrypted wireless data. Canadian federal policing agencies have been involved in this security development for quite a time. One of the principal problems with this situation is the low bandwidth wireless link. The kind of encryption that works on a 10 Mbps Ethernet will NOT work on an MDC4800 or RDLAP19.2 network. Things like key exchanges involving multiple transactions become problematic when a cop needs to jump in his car and login and begone to a crime in progress. So operational and technical limitations have had some effect of restricting the amount of security that can be deployed. But don't doubt that as new wireless technologies increase BW and new encryption schemes are available, subject to budget limitations, the PDs *will* adopt them. They are aware of their responsibilities... they just often have finite budgets and limited technical assets.
Pleasure in the job puts perfection in the work.
There was never a genius without a tincture of madness.
Aris
...it should be relatively simple to patch. Like the article mentioned, it should be easy to implement a constantly changing pseudonym based on any number of schema...
Just off the top of my head, they could use an algorithm based off of the user ID characters, the date, the time, or practically anything else.
Also, the problem with dropping a bug in a cybercafe could be resolved by making the transmission more tight-beamed. This might increase the amount of radiation output slightly, as it will require more energy to focus the transmission beam, but it could be worth it. Basically, you'd end up having to place the 'bug' in precisely the right spot to catch a transmission.
Kierthos
Mr. Hu is not a ninja.
Joe User cares more about whizbang features than security.
Joe User cares when his identity is stolen and his bank account is wiped
1Alpha7
Live to be Moderated
As time goes on, we hear more and more about security flaws in these new wireless personal devices. I think I'm going to devote some serious thought to whether I want to festoon myself with a bunch of linked equipment that contains my personal information, or on which I rely for things like communication, scheduling, directions, etc. I have this nightmare vision where someone manages to hack my body network and all my hardware starts conspiring against me. The modern-day equivalent of that old twilight zone episode where the guy is murdered by his own household devices.
"If I have seen further than other men, it is by stepping on their glasses." - Michael Swaine
As cypto-gram already reported; http://www.counterpane.com/crypto-gram-0008.html#8 ; Bluetooth is a broadcast procol and will always be insecure.
If people keep going around fixing things before they become problems, what are the scriptkiddie haxxors of tomorrow gonna do to keep themselves busy?
--------- Beware the dragon, for you are crunchy and good with ketchup.
A little known fact in the general computing public is that problems in secure communications lie more often in the communication protocol than in the encryption primitives.
There are some classical attacks:
It is possible to prevent those attacks by clever design of the protocol. For instance, the use of old keys can be prevented by some "nonce" numbers (generated once) or some clock data.
It is very difficult to analyse protocols and prove them correct.
First, a formal model of the protocol, its environment and what it means for it to be correct. This is nontrivial, since some models may just ignore some kinds of attacks.
Then the protocol must be proved correct with respect to the formal specification. Alas:
I have made some research on these topics. For more information, see for instance Jon Millen's page.