RE: problem with using BPA500

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> Hello,
> 
> i have a problem with sniffing my 2 bluetooth devices. Google & forums
> didn't helped me.
> I use the BPA500 for sniffing two BT3.0 devices; maybe someone of you also
> use this. This is my problem:
> The frontline technical support told me, that i have to put my devices in
> discovery mode & at least one device in ssp debug mode. And it is
important
> that the devices get paired AFTER i click on "Start Sniffing".
> I did so, but in my LMP there is some Opcode missing. There is only:
> ...
> au_rand
> sres
> encrypt_mode_req
> 
> But there SHOULD be something like that:
> ...
> comb_key
> au_rand
> sres
> au_rand
> sres
> setup_complete
> encrypt_mode_req
> 
> I think there is no problem with the BPA software, because when i sniff
> BT2.0 devices, everything works fine (because i don't have to use a ssp
> debug mode). And the BPA-support says, there are two possible misstakes:
> either the devices are paired before sniffing, or no device is in sspdebug
> mode. But i think i did this right.
> 
> Maybe you find out what i did wrong:
> 
> - two gentoo-PCs with two BT3.0 Dongles and i installed the latest bluez &
> the patch "Adding SSP debug mode configuration to hciconfig" on both PCs
> PC2 # hciconfig hci0 piscan
> PC1 # hciconfig hci0 piscan
> PC1 # hciconfig hci0 sspdebug 1
> (in a 2nd try also: PC2 # hciconfig hci0 sspdebug 1) click on "start
sniffing" at
> the software
> PC2 # rfcomm listen 0 1
> PC1 # rfcomm -r connect 0 <bluetooth-adress> 1
> 
> The connection worked (as seen on the two conncted PCs) but the sniffing
> software didn't really captured it. The Icon is blue indeed (so it's
> synchronized), but somehow there is missing something, because it doesn't
> sniff correctly.
> 
> Hope someone of you can help me.
> 
> Regards,
> Steffen

Hi!

If you don't get two sets of 

-> au_rand
<- sres
<- au_rand
-> sres

then no pairing occurred. Mutual LMP authentication (au_rand/sres in each
direction) is only used during pairing.

(A) For traditional pin code based pairing you should see

-> in_rand
-> comb_key
<- comb_key

 (B) For SSP based pairing, you should see

-> io_capability_req
<- io_capability_res
<-> some other SSP related messages based on the I/O capabilities
-> dhkey_check
<- accepted
<- dhkey_check
-> accepted

You should always see sequence (A) or (B) if pairing takes place. Neither of
these have anything to do with SSP Debug Mode.


So, given what you are seeing, I agree with Frontline tech support, no
pairing is taking place.

You might want to run HCIdump and look at the HCI sequence.

<- link_key_request
-> link_key_request_reply

Means the devices are already paired

<- link_key_request
-> link_key_request_negative_reply

Means the devices are not already paired

----------

Secure Simple Pairing uses the Diffie-Hellman Elliptic Curve algorithm
(DHEC).

DHEC as used in Bluetooth is based on private secrets (keys) that are only
known to each controller. You cannot set the private key nor can you read it
out of the controller. Most controllers make one up as needed.

The private keys are never on the air:  values derived from the keys  -- the
"public keys" -- are exchanged between the devices.

The "magic" of DHEC is that if you know

	Private Key A		Private Key B
	Public Key A		Public Key A
	Public Key B		Public Key B

you can feed those triplets into a formula that will produce the same
answer.

Since the private keys cannot be known, that pretty much makes air sniffing
useless.... UNLESS you enable SSP Debug Mode.

In SSP Debug Mode a set of well known keys is used.

If device A is in SSP debug mode

	Debug Mode Private Key A	Private Key B
	Debug Mode Public Key A	Debug Mode Public Key A
	Public Key B			Public Key B

Feeding those triplets into the formula that will produce the same answer.

Similarly, if device B is in SSP debug mode

	Private Key A			Debug Mode Private Key B
	Public Key A			Public Key A
	Debug Mode Public Key B	Debug Mode Public Key B

Feeding those triplets into the formula that will produce the same answer.

The trick is that when the air sniffer sees either of the debug mode public
keys on the air, it automatically knows the corresponding debug mode private
key for that device. That gives the air sniffer one (or both) of the
triplets that are used by the devices allowing it  (the air sniffer) to
compute the same answer.

----------

So in short, the air sniffer should always see the exchanges that I listed
in the first section of my answer. SSP debug mode lets the air sniffer do
something useful with the data that it collected.

Cheers!

--- tom


--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux