Linux bluetooth development
 help / color / mirror / Atom feed
From: Andrejs Hanins <andrejs.hanins@ubnt.com>
To: "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Subject: Re: DBus API for LTK OOB keys
Date: Thu, 05 Mar 2015 16:05:23 +0200	[thread overview]
Message-ID: <54F862A3.80400@ubnt.com> (raw)
In-Reply-To: <20150305134024.GA20862@t440s>

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


  reply	other threads:[~2015-03-05 14:05 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-05 13:21 DBus API for LTK OOB keys Andrejs Hanins
2015-03-05 13:40 ` Johan Hedberg
2015-03-05 14:05   ` Andrejs Hanins [this message]
2015-03-05 14:55     ` Marcel Holtmann
2015-03-05 20:11       ` Andrejs Hanins
2015-03-05 22:08         ` Marcel Holtmann
2015-03-06 17:54           ` Andrejs Hanins
2015-05-21  7:38           ` Andrejs Hanins
2015-05-21 12:12             ` Marcel Holtmann
2015-05-21 12:57               ` Andrejs Hanins
2015-05-21 13:10                 ` Marcel Holtmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54F862A3.80400@ubnt.com \
    --to=andrejs.hanins@ubnt.com \
    --cc=linux-bluetooth@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox