How to require encrypted notifications in STM32_WPAN

[crwper]

In `ble_defs.h`, we have the following security permissions for attributes:

/* Security permissions for an attribute
 */
#define ATTR_PERMISSION_NONE 0x00U /* No security. */
#define ATTR_PERMISSION_AUTHEN_READ 0x01U /* Need authentication to read */
#define ATTR_PERMISSION_AUTHOR_READ 0x02U /* Need authorization to read */
#define ATTR_PERMISSION_ENCRY_READ 0x04U /* Need encryption to read */
#define ATTR_PERMISSION_AUTHEN_WRITE 0x08U /* Need authentication to write */
#define ATTR_PERMISSION_AUTHOR_WRITE 0x10U /* Need authorization to write */
#define ATTR_PERMISSION_ENCRY_WRITE 0x20U /* Need encryption to write */

In particular, we have permissions to ensure ecryption of read and write operations, but no permissions to ensure encryption for notification, indication, or write-without-response.

If I create a characteristic with the write-without-response property and the encrypted write permission, then performing a write-without-response operation on that characteristic does not seem to trigger an "insufficient encryption" error on the central device and therefore does not trigger a pairing request on iOS.

However, if I create the same characteristic with the write property and the encrypted write permission, performing a write operation *does* trigger an "insufficient encryption" error and pairing request.

This makes me think the ATTR_PERMISSION_ENCRY_WRITE permission does not apply to write-without-response.

So, I am wondering how we can ensure that a particular notification, indication, or write-without-response is encrypted.

Thanks!

[STTwo-32]

Hello @crwper 

I'm not able to understand this behavior. Could you please explain more about it.

Best Regards.

STTwo-32 

[crwper]

I suppose the question is this: The flags in `ble_defs.h` only allow me to require encryption for "read" and/or "write" operations. But Bluetooth specifies several different ways we can interact with a characteristic, which STM32_WPAN refers to as:

• Read
• Write without response
• Write
• Notify
• Indicate

So there are 5 ways to interact with the characteristic, but only 2 flags to control encryption requirements. I can think of two ways to look at this. First, the flags in `ble_defs.h` might refer to a broader category of interaction, e.g.:

• `ATTR_PERMISSION_ENCRY_READ` requires encryption for read, notify, and indicate operations
• `ATTR_PERMISSION_ENCRY_WRITE` requires encryption for write with/without response operations

Or, second, they might refer to specific STM32_WPAN operations, e.g.:

• `ATTR_PERMISSION_ENCRY_READ` requires encryption for the STM32_WPAN "read" operation
• `ATTR_PERMISSION_ENCRY_WRITE` requires encryption for the STM32_WPAN "write" operation
• But then how do we require encryption for "write without response", "notify", and "indicate" operations?

I suspect the first option is the correct one, but wanted to confirm rather than assuming this is the case.

[Nico12]

Hi @crwper , @STTwo-32 

I got the same issue

- declaration of a characteristic with CHAR_PROP_WRITE_WITHOUT_RESP and ATTR_PERMISSION_ENCRY_WRITE, but I can write into the characteristic without to be paired,

- declaration of a characteristic with (CHAR_PROP_NOTIFY | CHAR_PROP_READ) and ATTR_PERMISSION_ENCRY_READ, the Read access is protected by the pairing process, but I can activate the Notification and have data through Notification without to be paired.

 

So I wonder if you have resolved this issue ?

 

Best regards.

 

[crwper]

I get similar results to what you describe, but there are some details which might be important here. For my test, I have two characteristics:

• CRS_RX allows read and write without response, and has permissions ENCRY_READ and ENCRY_WRITE.
• CRS_TX allows notify only, and has permissions ENCRY_READ.

If I reset all bonding information on both my peripheral and the host, then connect to my peripheral using LightBlue:

• I can write to CRS_RX without triggering the pairing dialog. However, this write does not seem to be processed by the peripheral.
• If I read from CRS_RX, the pairing dialog is triggered (i.e., the peripheral sends an "insufficient permissions" message to the host, which responds by elevating permissions).
• I can subscribe to notifications on CRS_TX without triggering the pairing dialog, and notifications are actually received when the characteristic is updated.

So reading from CRS_RX works as expected but the following outcomes are not as expected:

• Writing to CRS_RX when not paired should trigger the pairing dialog, I think, which suggests that the peripheral is not sending an "insufficient permissions" message to the host in this case, although it is not processing the write request.
• I should not be able to receive notifications from CRS_TX unless I am paired with the peripheral. Requesting notifications on a characteristic with ENCRY_READ should, I think, trigger the pairing dialog.

For this test I used stack version 1.17.2.

[Nico12]

For your information, I open a ticket to the ST support, and I got the answer for these behaviors:

 

For the case declaration of a characteristic with CHAR_PROP_WRITE_WITHOUT_RESP and ATTR_PERMISSION_ENCRY_WRITE, but I can write into the characteristic without to be paired:

=> "yes, client can write the characteristic without pairing, but this write is ignored on server side and as there is no response, client is not notified. You can try by reading the characteristic value back, that as long as you're not bonded, write is not changing the characteristic value."

 

For the case declaration of a characteristic with (CHAR_PROP_NOTIFY | CHAR_PROP_READ) and ATTR_PERMISSION_ENCRY_READ, the Read access is protected by the pairing process, but I can activate the Notification and have data through Notification without to be paired:

=> "notification is enabled by writing into characteristic descriptor, to protect notification you need set ATTR_PERMISSION_ENCRY_WRITE"

 

For the notification, after applying the ENCRY_WRITE permission, when I try to activate the Notification, the smartphone ask for the pairing correctly.

(I use stack version 1.17.2 too)

 

Best regards

[crwper]

Thank you for sharing this!