Re: [PATCH 2/8] Bluetooth: Add a custom type for Short Term Keys

[Brian Gix <bgix@codeaurora.org>]

Hi Johan, Vinicius,

On 11/11/2011 8:55 AM, Brian Gix wrote:
> On 11/10/2011 5:03 PM, Vinicius Costa Gomes wrote:
>> These keys are just used to encrypt the link, during SMP phase 2, they
>> should
>> not be stored nor reused. We use the same list as the LTKs to
>> temporarily store
>> them, but as soon as they are used they are removed from the list.
>>
>> Signed-off-by: Vinicius Costa Gomes<vinicius.gomes@openbossa.org>
>> ---
>> include/net/bluetooth/hci.h | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
>> index 139ce2a..069768c 100644
>> --- a/include/net/bluetooth/hci.h
>> +++ b/include/net/bluetooth/hci.h
>> @@ -260,6 +260,7 @@ enum {
>> #define HCI_LK_AUTH_COMBINATION 0x05
>> #define HCI_LK_CHANGED_COMBINATION 0x06
>> /* The spec doesn't define types for SMP keys */
>> +#define HCI_LK_SMP_STK 0x80
>> #define HCI_LK_SMP_LTK 0x81
>> #define HCI_LK_SMP_IRK 0x82
>> #define HCI_LK_SMP_CSRK 0x83
>
>
> At some point, we will also need to expand this list to include key
> types for both Initiator and Responder (or rather, keys Locally
> generated, and keys Remotely generated). Although there are 3 base types
> of LE keys (4 if you count the STK), there are in fact 6 different keys
> for different situations (7 if you count STK).
>
> LTKs might be considered an exception, since most devices will only ever
> be a Master or a Slave, and IRKs will often only need to be saved for
> remote privacy supporting peripherals, if the local side does not use
> privacy.
>
> However, for the CSRKs, I suspect that we will need to strongly
> differentiate between Locally and Remotely generated signing keys. If we
> have a server with a "Signed Write Cmd" Characteristic and the remote
> device has one too, we will need to sign the outbound Write Cmds with
> the key the remote side distributed to us, and they will use the key
> that we sent them, so we need to keep them separate.
>
> And once you start down that path, you should at least consider the
> possibility of needing to distinguish between remote and local LTKs and
> IRKs as well. STKs at least do not have that problem: them are jointly
> derived.
>
> Should we add _LCL_ and _REM_ to the naming conventions, and expand the
> enumeration out to 0x86?
>

I am including Johan in for this:
We also may want to expand or add an interface to MGMT to specify which 
keys we can Generate and Accept during LE pairing.  Obviously at this 
point, I think this would be set to Generating No keys (if we are 
Master, and Central) and accepting only the LTK (reverse that if we are 
LE slaves).

Looking towards the future, the keys distributed will depend very much 
on what the User space (bluez) entities are able to support.


-- 
Brian Gix
bgix@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum