[PATCH] Bluetooth: Auth combination keys should be stored permanently

[PATCH] Bluetooth: Auth combination keys should be stored permanently

[Vishal Agarwal]

If either local or remote device auth type is general bonding
(for ex. if local auth type is 0 but remote auth type is 5) then it
will result in link key of type authenticated link key. Which according
to spec should be stored for future use. So in case of key type
HCI_LK_AUTH_COMBINATION true should be return.

Signed-off-by: Vishal Agarwal <vishal.agarwal@stericsson.com>
---
 net/bluetooth/hci_core.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index c4dc263..e5fcb29 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1250,6 +1250,10 @@ static bool hci_persistent_key(struct hci_dev *hdev, struct hci_conn *conn,
 	if (conn->remote_auth == 0x02 || conn->remote_auth == 0x03)
 		return true;
 
+	/*If Key type is Authenticated combination key then store it*/
+	if (key_type == HCI_LK_AUTH_COMBINATION)
+		return true;
+
 	/* If none of the above criteria match, then don't store the key
 	 * persistently */
 	return false;
-- 
1.7.0.4

Re: [PATCH] Bluetooth: Auth combination keys should be stored permanently

[Johan Hedberg]

Hi Vishal,

On Tue, Apr 17, 2012, Vishal Agarwal wrote:
> If either local or remote device auth type is general bonding
> (for ex. if local auth type is 0 but remote auth type is 5) then it
> will result in link key of type authenticated link key. Which according
> to spec should be stored for future use.

You'll need to give some precise references into the core specification
about where you think it says this since I think you are a bit confused
here. I'd also advice you to carefully read section 5.2.2.6 on page 1668
and table 5.6 on page 1669. Those describe how the IO capabilities
(note: *not* authentication requirements) map to the resulting key type.
The only case where the auth requirements affect the key type is if
neither side has the MITM bit set (in which case you get an
unauthenticated key).

In your example with the local auth requirement being 0, meaning no
bonding, the spec says this (section 6.5.3.1, page 1680):

"'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."

I.e. if we have 0 it means that we do not intend to store the key and
hci_persistent_key should return false. The key type otoh tells us
nothing about the authentication requirement. You can get an
authenticated combination key with no-bonding, dedicated bonding
as well as with general bonding.

Johan

Re: [PATCH] Bluetooth: Auth combination keys should be stored permanently

[vishal agarwal]

Hi Johan,

On 4/17/12, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Vishal,
>
> On Tue, Apr 17, 2012, Vishal Agarwal wrote:
>> If either local or remote device auth type is general bonding
>> (for ex. if local auth type is 0 but remote auth type is 5) then it
>> will result in link key of type authenticated link key. Which according
>> to spec should be stored for future use.
>
> You'll need to give some precise references into the core specification
> about where you think it says this since I think you are a bit confused
> here. I'd also advice you to carefully read section 5.2.2.6 on page 1668
> and table 5.6 on page 1669. Those describe how the IO capabilities
> (note: *not* authentication requirements) map to the resulting key type.
> The only case where the auth requirements affect the key type is if
> neither side has the MITM bit set (in which case you get an
> unauthenticated key).
>
> In your example with the local auth requirement being 0, meaning no
> bonding, the spec says this (section 6.5.3.1, page 1680):
>
> "'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."
>
> I.e. if we have 0 it means that we do not intend to store the key and
> hci_persistent_key should return false. The key type otoh tells us
> nothing about the authentication requirement. You can get an
> authenticated combination key with no-bonding, dedicated bonding
> as well as with general bonding.
>
Thanks for your comments -
I will try to modify a bit my example

Local device -
Auth type = 5 (MITM with general bonding)
iocapability = DisplayYesNo

Remote device -
Auth type = 0 (No MITM)
iocapability = DisplayYesNo

Now as one of the device supports MITM, key type will be determined by
the table at 1669(table number 5.6). and also as both devices support
DisplayYesNo key type will be Authenticated. And also as local auth type
is not 'no bonding' should'nt we try to store the key? or because remote is
saying 'no bonding' we will also not store the key.

correct me if I am wrong, Spec is not saying that we should not store
the key if auth type is 'No bonding'. 'No bonding' is used when we do not want
to store the key. But because remote requested MITM and also supports required
capabilities link key generated is Authenticated. And if we store the
link key we will
avoid future pairing. If both the devices requested 'No Bonding' then
we will not store
the key.
> Johan
> --
> 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
>

Thanks
Vishal

Re: [PATCH] Bluetooth: Auth combination keys should be stored permanently

[Johan Hedberg]

Hi Vishal,

On Tue, Apr 17, 2012, vishal agarwal wrote:
> > On Tue, Apr 17, 2012, Vishal Agarwal wrote:
> >> If either local or remote device auth type is general bonding
> >> (for ex. if local auth type is 0 but remote auth type is 5) then it
> >> will result in link key of type authenticated link key. Which according
> >> to spec should be stored for future use.
> >
> > You'll need to give some precise references into the core specification
> > about where you think it says this since I think you are a bit confused
> > here. I'd also advice you to carefully read section 5.2.2.6 on page 1668
> > and table 5.6 on page 1669. Those describe how the IO capabilities
> > (note: *not* authentication requirements) map to the resulting key type.
> > The only case where the auth requirements affect the key type is if
> > neither side has the MITM bit set (in which case you get an
> > unauthenticated key).
> >
> > In your example with the local auth requirement being 0, meaning no
> > bonding, the spec says this (section 6.5.3.1, page 1680):
> >
> > "'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."
> >
> > I.e. if we have 0 it means that we do not intend to store the key and
> > hci_persistent_key should return false. The key type otoh tells us
> > nothing about the authentication requirement. You can get an
> > authenticated combination key with no-bonding, dedicated bonding
> > as well as with general bonding.
> >
> Thanks for your comments -
> I will try to modify a bit my example
> 
> Local device -
> Auth type = 5 (MITM with general bonding)
> iocapability = DisplayYesNo
> 
> Remote device -
> Auth type = 0 (No MITM)
> iocapability = DisplayYesNo
> 
> Now as one of the device supports MITM, key type will be determined by
> the table at 1669(table number 5.6). and also as both devices support
> DisplayYesNo key type will be Authenticated. And also as local auth type
> is not 'no bonding' should'nt we try to store the key? or because remote is
> saying 'no bonding' we will also not store the key.
> 
> correct me if I am wrong, Spec is not saying that we should not store
> the key if auth type is 'No bonding'. 'No bonding' is used when we do not want
> to store the key. But because remote requested MITM and also supports required
> capabilities link key generated is Authenticated. And if we store the
> link key we will
> avoid future pairing. If both the devices requested 'No Bonding' then
> we will not store
> the key.

As I quoted the spec says that a device which has no-bonding "does not
intend to retain the link key after the physical link is disconnected".

If one side doesn't store the key it makes no sense for the other side
to do so either as it couldn't be used for anything in subsequent
connections and this is why the logic is as it is.

Johan