Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: recommended way to register on bluetooth event
From:   Johan Hedberg <johan.hedberg@gmail.com>
In-Reply-To: <CAB+bgRaH+Vw1xDNQdOuG26v=QPvnporuo9waBeoxi7NTUE+8YA@mail.gmail.com>
Date:   Wed, 2 Oct 2019 14:05:56 +0300
Cc:     linux-bluetooth@vger.kernel.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <B0CC58AE-90B5-4299-B9CB-0D40A14685DE@gmail.com>
References: <CAB+bgRaH+Vw1xDNQdOuG26v=QPvnporuo9waBeoxi7NTUE+8YA@mail.gmail.com>
To:     Ordit Gross <ordit.gross@orcam.com>
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

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?
>=20
> 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 =E2=80=9CPIN or Key =
missing=E2=80=9D 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 =
=E2=80=9CPIN or Key missing=E2=80=9D 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=E2=80=99t think this is doable in user =
space with the current design.

Johan