オリジナル：https://blog.csdn.net/wenshifang/article/details/100038433
BLEペアリングは、より面倒なプロセス、唯一の原理は、より良い、このプロセスを理解することです理解し、身近な規範である必要があります。
最初の必要性は明確にする：ペアリングの目的は、通信リンクを暗号化するために、ペアリングプロセスを簡素化するためにバインディング、データのセキュリティを確保することです。
説明は、綴じ処理をペア：
の情報を1組の交換
2世代STK（短期秘密鍵）暗号化リンク
暗号化が結合に必要ならば、それはまた、LTK（長期秘密を生成する、各種のキー3つのリンクの後に分布を確保することができますキー）は、双方が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のホストである情報を照会するために標準として一致するもので、EDIVと呼ばdiversifier（分散）、があります：
ちょうどMACアドレスならば、それは現象のiOSシステムプライベート解像不可能なアドレスは説明することはできません。それぞれのリブートシステムのiOSやBluetoothを再起動し、BLEのMACアドレスがからデバイスを防ぐために追跡されていることを言って、変更されます。
diversifier添加を照合することによって開始ペア受信側によって送信された1つのdiversifier値、初期ベクトルIV LL_Encryption REQが相手に要求を暗号化されたように、暗号化乱数RAND、等に関連するパラメータがあります。
一致が見つかったら、フォローアップの通信リンクは、取得プロセスがホストの暗号化で開始された空気のパケット以下、暗号化の状態を入力することができます。
これは、M-> S要求パケットが4つのドメインがEDIV、後続S-> M、マスタースレーブの送信に暗号化された応答である一方は暗号化されたフィールドに関連付けられている含ま暗号化に見ることができます両側後の彼のSTKおよびIV、マスター・スレーブは、後続のパケットに、暗号化要求を開始するために、マシンから始めて、準備ができている、プロトコル解析ソフトウェアのショーよりSecurity_Enabledよりも、明確なリンクの暗号化の状態に入りました。
すべてがうまくいけば、上記のプロセスは何の問題は、リンク・エラーと、ペアリングが完了することができない、ではありません。（通常はフラッシュに保存され、フラッシュが100％信頼できるものではありません）の障害からマシンに格納されている情報をペアリングする場合例えば、それはリンク暗号化のために正しいことはできません。
私の場合、このスレーブはホストがiOSのシステムで、nrf52832である、ビジネスは簡単に処理：
スレーブのユーザアプリでペアリングが完了すると、アプリ、ANCSから独立して動作し、メッセージを受け取ることができた後。
テスト中にホスト（時間と周波数の不確実性）休憩の後、マシン、マシンからの手動のアクティブな接続はもはやであることがわかっていない、ANCS通知は正常ではない、と再び休憩後にも戻りません。
あなたのお母さんの程度は、何度も尋ねたが、関連する問題を見つけることができなかった、そして最終的に選択の余地はなくキラーに頼っていない後：パケットキャプチャ解析によって
次のデータパケットを実施し、我々は第二のマシンから見ることができ、それがスレーブリンク暗号化に暗号化された要求を送信し、スレーブ交換プロトコルのバージョン情報に関連して、ホストマシンから見ることができます応じて、というのiOS 5のシステムこのパッケージの意味を知らないが、それはStart_Encryption必須の魚である必要があり、通常の応答パケットに比べて、明らかに良いことをしませ拒否、多くの実験後に始まる、LL_Reject_Rspを送りました要求がLL_Reject_Rspを受信した暗号化時代の重いバーストが、でも（関連するリソースを見つけるために、まだリンゴ）、スレーブには戻りません、そして、私の考えはに、ないホストマシンからのペアリング情報を見ることですホストは、ペアリングを開始し、再確認ペアリングにユーザーが必要です。
コアオペレーティングモジュールにDM：dm_security_setup_req()ホストへのペアリング要求を開始します。
このソリューションは、基本的にこの問題を解決することができますが、ユーザが電話で生成するために十分な時間を持っており、行のペアリングと再接続倍以上5倍を確認していない場合、システムは、さらにバックマシンから停止またはます。
