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

[Johan Hedberg <johan.hedberg@gmail.com>]

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