Attack on the Bluetooth Pairing Process

There’s a new cryptographic result against Bluetooth. Yaniv Shaked and Avishai Wool of Tel Aviv University in Israel have figured out how to recover the PIN by eavesdropping on the pairing process.

Pairing is an important part of Bluetooth. It’s how two devices—a phone and a headset, for example—associate themselves with one another. They generate a shared secret that they use for all future communication. Pairing is why, when on a crowded subway, your Bluetooth devices don’t link up with all the other Bluetooth devices carried by everyone else.

According to the Bluetooth specification, PINs can be 8-128 bits long. Unfortunately, most manufacturers have standardized on a four decimal-digit PIN. This attack can crack that 4-digit PIN in less than 0.3 sec on an old Pentium III 450MHz computer, and in 0.06 sec on a Pentium IV 3Ghz HT computer.

At first glance, this attack isn’t a big deal. It only works if you can eavesdrop on the pairing process. Pairing is something that occurs rarely, and generally in the safety of your home or office. But the authors have figured out how to force a pair of Bluetooth devices to repeat the pairing process, allowing them to eavesdrop on it. They pretend to be one of the two devices, and send a message to the other claiming to have forgotten the link key. This prompts the other device to discard the key, and the two then begin a new pairing session.

Taken together, this is an impressive result. I can’t be sure, but I believe it would allow an attacker to take control of someone’s Bluetooth devices. Certainly it allows an attacker to eavesdrop on someone’s Bluetooth network.

News story here.

Tags: , , , , , ,

Posted on June 3, 2005 at 10:19 AM • 41 Comments

Comments

Israel Torres • June 3, 2005 10:34 AM

One must wonder what the endgame is. It always seems to be convenience over security that wins. Until it is the other way around there should be no big surprises that anything wireless is likely to be broken and disclosed. At least with disclosure we can pretend to know what is going on. The real scary stuff is what is running around right in front of us that goes on unnoticed by most.

Israel Torres

Warren Kelly • June 3, 2005 10:55 AM

Would this not allow an (adequately equipped) eavesdropper to monitor keystrokes on wireless keyboards?

Wim • June 3, 2005 11:27 AM

The “Wartyping” link is about non-Bluetooth keyboards, which probably make no effort at all to resist interception (“security through inconvenience”?). The attack on Bluetooth is more interesting, IMHO, because Bluetooth actually does put some effort into achieving real security (hence the need for the “pairing” process in the first place).

Jim • June 3, 2005 12:17 PM

“four-decimal-digit key…” This means that the implementation of the key was intended more so that multiple Bluetooth pairs could interoperate in the same “RF Space.” I’m sure the discussion was along the lines of “Do you think there would ever be more than 9999 Bluetooth users in the same office?”. This mindset would not take into account the security of the pair exchanging the secret key.

I an expert on the Bluetooth protocol, but given this information, I envision another attack mechanism. If an attacker attempts to pair with a Bluetooth device using sequentially generated PIN’s, would they not eventually succeed in paring and therefore expose the PIN? At this point the attacker could cause the first pair to be reset initiating the re-negotiation of the private key. Just a thought.

Bruce Schneier • June 3, 2005 12:47 PM

“I an expert on the Bluetooth protocol…”

Excellent. I’m not, and I wanted to talk to one of those.

What are the effects of being able to 1) recover PINs, and 2) force pairings? What can an attacker do?

Arik • June 3, 2005 12:51 PM

I’ve been on a lecture given by Yaniv in Tel Aviv. The problem is not just the PIN – the entire protocol was badly designed. Perhaps if they have put in a diffie-hellman algorithm and create a relatively secure channel on which to exchange PINs instead of using the PINs as the keys we would have been better off. Unfortunately it seems that one of the arguments against this is the cost of the hardware – simple BT chips don’t have the computing power necessary.

@Jim,

Pairing usually requires you to interacively initiate pairing on both ends. The re-pairing process is not the same as initial pairing.

Anonymous • June 3, 2005 1:19 PM

This is entirely Bluetooth’s fault. If the Bluetooth wanted the key to be used for security, it should have require 128 bit key (with decent algo). If Bluetooth simply wanted the key to avoid collisions, it should have required 16-bit, with a xor operation. In the latter case, the key should be transmitted publicly, even after the pairing, to avoid any misconceptions about whether a given transmission is secure. A transmission is secure or it isn’t. A transmission using a 16-bit key is no more secure than plaintext; the only difference is that the people sending plaintext are under no illusions of privacy.

A Nonymouse • June 3, 2005 2:02 PM

Forcing re-pairing by injecting traffic will cause the devices to prompt the user for a PIN again. If this keeps happening a lot, an alert user will realise that something is up. Of course, that relies on having an alert user. 🙂

JHendrickson • June 3, 2005 2:10 PM

Pair this with the blue tooth sniper rifle and you have a serious security problem. You could eavesdrop on someones cell conversation if they are using a bluetooth headset.

JohnJ • June 3, 2005 2:54 PM

@A Nonymouse: Users aren’t always prompted to re-enter the PIN. My BT headset, for instance, doesn’t have control buttons for entering a PIN. The PIN is hard-coded at the factory and cannot be changed. My cel phone remembers the PIN associated with the headset so I’ve never re-entered it there either.

That factory-coded PIN would also be found pretty quickly if they scanned sequentially since it’s 0000. 🙂

Anonymous • June 3, 2005 3:51 PM

Ah the 2 1/2 hour train journey from London Kings Cross to Leeds is going to be fun, I always wondered who Emma Nokia 6630, Jane Moto-1, Sarah SonyEric, Michelle Single and looking were, now I’ll get a chance to find out!

Davi Ottenheimer • June 3, 2005 4:32 PM

Bruce, I’m not a Bluetooth expert either but I don’t think you have to be one to notice that the paper leaves out a crucial bit of context.

Jim points to the implementation of the protocol, which makes me think that the study is really just another exposure of a flawed approach, rather than a failed specification. Yet the study and your log entry both do not make any such distinction — one might easily get the impression from your log that the Bluetooth protocol itself is flawed.

I think we’ve been round this bend before, but if a specification has the potential for adequate security, then do you fault the spec itself or the product vendors for not properly turning potential security into actual?

Moreover, beyond the implementation issues, there seem to be user-related security issues here as well. And if we start down that rabbit hole, then we really aren’t talking about flaws in Bluetooth as much as going back to the old equations and trade-offs (that you often cite) between manufacturers, vendors, users, and finally security.

Interesting that the paper makes no mention of the official Bluetooth security documentation. A quick check of the site found a simple answer to some of the user-related issues:

http://www.bluetooth.com/help/security.asp
“It is recommended that users employ an 8 digit or more alphanumeric PIN when possible. Product owners must share that PIN number only with trusted individuals and trusted products for pairing. Without this PIN number, pairing cannot occur. It is always advisable to pair products in areas with relative privacy.”

[…]

“Theoretically a hacker can monitor and record activities in the frequency spectrum and then use a computer to regenerate the PIN codes being exchanged. This requires specially built hardware and thorough knowledge of Bluetooth systems. By using a PIN code with 8 or more alphanumeric digits it would take the hacker years to discover the PIN. By using a 4 digit numeric PIN code, the hacker could discover the PIN in a matter of a few hours. Still advanced software is required.”

So, again, I’m not a Bluetooth expert but it seems fairly obvious that the study serves to point out what the Bluetooth organization has already publically stated — PINS can be forced, and so if you use a unreasonable numeric-only four digit PIN (e.g. the 0000 mentioned above) you will probably be able to crack it in a very reasonable amount of time.

jbl • June 3, 2005 5:46 PM

One could argue that the bluetooth spec is flawed by not requiring a 128-bit PIN at all times, thus allowing implementations that are vulnerable.

Aaron Brown • June 3, 2005 6:05 PM

One thing that I don’t think has been well adressed is the effects on different bluetooth-enabled devices. The effect of the attack will necessarily be limited or shaped by the device being attacked. Someone cracking a bluetooth headset will be able to perform different attacks than someone cracking, say, a bluetooth printer.

A quick look at http://www.bluetooth.com reveals that bluetooth is used in everything from phones to printers to medical equipment. Someone grabbing the pin to and linking up with a bluetooth heartmonitor will have a different agenda than someone hacking your phone. My question is: is there anyway to determine how much control an attacker will have over a device by only knowing what the device does? Is a bluetooth attack like this an all-or-nothing proposition? If you break a bluetooth system, do you control it, or is bluetooth communication/control typically limited to only certain features of the device?

I have to admit, I’ve never even used a bluetooth device, and know relatively little about the protocol, so maybe if someone could throw up a link to a good intro to the bluetooth protocol it might be helpful to those of us who are more ignorant about it.

Nigel Rugger • June 3, 2005 6:45 PM

@ Davi Ottenheimer, citing Bluetooth spec:

“By using a 4 digit numeric PIN code, the
hacker could discover the PIN in a matter of a few hours.”

vs.:
in 0.06 sec on a Pentium IV 3Ghz HT computer.

Gee, the estimate was only off by about 6 orders of magnitude.
What computers did they think hackers use, KIM-1’s?

Davi Ottenheimer • June 3, 2005 8:35 PM

@Nigel Rugger

Funny, but not particularly insightful (where’s the scoring system, eh?)

The point is that Bluetooth has stated out in the open that their PIN method has risks that need to be handled with “proper controls”, and they certainly never claimed it to be unbreakable or secure by default.

The ability to force a PIN disclosure is interesting, but it really just supports the point Bluetooth was already admitting. In fact the security spec seems to be more about weak links and trade-offs than dry statistical analysis of the numbers (e.g. distance and discovery). Don’t believe me? Consider that 1000 is a hundred times more than 10. Impressive no? Now consider that moving the PIN from four to eight and enforcing case-sensitive alphanumerics “would take the hacker years to discover the PIN”. Is years sufficient?

And from another perspective (with context included), it seems that pairing was only meant to be initiated by the user and refused in any other case by default. That would take care of this issue, and that is what most systems should be able to do if they follow the spec (let alone capable of handling sensitive data)…

Personally I think we would have reason to be concerned if Bluetooth were found to be incapable of being reasonably secured, or that it falsely advertised security. Are either of those that the case here? So far, I only hear that Bluetooth is susceptible to weak implementation and improper use, both of which are hardly a surprise.

Davi Ottenheimer • June 3, 2005 8:46 PM

“One could argue that the bluetooth spec is flawed by not requiring a 128-bit PIN at all times, thus allowing implementations that are vulnerable.”

Perhaps, but there must have been some kind of trade-off, legacy or group that forced security to a lesser default.

Anyone know what/why the PIN was allowed to be so weak, let alone 0000 by default on so many systems? Was it just simple convenience, since some Bluetooth devices probably were thought to have no need whatsoever to prevent a bond? Or was it because of mitigating controls?

Jay Carlson • June 3, 2005 9:26 PM

If bluetooth required physical contact between devices to pair them, users could maintain security through some of the same strategies they use to avoid physical theft.

For example, a huge pairing key could be sent over a simple two-contact connector. Low-power inductive might do it too. I don’t know enough electronics to know if you can do it with one wire; perhaps a really low power version of the over-the-air physical layer. Stub antenna?

You’d still need to maintain constant physical control of the devices while in public. In some scenarios you might not know somebody had snagged your key while you weren’t looking. But the barrier would be more like mugging than eavesdropping.

PacoBell • June 4, 2005 5:40 AM

This attack reminds me of a similar one for wifi where an attacker sends a disassociate frame to the mark and sniffs the ensuing traffic. I wonder if BT is susceptible to the same replay attacks as wifi is. I’m sure the fact that the PIN is so ridiculously short doesn’t help the situation either.

snit • June 4, 2005 9:46 AM

Davi appears to be either a PR flack or someone who likes to accuse others of being divorced from reality by way of being in denial. (People who remember the glory days of news groups will spot this type easily.)

The fact of the matter is that the protocol is flawed, if it allows attacks effecting the majority of the users.

I personally would define that statement downwards, quite a bit, but one has to start the conversation somewhere.

I’m not a ‘bluetooth expert’ by any stretch. I’ve done one implementation. My gut feeling, though, is that I’d never depend on it for more than amusement. It doesn’t “feel” like a protocol that worried about data leak or attacks. I know that’s subjective. Just a voice from the field.

Martin • June 4, 2005 10:07 AM

  1. Wasn’t a key or PIN of 0000 used for the PAL control of nuclear warheads? (Vague memory of turf battles.)

  2. It seems that various protocols (BT, WiFi, etc.) are introduced to the consumer space with deficient security implementations – because of time to market, user acceptance issues, limited CPU power, etc. After a few years, a radical upgrade is necessary. Vendors say “oops”, and now we who care will have to trash older stuff prematurely, while most folks run compromised gear for a long time. Is this inevitable, or would it be better to provide a planned security upgrade path within a given hardware & protocol family with automatically (?) installed sw modules?

  3. I observe that my car (useful life 10+ years) is now talking BT to my Treo phone/pda (lifetime 2-3 years). Can I expect Acura to keep security up to date? This will be a problem as more durable equipment gets connected.

  4. My cell phone provider manages to get me to update my phone configuration over the air occasionally. Could that work with BT or WiFi systems?

Anonymous • June 4, 2005 2:02 PM

Thanks for the google URL, Davi, but alas, I’d already tried a similar search and most of the sites I had to plow through were glitter-covered corporate bullshit. I was hoping maybe someone had a more technical look at the bluetooth protocol and how it works. The two “specification” links I found from other sources to the bluetooth website were both broken.

If anyone other than me is still interested in browsing the spec and hasn’t found it already, it’s available from the Bluetooth SIG (Special Interest Group) at https://www.bluetooth.org/spec/ (Reg. req.)

Davi Ottenheimer • June 5, 2005 1:18 PM

@snit

“The fact of the matter is that the protocol is flawed, if it allows attacks effecting the majority of the users.”

Security does not exist in a vacuum. It requires trade-offs, and all security controls are in some manner flawed. The spec calls for stronger controls, but vendors/manufacturers clearly choose not to implement them. So you are merely pointing out, again, that users are affected by a weak implementation, not the spec.

Anyone who works in security knows that a spec can not presume to know all the potential use cases if it is meant to be broadly implemented. Moreover, the broader the base of support, the harder it may be to find a commonly acceptable denominator of what “flawed” means. If a device is only meant for a narrow high-security implementation, then it makes sense to enforce high-security bonds. Someone somewhere will voiciferously defend the need for an option to build and deploy completely insecure devices…sometimes only under the assumption that many many other mitigating controls would be in place (e.g. deep in the bowels of a rapid-release test bunker where speed and compatibility are of the essence).

Again, I do not see the flaw in the spec unless we (as security commentators) are deciding that society as a whole has no need whatsoever for a weak Bluetooth PIN. Personally I do not see the need for a 0000 PIN, let alone four instead of eight case-sensitive alphanumerics, but that does not mean I am ready to throw out the baby with the bathwater. I will just be careful as a consumer to weigh the risks and chose products carefully.

Davi Ottenheimer • June 5, 2005 1:40 PM

@Anonymous
Seems like you wanted more than an “intro” to Bluetooth if you say you finally answered your needs with the SIG spec itself.

While an intro is obviously a distillation of the spec, you are correct to be wary of perspective. However, if you are virulently against commerical sources then many intros are also available from academic and non-commercial settings if you search for them (try site:edu or even site:gov if you prefer)

http://www.google.com/search?hl=en&lr=&as_qdr=all&q=site%3Agov+what+is+bluetooth&btnG=Search

You will note that the first gov hit is the NIST special publication 800-48. Note section 4-13 on Bluetooth Security, which very clearly cites security issues including “short pins are allowed”.

Terence Tan • June 5, 2005 6:34 PM

Usability.

We’ve said for some time that our capability to crack keys exceeds our ability to memorise long keys (or if it hasn’t already happened, it will soon). Now, in this case, you don’t need to memorise a long key, just enter it as a one-off. But keep in mind what the target market is:

A 128-bit key is something like 38 decimal digits – people have to enter this on a phone keypad. If they have to enter anything more than about 6 digits, they just won’t do it (these are non-techie people) and will just go without security or not use it at all. If they have to enter anything less than about 25 digits, it won’t be cryptographically secure. See the problem here?

Hence talk about alternative authentication methods.

Roger • June 5, 2005 10:27 PM

@Terence, Davi etc:

Terence has a good point. I have run up against exactly this problem in an unrelated project; your marketroids will not let you specify a user-entered key of anything like adequate length, because numerophobes will not be able to use your product. What this means in practice is that you have two choices for security in this field:
* bootstrap security by some method that does not involve user-entered keys (e.g. Jay Carlson suggested DH over a temporary private wired channel); or
* use a protocol which is able to bootstrap strong security from weak keys, despite being monitored. This means the EKE family & SRP. Currently, there are no other choices.
Bluetooth chose to specify a non-EKE protocol which required consumer entry of the bootstrap key through a (usually awkward, sometimes non-existent) interface. This gave them the ease of avoiding PK crypto, the marketability of a simple PIN entry, and the hardware ease of a single RF interface. But the cost of all this convenience is that the security is clearly and obviously broken and in fact is not practicably repairable without drastic changes in the protocol. (Caveat: we could reverse the position from “totally busted” back to “rather shaky” simply by removing the ability for devices to request re-pairing. The cost would probably be much lower reliability.)

@Davi:

Quite apart from the impracticality of asking grandma to punch in an 8 digit alphanumeric key, the calculation is still suspect. It is true only if we restrict the attacker to a small number of CPUs (not true in the real world) and use mixed case alphanumerics (unlikely to happen because it is especially awkward to enter mixed case text on a cellphone.) With single case alphanumeric, if we can check 10^4 keys in 0.06 seconds then we can check 36^8 keys in 196 days, not “years”. That’s much better than 0.06 seconds, but still hardly adequate. Note that this is for one CPU, and the problem is easily parallelized. Throw it at a 1000 host botnet, then if you picked up the pairing on the morning train you’ll have a solution in time for snooping on the train home. Even mixed case, totally random 8 character alphanumerics will succumb to a 1000 host botnet in two or three weeks; just enough to dissuade casual snoops, but not anyone with a bit of motivation, such as a corporate spy or a jealous lover.

To get 128 bit security from a mixed case, totally random alphanumeric password requires 22 characters. Like this:
aixTvDzZja7rC7GjCrEr4S
I think you’ll agree that it is ridiculous to suggest that an average person either memorise something like that, or type it in to initiate a pairing. Clearly a protocol that requires that of a typical consumer in order to obtain security, is flawed.

@Everyone:

If you haven’t heard of the EKE family, or SRP, have a look. They are real crypto black magic. You start with a weak secret (say, an n-digit PIN), allow active or passive attackers to monitor or interefere with every message, and yet end up with a strong cryptographic security. It is always possible for the attacker to simply guess the PIN and test it through an attempted pairing, but since that is an online attack with 10^-n probability of success per trial, standard logon procedures suffice to deal with that. In particular, because real pairings occur infrequently, the lockout period after several failures could be infinite (i.e. lockout until manual reset).

Davi Ottenheimer • June 6, 2005 10:53 AM

@Roger

“Caveat: we could reverse the position from “totally busted” back to “rather shaky” simply by removing the ability for devices to request re-pairing.”

That is, in fact, the recommendation. Devices should be disabled or made safe by being unable to respond to a probe unless user-initiated.

“I think you’ll agree that it is ridiculous to suggest that an average person either memorise something like that, or type it in to initiate a pairing.”

Hmmm, that is exactly what we all do when we type our passwords. You might say it is a pain or rediculous, and yet we require it and have no need to remember the hash values, just the passwords/phrases…

I think this all comes back to the fact that the paper cited by Bruce is more an academic treatment of a well known risk, perhaps to get a more accurate estimate, than a fresh discovery. Even Bruce was asking for some real data to quantify the impact, and so far we are still just discussing the theoretical issues.

Roger • June 6, 2005 12:01 PM

“That is, in fact, the recommendation…”
Well, I guess we’ll soon find out how often re-pairings are really necessary! (Bearing in mind that the specification permits a device to forget a link key whenever it likes!)

“Hmmm, that is exactly what we all do when we type our passwords. ”
You have a 22 random character password!?! Not many people would. For a start, passwords that can only be verified on-line don’t need to be that strong. For passwords that can be attacked off-line and do need high strength (e.g. cryptographic keys), as you know better interfaces allow you to enter a long phrase which is then hashed to the key. I have never come across a Bluetooth device which does this and to the best of my knowledge none exist. It would be extremely inconvenient on a cellphone, and to be compatible with “ordinary” Bluetooth devices it would have to output the hash anyway, to type into the other device. And it still wouldn’t be any good for “ordinary” users because they would choose their dog’s name as their “passphrase”.

Bluetooth can be made secure (modulo buffer overflows etc), but only for us security geeks. Ordinary consumers require a system that either doesn’t rely on user input for bootstrapping, or else can amplify weak user input to a strong secret. Solutions of both types are perfectly feasible, but Bluetooth is neither of them.

“…he paper cited by Bruce is more an academic treatment of a well known risk…”
Umm, I would have called it a practical treatment of an academically well known risk. The vulnerability of this sort of key exchange was indeed well known, and was specifically discussed for Bluetooth by Whitehouse. What Shaked and Wool did was two-fold, a) implement and optimise it (and publish measurements); and b) discover the re-pairing attack. The sort of low-level manipulation required for re-pairing is already common among Bluetooth crackers (see trifinite.org for example tools); would you care to wager a cyber-beer on how long before re-pairing hits the streets?

Davi Ottenheimer • June 6, 2005 1:22 PM

“And it still wouldn’t be any good for “ordinary” users because they would choose their dog’s name as their “passphrase”.”

Exactly my point. The implementation is the weakness.

I still do not see any Bluetooth claim that the conditions tested in the paper were meant to be strong or secure. Quite the contrary there are well documented warnings that public pairing may be forced and that PINs are insufficiently secure. So at the end of the day we have a paper proving a point (that Bluetooth was already making) about the need for more secure implementations, per the spec.

My guess is that re-pairing attacks have been around since the spec originally warned of the risk(s), but now they will be far more prevalent and efficient.

Steven Fisher • June 8, 2005 4:23 AM

I must be buying the wrong devices. I’ve never used a BlueTooth device that does not need to be put in “discoverable” mode before the PIN will work. So someone can loop through PINs in less than a second. So what? They need to get my to pull the device out of my pocket and set it to Discoverable first.

Davi Ottenheimer • June 8, 2005 2:51 PM

Today’s Register mentions that Ollie Whitehouse set the stage to explore a re-pairing attack at CanSecWest in 2004, along with some research in how to discover devices that have been set to be undiscoverable.
http://www.theregister.co.uk/2005/06/08/bluetooth_mobo_attack/

Here’s Ollies’ presentation (note page 23, where he lists countermeasures):
http://cansecwest.com/csw04/csw04-Whitehouse.pdf
– Restrict bonding to secure locations
– Use 16 byte PINs
– Use Diffie-Helman, per the spec, for sensitive deployments

Eric • June 9, 2005 1:29 PM

  • bootstrap security by some method that does not involve user-entered keys (e.g. Jay Carlson suggested DH over a temporary private wired channel); or

Actually, DH is a fine method for generating a secure communications channel.
The only danger being that you’d like a way to ensure that the device you’re pairing
with really is the correct device. So entering a PIN still makes sense.

It seems to me that a simple “fix” to this impelentation problem
is to not allow devices to accept the “I forgot my key” message.
That sort of defeats the purpose of the hopefully secure initial exchange.

So if a manufacturer implements this fix, next time I go downtown,
maybe my phone prompts me to say “Key authentication failure —
do you want to pair again?”. I should be able to select “no” at which point,
maybe I am still suffering a denial-of-service attack because my device doesn’t
work, but I walk to the next subway station and it starts working again.

Manufacturers really need to do a better job implementing secure systems or people
will continue to think the whole world is insecure, when it really doesn’t have to be so bad.

Even secure algorithms like diffie-helman aren’t so expensive computationally that
you couldn’t run them once in a while just for pairing. I mean, so what if it takes a few
seconds longer. If people didn’t want that, the manufacturer could allow them to select
‘skip secure pairing’.

Dick Fikkert • October 22, 2005 4:13 AM

Many headsets and GPS receivers can only use 0000 as the PIN. So when these devices have been paired with my PDA, one knows at least one PIN for that PDA and I presume the Bluetooth device address can easily be monitored.
What then can be done with that info? Is my PDA compromised because of that 0000 pairing? Can one indeed enter my PDA when I stopped using my headset? Can one call through my PDA? Can one get my stored password from the PDA?

N82 • December 12, 2007 1:11 AM

gentlemen…I’m just a college student and cannot so relate to your arguments. But I’ve understand some points you guys posts here…that Bluetooth security mechanism is weak and so on…Just few questions, how serious matter is this? what will the hacker gain after gaining the PIN? and who the heck will care to hack your PIN when pairing to other devices (like sending your pics to someone else) ^_^ thnx guyz!

Gajipara keyur • February 4, 2008 10:54 AM

i’m keyur gajipara from india in gujrat.
i’m study in birla vishvakarma mahavidhyalaya engineering collage.
i’m student of computer engineering in first year.
i want to learn how i’m hack bluetooth pair hack?
i explain ,first i’m search bluetooth device,assume a unknown device find so how i can connect his bluetooth without he konw ?
how i can enter in his mobile without his presency of mind?
I hope u help me.

DrSyn • August 11, 2008 8:22 AM

All,
Interesting reading & thank you for being candid. Having worked on networks from 20 milliamp wire all the way through to full blown ISDN, the aspect of security is always the latecomer on the design, build and release. Costs and get to market faster are the overiding factors.
As long as people are ”aware” that Bluetooth is a non secure medium, they should act accordingly. Yes I shread my personal documents into waste !! DrSyn

Scooby Doo Backpacks • June 2, 2010 8:13 PM

Hey this is great news,

The Bluetooth feature on my phoned has been malfunctioning and I lost my pin. As a result I tried to get the manufacturers to help me out but they said “that they don’t have standardized on a four decimal-digit PIN.

So with the pairing thing what can I do to retrieve all my lost information.

Thanks,
Chris

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.