DBus API for LTK OOB keys

DBus API for LTK OOB keys

[Andrejs Hanins]

Hello,

     There is a MGMT "Load Long Term Keys Command" to feed keys to the 
Kernel which are stored in the BlueZ settings storage file and read 
during adapter init (load_devices->load_ltks). I searched through the 
code and couldn't find any means to feed LTK keys from "the outside", 
for example through DBus API. This is needed for an LE OOB pairing 
scheme, when key is known in advance by both parties and is not derived 
from pairing procedure. Is there a standardized way to add LTK keys 
"manually" or this is not supported-yet feature? According to setting 
storage rules "Direct access to the storage outside from bluetoothd is 
highly discouraged".

BR, Andrey

Re: DBus API for LTK OOB keys

[Johan Hedberg]

Hi Andrejs,

On Thu, Mar 05, 2015, Andrejs Hanins wrote:
>     There is a MGMT "Load Long Term Keys Command" to feed keys to the Kernel
> which are stored in the BlueZ settings storage file and read during adapter
> init (load_devices->load_ltks). I searched through the code and couldn't
> find any means to feed LTK keys from "the outside", for example through DBus
> API. This is needed for an LE OOB pairing scheme, when key is known in
> advance by both parties and is not derived from pairing procedure. Is there
> a standardized way to add LTK keys "manually" or this is not supported-yet
> feature? According to setting storage rules "Direct access to the storage
> outside from bluetoothd is highly discouraged".

Are the keys provisioned beforehand or is this something that can happen
at any time when bluetoothd is already running? If it's the former then
a custom bluetoothd plugin that gives bluetoothd core an extra set of
keys could be one way to go. If it's the latter, then things get tricky
since the mgmt command wipes all existing keys away before adding new
ones.

If your OOB scheme is this latter "non-pre-provisioned" one I'd wonder
why you're not using the standard OOB mechanism provided by LE SMP,
since for that we do have at least partial support.

Johan

Re: DBus API for LTK OOB keys

[Andrejs Hanins]

Hi Johan,

On 2015.03.05. 15:40, Johan Hedberg wrote:
> Hi Andrejs,
>
> On Thu, Mar 05, 2015, Andrejs Hanins wrote:
>>      There is a MGMT "Load Long Term Keys Command" to feed keys to the Kernel
>> which are stored in the BlueZ settings storage file and read during adapter
>> init (load_devices->load_ltks). I searched through the code and couldn't
>> find any means to feed LTK keys from "the outside", for example through DBus
>> API. This is needed for an LE OOB pairing scheme, when key is known in
>> advance by both parties and is not derived from pairing procedure. Is there
>> a standardized way to add LTK keys "manually" or this is not supported-yet
>> feature? According to setting storage rules "Direct access to the storage
>> outside from bluetoothd is highly discouraged".
> Are the keys provisioned beforehand or is this something that can happen
> at any time when bluetoothd is already running? If it's the former then
> a custom bluetoothd plugin that gives bluetoothd core an extra set of
> keys could be one way to go. If it's the latter, then things get tricky
> since the mgmt command wipes all existing keys away before adding new
> ones.
In my particular scenario, the OOB key is provisioned only once and 
beforehand and used to connect with multiple LE devices. LE devices get 
this key via some proprietary mechanism. So it is kind of "global master 
key". As such, it is not a problem to restart the BlueZ daemon after the 
key is (re-)provisioned.
>
> If your OOB scheme is this latter "non-pre-provisioned" one I'd wonder
> why you're not using the standard OOB mechanism provided by LE SMP,
> since for that we do have at least partial support.
I'm now confused a bit. Indeed, I want to use OOB mechanism provided by 
LE SMP, but in order to start OOB pairing, the OOB key itself should be 
known to both sides (central and peripheral). For the peripheral I have 
my own ways to do it (proprietary), but the main question it how to give 
the key value to the central which is BlueZ in this case.
>
> Johan

Re: DBus API for LTK OOB keys

[Marcel Holtmann]

Hi Andrejs,

>>>     There is a MGMT "Load Long Term Keys Command" to feed keys to the Kernel
>>> which are stored in the BlueZ settings storage file and read during adapter
>>> init (load_devices->load_ltks). I searched through the code and couldn't
>>> find any means to feed LTK keys from "the outside", for example through DBus
>>> API. This is needed for an LE OOB pairing scheme, when key is known in
>>> advance by both parties and is not derived from pairing procedure. Is there
>>> a standardized way to add LTK keys "manually" or this is not supported-yet
>>> feature? According to setting storage rules "Direct access to the storage
>>> outside from bluetoothd is highly discouraged".
>> Are the keys provisioned beforehand or is this something that can happen
>> at any time when bluetoothd is already running? If it's the former then
>> a custom bluetoothd plugin that gives bluetoothd core an extra set of
>> keys could be one way to go. If it's the latter, then things get tricky
>> since the mgmt command wipes all existing keys away before adding new
>> ones.
> In my particular scenario, the OOB key is provisioned only once and beforehand and used to connect with multiple LE devices. LE devices get this key via some proprietary mechanism. So it is kind of "global master key". As such, it is not a problem to restart the BlueZ daemon after the key is (re-)provisioned.

using the same LTK for multi devices is a really bad idea. This is not how Bluetooth LE security was designed. My advise would be strictly against doing that in any product.

>> If your OOB scheme is this latter "non-pre-provisioned" one I'd wonder
>> why you're not using the standard OOB mechanism provided by LE SMP,
>> since for that we do have at least partial support.
> I'm now confused a bit. Indeed, I want to use OOB mechanism provided by LE SMP, but in order to start OOB pairing, the OOB key itself should be known to both sides (central and peripheral). For the peripheral I have my own ways to do it (proprietary), but the main question it how to give the key value to the central which is BlueZ in this case.

When using LE OOB pairing (Legacy Pairing and Secure Connections), then at least you get a sense of key strength that is guaranteed based on how LE security is designed. So doing LE OOB pairing is a good idea. You feed different information into OOB pairing. You share and OOB secret between two devices and based on that they can pair. However they need to be in range to actually use that OOB secret to pair. Pairing requires a connection. The advantage with pairing is that you get a proper key with a proper strength.

Regards

Marcel

Re: DBus API for LTK OOB keys

[Andrejs Hanins]

Hi Marcel,

On 2015.03.05. 16:55, Marcel Holtmann wrote:
> Hi Andrejs,
>
>>>>      There is a MGMT "Load Long Term Keys Command" to feed keys to the Kernel
>>>> which are stored in the BlueZ settings storage file and read during adapter
>>>> init (load_devices->load_ltks). I searched through the code and couldn't
>>>> find any means to feed LTK keys from "the outside", for example through DBus
>>>> API. This is needed for an LE OOB pairing scheme, when key is known in
>>>> advance by both parties and is not derived from pairing procedure. Is there
>>>> a standardized way to add LTK keys "manually" or this is not supported-yet
>>>> feature? According to setting storage rules "Direct access to the storage
>>>> outside from bluetoothd is highly discouraged".
>>> Are the keys provisioned beforehand or is this something that can happen
>>> at any time when bluetoothd is already running? If it's the former then
>>> a custom bluetoothd plugin that gives bluetoothd core an extra set of
>>> keys could be one way to go. If it's the latter, then things get tricky
>>> since the mgmt command wipes all existing keys away before adding new
>>> ones.
>> In my particular scenario, the OOB key is provisioned only once and beforehand and used to connect with multiple LE devices. LE devices get this key via some proprietary mechanism. So it is kind of "global master key". As such, it is not a problem to restart the BlueZ daemon after the key is (re-)provisioned.
> using the same LTK for multi devices is a really bad idea. This is not how Bluetooth LE security was designed. My advise would be strictly against doing that in any product.
Beg your pardon, I mixed up OOB and LTK, my bad. The proper question is 
to how to feed OOB Datafor OOB pairing, which in turn used to generate 
STK and then unique per-device LTK as you have described below. 
Actually, I have found a way - btd_adapter_add_remote_oob_data() which 
is exactly what I need. But, in order for OOB Pairing to be started, the 
"SMP Pairing Request (0x01)" should indicate the presence of OOB Data. 
In kernel 3.18.6 it does not happening simply because the macro 
SMP_OOB_PRESENT is not used at all. In latest kernel 3.19 some changes 
were made in regard to OOB Data and macro is now used (see 
build_pairing_cmd) but only if local device and authreq from remote 
party both support "Secure Connections" which is in turn BT Core 4.2 
feature. But OOB pairing is supported also in BT Core 4.0, isn't it? So 
my question boils down to the following (it is all about LE bearers only):
1. Is LE OOB Pairing not supported before kernel 3.19 ? (see 
SMP_OOB_PRESENT macro which is not used)
2. Is LE OOB Pairing is still broken in 3.19, because it works only when 
both sides support "Secure Connections" thus are 4.2 version devices?
>
>>> If your OOB scheme is this latter "non-pre-provisioned" one I'd wonder
>>> why you're not using the standard OOB mechanism provided by LE SMP,
>>> since for that we do have at least partial support.
>> I'm now confused a bit. Indeed, I want to use OOB mechanism provided by LE SMP, but in order to start OOB pairing, the OOB key itself should be known to both sides (central and peripheral). For the peripheral I have my own ways to do it (proprietary), but the main question it how to give the key value to the central which is BlueZ in this case.
> When using LE OOB pairing (Legacy Pairing and Secure Connections), then at least you get a sense of key strength that is guaranteed based on how LE security is designed. So doing LE OOB pairing is a good idea. You feed different information into OOB pairing. You share and OOB secret between two devices and based on that they can pair. However they need to be in range to actually use that OOB secret to pair. Pairing requires a connection. The advantage with pairing is that you get a proper key with a proper strength.
>
> Regards
>
> Marcel
>

Re: DBus API for LTK OOB keys

[Marcel Holtmann]

Hi Andrejs,

>>>>>     There is a MGMT "Load Long Term Keys Command" to feed keys to the Kernel
>>>>> which are stored in the BlueZ settings storage file and read during adapter
>>>>> init (load_devices->load_ltks). I searched through the code and couldn't
>>>>> find any means to feed LTK keys from "the outside", for example through DBus
>>>>> API. This is needed for an LE OOB pairing scheme, when key is known in
>>>>> advance by both parties and is not derived from pairing procedure. Is there
>>>>> a standardized way to add LTK keys "manually" or this is not supported-yet
>>>>> feature? According to setting storage rules "Direct access to the storage
>>>>> outside from bluetoothd is highly discouraged".
>>>> Are the keys provisioned beforehand or is this something that can happen
>>>> at any time when bluetoothd is already running? If it's the former then
>>>> a custom bluetoothd plugin that gives bluetoothd core an extra set of
>>>> keys could be one way to go. If it's the latter, then things get tricky
>>>> since the mgmt command wipes all existing keys away before adding new
>>>> ones.
>>> In my particular scenario, the OOB key is provisioned only once and beforehand and used to connect with multiple LE devices. LE devices get this key via some proprietary mechanism. So it is kind of "global master key". As such, it is not a problem to restart the BlueZ daemon after the key is (re-)provisioned.
>> using the same LTK for multi devices is a really bad idea. This is not how Bluetooth LE security was designed. My advise would be strictly against doing that in any product.
> Beg your pardon, I mixed up OOB and LTK, my bad. The proper question is to how to feed OOB Datafor OOB pairing, which in turn used to generate STK and then unique per-device LTK as you have described below. Actually, I have found a way - btd_adapter_add_remote_oob_data() which is exactly what I need. But, in order for OOB Pairing to be started, the "SMP Pairing Request (0x01)" should indicate the presence of OOB Data. In kernel 3.18.6 it does not happening simply because the macro SMP_OOB_PRESENT is not used at all. In latest kernel 3.19 some changes were made in regard to OOB Data and macro is now used (see build_pairing_cmd) but only if local device and authreq from remote party both support "Secure Connections" which is in turn BT Core 4.2 feature. But OOB pairing is supported also in BT Core 4.0, isn't it? So my question boils down to the following (it is all about LE bearers only):
> 1. Is LE OOB Pairing not supported before kernel 3.19 ? (see SMP_OOB_PRESENT macro which is not used)
> 2. Is LE OOB Pairing is still broken in 3.19, because it works only when both sides support "Secure Connections" thus are 4.2 version devices?

we still have a problem with LE OOB pairing in the sense of giving the kernel enough information. That will be fixed hopefully pretty soon. The proposal on how to do that is in mgmt-api.txt. I think Johan is working on it.

The main problem is that we can currently only get OOB information for BR/EDR side of things. The missing part is to the get the LE OOB information. And of course there is a difference between LE Legacy Pairing and LE Secure Connections.

>>>> If your OOB scheme is this latter "non-pre-provisioned" one I'd wonder
>>>> why you're not using the standard OOB mechanism provided by LE SMP,
>>>> since for that we do have at least partial support.
>>> I'm now confused a bit. Indeed, I want to use OOB mechanism provided by LE SMP, but in order to start OOB pairing, the OOB key itself should be known to both sides (central and peripheral). For the peripheral I have my own ways to do it (proprietary), but the main question it how to give the key value to the central which is BlueZ in this case.
>> When using LE OOB pairing (Legacy Pairing and Secure Connections), then at least you get a sense of key strength that is guaranteed based on how LE security is designed. So doing LE OOB pairing is a good idea. You feed different information into OOB pairing. You share and OOB secret between two devices and based on that they can pair. However they need to be in range to actually use that OOB secret to pair. Pairing requires a connection. The advantage with pairing is that you get a proper key with a proper strength.

So LE Legacy Pairing needs the Security Manager TK value and LE Secure Connections needs the Confirmation and Random values. However right now, we can not get these ones from the kernel.

As a side note, I added tools/oobtest utility where you can test this between two controllers attached to the same host.

Regards

Marcel

Re: DBus API for LTK OOB keys

[Andrejs Hanins]

Hi Marcel,

On 2015.03.06. 00:08, Marcel Holtmann wrote:
> Hi Andrejs,
>
>>>>>>      There is a MGMT "Load Long Term Keys Command" to feed keys to=
 the Kernel
>>>>>> which are stored in the BlueZ settings storage file and read durin=
g adapter
>>>>>> init (load_devices->load_ltks). I searched through the code and co=
uldn't
>>>>>> find any means to feed LTK keys from "the outside", for example th=
rough DBus
>>>>>> API. This is needed for an LE OOB pairing scheme, when key is know=
n in
>>>>>> advance by both parties and is not derived from pairing procedure.=
 Is there
>>>>>> a standardized way to add LTK keys "manually" or this is not suppo=
rted-yet
>>>>>> feature? According to setting storage rules "Direct access to the =
storage
>>>>>> outside from bluetoothd is highly discouraged".
>>>>> Are the keys provisioned beforehand or is this something that can h=
appen
>>>>> at any time when bluetoothd is already running? If it's the former =
then
>>>>> a custom bluetoothd plugin that gives bluetoothd core an extra set =
of
>>>>> keys could be one way to go. If it's the latter, then things get tr=
icky
>>>>> since the mgmt command wipes all existing keys away before adding n=
ew
>>>>> ones.
>>>> In my particular scenario, the OOB key is provisioned only once and =
beforehand and used to connect with multiple LE devices. LE devices get t=
his key via some proprietary mechanism. So it is kind of "global master k=
ey". As such, it is not a problem to restart the BlueZ daemon after the k=
ey is (re-)provisioned.
>>> using the same LTK for multi devices is a really bad idea. This is no=
t how Bluetooth LE security was designed. My advise would be strictly aga=
inst doing that in any product.
>> Beg your pardon, I mixed up OOB and LTK, my bad. The proper question i=
s to how to feed OOB Datafor OOB pairing, which in turn used to generate =
STK and then unique per-device LTK as you have described below. Actually,=
 I have found a way - btd_adapter_add_remote_oob_data() which is exactly =
what I need. But, in order for OOB Pairing to be started, the "SMP Pairin=
g Request (0x01)" should indicate the presence of OOB Data. In kernel 3.1=
8.6 it does not happening simply because the macro SMP_OOB_PRESENT is not=
 used at all. In latest kernel 3.19 some changes were made in regard to O=
OB Data and macro is now used (see build_pairing_cmd) but only if local d=
evice and authreq from remote party both support "Secure Connections" whi=
ch is in turn BT Core 4.2 feature. But OOB pairing is supported also in B=
T Core 4.0, isn't it? So my question boils down to the following (it is a=
ll about LE bearers only):
>> 1. Is LE OOB Pairing not supported before kernel 3.19 ? (see SMP_OOB_P=
RESENT macro which is not used)
>> 2. Is LE OOB Pairing is still broken in 3.19, because it works only wh=
en both sides support "Secure Connections" thus are 4.2 version devices?
> we still have a problem with LE OOB pairing in the sense of giving the =
kernel enough information. That will be fixed hopefully pretty soon. The =
proposal on how to do that is in mgmt-api.txt. I think Johan is working o=
n it.
Thanks a lot for your support, now it is clear. I analyzed kernel=20
sources and obviously something is missing. I tried to do some quick=20
hacks here and there to feed OOB data into TK and even managed to start=20
LE OOB pairing data exchange, but it failed with confirmation mismatch.=20
Most probably, I got some bad mix of legacy and SC procedures :) So I'd=20
better wait for the proper implementation of "LE OOB Legacy Pairing" in=20
upstream. I hope the term is now correct and unambiguous.
>
> The main problem is that we can currently only get OOB information for =
BR/EDR side of things. The missing part is to the get the LE OOB informat=
ion. And of course there is a difference between LE Legacy Pairing and LE=
 Secure Connections.
>
>>>>> If your OOB scheme is this latter "non-pre-provisioned" one I'd won=
der
>>>>> why you're not using the standard OOB mechanism provided by LE SMP,=

>>>>> since for that we do have at least partial support.
>>>> I'm now confused a bit. Indeed, I want to use OOB mechanism provided=
 by LE SMP, but in order to start OOB pairing, the OOB key itself should =
be known to both sides (central and peripheral). For the peripheral I hav=
e my own ways to do it (proprietary), but the main question it how to giv=
e the key value to the central which is BlueZ in this case.
>>> When using LE OOB pairing (Legacy Pairing and Secure Connections), th=
en at least you get a sense of key strength that is guaranteed based on h=
ow LE security is designed. So doing LE OOB pairing is a good idea. You f=
eed different information into OOB pairing. You share and OOB secret betw=
een two devices and based on that they can pair. However they need to be =
in range to actually use that OOB secret to pair. Pairing requires a conn=
ection. The advantage with pairing is that you get a proper key with a pr=
oper strength.
> So LE Legacy Pairing needs the Security Manager TK value and LE Secure =
Connections needs the Confirmation and Random values. However right now, =
we can not get these ones from the kernel.
>
> As a side note, I added tools/oobtest utility where you can test this b=
etween two controllers attached to the same host.
>
> Regards
>
> Marcel
>

Re: DBus API for LTK OOB keys

[Andrejs Hanins]

Hi Marcel,

On 03/06/2015 12:08 AM, Marcel Holtmann wrote:
> 
> So LE Legacy Pairing needs the Security Manager TK value and LE Secure Connections needs the Confirmation and Random values. However right now, we can not get these ones from the kernel.
> 
> As a side note, I added tools/oobtest utility where you can test this between two controllers attached to the same host.
Based on oobtest/kernel code/mgmt-api comments, the OOB LE legacy pairing is still not supported: "Currently there is no support for providing the Security Manager TK Value for LE legacy pairing".

Is there any plan to support it? Maybe some patches exist? Are there any serious technical difficulties behind the absence of this functionality?
I know that BT 4.2 SC provides better alternatives for secure pairing, but the 4.2 is not so widely adopted as 4.0 and our BT chip also don't support 4.2...

> 
> Regards
> 
> Marcel
> 

Re: DBus API for LTK OOB keys

[Marcel Holtmann]

Hi Andrejs,

>> So LE Legacy Pairing needs the Security Manager TK value and LE Secure Connections needs the Confirmation and Random values. However right now, we can not get these ones from the kernel.
>> 
>> As a side note, I added tools/oobtest utility where you can test this between two controllers attached to the same host.
> Based on oobtest/kernel code/mgmt-api comments, the OOB LE legacy pairing is still not supported: "Currently there is no support for providing the Security Manager TK Value for LE legacy pairing".
> 
> Is there any plan to support it? Maybe some patches exist? Are there any serious technical difficulties behind the absence of this functionality?

making OOB LE legacy pairing work is pretty tricky since it is the wrong kind of OOB. Essentially it is just a shared secret between two device and only if that shared secret is truly random and communicated out-of-band you get proper strong keys. But nothing in the process guarantees that or can verify it.

It also does not fit into the SSP, BR/EDR SC or LE SC model with the public key exchange. So we actually gave up on supporting OOB LE legacy pairing.

> I know that BT 4.2 SC provides better alternatives for secure pairing, but the 4.2 is not so widely adopted as 4.0 and our BT chip also don't support 4.2…

You can run LE SC on Bluetooth 4.0 chips. We do that and also Apple’s iOS does that. No need for new hardware.

Regards

Marcel

Re: DBus API for LTK OOB keys

[Andrejs Hanins]

Marcel,

On 05/21/2015 03:12 PM, Marcel Holtmann wrote:
> Hi Andrejs,
> 
>>> So LE Legacy Pairing needs the Security Manager TK value and LE Secure Connections needs the Confirmation and Random values. However right now, we can not get these ones from the kernel.
>>>
>>> As a side note, I added tools/oobtest utility where you can test this between two controllers attached to the same host.
>> Based on oobtest/kernel code/mgmt-api comments, the OOB LE legacy pairing is still not supported: "Currently there is no support for providing the Security Manager TK Value for LE legacy pairing".
>>
>> Is there any plan to support it? Maybe some patches exist? Are there any serious technical difficulties behind the absence of this functionality?
> 
> making OOB LE legacy pairing work is pretty tricky since it is the wrong kind of OOB. Essentially it is just a shared secret between two device and only if that shared secret is truly random and communicated out-of-band you get proper strong keys. But nothing in the process guarantees that or can verify it.
> 
> It also does not fit into the SSP, BR/EDR SC or LE SC model with the public key exchange. So we actually gave up on supporting OOB LE legacy pairing.
> 
>> I know that BT 4.2 SC provides better alternatives for secure pairing, but the 4.2 is not so widely adopted as 4.0 and our BT chip also don't support 4.2…
> 
> You can run LE SC on Bluetooth 4.0 chips. We do that and also Apple’s iOS does that. No need for new hardware.
Our device (peripheral) chip runs proprietary SW which doesn't support 4.2 yet, it is not related to BlueZ/Linux at all, unfortunately.

Anyway, thanks Marcel for the support. 

> 
> Regards
> 
> Marcel
> 

Re: DBus API for LTK OOB keys

[Marcel Holtmann]

Hi Andrejs,

>>>> So LE Legacy Pairing needs the Security Manager TK value and LE Secure Connections needs the Confirmation and Random values. However right now, we can not get these ones from the kernel.
>>>> 
>>>> As a side note, I added tools/oobtest utility where you can test this between two controllers attached to the same host.
>>> Based on oobtest/kernel code/mgmt-api comments, the OOB LE legacy pairing is still not supported: "Currently there is no support for providing the Security Manager TK Value for LE legacy pairing".
>>> 
>>> Is there any plan to support it? Maybe some patches exist? Are there any serious technical difficulties behind the absence of this functionality?
>> 
>> making OOB LE legacy pairing work is pretty tricky since it is the wrong kind of OOB. Essentially it is just a shared secret between two device and only if that shared secret is truly random and communicated out-of-band you get proper strong keys. But nothing in the process guarantees that or can verify it.
>> 
>> It also does not fit into the SSP, BR/EDR SC or LE SC model with the public key exchange. So we actually gave up on supporting OOB LE legacy pairing.
>> 
>>> I know that BT 4.2 SC provides better alternatives for secure pairing, but the 4.2 is not so widely adopted as 4.0 and our BT chip also don't support 4.2…
>> 
>> You can run LE SC on Bluetooth 4.0 chips. We do that and also Apple’s iOS does that. No need for new hardware.
> Our device (peripheral) chip runs proprietary SW which doesn't support 4.2 yet, it is not related to BlueZ/Linux at all, unfortunately.

I would try to get your chip software updated to support LE SC as quickly as possible. It is the one update that is really worth the effort since it makes a huge difference from a security point of view.

The advantage with OOB from LE SC is that the OOB material only needs to be transported in one direction. It is truly random since it is based on your public/private key pair.

Regards

Marcel