Return-Path: <cyrus@holtmann.org>
Message-ID: <4F7D9848.6060202@tu-ilmenau.de>
Date: Thu, 05 Apr 2012 15:04:08 +0200
From: Steffen Becker <steffen.becker@tu-ilmenau.de>
MIME-Version: 1.0
To: wyrles@ytram.com
CC: linux-bluetooth@vger.kernel.org
Subject: Re: problem with ssp debug mode & pand
References: <4F7349EC.8080706@tu-ilmenau.de> <4F755663.1050508@tu-ilmenau.de> <81C9FA9C1C2E9E45A9AC3EDD1858BC4323E12DC1@048-CH1MPN1-101.048d.mgd.msft.net> <4F75BB73.2010708@tu-ilmenau.de> <81C9FA9C1C2E9E45A9AC3EDD1858BC4323E12E14@048-CH1MPN1-101.048d.mgd.msft.net> <4F7BE3A8.9010801@tu-ilmenau.de> <81C9FA9C1C2E9E45A9AC3EDD1858BC4323E13D11@048-CH1MPN1-101.048d.mgd.msft.net> <4F7C4BCD.6070904@tu-ilmenau.de> <04dd01cd12af$1b279c90$5176d5b0$@ytram.com>
In-Reply-To: <04dd01cd12af$1b279c90$5176d5b0$@ytram.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Sender: linux-bluetooth-owner@vger.kernel.org
List-ID: <linux-bluetooth.vger.kernel.org>

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@vger.kernel.org [mailto:linux-bluetooth-
>> owner@vger.kernel.org] On Behalf Of Steffen Becker
>> Sent: Wednesday, April 04, 2012 6:26 AM
>> To: james.steele@accenture.com; linux-bluetooth@vger.kernel.org
>> 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
>>
>>