Return-Path: <cyrus@holtmann.org>
Message-ID: <4F83F3D7.1020402@tu-ilmenau.de>
Date: Tue, 10 Apr 2012 10:48:23 +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> <4F7D9848.6060202@tu-ilmenau.de> <4F816028.9080805@tu-ilmenau.de>
In-Reply-To: <4F816028.9080805@tu-ilmenau.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Sender: linux-bluetooth-owner@vger.kernel.org
List-ID: <linux-bluetooth.vger.kernel.org>

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@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
>>>>
>>>>
>>
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe 
>> linux-bluetooth" in
>> the body of a message to majordomo@vger.kernel.org
>> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html