Return-Path: Message-ID: <4F816028.9080805@tu-ilmenau.de> Date: Sun, 08 Apr 2012 11:53:44 +0200 From: Steffen Becker 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> In-Reply-To: <4F7D9848.6060202@tu-ilmenau.de> Content-Type: text/plain; charset=UTF-8; format=flowed Sender: linux-bluetooth-owner@vger.kernel.org List-ID: 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//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