Preventing Services From Being Discovered

[Cory Mast]

Hello,

I am currently working on a project and I would like to add some security to my device by preventing services from being discovered. Ideally when a user connects to the device they should only see a Password service with a lock and unlock characteristic. When the user unlocks the device by entering the proper password, the user will then be presented with additional services and characteristics for configuring the device. Once the user locks the device, disconnects and reconnects, they will again only be presented with the Password service. I would like this functionality to prevent unauthorized users from enumerating my GATT table. I have also tried to add the services i wish to hide as secondary services using sd_ble_gatts_service_add(BLE_GATTS_SRVC_TYPE_SECONDARY, p_uuid, p_handle) and then call sd_ble_gatts_include_add() but have been unsuccessful and there is no sample code to help guide me in the right direction regarding its usage.

Is this possible with the S110 SoftDevice and SDK 7.2? I know that there are some devices on the market that do this such as the Nike Fuel Band and I would like to add it to my current project using the nRF51822.

Any help or recommendations you have would be greatly appreciated.

Thanks!

Cory

[shibshab]

When initializing the softdevice, have you set the service change bit to '1' ? This is required for the functionality you are describing at least.

This is the service_changed property of ble_enable_params.gatts_enable_params

[Ulrich Myhre]

Hi Cory,

Unfortunately, the thing you are asking for is not allowed per the Bluetooth spec. All declarations have to be readable and not require authentication or authorization, and this is mentioned for services, includes and characteristics alike. So disallowing enumeration is not allowed. Additionally, blocking enumeration will not block peers from reading and writing to arbitrary handles.

The only possible way I see for you to accomplish what you are requesting is to actually create the database after the authentication is successful. You are then, as shibshab mentions, required to include the service changed characteristic. This lets you notify the peer that you did indeed change your database so it can rediscover it. Changing the database on the fly without service changed is also against the spec, so thread carefully!

The Nike Fuel Band has implemented its own protocol over two characteristic in its database (which is fully discoverable), and basically re-implement a subset of GATT through sending commands to one of the characteristics and receiving data from the other one. This is also possible with Nordic SoftDevices that implement BLE, but we do not have any examples that do this.

[Hung Bui]

@Cory: I agree with what Ulrich explained. Just want to attach here an example of how to update the attribute table on the fly and send service changed indication. In the example (SDK v6.1) I add the battery level service 20 seconds after connected.

ble_app_hrs - ServiceChangedBond.zip