Original: https://blog.csdn.net/wenshifang/article/details/100038433
BLE pairing is a more cumbersome process, need to be familiar norms, only understand the principle is to better understand this process.
First need to be clear: The purpose of pairing is to encrypt communications link, to ensure data security, binding to simplify the pairing process.
Description paired binding process:
exchange of information 1 pair of
2 generation STK (short-term secret key) encryption link
encryption can secure distribution after various keys three links, if necessary binding, it will also generate LTK (long-term secret key), the two sides are stored LTK.
After 4 LTK assignment, each time re-connecting the two sides eventually generate other information LTK session keys and other dispersed a secret session key, encryption is the real secret session key, in fact, this is also the most similar encryption mechanisms.
The following simple analysis of the protocol stack processes nrf about pairing moieties.
In NRF52832 (SDK 11.0 softdevice s132) link security-related events:
BLE_GAP_EVT_SEC_PARAMS_REQUEST
BLE_GAP_EVT_SEC_INFO_REQUEST
BLE_GAP_EVT_CONN_SEC_UPDATE
BLE_GAP_EVT_AUTH_STATUS
(1) In the pairing information exchange phase, BLE_GAP_EVT_SEC_PARAMS_REQUEST events will be reported by the protocol stack to the application layer:
(2) In this event, the opportunity to put their information exchange with the host, which contains the IO capability from the machine, pairing is bound, etc. (in sd_ble_gap_sec_params_reply third parameter definitions) information.
1) If the machine has the ability to show that BLE_GAP_IO_CAPS_DISPLAY_ONLY specified, after calling sd_ble_gap_sec_params_reply, application layer will receive BLE_GAP_EVT_PASSKEY_DISPLAY event, the slave protocol stack will generate a random password can be displayed on the screen, this time there will be a host pair box, the user enters a password from the machine to complete the pairing of the display. If there is no output capability from the machine, you can specify BLE_GAP_IO_CAPS_NONE, when the host is no longer required to enter a password, but asked whether consent pairing. If the password matches the user's consent or pairing, the pairing process continues until the protocol stack reported BLE_GAP_EVT_CONN_SEC_UPDATE event on behalf of the pairing is successful:
2. If you specify pairing complete the binding, the protocol stack LTK will be distributed after the key distribution is completed, the stack will report the BLE_GAP_EVT_AUTH_STATUSevent, said:
(3) After the completion of the distribution LTK slave protocol stack can return relevant information saved secret key:
At this point the entire pairing binding process is complete.
The following re-analysis, when the link is re-established situation.
As mentioned above, the binding operation is to simplify the pairing process. When both stores pairing information (most importantly LTK), can be used directly LTK involved in generating session keys, under normal circumstances, host initiates an encrypted request, from the opportunity to respond to an encrypted request, nrf protocol stack, the relevant event is BLE_GAP_EVT_SEC_INFO_REQUEST:
After receiving BLE_GAP_EVT_SEC_INFO_REQUEST event, from there the opportunity to query the local host related secret key information about the current connection, and the results passed to the protocol stack to the host response. So in the end is what match as a standard to query the information it secret key, the first thought is the host of the MAC, yes, indeed MAC address, MAC address but in addition, there is a diversifier (disperser), referred to as EDIV:
If just the MAC address, it can not explain the phenomenon iOS system Private Non-Resolvable address is: iOS each reboot the system or restart Bluetooth, BLE's MAC address will be changed, saying that in order to prevent the device from being tracked.
one diversifier value transmitted by the initiating pairing receiving end by matching diversifier addition, there are parameters associated with the encrypted random number Rand, etc. As the initial vector IV LL_Encryption Req encrypted request to the counterpart.
Once a match is found, the follow-up communication links can enter the encryption status, following the air packet capture process is initiated on the host encryption:
It can be seen in the encryption M-> S request packet contains four domains are associated with the encrypted fields, one of which is EDIV, the encrypted response to the subsequent S-> M, the slave transmits to the master his STK and IV, master-slave after the two sides are ready, beginning from machine to initiate encryption request, in a subsequent packet, the protocol analysis software shows more than a Security_Enabled, has entered a clear link encryption status.
Should all goes well, the above process is no problem, once a link error, the pairing can not be completed. For example, when pairing information stored in the machine from the failure of the (usually stored in Flash, Flash is not 100% reliable), it can not be right for link encryption.
In my case this slave is nrf52832, the host is iOS systems, business processes simple:
Slave by user app after pairing is complete, and can work independently from the app, ANCS and receive messages.
During the test found that the host (time and frequency uncertainty) after the break, is no longer active connection from the machine, the manual from the machine, ANCS notice is not normal, and again after the break will not even return.
After the degree of your mother asked numerous times, but could not find the relevant issues, and finally no choice but resorted to killer: by packet capture analysis
It can be seen from the host machine in connection with the slave exchange protocol version information, then it sends an encrypted request to the slave link encryption performed, the following data packet, we can see from the second machine in response, sent a LL_Reject_Rsp, a beginning not know the meaning of this package, but Reject obviously not a good thing, compared to a normal response packet, where it should be Start_Encryption Req fishes, after many experiments that, iOS 5 system heavy bursts of encryption times when requests are received LL_Reject_Rsp, will not even return to the slave (apple yet to find related resources), then, my idea is to look at the pairing information not from the host machine, to host initiate pairing, and requires the user to re-confirm the pairing.
Dm in the core operating module: dm_security_setup_req()initiating a pairing request to the host.
This solution can basically solve this problem, but if the user does not have enough time to produce at the phone and confirm the pairing and reconnection times more than 5 times in a row, the system will stop or even back from the machine.
