About GATT Server Context in HID mouse/keyboard example

RE: About GATT Server Context in HID mouse/keyboard example

Ulrich Myhre — Wed, 27 May 2015 09:27:42 GMT

As I mentioned in the original post, you are required to get/set the system attributes for bonded devices only. Deleting/forgetting the bond AND the system attributes is allowed, but confuses the peer and might need manual removal from the peer. Deleting only one of the two is a spec violation.

RE: About GATT Server Context in HID mouse/keyboard example

chd — Tue, 26 May 2015 23:24:31 GMT

Hi Ulrich, could you please give me some information about the need of storing and applying gatts_context to the system using sd_ble_gatts_sys_attr_set function?

As my observation, when I reconnect to a previously bonded device, there seems to be no problem if I pass a NULL pointer to sd_ble_gatts_sys_attr_set function:

sd_ble_gatts_sys_attr_set(conn_handle, NULL, 0);

Everything still work fine even when my device switches the connection back and forth between its bonded peers (e.g. bond with peer 1 -> disconnect -> bond peer 2 -> disconnect -> reconnect with peer 1, ...) as long as I call the sd_ble_gatts_sys_attr_set upon BLE_GAP_EVT_CONN_SEC_UPDATE event (NULL pointer as parameter)

RE: About GATT Server Context in HID mouse/keyboard example

Ulrich Myhre — Tue, 12 May 2015 14:07:52 GMT

After reading the spec, it does not explicitly mention deleting the bond when a rejection to re-encryption occurs. It only specifies to "abort the procedure". I think in cases where the bond is lost, you will have to manually delete the bond from the iPhone to make it re-encrypt.

RE: About GATT Server Context in HID mouse/keyboard example

chd — Fri, 08 May 2015 17:06:28 GMT

Is it the function call sd_ble_gap_sec_info_reply(m_conn_handle, NULL, NULL) that you're mentioning? If it is, the peer (an iPhone in my case) will still keep the connection, but it's unencrypted. As my application uses HID services that require encryption, doing so will make it got stuck with this iPhone (whenever I disconnect from my device's side, iPhone will automatically request a reconnecting if it see my device's advertising and get stuck in this unencrypted link again!)

RE: About GATT Server Context in HID mouse/keyboard example

Ulrich Myhre — Fri, 08 May 2015 01:42:01 GMT

To my understanding, it should send a negative reply if you provide only null-pointers to the security fields of sec_info_reply().

RE: About GATT Server Context in HID mouse/keyboard example

chd — Fri, 08 May 2015 00:06:00 GMT

Thank you for the swift response. I understand that sd_ble_gatts_sys_attr_set function is used to apply the gatt server context. But how about the bond context or encryption keys? When does it get applied? I mean, I only have the instance of it from persistent memory, but I dont see any function to apply it to the stack.

One more question, I already asked a question about how to setup the paring/bonding again if one of the two devices lose the encryption info. This seems to be impossible as per a Nordic employee answered me but as you said that we can do this by sending a "Pin or key missing", I'm really confused now.

RE: About GATT Server Context in HID mouse/keyboard example

Ulrich Myhre — Thu, 07 May 2015 22:42:03 GMT

For bonded devices, you are required to remember the exchanged keys and the peer's "preferences" (i.e. GATT CCCD states like "notification enabled") shall be remembered between connections. This means that if a previously bonded device connects to you, you should be able to restore all the CCCD states as they were when you last communicated (this is done with sd_ble_gatts_sys_attr_set) and encrypt with the LTK received from earlier. I am not very familiar with the HID example, but I assume the two contexts refer to these two things. The GATT Server Context will contain every handle + value for each CCCD and the Bond Context I presume contain the encryption keys.

Not remembering the encryption keys will lead to a new pairing happening each time, and might confuse the peer if you do not send a "Pin or key missing" response to the security key request (which should delete the bond on the peer side). Not remembering the CCCD states between connections with a bonded device is a spec violation, and will lead to interoperability problems down the road.

Forgetting both the encryption keys and the CCCD context is allowed if you respond with "Pin or Key Missing", but this leads to a really slow ramp-up time. The bonding procedure exchanges a minimum of 6 packets + 1-2 for each key specified. It is also not possible to use IRK-based white-listing or Privacy 1.1/1.2 if you do not remember the Identity Resolving Key of your peer.

So these contexts are needed for HID, and while losing both is fine from a "What's allowed" perspective, it will really hurt power usage, latency and interoperability. This could legitimately happen if the device is restored to factory settings or lose power before saving the contexts. Losing only one of them is not allowed however.