public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: Johan Hedberg <johan.hedberg@gmail.com>
To: Ordit Gross <ordit.gross@orcam.com>
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: recommended way to register on bluetooth event
Date: Wed, 2 Oct 2019 14:05:56 +0300	[thread overview]
Message-ID: <B0CC58AE-90B5-4299-B9CB-0D40A14685DE@gmail.com> (raw)
In-Reply-To: <CAB+bgRaH+Vw1xDNQdOuG26v=QPvnporuo9waBeoxi7NTUE+8YA@mail.gmail.com>

Hi Ordit,

On 1 Oct 2019, at 16.36, Ordit Gross <ordit.gross@orcam.com> wrote:
> I would like to register on encryption changed event.
> As far as I could tell mgmt-api does not consist of such capability.
> I think that reading from an HCI socket may enable me to read all
> events (and the needed one as well).
> is there a better way of registering on encryption changed event?
> 
> The reason I need this capability in the first place is that I want to
> enable repairing if BLE Peripheral Removes Pairing keys.
> currently, when the peripheral deletes his side of keys and attempt to
> connect to master, the master will get  encryption changed event with
> error  "PIN or Key Missing".
> that's why I want to be notified on application that we got this
> event, so I can delete my side of keys as well..

Looking at the kernel code (hci_event.c) a “PIN or Key missing” encryption error should cause a unique MGMT_DEV_DISCONN_AUTH_FAILURE disconnection reason to be presented in the mgmt Device Disconnected event. So that could be one way to identify this in user space. That said, I think a better way would be to add some configurable policy to the kernel to decide what to do in such a case. This is also a security sensitive scenario, since the reason you get “PIN or Key missing” could be because someone is pretending to be the real device, i.e. they could force you to drop the keys for the real device without any authentication. So to be safe, the old keys should only be discarded when the new pairing has been successful, and the security level of the new pairing should be at least as strong as the old one. I don’t think this is doable in user space with the current design.

Johan


  reply	other threads:[~2019-10-02 11:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-01 13:36 recommended way to register on bluetooth event Ordit Gross
2019-10-02 11:05 ` Johan Hedberg [this message]
2019-10-02 11:24 ` Szymon Janc

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=B0CC58AE-90B5-4299-B9CB-0D40A14685DE@gmail.com \
    --to=johan.hedberg@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=ordit.gross@orcam.com \
    /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