2019-10-01 13:37:40

by Ordit Gross

[permalink] [raw]
Subject: recommended way to register on bluetooth event

hi all,
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..

any suggestions?
thanks in advance!!
Ordit


2019-10-02 12:14:34

by Johan Hedberg

[permalink] [raw]
Subject: Re: recommended way to register on bluetooth event

Hi Ordit,

On 1 Oct 2019, at 16.36, Ordit Gross <[email protected]> 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

2019-10-02 12:15:49

by Szymon Janc

[permalink] [raw]
Subject: Re: recommended way to register on bluetooth event

Hi,

On Tuesday, 1 October 2019 15:36:19 CEST Ordit Gross wrote:
> hi all,
> 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..
>
> any suggestions?
> thanks in advance!!
> Ordit

Ha, I was working on that few years back but unfortunatelly it never got in...
mostly due to objections about dropping old keys before new pairing (which I
don't think is necessary with proposed Agent consent-based approach but others
were not sharing my view on this ;-).

Kernel part with reporting proper error to userspace is done so userspace has
all the information it needs. For bluetoothd I've sent RFC [1] which might
give you a bit of headstart while working on this. In short, it extends Agent
API with new call used to consent re-bond of remote device.

[1] https://marc.info/?l=linux-bluetooth&m=147031736607899&w=2

--
pozdrawiam
Szymon Janc