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.