Why gatttool can access characteristics whithout secure connection on ble_app_gls example from SDK?

[Chencheng]

Hi,

I just started with Nordic nRF52 DK and builded and flashed nRF5_SDK_15.2.0_9412b96/examples/ble_peripheral/ble_app_gls application on Ubuntu 18.04 using armgcc toolchain. Softdevice is s132 6.1.0.

I just used what was there in the SDK and "make" and used "nrfutil dfu ble" to upload the app with secure bootloader. I haven't changed any code. I followed GitHub - gamnes/nRF52832-buttonless-dfu-development-tutorial: How to develop on nRF52832 with buttonless DFU service (default dfu with button) and used https://github.com/NordicSemiconductor/pc-ble-driver-py to perform the "nrfutil dfu ble" from RPi.

Then I bonded my Adriod nRF connect APP to the DK. Everything works fine and it asked for passkey.

Then I disconnected from my phone, swithed to RPi 3 B+, and used gatttool (bluez/stable,now 5.43-2+rpt2+deb9u2 armhf) on raspbian lite and tried to read the characteristic:

pi@raspberrypi:~$ sudo gatttool  -b F6:9E:F1:EC:57:43 -t random --char-read --uuid=0x2A00
handle: 0x0003 	 value: 4e 6f 72 64 69 63 5f 47 6c 75 63 6f 73 65 

The serial port from DK reads out:

<info> app: Connected
<info> app: Fast advertising
<info> app: Disconnected

I am surprised that it didn't ask for passkey since ble_app_gls is using LESC with MITM protection.

I can even change the value in the characteristic:

pi@raspberrypi:~$ sudo gatttool -b F6:9E:F1:EC:57:43 -t random --char-write-req  -a 0x0003 -n 4e4e4e4e
Characteristic value was written successfully
pi@raspberrypi:~$ sudo gatttool  -b F6:9E:F1:EC:57:43 -t random --char-read --uuid=0x2A00
handle: 0x0003 	 value: 4e 4e 4e 4e 

I can also do:

pi@raspberrypi:~$ sudo gatttool -b F6:9E:F1:EC:57:43 -t random -I
[F6:9E:F1:EC:57:43][LE]> connect
Attempting to connect to F6:9E:F1:EC:57:43
Connection successful
[F6:9E:F1:EC:57:43][LE]> char-read-hnd 0x0003
Characteristic value/descriptor: 4e 6f 72 64 69 63 5f 47 6c 75 63 6f 73 65 
[F6:9E:F1:EC:57:43][LE]> char-write-req 0x0003 4f4f4f4f4f4f4f4f
Characteristic value was written successfully
[F6:9E:F1:EC:57:43][LE]> char-read-hnd 0x0003
Characteristic value/descriptor: 4f 4f 4f 4f 4f 4f 4f 4f 
[F6:9E:F1:EC:57:43][LE]> disconnect 

(gatttool:4709): GLib-WARNING **: Invalid file descriptor.

[F6:9E:F1:EC:57:43][LE]> quit
pi@raspberrypi:~$ 

The serial port from DK reads out:

<info> app: Connected
<info> app: BLE_GAP_EVT_AUTH_STATUS: status=0x1 bond=0x0 lv4: 0 kdist_own:0x0 kdist_peer:0x0
<info> app: Fast advertising
<info> app: Disconnected

I am wondering why I am not getting rejection like, e.g.: "connect error: Connection refused (111)"?

Anything I was missing when I built and dfu the ble_app_gls?

Thanks & best regards!

[Vidar Berg]

Hi, 

The security level on the gls characteristics are set to "just works" by default, so MITM protection is not required to access these. You can change the security level in service init to require MITM:

// Here the sec level for the Glucose Service can be changed/increased.
gls_init.gl_meas_cccd_wr_sec = SEC_JUST_WORKS;
gls_init.gl_feature_rd_sec = SEC_JUST_WORKS;
gls_init.racp_cccd_wr_sec = SEC_JUST_WORKS;
gls_init.racp_wr_sec = SEC_JUST_WORKS;

Here are some message sequence charts that illustrate the different bonding procedures: http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s132.api.v6.1.0/group___b_l_e___g_a_p___p_e_r_i_p_h___s_e_c___m_s_c.html?cp=2_3_1_1_0_2_1_3_10 

Best regards,

Vidar 

[Chencheng]

Thanks Vidar,

That's exact answer to my problem.

BTW, can you elaborate what pairing methods does SEC_SIGNED applies to? Or what is the difference between SEC_MITM and SEC_SIGNED_MITM? Do they differs just as LEGACY versus LESC connection?

(http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.s132.api.v6.1.0%2Fgroup___b_l_e___g_a_p___p_e_r_i_p_h___s_e_c___m_s_c.html&cp=2_3_1_1_0_2_1_3_10)

All OOB, numeric comparison, and passkey pairing are for MITM protection as I understand.

Best regards,

Chencheng

[Vidar Berg]

Hi Checheng,

I think it's easier if you look at the switch case in ble_srv_common.c::set_security_req() which invoke BLE_GAP_CONN_SEC_MODE_SET_* macros. These macros show what security mode and level each security_req_t member correspond to. Then have a look at the different security modes and levels defined by the core spec (core spec v5, vol. 3, part C, section 10.2).  

"All OOB, numeric comparison, and passkey pairing are for MITM protection as I understand." Yes, that is correct. 

[Chencheng]

Great, Thanks!