Enabling BLE security mode 4 only on BLE and not on BLE-Mesh

[Ubaid_M]

Hello,

I wanted to enable L4 security on my BLE connection, 

    /** Level 4: Authenticated Secure Connections and 128-bit key. */

    BT_SECURITY_L4,

Hence added the param in my prj.conf as :

CONFIG_BT_SMP_SC_ONLY=y

But now as an unintended result the L4 security is also enabled for my BLE-Mesh models, and it is prompting me to enter key while provisioning.

Is this a bug..?

How can I enable L4 security only for BLE and not for BLE-Mesh..?

Thanks,

[tesc]

Hi,

The supported security level is for the device itself, and not for individual services. Centrals typically either always initiates pairing with the highest available security level, or they wait until they find an ATT table entry (service, characteristic or descriptor) requiring higher security level, then pairs with the highest available security level. Since this is in the hands of the central, there isn't any quick fix on the peripheral (mesh node) side. Since on the central side this is typically handled in the OS, without any API for overriding, there is little you can do on the central side as well.

I would not consider this a bug, but rather a feature request for improving user experience (for the end user) when having normal BLE Services along with the Bluetooth mesh GATT Proxy service, on the same device.

I am in touch with our Bluetooth mesh team, to see if we can think of a workaround or solution, but thus far I am afraid it doesn't look promising. I will get back to you with our findings, at the latest end of next week. If in the mean time you have any related suggestions or questions, feel free to ask here and I will look into them.

Regards,
Terje

[Ubaid_M]

Hello tesc,

Thank you for the same, but 

tesc said:

I am in touch with our Bluetooth mesh team, to see if we can think of a workaround or solution

I shall wait for this, as this is having implications on the BLE-Mesh models I am developing and it makes for uneasy development experience.

Thanks,

[tesc]

Hi,

For development, you can always change the configuration such that higher security mode is not supported / required.

For a production setting, if you do pairing with bonding, the manual authentication process is required only once per pair of devices.

In order to reduce or remove the need for authentication, for centrals only supposed to use the Mesh Proxy Service, it may be a workaround to originally have two services on the device; the Mesh Proxy Service and a custom service, both without security. The purpose of the custom service would be to signal to the device, that it should reboot into a state where it presents all services, as well as require higher security level. This way the mesh devices can connect without authentication, but when one device needs access to the other BLE services authentication is needed by everyone. Also, the other BLE services will only be available after using a custom BLE service for unlocking them, so it will not be compatible with standard BLE devices. This means for end users, it is probably best after all to require authentication, which is only needed the first time the central connects to the device (using pairing with bonding.)

Regards,
Terje

[Ubaid_M]

Hello Terje,

I understand that 

tesc said:

it is probably best after all to require authentication, which is only needed the first time the central connects to the device (using pairing with bonding.)

But my application requirement is completely different.

Please find the snap below:

These are API flow for two different images for two different processes.

1. On LHS, we have API flow for BLE L4 passkey authentication for connection validation

2. On RHS, we have the API flow for BLE-Mesh provisioning.

Now if I mix these two codes, then passkey will be requested during BLE-Mesh device provisioning as well, which I do not want to happen.

Based on the API flow as in snap, after L2CAP, the flow takes a different path.

So can you suggest something for me, even if it is code changes..?
That will not ask for passkey for provisioning and ask passkey only during BLE device bonding/connecting..?

Thanks,

[tesc]

Hi,

After some investigation, it turns out centrals waits until after a failed read/write before pairing. In other words, if the only service actually being used is the Mesh Proxy Service, then pairing should not be required, and therefore should not be triggered by the central.

Therefore it should be possible to set a higher security level on one service, and no security on another service, and as long as you only use the no security service you should get no pairing requests. There might however be other apps or OS functions reading or writing on certain characteristics, triggering the pair request.

In other words: By setting no security on the Mesh Proxy Service, it should be possible to use PB-GATT and only get the OOB for mesh, not the OOB for BLE pairing.

The CONFIG_BT_SMP_SC_ONLY=y should only affect services with security, so the behavior in terms of triggering pairing should not rely on it being n or y.

In order to figure out why you still get BLE pairing, I need more information about your setup. What kind of device is your central, and what other BLE services do you have on the device?

Regards,
Terje