原文：https://blog.csdn.net/wenshifang/article/details/100038433
BLE的配對是一個比較繁瑣的過程，需要熟悉規範，只有明白其中的原理才能更好的理解這個過程。
首先需要明確一點：配對的目的是爲了加密通訊鏈路，保證數據安全，綁定是爲了簡化配對流程。
配對綁定過程說明：
1 配對信息的交換
2 生成STK(短期祕鑰)加密鏈路
3 鏈路加密後就可以安全分發各種祕鑰了，如果需要綁定，那麼也會生成LTK(長期祕鑰），雙方都會存儲LTK。
4 LTK分配之後，每次重新連接時雙方用LTK與會話祕鑰分散器等其他信息最終生成一個會話祕鑰，真正的加密是用這個會話祕鑰，其實這點也與大多數加密機制類似。
下面簡單分析一下nrf協議棧中關於配對部分的流程。
在NRF52832（SDK 11.0 softdevice s132）中與鏈路安全相關的事件：
BLE_GAP_EVT_SEC_PARAMS_REQUEST
BLE_GAP_EVT_SEC_INFO_REQUEST
BLE_GAP_EVT_CONN_SEC_UPDATE
BLE_GAP_EVT_AUTH_STATUS
（1）在配對信息交換階段，BLE_GAP_EVT_SEC_PARAMS_REQUEST事件會由協議棧上報給應用層:
（2）在這個事件中，從機會把自己的信息與主機進行交換，其中就包含了從機的IO能力、配對完成是否綁定等（在sd_ble_gap_sec_params_reply第三個參數定義）信息。
1） 如果指定了從機具有顯示能力，即BLE_GAP_IO_CAPS_DISPLAY_ONLY，那麼調用sd_ble_gap_sec_params_reply後，應用層會收到BLE_GAP_EVT_PASSKEY_DISPLAY事件，從機將協議棧生成的隨機密碼顯示到屏幕即可，此時主機也會出現一個配對框，用戶輸入從機顯示的密碼即可完成配對。若從機沒有輸出能力，那麼可以指定爲BLE_GAP_IO_CAPS_NONE,此時主機不再要求輸入密碼，而是詢問是否同意配對。若密碼匹配或用戶同意配對，那麼配對過程繼續，直到協議棧上報BLE_GAP_EVT_CONN_SEC_UPDATE事件代表配對成功：
2.如果指定配對完成後綁定，那麼協議棧會進行LTK的分發，祕鑰分發完成後，協議棧會上報BLE_GAP_EVT_AUTH_STATUS事件表示：
（3）LTK分發完成後，從機可以將協議棧返回相關祕鑰信息保存下來：
至此整個配對綁定過程完成。
下面再分析一下，當鏈路重新建立時的情況。
上面提到，綁定操作是爲了簡化配對流程。當雙方都保存有配對信息時（最重要的是LTK），可以直接使用LTK參與會話祕鑰的生成，一般情況下，主機會發起加密請求，從機會響應加密請求，在nrf協議棧中，相關事件是BLE_GAP_EVT_SEC_INFO_REQUEST:
收到BLE_GAP_EVT_SEC_INFO_REQUEST事件後，從機會查詢本地有沒有當前連接的主機相關祕鑰信息，並把查詢結果傳遞到協議棧給主機迴應。那麼到底是以什麼作爲匹配標準來查詢這個祕鑰信息呢，首先想到的是主機的MAC，沒錯，確實是MAC地址，但是除了MAC地址，還有一項diversifier（分散器）,記爲EDIV：
如果單單是MAC地址，就無法解釋iOS系統Private Non-Resolvable address的現象：iOS每次重啓系統或重啓藍牙，BLE的MAC地址都會被改變，話說是爲了防止設備被追蹤。
diversifier的值由發起配對的一方傳送，接收的一端進行匹配，除了diversifier之外，還有隨機數Rand、初始向量IV等與加密相關的參數隨着加密請求LL_Encryption Req發送給對方。
一旦匹配成功，後續通訊鏈路就可以進入加密狀態，下面是通過空中抓包關於主機發起加密的過程：
可以看到，在M->S的加密請求包中，包含了4個域，都是與加密相關的字段，其中一項就是EDIV，隨後S->M的加密響應中，從機向主機傳送了自己的STK和IV，主從雙方準備好之後，從機發起開始加密請求，在隨後的數據包中，協議分析軟件顯示多了一項Security_Enabled，可知鏈路已進入了加密狀態。
如若一切順利，上述過程沒有什麼問題，一旦一個環節出錯，配對就無法完成了。例如當從機保存的配對信息失效了（一般會保存在Flash中，Flash並不是百分之百可靠），就無法再正確的進行鏈路加密。
在我的這個案例中，從機是nrf52832，主機是iOS系統，業務流程簡單：
從機通過用戶app配對完成後，可以脫離app而獨立工作，並接收ANCS消息。
在測試過程中發現，主機在斷線後（時間和次數不確定），不再主動連接從機，手動連接從機後，ANCS通知也不正常，並且再次斷線後也不會回連。
經過無數次的問度娘，也沒有找到相關的問題，最後無奈，只能使出殺手鐗：通過抓包分析
可以看到，主機在連接上從機後與從機交換了協議版本信息，接着就發送了一條加密請求，要求從機進行鏈路加密，後面的數據包中，我們看到從機第二次迴應時，發送了一個LL_Reject_Rsp，一開始不知道這個包的含義，但是Reject明顯不是什麼好事，對比正常的響應包，此處應該是Start_Encryption Req纔對，經過多次實驗得知，iOS系統在5次重連發加密請求都收到LL_Reject_Rsp時，就不會再回連該從機（目前還沒找到apple相關資源）， 那麼，我的思路就是在從機查找不到主機的配對信息時，向主機發起配對請求，要求用戶重新確認並配對。
核心操作就在dm模塊：dm_security_setup_req()，向主機發起配對請求。
這個方案基本上可以解決這個問題，但如果用戶沒有來得及產看手機並確認配對，且重連次數連續超過5次，系統還是會停止回連從機。