Implement access levels in BLE characteristics

RE: Implement access levels in BLE characteristics

Edvin — Thu, 16 Jan 2025 22:55:20 GMT

To implement your own characteristic I suggest you go through the Bluetooth Low Energy Fundamentals course in the Nordic DevAcademy.

I don't have any roadmap details, but I doubt that implementing this service is something that will come from us any time soon. Although I don't think there is anything magic about this service in particular, other than that it may be used by other devices as well, since it has a dedicated UUID. You would still need to handle it's behavior in your application.

As I see it, you have two options:

1: Go through with pairing/bonding only the technician. The rest can have an unencrypted connection, and these limitations will then not allow them to write to the characteristics that you specify.

2: Implement some custom service characteristic with a "password". Then, only if the user have entered the correct password, the device will stop ignoring what is written to the characteristic.

For 2: Do note that if they are unencrypted, then someone can pick up the password by sniffing the packets over the air.

What I mean by "ignoring" is something like:

Everyone can read characteristic Service 1 characteristic A (1A). But only the ones who have written the correct password to Serivce 2 Characteristic A (2A) can successfully write to Service 1 characteristic B (1B). If anyone else tries to write to 1B, it will be ignored. If the technician has done it, your application will copy the content of 1B to 1A, so that everyone can read it.

Noone can read characteristic 1B. It is a write only characteristic.

Best regards,

Edvin

RE: Implement access levels in BLE characteristics

Beldramma — Thu, 16 Jan 2025 09:28:33 GMT

Hi Edvin ,

Is it planned to implement this service ?

Where can I find the list of all implemented BLE services ?

Is it possible to implement it on my own ? (Not sure I will do it though)

RE: Implement access levels in BLE characteristics

Beldramma — Wed, 15 Jan 2025 09:53:08 GMT

Hi Edvin

These different access levels are not implemented on our side for the moment, our current product protects all characteristics through LE Secure Connection.

What we want is that after this step, not all people can for example write the characteristics. The idea can be to enter another password in order to have the possibility to write a characteristic.

RE: Implement access levels in BLE characteristics

Edvin — Wed, 15 Jan 2025 07:39:06 GMT

Hello,

Looks like me and Einar replied at the same time.

I don't think we have an implementation for this particular service.

So what is the flow when a technician connects and pairs/bonds with the device? How do you prevent a normal user from using LESC? Does the technician input some sort of passkey when pairing?

BR,
Edvin

RE: Implement access levels in BLE characteristics

Beldramma — Tue, 14 Jan 2025 15:33:19 GMT

Hi Einar, Edvin,

thanks for the quick answers.

Einar Thorsrud I already know these security levels and I use them (Le secure connections). In my case, I don't want just anyone to be able to access the charactéristics so all characteristics are protected with pairing through a password, it is after this step that I want to have these differrent access levels.

Edvin, in what you talk about, is it possible to have what I was talking to Einar ?

To implement these access levels, I have began to look at Bluetooth-SIG Authorization Control Service (ACS), which seems to permit that.

Do you know this service ?DO you have any information on it ? Someone at Nordic told me that this service is not implemented for the moment in NRF Connect SDK, can you confirm that ?

RE: Implement access levels in BLE characteristics

Edvin — Tue, 14 Jan 2025 14:19:16 GMT

Hello,

If you look at the implementation of the Nordic UART Service (NUS), found in ncs\nrf\subsys\bluetooth\services\nus.c, you can look at how the service and characteristics are set up, starting with the line "BT_GATT_SERVICE_DEFINE(...)"

This sample has a config to set up authentication (which will require encryption), so see how it sets e.g. either BT_GATT_PERM_WRITE or BT_GATT_PERM_WRITE_AUTHEN, depending on whether CONFIG_BT_NUS_AUTHEN is defined or not.

You can look up all the different levels of encryption in ncs\zephyr\include\bluetooth\gatt.h, in the bt_gatt_perm enum.

So in your case, you would set BT_GATT_PERM_READ for all characteristics that the user should be able to access, and then you set e.g. BT_GATT_PERM_WRITE_ENCRYPT or BT_GATT_PERM_WRITE_AUTHEN on the characteristics that only the technician should be able to write to. (or any of the other WRITE values, depending on the level of security used in the pairing/bonding process.

BT_GATT_PERM_WRITE: Everyone can write

BT_GATT_PERM_WRITE_ENCRYPT: You need to be encrypted using just works encryption or better (meaning the keys are just sent over the air)

BT_GATT_PERM_WRITE_AUTHEN: You need to be encrypted using a key (e.g. a 6-digit numerical pin).

BT_GATT_PERM_WRITE_LESC: You need to use LE SECURE Connection to write to the characteristic.

Best regards,

Edvin

RE: Implement access levels in BLE characteristics

Einar Thorsrud — Tue, 14 Jan 2025 14:13:20 GMT

Hi,

There i no concept of users in Bluetooth LE. However, there is a conecpt of security levels (see dev academy), and you can requier a different security level fro reading and writing (for instance allow anyone to read, but only allow paired/bonded devicec above a certain threshold to write to a characteristic. Could that be used in your case?