Security of data passing in BLE communication

[Kova]

Security of data passing in BLE communication
Hello
I am developing based on "multirole lesc" of BLE sample project.
What is worrisome about the project is the "security_req_t" structure in "ble_srv_common.h".
I think that this structure is where security is set when reading and writing data, but data cannot be sent in the following configuration.

1.PERIPHERAL (SEC_MITM) ⇔Multirole (SEC_MITM)
2.Multirole (SEC_MITM) ⇔Central (??: There is no place to set)
In case of 1, it will succeed when the peripheral and Multirole are “SEC_OPEN”, but is there any superiority or inferiority relationship?
In case 2, Multirole succeeds when “SEC_OPEN”, but can CENTRAL project be other than SEC_OPEN? Please let me know if there is a setting method.

Is this structure related to the communication security mode and security level?

The environment is as follows.
SoftDevice: S132
IDE: SES
BLE Device: NRF52832
SDK version: 15.30
peripheral project: ble_peripheral⇒ble_app_hrs
multirole project: experimental⇒ble_app_multirole_lesc
central project: ble_central⇒ble_app_hrs_c

Thank you.

[Vidar Berg]

Hi,

The security levels should be applied to the characteristics you have on the GATT server. The security level of the link and the characteristics will then determine whether the client gets read/write access. It's not uncommon to have some characteristics set with "open" while having others with a security level that requires bonding. 

So if we use the ble_app_hrs project as an example:

    // Here the sec level for the Heart Rate Service can be changed/increased.
    hrs_init.hrm_cccd_wr_sec = SEC_OPEN;
    hrs_init.bsl_rd_sec      = SEC_OPEN;

Here write access to the CCCD is set to open, so any connected client can enable notifications for this characteristic. And let's say we want to require just works bonding or pairing before notifications can be enabled. Then we need to changes it to this:

    // Here the sec level for the Heart Rate Service can be changed/increased.
    hrs_init.hrm_cccd_wr_sec = SEC_JUST_WORKS;
    hrs_init.bsl_rd_sec      = SEC_OPEN;

Also note that the security level achieved through bonding will depend on the security capabilities of both the GAP central and GAP peripheral. Most of the examples are not set up to support MITM protection since it requires some kind of input or output (keyboard, display, etc) to the user. 

Security parameters used for the bonding in the ble_app_hrs example:

#define SEC_PARAM_BOND                      1                                       /**< Perform bonding. */
#define SEC_PARAM_MITM                      0                                       /**< Man In The Middle protection not required. */
#define SEC_PARAM_LESC                      1                                       /**< LE Secure Connections enabled. */
#define SEC_PARAM_KEYPRESS                  0                                       /**< Keypress notifications not enabled. */
#define SEC_PARAM_IO_CAPABILITIES           BLE_GAP_IO_CAPS_NONE                    /**< No I/O capabilities. */
#define SEC_PARAM_OOB                       0                                       /**< Out Of Band data not available. */
#define SEC_PARAM_MIN_KEY_SIZE              7                                       /**< Minimum encryption key size. */
#define SEC_PARAM_MAX_KEY_SIZE              16                                      /**< Maximum encryption key size. */

[Kova]

Hello Vidar Berg.
Sorry for the late reply.
I do not know where GATT Central security settings are configured.
If you do not mind, please teach me.

[Vidar Berg]

Hello,

The security capabilities are set in peer manager init (pm_init) using the defines (SEC_PARAM_BOND,..) shown in my previous reply.