avoid cross-transport key derivation

avoid cross-transport key derivation

[Ordit Gross]

hi all,

our application connects both to mobile (ble) and speakers (br/edr)
using bluez stack.
our controller is configured as follows:
current settings: powered connectable bondable ssp br/edr le secure-conn

ever since IOS started supporting CTKD (cross-transport key
derivation) at IOS13, pairing to mobile causes also link key
distribution and brief br/edr connection follows the ble connection.
I would like to avoid the link key distribution at the pairing stage.
the only way I was able to achieve that is by disabling either
secure-conn or ssp which is undesirable as disabling either of them
block other functionality.
what is the recommended approach?

** when br/edr is turned off we do not experience disconnections from
mobile app running with IOS13. and vis versa.
looking on HCI dump from mobile side the disconnections is initiated
from mobile side, however the application is not the one initiating
the disconnections.
any advice is greatly appreciated
Ordit

Re: avoid cross-transport key derivation

[Marcel Holtmann]

Hi Ordit,

> our application connects both to mobile (ble) and speakers (br/edr)
> using bluez stack.
> our controller is configured as follows:
> current settings: powered connectable bondable ssp br/edr le secure-conn
> 
> ever since IOS started supporting CTKD (cross-transport key
> derivation) at IOS13, pairing to mobile causes also link key
> distribution and brief br/edr connection follows the ble connection.
> I would like to avoid the link key distribution at the pairing stage.
> the only way I was able to achieve that is by disabling either
> secure-conn or ssp which is undesirable as disabling either of them
> block other functionality.
> what is the recommended approach?
> 
> ** when br/edr is turned off we do not experience disconnections from
> mobile app running with IOS13. and vis versa.
> looking on HCI dump from mobile side the disconnections is initiated
> from mobile side, however the application is not the one initiating
> the disconnections.
> any advice is greatly appreciated

you would have to show the btmon trace for this. The extra connection is not needed for cross-transport pairing and seems to be iOS specific to check that the connection actually works.

From our side it is by design that if both transports use the same identity address, that both sides are being paired. So this is pretty much intentional. If you disable BR/EDR, then of course pairing will stick to just pair LE only.

Regards

Marcel

Re: avoid cross-transport key derivation

[Marcel Holtmann]

Hi Ordit,

> thanks Marcel,
> btmon file attached. (both as btmon format and txt)
> actually it looks like the BR/EDR connection is initiated by my side,
> not the mobile.
> #11 LE Connection Complete
> #85 done pairing
> #138 Create Connection (br/edr)
> #263 Disconnection Request (br/edr)
> 
> ** is it possible that bluetoothd might invoke this br/edr connection?
> - I was able to reproduce this when running btgatt-server with
> bluetoothd running. meaning after pairing I saw creation of br/edr
> connection.
> - running btgatt-server without bluetoothd in background, br/edr
> connection was not observed after pairing.
> (in both cases I used btmgmt to verify controller settings are the same )
> 
> ** in order to reproduce the br/edr connection after pairing, I must
> remove credentials from both mobile side and my side.
>    removing credentials from mobile side only, I can see pairing but
> no br/edr connection is created.
> thanks again!

so bluetoothd is doing a service discovery via BR/EDR and then terminated the L2CAP link used for SDP. However then the remote device / phone terminates the BR/EDR link. They LE link seems not be terminated.

Nothing looks bad here. It is a bit of extra traffic, but bluetoothd actually has to learn about the BR/EDR services somehow.

Regards

Marcel