pc-ble-driver bonding with LESC succeeded (BLE_GAP_SEC_STATUS_SUCCESS) but get invalid encryption information

[Chencheng]

Hi,

I am trying to implement LESC Security Mode 1 Level 4 with a peripheral ble_app_hrs on PCA10040 and a central via pc-ble-driver example heart_rate_collector_v6 with PCA10040.

I am using pc-ble-driver latest version. I compiled the connectivity firmware from source and load connectivity_<version>_1m_with_s132_6.1.1.hex onto serialization PCA10040.

The peripheral device is implemented as mentioned here.

I am following Central LESC for hear rate collector example:

Bonding: Passkey Entry: User Inputs on Central

The heart_rate_collector example modification is here:

(Updated on 2019-04-16 with fix to passkey entry):

/cfs-file/__key/support-attachments/beef5d1b77644c448dabff31668f3a47-226eb83e350846778d6a5ac3302b24ec/HRSC_2D00_Third_2D00_party_2D00_light_2D00_LESC_2D00_impl_2D00_master.patch

Strangely, every time after I get BLE_GAP_SEC_STATUS_SUCCESS, I found kdist_own value is changing all the time. The value can be anything, e.g. 0x00, 0x30, 0x40, 0x60, 0x70, 0x80, 0xc0, 0xc0, 0xf0, etc.

Update on 2019-05-13 with fix to unstable BLE_GAP_EVT_AUTH_STATUS returning values:

HRSC-Third-party-light-LESC-impl-master.patch

And I only get ble_gap_enc_key_t (LTK and so on) information with only zero values.

An example log:

$ ./heart_rate_collector_sd_api_v6 /dev/ttyACM0 
Serial port used: /dev/ttyACM0
Baud rate used: 1000000
Info: Successfully opened /dev/ttyACM0. Baud rate: 1000000. Flow control: none. Parity: none.
SDH: Status: 6, message: Target Reset performed
SDH: Status: 7, message: Connection active
Scan started
Received BLE_GAP_EVT_ADV_REPORT with device address: 0xCB76125C099D
Connection established
Received BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST. Reply with 247
Received BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST. Peer data length is:
	max_rx_octets = 251
	max_tx_octets = 251
	max_rx_time = 2120
	max_tx_time = 2120
Received BLE_GAP_EVT_DATA_LENGTH_UPDATE (157, max_rx_time 1370).
sd_ble_gap_authenticate succeeded
Received BLE_GAP_EVT_SEC_PARAMS_REQUEST
uECC PK own "m_lesc_pk_own(keyset_pointer)":
53(53)	176(176)	227(227)	134(134)	192(192)	182(182)	152(152)	104(104)	144(144)	59(59)	164(164)	248(248)	45(45)	54(54)	216(216)	245(245)	243(243)	114(114)	5(5)	137(137)	175(175)	5(5)	93(93)	215(215)	150(150)	62(62)	160(160)	110(110)	148(148)	142(142)	74(74)	107(107)	72(72)	119(119)	84(84)	253(253)	247(247)	243(243)	57(57)	115(115)	73(73)	142(142)	125(125)	82(82)	18(18)	22(22)	35(35)	229(229)	174(174)	198(198)	184(184)	152(152)	45(45)	137(137)	61(61)	123(123)	109(109)	41(41)	120(120)	169(169)	52(52)	188(188)	75(75)	139(139)	
SK own:
111	201	75	248	121	184	84	213	111	54	63	45	152	34	229	82	32	134	100	229	6	37	25144	69	41	246	107	41	121	162	47	
Security parameters replied.
BLE_GAP_EVT_AUTH_KEY_REQUEST received.
Enter passkey:
890975
Enter passkey again:
Got passkey: 890975
Authentication passkey replied.
Received BLE_GAP_EVT_LESC_DHKEY_REQUEST
PK Peer:
108	41	67	129	227	11	160	54	97	160	221	138	21	166	181	217	14	25	45	189	208	97	52	225	91	25	221	46	61	5	235	85	16	95	229	176	172	89	154	168	199	220	91	22	138	122173	188	57	73	5	148	183	178	107	96	139	237	164	115	250	158	22	152	
DHKey:
148	232	74	125	19	144	198	34	192	2	236	188	113	11	151	28	95	216	40	45	162	124	21422	140	176	248	124	217	157	68	249	
LESC DHkey replied.
BLE_GAP_EVT_CONN_SEC_UPDATE: Security mode: 1. Security level: 4
Security level high enough to enable BAS notifications.
BLE_GAP_EVT_AUTH_STATUS: status=0x0 bond=0x1 lv4: 1 kdist_own:0x0 kdist_peer:0x0
Authorization succeeded!
Own	LTK:
	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	
	EDIV:
	0
	RAND:
	0	0	0	0	0	0	0	0	

Peer	LTK:
	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	
	EDIV:
	0
	RAND:
	0	0	0	0	0	0	0	0	
Discovering primary services
Received BLE_GATTC_EVT_PRIM_SRVC_DISC_RSP
Discovered heart rate service. UUID: 0x180D, start handle: 0x000E, end handle: 0x0013
Discovering characteristics
Received BLE_GATTC_EVT_CHAR_DISC_RSP, characteristics count: 2
Characteristic handle: 0x000F, UUID: 0x2A37
Characteristic handle: 0x0012, UUID: 0x2A38
Discovering characteristic's descriptors
Received BLE_GATTC_EVT_DESC_DISC_RSP, descriptor count: 5
Descriptor handle: 0x000F, UUID: 0x2803
Descriptor handle: 0x0010, UUID: 0x2A37
Descriptor handle: 0x0011, UUID: 0x2902
Press 't' to toggle notifications on the HRM characteristic
Descriptor handle: 0x0012, UUID: 0x2803
Descriptor handle: 0x0013, UUID: 0x2A38

Can anyone kindly help me how to properly fetch ble_gap_enc_key_t (LTK) information after the bonding procedure seems successful so that I can store it in the file system?

Thanks & best regards,

Chencheng

[Simon]

During the easter, a large part of the support team are on vacation, and you may not get an answer at first. The 23 of april, most of the staff will be back, and you can expect an answer that week.

Best regards,

Simon

[Chencheng]

Hi Simon, Any update?

BR/Chencheng

[Simon]

I am sorry for the delay, there is a quite large workload after easter break. 

Regarding your application I am currently struggling to run it due some issues with the included header file stdint.h inside uECC.h. Did you encounter this? If so, how did you resolve it?

Best regards,

Simon

[Chencheng]

uECC.h is from https://github.com/kmackay/micro-ecc

You should add this repository under pc-ble-driver/examples/heart_rate_collector and add the git repo as a submodule under pc-ble-driver.

I don't have problem with stdint.h. I'm running under Ubuntu 18.04.

/Chencheng

[Simon]

I have cloned the repo and added it as a submodule (everything mentioned in the patch). I am using MSVC and windows and the issue is probably due to this. Will try to fix it tomorrow.

[Simon]

Any progress? I am still struggling with getting your project to run, when I fix one problem another pops up. All the errors are unix related. I will try to set it up in Ubuntu and get to the core of it.

Best regards,

Simon

[Chencheng]

Not really. I am not blocking myself by this step.

Actually now I am looking at Linux platform on different architectures.

I would say Ubuntu is better OS for developing firmware cause the dependencies or packages are handled in a easier manner where user can easily fetch and integrate.

I don't know if Ken has done it or not, I have completely running the toolchains and pc-ble-driver on Raspberry Pi. And my teammate has also brought up pc-ble-driver on some other ARM architecture HW platforms.

[Simon]

You said earlier "I am not blocking myself by this step.", and I have not prioritized this case for that reason. Would you like me to figure out your issue, or is it not important?

Best regards,

Simon 

[Chencheng]

It's still on my first priority. I am looking at other implementation like nrfconnect-ble and so on. It's blocked on my list but I have other parallel tasks to do as well.

Could you please still investigate this issue and reply as soon as you have any findings?

Thanks & Best regards,

Chencheng