Hello All,
?I am facing some problem with SSP pairing.
Sometimes Bluez does not store the Authenticated Combination link key
generated during pairing process And found the below code in
dbus-hci.c
hci_dbus_link_key_notify
/* Only store the link key if one of the following is true:
??? ?* 1. this is a legacy link key
??? ?* 2. this is a changed combination key and there was a previously
??? ?*??? stored one
??? ?* 3. neither local nor remote side had no-bonding as a requirement
??? ?* 4. the local side had dedicated bonding as a requirement
??? ?* 5. the remote side is using dedicated bonding since in that case
??? ?*??? also the local requirements are set to dedicated bonding
??? ?*/
And from the logs found that, Bluez sets the Auth requirement as "no
bonding" and remote device sets the auth requirement as "General
Bonding", as a result of this pairing process "Authenticated
combination key" has been generated but not stored because of the
above mentioned check. Hence for the reconnection or other profile
connections, Bluez would re initiate the pairing process which User
would not like.
Usecase:
Remote device was not paired, I initiated a2dp connection through dbus
commands to remote device, hence the l2cap security level is low and
auth requirement is set as "No Bonding" at kernel.
I could not find Specification points for this behavior.
Can some body explain why Bluez has this check (based on some
specification?) while storing link key.
Thanks,
Prabhakaran.
Hi,
Basically the reasoning behind all this in the specification is that there is no point in saving the link key on only one side at pairing.
Next connection would then fail anyway.
I agree with Waldemar, this is correct behavior by BlueZ.
Best regards,
Par-Gunnar Hjalmdahl, ST-Ericsson
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of [email protected]
Sent: den 15 juli 2010 10:57
To: [email protected]; [email protected]
Cc: [email protected]
Subject: RE: SSP Link key storing issue
Hi,
From: [email protected] [mailto:[email protected]] On Behalf Of Luiz Augusto von Dentz
>Hi,
>On Thu, Jul 15, 2010 at 9:38 AM, Prabhakaran Chandrasekara M <[email protected]> wrote:
> Can some body please explain why the below check is considered while
> storing link key.
>
>
> On Thu, Jul 15, 2010 at 10:25 AM, Prabhakaran Chandrasekara M
> <[email protected]> wrote:
>> Hello All,
>>
>> ?I am facing some problem with SSP pairing.
>> Sometimes Bluez does not store the Authenticated Combination link key
>> generated during pairing process And found the below code in
>> dbus-hci.c hci_dbus_link_key_notify
>>
>> /* Only store the link key if one of the following is true:
>> ??? ?* 1. this is a legacy link key
>> ??? ?* 2. this is a changed combination key and there was a
>> previously
>> ??? ?*??? stored one
>> ??? ?* 3. neither local nor remote side had no-bonding as a
>> requirement
>> ??? ?* 4. the local side had dedicated bonding as a requirement
>> ??? ?* 5. the remote side is using dedicated bonding since in that
>> case
>> ??? ?*??? also the local requirements are set to dedicated bonding
>> ??? ?*/
> don;t know exactly which page, but the spec says that when one side has no-bonding, I guess 3. is about that, then the link key should not be stored. Also a2dp connection should be using medium security as we do in bluetoothd (it is the default when using BtIO) then you will got >the link key stored properly.
In the spec 2.1 is not clearly stated, but it was explained in the errara to the GAP 2.1
https://www.bluetooth.org/errata/errata_view.cfm?errata_id=2460
You can see also spec to core 3.0 in 6.5.3.1 chapter which says
"When the devices that are performing General Bonding both support Secure
Simple Pairing, the Authentication_Requirements parameter should be set to
MITM Protection Not Required - General Bonding unless the security policy of
an available local service requires MITM Protection in which case the
Authentication_Requirements parameter shall be set to MITM Protection
Required - General Bonding. 'No bonding' is used when the device is performing
a Secure Simple Pairing procedure, but does not intend to retain the link
key after the physical link is disconnected."
In general, this is correct behaviour of Bluez.
Thanks,
Waldek-
Hi,
From: [email protected] [mailto:[email protected]] On Behalf Of Luiz Augusto von Dentz
>Hi,
>On Thu, Jul 15, 2010 at 9:38 AM, Prabhakaran Chandrasekara M <[email protected]> wrote:
> Can some body please explain why the below check is considered while
> storing link key.
>
>
> On Thu, Jul 15, 2010 at 10:25 AM, Prabhakaran Chandrasekara M
> <[email protected]> wrote:
>> Hello All,
>>
>> ?I am facing some problem with SSP pairing.
>> Sometimes Bluez does not store the Authenticated Combination link key
>> generated during pairing process And found the below code in
>> dbus-hci.c hci_dbus_link_key_notify
>>
>> /* Only store the link key if one of the following is true:
>> ??? ?* 1. this is a legacy link key
>> ??? ?* 2. this is a changed combination key and there was a
>> previously
>> ??? ?*??? stored one
>> ??? ?* 3. neither local nor remote side had no-bonding as a
>> requirement
>> ??? ?* 4. the local side had dedicated bonding as a requirement
>> ??? ?* 5. the remote side is using dedicated bonding since in that
>> case
>> ??? ?*??? also the local requirements are set to dedicated bonding
>> ??? ?*/
> don;t know exactly which page, but the spec says that when one side has no-bonding, I guess 3. is about that, then the link key should not be stored. Also a2dp connection should be using medium security as we do in bluetoothd (it is the default when using BtIO) then you will got >the link key stored properly.
In the spec 2.1 is not clearly stated, but it was explained in the errara to the GAP 2.1
https://www.bluetooth.org/errata/errata_view.cfm?errata_id=2460
You can see also spec to core 3.0 in 6.5.3.1 chapter which says
"When the devices that are performing General Bonding both support Secure
Simple Pairing, the Authentication_Requirements parameter should be set to
MITM Protection Not Required - General Bonding unless the security policy of
an available local service requires MITM Protection in which case the
Authentication_Requirements parameter shall be set to MITM Protection
Required - General Bonding. 'No bonding' is used when the device is performing
a Secure Simple Pairing procedure, but does not intend to retain the link
key after the physical link is disconnected."
In general, this is correct behaviour of Bluez.
Thanks,
Waldek
Hi,
On Thu, Jul 15, 2010 at 9:38 AM, Prabhakaran Chandrasekara M
<[email protected]> wrote:
> Can some body please explain why the below check is considered while
> storing link key.
>
>
> On Thu, Jul 15, 2010 at 10:25 AM, Prabhakaran Chandrasekara M
> <[email protected]> wrote:
>> Hello All,
>>
>> ?I am facing some problem with SSP pairing.
>> Sometimes Bluez does not store the Authenticated Combination link key
>> generated during pairing process And found the below code in
>> dbus-hci.c
>> hci_dbus_link_key_notify
>>
>> /* Only store the link key if one of the following is true:
>> ??? ?* 1. this is a legacy link key
>> ??? ?* 2. this is a changed combination key and there was a previously
>> ??? ?*??? stored one
>> ??? ?* 3. neither local nor remote side had no-bonding as a requirement
>> ??? ?* 4. the local side had dedicated bonding as a requirement
>> ??? ?* 5. the remote side is using dedicated bonding since in that case
>> ??? ?*??? also the local requirements are set to dedicated bonding
>> ??? ?*/
I don;t know exactly which page, but the spec says that when one side
has no-bonding, I guess 3. is about that, then the link key should not
be stored. Also a2dp connection should be using medium security as we
do in bluetoothd (it is the default when using BtIO) then you will got
the link key stored properly.
--
Luiz Augusto von Dentz
Computer Engineer
Can some body please explain why the below check is considered while
storing link key.
On Thu, Jul 15, 2010 at 10:25 AM, Prabhakaran Chandrasekara M
<[email protected]> wrote:
> Hello All,
>
> ?I am facing some problem with SSP pairing.
> Sometimes Bluez does not store the Authenticated Combination link key
> generated during pairing process And found the below code in
> dbus-hci.c
> hci_dbus_link_key_notify
>
> /* Only store the link key if one of the following is true:
> ??? ?* 1. this is a legacy link key
> ??? ?* 2. this is a changed combination key and there was a previously
> ??? ?*??? stored one
> ??? ?* 3. neither local nor remote side had no-bonding as a requirement
> ??? ?* 4. the local side had dedicated bonding as a requirement
> ??? ?* 5. the remote side is using dedicated bonding since in that case
> ??? ?*??? also the local requirements are set to dedicated bonding
> ??? ?*/
>
> And from the logs found that, Bluez sets the Auth requirement as "no
> bonding" and remote device sets the auth requirement as "General
> Bonding", as a result of this pairing process "Authenticated
> combination key" has been generated but not stored because of the
> above mentioned check.
(* 3. neither local nor remote side had no-bonding as a requirement)
Forgot mention the Check.
>Hence for the reconnection or other profile
> connections, Bluez would re initiate the pairing process which User
> would not like.
>
> Usecase:
> Remote device was not paired, I initiated a2dp connection through dbus
> commands to remote device, hence the l2cap security level is low and
> auth requirement is set as "No Bonding" at kernel.
>
>
> I could not find Specification points for this behavior.
>
> Can some body explain why Bluez has this check (based on some
> specification?) while storing link key.
>
> Thanks,
> Prabhakaran.
>
Thanks,
Prabhakaran.