Re: [Bluez-devel] "promiscuous mode" for hci devices?

[Steven Singer <steven.singer@csr.com>]

Andrew Kohlsmith wrote:
> On Monday 04 December 2006 09:07, Marcel Holtmann wrote:
>> The radio, baseband and link manager are part of the Bluetooth chip and
>> not accessible via the host operating system.
> 
> That's what I was getting at; the device *does* see all communications, but 
> unless there is a method to flip on the equivalent of ethernet's promiscuous 
> mode, you'll never see anything not intended for you.  Your message suggests 
> that there is no HCI call to do this, which puts me out of luck.

No. Your assumptions are wrong. The device does *not* see all
communication, even with complete control of the baseband firmware,
putting a mass produced standard device into promiscuous mode is
impossible.

Your analogy between Ethernet and Bluetooth is flawed. Ethernet packets
are transmitted on a wire. Wires are quiet between packets. The signal
to noise ratio is good. This allows a device easily to identify the
start of any packet without knowing anything about the contents.

Bluetooth packets are transmitted on a radio. The signals you're looking
for are often not far off the noise level. This means you get random
data between packets. To avoid triggering on the noise you need to look
for a long sequence of bits. To reduce wastage, the sequence used is
related to part of the MAC address of the master. So, the only (easy)
way to know that the packet exists at all is to know the address being
used.

However, before you get that far, there's the problem of knowing which
channel to listen to. Bluetooth packets are spread over 79 frequencies.
The link hops between these, changing frequency for every packet. A
(standard) radio can be tuned to only one frequency at a time. So, in
your Ethernet analogy, imaging your Ethernet packets are coming down
79 wires in an almost random order. You have no custom hardware so you'd
have to switch those wires in and out of your Ethernet card in the right
order before each packet is received.

This is a very important point. You wrote that "any device in a shared
medium would by its very nature have to receive all messages". At best
an unsynchronised Bluetooth device gets just one seventh-nineth of all
messages into its radio and then has to worry about distinguishing
messages from noise.

Supposing you solve the frequency hopping problem - say by having an
array of 79 devices, one for each frequency - and the correlator
problem, you next have to contend with whitening. Each packet is
trivially scrambled to remove DC bias. The scrambling is simply related
to the Bluetooth clock, so can take one of 64 sequences. Bluetooth chips
are set up to know the sequence to use for each packet. They can't
simply try all of them.

Then, there are persistent changes to the state of a link. For example,
switching between basic rate and enhanced data rate changes the packet
format. A Bluetooth receiver has to know which mode to be in. It knows
because it was party to the LMP negotiation. A stateless promiscuous
sniffer would have to try both.

This gets you as far as knowing that a packet exists. In theory, all
the problems so far could be overcome with sufficient custom equipment,
but you're probably talking about a crate of FPGAs.

However, even if you were to assemble all that equipment, you will
fall over at the next hurdle: all non-trivial Bluetooth traffic is
encrypted specifically to prevent sniffing. Unless you know the
encryption keys for all traffic in the area you want to sniff, you're
doomed (this applies to normal Bluetooth sniffers to - you have to
get the encryption keys into them somehow).

The best you could do with a standard dongle, albeit with modified
firmware, is to report all the unencrypted traffic in a single
piconet. However, that's a lot less than a promiscuous mode.

Man in the middle attacks are different. In this case, the man in
the middle wants to intercept the traffic for just one connection.
This is much closer to the sniffer problem and doesn't require being
promiscuous. It would still require firmware modification.

	- Steven
-- 


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel