problem with using BPA500

problem with using BPA500

[Steffen Becker]

Hello,

i have a problem with sniffing my 2 bluetooth devices. Google & forums 
didn't helped me.
I use the BPA500 for sniffing two BT3.0 devices; maybe someone of you 
also use this. This is my problem:
The frontline technical support told me, that i have to put my devices 
in discovery mode & at least one device in ssp debug mode. And it is 
important that the devices get paired AFTER i click on "Start Sniffing". 
I did so, but in my LMP there is some Opcode missing. There is only:
...
au_rand
sres
encrypt_mode_req

But there SHOULD be something like that:
...
comb_key
au_rand
sres
au_rand
sres
setup_complete
encrypt_mode_req

I think there is no problem with the BPA software, because when i sniff 
BT2.0 devices, everything works fine (because i don't have to use a ssp 
debug mode). And the BPA-support says, there are two possible misstakes: 
either the devices are paired before sniffing, or no device is in 
sspdebug mode. But i think i did this right.

Maybe you find out what i did wrong:

- two gentoo-PCs with two BT3.0 Dongles and i installed the latest bluez 
& the patch "Adding SSP debug mode configuration to hciconfig" on both PCs
PC2 # hciconfig hci0 piscan
PC1 # hciconfig hci0 piscan
PC1 # hciconfig hci0 sspdebug 1
(in a 2nd try also: PC2 # hciconfig hci0 sspdebug 1)
click on "start sniffing" at the software
PC2 # rfcomm listen 0 1
PC1 # rfcomm -r connect 0 <bluetooth-adress> 1

The connection worked (as seen on the two conncted PCs) but the sniffing 
software didn't really captured it. The Icon is blue indeed (so it's 
synchronized), but somehow there is missing something, because it 
doesn't sniff correctly.

Hope someone of you can help me.

Regards,
Steffen

RE: problem with using BPA500

[Tom Allebrandi]

> -----Original Message-----
> Hello,
> 
> i have a problem with sniffing my 2 bluetooth devices. Google & forums
> didn't helped me.
> I use the BPA500 for sniffing two BT3.0 devices; maybe someone of you also
> use this. This is my problem:
> The frontline technical support told me, that i have to put my devices in
> discovery mode & at least one device in ssp debug mode. And it is
important
> that the devices get paired AFTER i click on "Start Sniffing".
> I did so, but in my LMP there is some Opcode missing. There is only:
> ...
> au_rand
> sres
> encrypt_mode_req
> 
> But there SHOULD be something like that:
> ...
> comb_key
> au_rand
> sres
> au_rand
> sres
> setup_complete
> encrypt_mode_req
> 
> I think there is no problem with the BPA software, because when i sniff
> BT2.0 devices, everything works fine (because i don't have to use a ssp
> debug mode). And the BPA-support says, there are two possible misstakes:
> either the devices are paired before sniffing, or no device is in sspdebug
> mode. But i think i did this right.
> 
> Maybe you find out what i did wrong:
> 
> - two gentoo-PCs with two BT3.0 Dongles and i installed the latest bluez &
> the patch "Adding SSP debug mode configuration to hciconfig" on both PCs
> PC2 # hciconfig hci0 piscan
> PC1 # hciconfig hci0 piscan
> PC1 # hciconfig hci0 sspdebug 1
> (in a 2nd try also: PC2 # hciconfig hci0 sspdebug 1) click on "start
sniffing" at
> the software
> PC2 # rfcomm listen 0 1
> PC1 # rfcomm -r connect 0 <bluetooth-adress> 1
> 
> The connection worked (as seen on the two conncted PCs) but the sniffing
> software didn't really captured it. The Icon is blue indeed (so it's
> synchronized), but somehow there is missing something, because it doesn't
> sniff correctly.
> 
> Hope someone of you can help me.
> 
> Regards,
> Steffen

Hi!

If you don't get two sets of 

-> au_rand
<- sres
<- au_rand
-> sres

then no pairing occurred. Mutual LMP authentication (au_rand/sres in each
direction) is only used during pairing.

(A) For traditional pin code based pairing you should see

-> in_rand
-> comb_key
<- comb_key

 (B) For SSP based pairing, you should see

-> io_capability_req
<- io_capability_res
<-> some other SSP related messages based on the I/O capabilities
-> dhkey_check
<- accepted
<- dhkey_check
-> accepted

You should always see sequence (A) or (B) if pairing takes place. Neither of
these have anything to do with SSP Debug Mode.


So, given what you are seeing, I agree with Frontline tech support, no
pairing is taking place.

You might want to run HCIdump and look at the HCI sequence.

<- link_key_request
-> link_key_request_reply

Means the devices are already paired

<- link_key_request
-> link_key_request_negative_reply

Means the devices are not already paired

----------

Secure Simple Pairing uses the Diffie-Hellman Elliptic Curve algorithm
(DHEC).

DHEC as used in Bluetooth is based on private secrets (keys) that are only
known to each controller. You cannot set the private key nor can you read it
out of the controller. Most controllers make one up as needed.

The private keys are never on the air:  values derived from the keys  -- the
"public keys" -- are exchanged between the devices.

The "magic" of DHEC is that if you know

	Private Key A		Private Key B
	Public Key A		Public Key A
	Public Key B		Public Key B

you can feed those triplets into a formula that will produce the same
answer.

Since the private keys cannot be known, that pretty much makes air sniffing
useless.... UNLESS you enable SSP Debug Mode.

In SSP Debug Mode a set of well known keys is used.

If device A is in SSP debug mode

	Debug Mode Private Key A	Private Key B
	Debug Mode Public Key A	Debug Mode Public Key A
	Public Key B			Public Key B

Feeding those triplets into the formula that will produce the same answer.

Similarly, if device B is in SSP debug mode

	Private Key A			Debug Mode Private Key B
	Public Key A			Public Key A
	Debug Mode Public Key B	Debug Mode Public Key B

Feeding those triplets into the formula that will produce the same answer.

The trick is that when the air sniffer sees either of the debug mode public
keys on the air, it automatically knows the corresponding debug mode private
key for that device. That gives the air sniffer one (or both) of the
triplets that are used by the devices allowing it  (the air sniffer) to
compute the same answer.

----------

So in short, the air sniffer should always see the exchanges that I listed
in the first section of my answer. SSP debug mode lets the air sniffer do
something useful with the data that it collected.

Cheers!

--- tom

problem with ssp debug mode & pand

[Steffen Becker]

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



Am 04.04.2012 10:46, schrieb james.steele@accenture.com:
> If you can run hcidump you should be able to verify that a command is being sent correctly (and completed with a status code 0 ==OK) - you might need the patches I sent to the mailing list to decode the command correctly.
>
> Slave Page refers to the mechanism by which the sniffer follows and joins in with the piconet - I believe it means it tries to look for page requests to the slave device (i.e. the acceptor).  But that is for initiating the sniffing connection; if you can see some LMP in the sniff then you have successfully passed that stage and so Slave Page, Master Inquiry, etc. is not relevant to your problem.
>
> BR,
> James
>
> James Steele
> Accenture Mobility Services
> Cambridge
> Email: james.steele@accenture.com
>
> This message is for the designated recipient only and may contain confidential, privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of this email by you is prohibited.
>
> Communications with Accenture or any of its group companies (“Accenture Group”) including telephone calls and emails (including content), may be monitored by us for the purposes of security and the assessment of internal compliance with company policy. Accenture Group does not accept service by e-mail of court proceedings, other processes or formal notices of any kind.
>
> Accenture means Accenture (UK) Limited (registered number 4757301), Accenture Services Limited (registered number 2633864), or Accenture HR Services Limited (registered number 3957974), all registered in England and Wales with registered addresses at 30 Fenchurch Street, London EC3M 3BD, as the case may be.
>
>
>> From: Steffen Becker [mailto:steffen.becker@tu-ilmenau.de]
>> Sent: 04 April 2012 07:01
>> To: Steele, James
>> Subject: Re: problem with ssp debug mode
>>
>> Hi James,
>>
>> thank you again for your answer!
>> # hciconfig -a hci0 sspdebug 1
>> also didn't work... i think there is a problem using this command. Is
>> there a possibility that i can see if my device is in sspdebug mode or not?
>>
>> And what do you mean with "Slave Page"?
>>
>> Regards,
>> Steffen
>>
>>
>> Am 30.03.2012 16:02, schrieb james.steele@accenture.com:
>>> I think you are missing the '-a' switch on hciconfig for specifying the
>> particular controller to use i.e.
>>> hciconfig -a hci0 sspdebug 1
>>>
>>> If the parameter to the sspdebug mode is invalid it should be errored by
>> the controller.
>>> Also, I normally use the "Slave Page" type of sniffing when using the tool - I
>> don't know if that will make a difference for you.
>>> James Steele
>>> Accenture Mobility Services
>>> Cambridge
>>> Email: james.steele@accenture.com
>>>
>>> Communications with Accenture or any of its group companies (“Accenture
>> Group”) including telephone calls and emails (including content), may be
>> monitored by our systems for the purposes of security and the assessment
>> of internal compliance with company policy.  Accenture Group does not
>> accept service by e-mail of court proceedings, other processes or formal
>> notices of any kind.
>>> Accenture means Accenture (UK) Limited (registered number 4757301),
>> Accenture Technology Solutions Limited (registered number 4442596), or
>> Accenture HR Services Limited (registered number 3957974), all registered in
>> England and Wales with registered addresses at 30 Fenchurch Street, London
>> EC3M 3BD, as the case may be.
>>>
>>>
>>>> -----Original Message-----
>>>> From: Steffen Becker [mailto:steffen.becker@tu-ilmenau.de]
>>>> Sent: 30 March 2012 14:56
>>>> To: Steele, James
>>>> Subject: Re: problem with ssp debug mode
>>>>
>>>> Hi James,
>>>>
>>>> thank you very much for your answer!
>>>>
>>>> Sadly i didn't gain any new information to solve my problem, because i
>>>> tried it both ways (with my BT3.0 devices):
>>>> 1. enable page&   inquiry scan
>>>> 2. start sniffing
>>>> 3. enable sspdebug mode
>>>>        ->   but is "# hciconfig hci0 sspdebug 1" the correct command?
>>>> Because even if i enter "# hciconfig hci0 sspdebug xyz" there is no
>>>> failure message
>>>> 4. connect (via rfcomm)
>>>> ->   connection works, but sniffing failed
>>>>
>>>> alternative:
>>>> 1. enable page&   inquiry scan
>>>> 2. go to /var/lib/bluetooth/<local-bd-addr>/linkkeys
>>>> 3. enter the linkkey in the sniffing software (i even tried EVERY
>>>> linkkey that i found in that path)
>>>> 4. start sniffing
>>>> 5. connect (via rfcomm)
>>>> ->   connection works, but sniffing failed
>>>>
>>>> I think i did everything as you said, did I?
>>>> If yes, i think i have to contact the frontline support again...
>>>>
>>>> Regards,
>>>> Steffen
>>>>
>>>>
>>>> Am 30.03.2012 15:07, schrieb james.steele@accenture.com:
>>>>> Hi Steffen,
>>>>>
>>>>> Sorry not getting back to you sooner, what free time I get at work has
>> been
>>>> spent trying to get the patches I sent to the mailing list into a valid form to
>> be
>>>> committed ☺
>>>>>> The main problem is, that i use a sniffing tool (BPA500) to sniff the
>>>> connection between two Bluetooth3.0-dongles. But the sniffing software
>>>>>> has a problem to capture it. And i think i made a misstake by putting the
>>>> devices in ssp debug mode (because when i sniff two Bluetooth2.0
>>>>>> devices then everything works fine).
>>>>>> That's what i've done:
>>>>>>
>>>>>> I have two gentoo-PCs with two BT3.0 Dongles and i installed on both
>> PCs
>>>> the latest bluez (v4.99)&    your patch "Adding SSP debug mode
>>>>>> configuration to hciconfig" (from March, 19th) and even the second
>> patch
>>>> from March the 28th: "lib: Add HCI write SSP debug mode library
>>>>>> function" and "Adding SSP debug mode configuration to hciconfig."
>>>>>> then i did:
>>>>>> PC2 # hciconfig hci0 piscan
>>>>>> PC1 # hciconfig hci0 piscan
>>>>>> PC1 # hciconfig hci0 sspdebug 1
>>>>>> (in a 2nd try also: PC2 # hciconfig hci0 sspdebug 1)
>>>>>> click on "start sniffing" at the software
>>>>>> PC2 # rfcomm listen 0 1
>>>>>> PC1 # rfcomm -r connect 0<bluetooth-adress>    1
>>>>>>
>>>>>> The two PCs are connected now (as seen on the screens) but the
>> sniffing
>>>> software didn't captured it. Maybe i did something wrong by using
>>>>>> the "sspdebug" command?
>>>>>> It would be great if you can answer me.
>>>>> The reason v2.0 hardware works and v3.0 hardware doesn't relate to
>>>> changes made for Bluetooth v2.1.  A feature called secure simple pairing
>>>> (SSP) was added to improve the security of Bluetooth - part of that
>> mandates
>>>> that (most) Bluetooth logical channels must enable encryption before
>>>> connection.  So with v2.0 hardware as you haven't specified the '-E' option
>>>> then the link will not be encrypted, but with the v3.0 hardware the
>> Bluetooth
>>>> stack is mandated to encrypt the link before proceeding with the
>> connection.
>>>>>            Therefore if you use the -E option with the v2.0 hardware I believe
>> you
>>>> will see the same problem.
>>>>> Sniffers (like Frontline) can decode after encryption, *but* only if they
>>>> know the encryption key that is to be used.  They can acquire this
>>>> information either by observing the pairing process, or by having the link
>> key
>>>> entered manually. (Pairing generates a link key which is used to
>> authenticate
>>>> the link and from which the encryption key is derived).
>>>>> You enter this information normally on a dialog you can get to from the
>>>> dialog that shows the comprobe details (with the red/yellow/green/bluet
>>>> traffic light icon) - it is one of the buttons on there for configuring the
>>>> comprobe (I can't remember the exact text).
>>>>> For v2.0 and earlier - you may have to enter the PIN code into the
>> sniffing
>>>> tool before it is used for the pairing process (the sniffer can then also
>>>> generate the same link key as pairing proceeds).  For v2.1 and later you
>> just
>>>> have to indicate that SSP debug mode is being used (and so you have to
>>>> enable that on at least one of the devices).  Or you can enter the link key -
>> on
>>>> BlueZ you can find it somewhere like
>>>>>            /var/lib/Bluetooth/<BD_ADDR for local hardware>/linkkeys
>>>>> The 16 byte stream follows the BD_ADDR for the remote device the link
>>>> key is associated with.
>>>>> If you have entered this information in the sniffer before the connection
>> is
>>>> made you should be able to see the packets after encryption is enabled.
>>>> There are some "gotchas" though:
>>>>> * Sometimes the sniffer will fail to decode after encryption starts
>> anyway -
>>>> it is just sometimes not that reliable.  The only choice is to just try again.
>>>>> * If the devices are already paired then they do not need to exchange
>>>> information to generate the encryption key (i.e. so it can't be decoded).
>> You
>>>> have to make sure that the pairing occurs while the sniffer is operating
>> (with
>>>> the provided information).  Therefore be sure to "unbond" or "delete
>>>> device" before starting the sniffer and connection each time.
>>>>>            * The sniffer will often remember the key for that session, but I
>> mostly
>>>> always unbond the devices anyway.
>>>>> Cheers,
>>>>> James
>>>>>
>>>>> James Steele
>>>>> Accenture Mobility Services
>>>>> Cambridge
>>>>> Email: james.steele@accenture.com
>>>>>
>>>>> Communications with Accenture or any of its group companies
>> (“Accenture
>>>> Group”) including telephone calls and emails (including content), may be
>>>> monitored by our systems for the purposes of security and the
>> assessment
>>>> of internal compliance with company policy.  Accenture Group does not
>>>> accept service by e-mail of court proceedings, other processes or formal
>>>> notices of any kind.
>>>>> Accenture means Accenture (UK) Limited (registered number 4757301),
>>>> Accenture Technology Solutions Limited (registered number 4442596), or
>>>> Accenture HR Services Limited (registered number 3957974), all registered
>> in
>>>> England and Wales with registered addresses at 30 Fenchurch Street,
>> London
>>>> EC3M 3BD, as the case may be.
>>>>> ________________________________
>>>>> Subject to local law, communications with Accenture and its affiliates
>>>> including telephone calls and emails (including content), may be
>> monitored
>>>> by our systems for the purposes of security and the assessment of
>> internal
>>>> compliance with Accenture policy.
>>>>
>> __________________________________________________________
>>>> ____________________________
>>>>> www.accenture.com
>>> ________________________________
>>> Subject to local law, communications with Accenture and its affiliates
>> including telephone calls and emails (including content), may be monitored
>> by our systems for the purposes of security and the assessment of internal
>> compliance with Accenture policy.
>> __________________________________________________________
>> ____________________________
>>> www.accenture.com
>
> ________________________________
> Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy.
> ______________________________________________________________________________________
>
> www.accenture.com

RE: problem with ssp debug mode & pand

[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
> 
> 
> 
> Am 04.04.2012 10:46, schrieb james.steele@accenture.com:
> > If you can run hcidump you should be able to verify that a command is
> being sent correctly (and completed with a status code 0 ==OK) - you might
> need the patches I sent to the mailing list to decode the command correctly.
> >
> > Slave Page refers to the mechanism by which the sniffer follows and joins
> in with the piconet - I believe it means it tries to look for page requests to the
> slave device (i.e. the acceptor).  But that is for initiating the sniffing
> connection; if you can see some LMP in the sniff then you have successfully
> passed that stage and so Slave Page, Master Inquiry, etc. is not relevant to
> your problem.
> >
> > BR,
> > James
> >
> > James Steele
> > Accenture Mobility Services
> > Cambridge
> > Email: james.steele@accenture.com
> >
> > This message is for the designated recipient only and may contain
> confidential, privileged, proprietary, or otherwise private information. If you
> have received it in error, please notify the sender immediately and delete
> the original. Any other use of this email by you is prohibited.
> >
> > Communications with Accenture or any of its group companies (“Accenture
> Group”) including telephone calls and emails (including content), may be
> monitored by us for the purposes of security and the assessment of internal
> compliance with company policy. Accenture Group does not accept service
> by e-mail of court proceedings, other processes or formal notices of any kind.
> >
> > Accenture means Accenture (UK) Limited (registered number 4757301),
> Accenture Services Limited (registered number 2633864), or Accenture HR
> Services Limited (registered number 3957974), all registered in England and
> Wales with registered addresses at 30 Fenchurch Street, London EC3M 3BD,
> as the case may be.
> >
> >
> >> From: Steffen Becker [mailto:steffen.becker@tu-ilmenau.de]
> >> Sent: 04 April 2012 07:01
> >> To: Steele, James
> >> Subject: Re: problem with ssp debug mode
> >>
> >> Hi James,
> >>
> >> thank you again for your answer!
> >> # hciconfig -a hci0 sspdebug 1
> >> also didn't work... i think there is a problem using this command. Is
> >> there a possibility that i can see if my device is in sspdebug mode or not?
> >>
> >> And what do you mean with "Slave Page"?
> >>
> >> Regards,
> >> Steffen
> >>
> >>
> >> Am 30.03.2012 16:02, schrieb james.steele@accenture.com:
> >>> I think you are missing the '-a' switch on hciconfig for specifying
> >>> the
> >> particular controller to use i.e.
> >>> hciconfig -a hci0 sspdebug 1
> >>>
> >>> If the parameter to the sspdebug mode is invalid it should be
> >>> errored by
> >> the controller.
> >>> Also, I normally use the "Slave Page" type of sniffing when using
> >>> the tool - I
> >> don't know if that will make a difference for you.
> >>> James Steele
> >>> Accenture Mobility Services
> >>> Cambridge
> >>> Email: james.steele@accenture.com
> >>>
> >>> Communications with Accenture or any of its group companies
> >>> (“Accenture
> >> Group”) including telephone calls and emails (including content), may
> >> be monitored by our systems for the purposes of security and the
> >> assessment of internal compliance with company policy.  Accenture
> >> Group does not accept service by e-mail of court proceedings, other
> >> processes or formal notices of any kind.
> >>> Accenture means Accenture (UK) Limited (registered number 4757301),
> >> Accenture Technology Solutions Limited (registered number 4442596),
> >> or Accenture HR Services Limited (registered number 3957974), all
> >> registered in England and Wales with registered addresses at 30
> >> Fenchurch Street, London EC3M 3BD, as the case may be.
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Steffen Becker [mailto:steffen.becker@tu-ilmenau.de]
> >>>> Sent: 30 March 2012 14:56
> >>>> To: Steele, James
> >>>> Subject: Re: problem with ssp debug mode
> >>>>
> >>>> Hi James,
> >>>>
> >>>> thank you very much for your answer!
> >>>>
> >>>> Sadly i didn't gain any new information to solve my problem,
> >>>> because i tried it both ways (with my BT3.0 devices):
> >>>> 1. enable page&   inquiry scan
> >>>> 2. start sniffing
> >>>> 3. enable sspdebug mode
> >>>>        ->   but is "# hciconfig hci0 sspdebug 1" the correct command?
> >>>> Because even if i enter "# hciconfig hci0 sspdebug xyz" there is no
> >>>> failure message 4. connect (via rfcomm)
> >>>> ->   connection works, but sniffing failed
> >>>>
> >>>> alternative:
> >>>> 1. enable page&   inquiry scan
> >>>> 2. go to /var/lib/bluetooth/<local-bd-addr>/linkkeys
> >>>> 3. enter the linkkey in the sniffing software (i even tried EVERY
> >>>> linkkey that i found in that path) 4. start sniffing 5. connect
> >>>> (via rfcomm)
> >>>> ->   connection works, but sniffing failed
> >>>>
> >>>> I think i did everything as you said, did I?
> >>>> If yes, i think i have to contact the frontline support again...
> >>>>
> >>>> Regards,
> >>>> Steffen
> >>>>
> >>>>
> >>>> Am 30.03.2012 15:07, schrieb james.steele@accenture.com:
> >>>>> Hi Steffen,
> >>>>>
> >>>>> Sorry not getting back to you sooner, what free time I get at work
> >>>>> has
> >> been
> >>>> spent trying to get the patches I sent to the mailing list into a
> >>>> valid form to
> >> be
> >>>> committed ☺
> >>>>>> The main problem is, that i use a sniffing tool (BPA500) to sniff
> >>>>>> the
> >>>> connection between two Bluetooth3.0-dongles. But the sniffing
> >>>> software
> >>>>>> has a problem to capture it. And i think i made a misstake by
> >>>>>> putting the
> >>>> devices in ssp debug mode (because when i sniff two Bluetooth2.0
> >>>>>> devices then everything works fine).
> >>>>>> That's what i've done:
> >>>>>>
> >>>>>> I have two gentoo-PCs with two BT3.0 Dongles and i installed on
> >>>>>> both
> >> PCs
> >>>> the latest bluez (v4.99)&    your patch "Adding SSP debug mode
> >>>>>> configuration to hciconfig" (from March, 19th) and even the
> >>>>>> second
> >> patch
> >>>> from March the 28th: "lib: Add HCI write SSP debug mode library
> >>>>>> function" and "Adding SSP debug mode configuration to hciconfig."
> >>>>>> then i did:
> >>>>>> PC2 # hciconfig hci0 piscan
> >>>>>> PC1 # hciconfig hci0 piscan
> >>>>>> PC1 # hciconfig hci0 sspdebug 1
> >>>>>> (in a 2nd try also: PC2 # hciconfig hci0 sspdebug 1) click on
> >>>>>> "start sniffing" at the software
> >>>>>> PC2 # rfcomm listen 0 1
> >>>>>> PC1 # rfcomm -r connect 0<bluetooth-adress>    1
> >>>>>>
> >>>>>> The two PCs are connected now (as seen on the screens) but the
> >> sniffing
> >>>> software didn't captured it. Maybe i did something wrong by using
> >>>>>> the "sspdebug" command?
> >>>>>> It would be great if you can answer me.
> >>>>> The reason v2.0 hardware works and v3.0 hardware doesn't relate to
> >>>> changes made for Bluetooth v2.1.  A feature called secure simple
> >>>> pairing
> >>>> (SSP) was added to improve the security of Bluetooth - part of that
> >> mandates
> >>>> that (most) Bluetooth logical channels must enable encryption
> >>>> before connection.  So with v2.0 hardware as you haven't specified
> >>>> the '-E' option then the link will not be encrypted, but with the
> >>>> v3.0 hardware the
> >> Bluetooth
> >>>> stack is mandated to encrypt the link before proceeding with the
> >> connection.
> >>>>>            Therefore if you use the -E option with the v2.0
> >>>>> hardware I believe
> >> you
> >>>> will see the same problem.
> >>>>> Sniffers (like Frontline) can decode after encryption, *but* only
> >>>>> if they
> >>>> know the encryption key that is to be used.  They can acquire this
> >>>> information either by observing the pairing process, or by having
> >>>> the link
> >> key
> >>>> entered manually. (Pairing generates a link key which is used to
> >> authenticate
> >>>> the link and from which the encryption key is derived).
> >>>>> You enter this information normally on a dialog you can get to
> >>>>> from the
> >>>> dialog that shows the comprobe details (with the
> >>>> red/yellow/green/bluet traffic light icon) - it is one of the
> >>>> buttons on there for configuring the comprobe (I can't remember the
> exact text).
> >>>>> For v2.0 and earlier - you may have to enter the PIN code into the
> >> sniffing
> >>>> tool before it is used for the pairing process (the sniffer can
> >>>> then also generate the same link key as pairing proceeds).  For
> >>>> v2.1 and later you
> >> just
> >>>> have to indicate that SSP debug mode is being used (and so you have
> >>>> to enable that on at least one of the devices).  Or you can enter
> >>>> the link key -
> >> on
> >>>> BlueZ you can find it somewhere like
> >>>>>            /var/lib/Bluetooth/<BD_ADDR for local
> >>>>> hardware>/linkkeys The 16 byte stream follows the BD_ADDR for the
> >>>>> remote device the link
> >>>> key is associated with.
> >>>>> If you have entered this information in the sniffer before the
> >>>>> connection
> >> is
> >>>> made you should be able to see the packets after encryption is
> enabled.
> >>>> There are some "gotchas" though:
> >>>>> * Sometimes the sniffer will fail to decode after encryption
> >>>>> starts
> >> anyway -
> >>>> it is just sometimes not that reliable.  The only choice is to just try again.
> >>>>> * If the devices are already paired then they do not need to
> >>>>> exchange
> >>>> information to generate the encryption key (i.e. so it can't be
> decoded).
> >> You
> >>>> have to make sure that the pairing occurs while the sniffer is
> >>>> operating
> >> (with
> >>>> the provided information).  Therefore be sure to "unbond" or
> >>>> "delete device" before starting the sniffer and connection each time.
> >>>>>            * The sniffer will often remember the key for that
> >>>>> session, but I
> >> mostly
> >>>> always unbond the devices anyway.
> >>>>> Cheers,
> >>>>> James
> >>>>>
> >>>>> James Steele
> >>>>> Accenture Mobility Services
> >>>>> Cambridge
> >>>>> Email: james.steele@accenture.com
> >>>>>
> >>>>> Communications with Accenture or any of its group companies
> >> (“Accenture
> >>>> Group”) including telephone calls and emails (including content),
> >>>> may be monitored by our systems for the purposes of security and
> >>>> the
> >> assessment
> >>>> of internal compliance with company policy.  Accenture Group does
> >>>> not accept service by e-mail of court proceedings, other processes
> >>>> or formal notices of any kind.
> >>>>> Accenture means Accenture (UK) Limited (registered number
> >>>>> 4757301),
> >>>> Accenture Technology Solutions Limited (registered number 4442596),
> >>>> or Accenture HR Services Limited (registered number 3957974), all
> >>>> registered
> >> in
> >>>> England and Wales with registered addresses at 30 Fenchurch Street,
> >> London
> >>>> EC3M 3BD, as the case may be.
> >>>>> ________________________________
> >>>>> Subject to local law, communications with Accenture and its
> >>>>> affiliates
> >>>> including telephone calls and emails (including content), may be
> >> monitored
> >>>> by our systems for the purposes of security and the assessment of
> >> internal
> >>>> compliance with Accenture policy.
> >>>>
> >>
> __________________________________________________________
> >>>> ____________________________
> >>>>> www.accenture.com
> >>> ________________________________
> >>> Subject to local law, communications with Accenture and its
> >>> affiliates
> >> including telephone calls and emails (including content), may be
> >> monitored by our systems for the purposes of security and the
> >> assessment of internal compliance with Accenture policy.
> >>
> __________________________________________________________
> >> ____________________________
> >>> www.accenture.com
> >
> > ________________________________
> > Subject to local law, communications with Accenture and its affiliates
> including telephone calls and emails (including content), may be monitored
> by our systems for the purposes of security and the assessment of internal
> compliance with Accenture policy.
> >
> __________________________________________________________
> ____________
> > ________________
> >
> > www.accenture.com
> 
> --
> 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

Re: problem with ssp debug mode & pand

[Steffen Becker]

Thanks,
but:
a)
How can I change my security configuration for bnep?

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

Re: problem with ssp debug mode & pand

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

RE: problem with ssp debug mode & pand

[Tom Allebrandi]

That is correct behavior. 

SSP Debug Mode was created specifically to allow people to use air sniffers.

Unfortunately, there is no way to know when you are being sniffed, meaning that there is also no way to know if a person who might be sniffing is a friend or foe. SSP Debug Mode defeats the reasons that SSP was created in the first place, so there are some strings attached.

One of those strings is that the debug link keys that result from SSP Debug Mode are not supposed to be persistent. If a host has a debug key in hand that has already been used for LMP Authentication, it is supposed to discard it and pair again.

Debug link keys should always be considered insecure since you don't know who might have been listening during a Debug Mode pairing.

So, you need to always run with SSP Debug Mode enabled, or pair the devices once and enter the link key into the air sniffer.

Cheers!

--- tom

> -----Original Message-----
> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-
> owner@vger.kernel.org] On Behalf Of Steffen Becker
> Sent: Thursday, April 05, 2012 6:04 AM
> To: wyrles@ytram.com
> Cc: linux-bluetooth@vger.kernel.org
> Subject: Re: problem with ssp debug mode & pand
> 
> 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

Re: problem with ssp debug mode & pand

[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

Re: problem with ssp debug mode & pand

[Steffen Becker]

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