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
