Re: problem with ssp debug mode & pand

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

 



Hi again,

(and sorry for this lot of emails),
I just read my last email again and I think I didn't explained it well enough what I want to know: I need to know what command I have to use OR which file I have to change (and how to change) to handle this security block at my pand-connection.

Regards,
Steffen

Am 08.04.2012 11:53, schrieb Steffen Becker:
Thank you for this information!

But can anyone tell me how I can change my security configuration? Regarding to this "pand"-security-problem explained in my question (a).

Cheers
Steffen

Am 05.04.2012 15:04, schrieb Steffen Becker:
To b)
Thanks, this worked!
I deleted the file /var/lib/bluetooth/<local-bdaddr>/linkkeys
then enabled sspdebug and the captures worked!
But I have a question to that (it's no problem for what I want to do, I'm just interested): Even if I disable the sspdebug mode and reboot the PCs, and than connect again (with disabled SSP debug mode!) the devices ALWAYS create a new Link Key. Before I deleted the "linkkeys"-file, the devices used everytime the same linkkey from this file. So why is no new "linkkeys"-file being created now?

Cheers,
Steffen


Am 05.04.2012 00:05, schrieb Tom Allebrandi:
a) Maybe the link key between the devices is not "strong" enough? There are three levels of link key:

1) Authenticated - This is the strongest type of key and should be used with profiles that carry sensitive data. The SSP process was executed with "man in the middle" protection enabled.

2) Unauthenticated - This is a weaker key and should be used with profiles where data sensitivity may not be much of an issue. These occur when the SSP process was executed with "man in the middle" protection disabled.

3) Debug - The key resulted from executing SSP with debug mode enabled. The resulting link key is considered to be unsecure since an unfriendly air sniffer could have picked up the data needed to compute the link key.

-----

b) I've been carrying on a direct conversation with Steffen about getting the sniffer working by using the link key. A little while ago I sent him a note about SSP Debug Mode and thought that others might find this information helpful:

SSP stands for Secure Simple PAIRING. It is only used during the pairing (aka bonding) process.

Here is an important piece of information:

1) SSP Debug Mode is of value when pairing is taking place.

2) SSP Debug Mode is of NO value when NO pairing happens -- in other words, the devices are already paired.

SSP Debug Mode allows an air sniffer to compute the correct link key WHEN IT SNIFFS the pairing operation between two devices. If no pairing is sniffed, then the air sniffer has no useful link key and you have to resort to other means to get it into the air sniffer -- like entering it manually.

So, I would

1) Unpair the devices. You can do this by deleting the stored link key on one or both devices.
2) Set sspdebug mode on one or both of the devices;
3) Make sure that the sniffer is running when you pair the devices;

(I've forgotten, is there an hciconfig or hcitool subcommand to unpair two devices? I don't have a Linux system handy to check.)

If you unpair and then sniff the pairing, the sniffer should have the correct link key.

Remember

1) One set of au_rand/sres messages in the sniffer trace: No pairing occurred. 2)Two sets of au_rand/sres messages in the sniffer trace (one set in each
direction): Pairing occurred.

That's a quick check to see if the sniffer might have gotten the right link key. (Other important messages may have been missed but at least you know that the sniffer was active during the pairing process.)

Of course the best check for having the right link key is if things are being decoded properly after encryption is enabled.


Cheers!

--- tom




-----Original Message-----
From: linux-bluetooth-owner@xxxxxxxxxxxxxxx [mailto:linux-bluetooth-
owner@xxxxxxxxxxxxxxx] On Behalf Of Steffen Becker
Sent: Wednesday, April 04, 2012 6:26 AM
To: james.steele@xxxxxxxxxxxxx; linux-bluetooth@xxxxxxxxxxxxxxx
Subject: problem with ssp debug mode&  pand

Now I installed hcidump, hope this helps you supporting me.
So again my 2 problems are:

a)
pand-connection doesn't work. "Connection refused".
hcidump at the device which is listening when I try to connect:

<  ACL data: handle 11 flags 0x00 dlen 16
      L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0040 result 3 status 0
      Connection refused - security block

>  HCI Event: Disconn Complete (0x05) plen 4
      status: 0x00 handle 11 reason 0x13
      Reason: Remote User Terminated Connection


I see "security block" but... what can i do?


b)
It's possible to create a RFCOMM-connection between two Bluetooth3.0-
Devices. For that I use a Sniffing-Tool (BPA500). When I enter the Link Key into the sniffing software, the connection can be captured by the sniffer. But if I don't use the link key and enable the sspdebug mode instead, the sniffer can't capture it. So maybe something's wrong with enabling the sspdebug
mode.
hcidump when I enable the sspdebug mode:
<  HCI Command: Write Simple Pairing Debug Mode (0x06|0x0004) plen 1
      mode 0x01
>  HCI Event: Command Complete (0x0e) plen 4
      Write Simple Pairing Debug Mode (0x06|0x0004) ncmd 1
      status 0x00


I see "status 0x00", i think that means sspdebug mode is enabled. So why
can't the sniffer capture it?

If you need more information, just tell me.
Hope someone can help me :-)

Cheers,
Steffen



--
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

--
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

--
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