什么是低功耗藍牙配對？什么又是綁定？

什么是低功耗藍牙配對？什么又是綁定？配對和綁定有什么區(qū)別？配對有什么好處？如何刪除綁定信息？如何確定配對的安全等級？just work的配對一定就不安全嗎？如何開發(fā)自己的配對應用？本文將對以上問題進行論述。

Paring（配對）和bonding（綁定）是實現(xiàn)藍牙射頻通信安全的一種機制，有兩點需要注意：

一是paring/bonding實現(xiàn)的是藍牙鏈路層的安全，對應用來說完全透明，也就是說，不管有沒有paring/bonding，你發(fā)送或接收應用數(shù)據(jù)的方式是一樣的，不會因為加了paring/bonding應用數(shù)據(jù)傳輸需要做某些特殊處理；

二安全有兩種選項：加密或者簽名，目前絕大多數(shù)應用都是選擇加密，后續(xù)我們也會以加密為重點進行講述

實現(xiàn)藍牙通信安全，除了paring/bonding這種底層方式，用戶也可以在應用層去實現(xiàn)相同功能，兩者從功能上和安全性上沒有本質區(qū)別，只不過應用層自己實現(xiàn)的話，需要自己選擇密碼算法，密鑰生成，密鑰交換等，如果你不是這方面的專家，你的應用就有可能會存在安全漏洞。Paring/bonding則把上述過程標準化，放在了藍牙協(xié)議棧中，并且其安全性得到了充分評估，用戶可以 “無感的” 用上安全的藍牙通信。

Paring/bonding是藍牙security manager（SM）的一部分，SM定義了藍牙通信的安全框架，里面涉及安全架構，密碼工具箱，paring協(xié)議等，其中paring協(xié)議是關鍵，所以我們經(jīng)常把paring和SM二者等價，下面將對paring進行詳細闡述。

1、基本概念解讀

°Paring（配對）

配對包括配對能力交換，設備認證，密鑰生成，連接加密以及機密信息分發(fā)等過程，配對的目的有三個：加密連接，認證設備，以及生成密鑰。從手機角度看，一旦設備跟手機配對成功，藍牙配置菜單將包含該配對設備，如下所示：

如果用戶需要主動刪除配對設備，點擊配對設備右邊的“設置”菜單，出現(xiàn)如下界面，選擇“取消配對”或者“忽略該設備”，設備的配對信息即被手機刪除。

°

Bonding（綁定）

配對過程中會生成一個長期密鑰（LTK，long-term Key），如果配對雙方把這個LTK存儲起來放在Flash中，那么這兩個設備再次重連的時候，就可以跳過配對流程，而直接使用LTK對藍牙連接進行加密，設備的這種狀態(tài)稱為bonding。

如果paring過程中不存儲LTK（不分發(fā)LTK）也是可以的，paring完成后連接也是加密的，但是如果兩個設備再次重連，那么就需要重走一次paring流程，否則兩者還是明文通信。

在不引起誤解的情況下，我們經(jīng)常把paring當成paring和bonding兩者的組合，因為只paring不bonding的應用情況非常少見。在不引起混淆的情況下，下文就不區(qū)分paring和bonding的區(qū)別，換句話說，我們會把paring和bonding兩個概念等同起來進行混用。

°SM（security manager）

藍牙協(xié)議棧的安全管理層，規(guī)定了跟藍牙安全通信有關的所有要素，包括paring，bonding，以及下文提到的SMP。

°SMP（security manager protocol）

安全管理協(xié)議，SMP著重兩個設備之間的藍牙交互命令序列，對paring的空中包進行了嚴格時序規(guī)定。

°OOB（out of band，帶外）

OOB就是不通過藍牙射頻本身來交互，而是通過比如人眼，NFC，UART等帶外方式來交互配對信息，在這里人眼，NFC，UART通信方式就被稱為OOB通信方式。

°Passkey

又稱pin碼，是指用戶在鍵盤中輸入的一串數(shù)字，以達到認證設備的目的。低功耗藍牙的passkey必須為6位。

°Numeric comparison（數(shù)字比較）

Numeric comparison其實跟passkey一樣，也是用來認證設備的，只不過passkey是通過鍵盤輸入的，而numeric comparison是顯示在顯示器上的，numeric comparison也必須是6位的數(shù)字。

°MITM（man in the middle）

MITM是指A和B通信過程中，C會插入進來以模擬A或者B，并且具備截獲和篡改A和B之間所有通信報文的能力，從而達到讓A或者B信任它，以至于錯把C當成B或者A來通信。

如果對安全要求比較高，需要具備MITM保護能力，在SM中這個是通過認證（authentication）來實現(xiàn)的，SM中實現(xiàn)認證的方式有三種：OOB認證信息，passkey以及numeric comparison，大家根據(jù)自己的實際情況，選擇其中一種即可。

°LESC（LE secure connections）

又稱SC，藍牙4.2引入的一種新的密鑰生成方式和驗證方式，SC通過基于橢圓曲線的Diffie-Hellman密鑰交換算法來生成設備A和B的共享密鑰，此密鑰生成過程中需要用到公私鑰對，以及其他的密碼算法庫。

LESC同時還規(guī)定了相應的通信協(xié)議以生成該密鑰，并驗證該密鑰。需要注意的是LESC對paring的其他方面也會產生一定的影響，所以我們經(jīng)常會把LESC看成是一種新的配對方式。

°Legacy paring

在LESC引入之前的密鑰生成方式，稱為legacy paring，換句話說，legacy paring是相對LESC來說的，不支持LESC的配對即為legacy paring（legacy配對）。

°TK（Temporary Key，臨時密鑰）

legacy paring里面的概念，如果采用just work配對方式，TK就是為全0；如果采用passkey配對方式，TK就是passkey；如果采用OOB配對方式，TK就是OOB里面的信息。

°STK（short term key，短期密鑰）

legacy配對里面的概念，STK是通過TK推導出來的，通過TK對設備A和B的隨機數(shù)進行加密，即得到STK。

°LTK（long term key，長期密鑰）

legacy配對和LESC配對都會用到LTK，如前所述，LTK是用來對未來的連接進行加密和解密用的。Legacy paring中的LTK由從設備根據(jù)相應的算法自己生成的（LTK生成過程中會用到EDIV（分散因子）和Rand（隨機數(shù)）），然后通過藍牙空中包傳給主機。

LESC配對過程中，先通過Diffie-Hellman生成一個共享密鑰，然后這個共享密鑰再對設備A和B的藍牙地址和隨機數(shù)進行加密，從而得到LTK，LTK由設備A和B各自同時生成，因此LTK不會出現(xiàn)在LESC藍牙空中包中，大大提高了藍牙通信的安全性。

°IRK（Identity Resolving Key，藍牙設備地址解析密鑰）

有些藍牙設備的地址為可解析的隨機地址，比如iPhone手機，由于他們的地址隨著時間會變化，那如何確定這些變化的地址都來自同一個設備呢？

答案就是IRK，IRK通過解析變化的地址的規(guī)律，從而確定這些地址是否來自同一個設備，換句話說，IRK可以用來識別藍牙設備身份，因此其也稱為Identity information。IRK一般由設備出廠的時候按照一定要求自動生成。

°Identity Address（設備唯一地址）

藍牙設備地址包括public，random static， private resolvable，random unresolved共四類。

如果設備不支持privacy，那么identity address就等于public或者random static設備地址。

如果設備支持privacy，即使用private resolvable藍牙設備地址，在這種情況下，雖然其地址每隔一段時間會變化一次，但是identity address仍然保持不變，其取值還是等于內在的public或者random static設備地址。

Identity Address和IRK都可以用來唯一標識一個藍牙設備。

°IO capabilities（輸入輸出能力）

是指藍牙設備的輸入輸出能力，比如是否有鍵盤，是否有顯示器，是否可以輸入Yes/No兩個確認值。

°Key size（密鑰長度）

一般來說，密鑰默認長度為16字節(jié)，為了適應一些低端的藍牙設備處理能力，你也可以把密鑰長度調低，比如變?yōu)?0個字節(jié)。

2、Paring流程及命令

°Paring包含三個階段：1、階段1：配對特性交換，即交換各自都支持哪些配對特性，比如支不支持SC，支不支持MITM，支不支持OOB，以及它的輸入輸出能力等。2、階段2：密鑰生成階段，legacy paring和LESC paring兩者的區(qū)別就在這里，因此后續(xù)我們會分開闡述legacy paring和SC paring的階段2。

Legacy paring：STK生成（注：legacy paring的LTK生成跟配對流程無關，如前所述，其是由從機自己生成的）

SC paring：LTK生成

3、階段3：通過藍牙空中包分發(fā)一些秘密信息。Legacy paring需要分發(fā)LTK，IRK等，而SC paring只需分發(fā)IRK。秘密信息分發(fā)之前，必須保證連接已加密。 °Paring流程如下所示：

2.1階段1：配對特性交換Paring流程及命令

°配對特性交換涉及三條PDU命令：1、Paring_Request：

2、Paring_Response：

3、Security_Request：

°IO Capability占一個字節(jié)，其定義如下所示：

°AuthReq也是占用一個字節(jié)，其定義如下所示：

2.2階段2：密鑰生成

°根據(jù)階段1的IO輸入輸出能力以及是否存在OOB，階段2存在如下幾種配對方式（或者說認證方式）：

Just works

Numeric comparison（LESC才有）

Passkey

OOB

對于legacy paring，如果A和B都支持OOB，那么兩者就會采用OOB方式進行配對，否則根據(jù)IO能力選擇配對方式。對于SC paring，如果A或者B有一方支持OOB，那么兩者就會采用OOB方式進行配對，否則根據(jù)IO能力選擇配對方式。不同的IO能力對應的配對方式如下所示。

粗略來說，有認證的配對方式就具備MITM保護功能，從IO角度看，有三種配對方式：just works，passkey和Numeric Comparison，其中just works沒有MITM保護功能，而passkey和Numeric comparison具備MITM保護功能。換句話說，如果你要求你的設備具備MITM保護功能，那么它必須有一定IO能力，而不能是“NoInputNoOutput”。至于OOB方式有沒有MITM保護，取決于OOB通信的安全性，如果OOB通信具備MITM保護，那么藍牙也具備MITM保護，否則就不具備。

下面分legacy paring和sc paring對配對流程進行講解。

2.2.1 legacy paring

°Legacy paring整個配對流程是圍繞STK生成來做的： 設備的認證是通過設備A和B經(jīng)由TK生成一個確認數(shù)，如果這個確認數(shù)相同，則認證通過。 如前所述，legacy paring需要先生成TK，TK的生成方式取決于配對方式：

Just works。TK默認為全0

Passkey。TK由6位passkey擴展而來

OOB。TK直接由OOB數(shù)據(jù)提供

°然后生成確認數(shù)，算法如下所示：

°生成STK的算法如下所示：

°以passkey legacy paring為例，其第2階段全工作流程如下所示：

Just works和OOB配對流程就不再贅述了，大家自己去看一下藍牙核心規(guī)范的說明。

這里強調一下，配對完成之后，連接就會加密，而且加密的密鑰是STK，而不是LTK。

對于legacy paring，如果A和B都支持OOB，那么兩者就會采用OOB方式進行配對，否則根據(jù)IO能力選擇配對方式。對于SC paring，如果A或者B有一方支持OOB，那么兩者就會采用OOB方式進行配對，否則根據(jù)IO能力選擇配對方式。不同的IO能力對應的配對方式如下所示。

2.2.2LESC paring

°跟legacy paring不一樣的地方： LESC paring是通過Diffie-Hellman算法直接生成LTK，因此它不需要生成TK和STK。為了生成LTK，雙方需要先交換公鑰，流程如下所示：

公鑰交換后，設備A和B就開始獨自計算各自的DHKey，按照D-H算法，他們倆算出的DHKey會是同一個。而LTK和MacKey就是通過這個DHKey加密一系列數(shù)據(jù)而得到的。

Legacy paring在整個配對流程中只做一次認證，而LESC paring會做兩次認證。LESC第一階段認證的原理是，設備A和B各生成一個隨機數(shù)，然后認證這個隨機數(shù)對不對。LESC第二階段認證過程是：設備A和B通過MacKey各生成一個檢查值，對方確認這個值對不對。

以LESC Numeric comparison為例，其第一階段認證流程如下所示：

我們還是以LESC Numeric comparison為例，其第二階段全工作流程如下所示：

一旦LTK生成成功，主機端就可以發(fā)起加密連接流程，如下所示：

至此，LESC連接被LTK加密了，后面就可以分發(fā)秘密信息了。

2.3 階段3：秘密信息分發(fā)

°一旦連接加密了，主機和從機之間就可以分發(fā)一些秘密信息。如果是legacy paring，如下秘密信息必須分發(fā)：

LTK

EDIV

Rand

°同時根據(jù)情況，legacy paring還需分發(fā)如下信息：

IRK

Identity adresss

°對于LESC paring，秘密信息分發(fā)是可選，一般有可能分發(fā)如下信息：

IRK

Identity adresss

如下為legacy paring可能分發(fā)的最多秘密信息的一個例子：

2.4 綁定，重連和加密

°如果配對的兩個設備生成了LTK及其他秘密信息： 如上所述，如果配對的兩個設備生成了LTK及其他秘密信息，并且把LTK及其他秘密信息保存到Flash等永久化存儲設備中，那么我們就可以說這兩個設備綁定成功。換句話說，paring和bonding是兩個不同的概念，paring更強調認證和密鑰生成，而bonding更強調密鑰保存。一旦兩個設備bonding成功，那么這兩個設備斷開再次重連的時候，主機就可以發(fā)起加密流程，從而使用paring生成的LTK對后續(xù)的連接進行加密。主機發(fā)出加密連接流程如下所示：

這里說明一下，加密連接只能由主機發(fā)出，而不能由從機發(fā)起。不過從機可以發(fā)出加密請求，主機收到從機的加密請求后，可以發(fā)起加密連接也可以拒絕其請求。如下為主機同意從機的加密請求的工作流程：

2.5 配對命令一覽表

°如下為SM中用的PDU命令列表： （注：加密連接命令屬于LL控制命令，所以沒有包含在其中）

3. Nordic SDK配對流程

°如下為SM中用的PDU命令列表： 那么如何實現(xiàn)這個配對流程呢？也就是說，我該調用哪些API去實現(xiàn)配對流程，這些API調用的順序又是如何，具體會產生哪些協(xié)議棧事件，該如何處理這些協(xié)議棧事件，這就涉及到協(xié)議棧的實現(xiàn)。

Nordic藍牙協(xié)議棧softdevice提供詳細的工作流程圖，以指導用戶如何調用softdevice API去實現(xiàn)想要的配對流程，詳細的配對流程圖請參考infocenter如下界面：

比如S132協(xié)議棧，其從機端配對流程圖鏈接為：https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.s132.api.v7.0.1%2Fgroup___b_l_e___g_a_p___p_e_r_i_p_h___s_e_c___m_s_c.html。

以legacy paring，從機端顯示passkey，主機端輸入passkey為例，softdevice的配對流程圖如下所示，鏈接為：https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.s132.api.v7.0.1%2Fgroup___b_l_e___g_a_p___p_e_r_i_p_h___b_o_n_d_i_n_g___p_k___p_e_r_i_p_h___m_s_c.html

上述配對流程圖把用到的API，產生的softdevice事件，以及softdevice事件如何處理，都一一闡明，大家只要按照這個流程圖來做，就可以完成期望的配對。更讓人省心的是，Nordic SDK已經(jīng)把幾種典型的配對場景做成了例子，大家可以直接就拿過來用，連上面的配對流程圖都不用看，就可以輕松完成自己的配對應用。

Nordic提供的配對例子有：ble_app_hids_keyboard，ble_app_hrs，ble_app_gls，ble_app_bps，ble_app_bms，ble_app_cscs，ble_app_hrs_nfc_pairing，experimental_ble_app_hrs_nfc_pairing，ble_app_hids_keyboard_pairing_nfc，ble_app_multirole_lesc等，基本上囊括了藍牙各種配對情況。

后面會以ble_app_hrs為例來詳細講解如何實現(xiàn)低功耗藍牙配對

4. 配對例程ble_app_hrs解讀

°nRF5 SDK把藍牙配對做成了一個模塊： peer_manager，也就是說，所有關于paring的工作都由peer manager自動完成，用戶無需去了解softdevice底層API的使用方法，大家直接參考nRF5 SDK里面的例程就可以完成自己的配對應用開發(fā)。

nRF5 SDK提供的配對例子有：ble_app_hids_keyboard，ble_app_hrs，ble_app_gls，ble_app_bps，ble_app_bms，ble_app_cscs，ble_app_hrs_nfc_pairing，experimental_ble_app_hrs_nfc_pairing，ble_app_hids_keyboard_pairing_nfc，ble_app_multirole_lesc等，基本上囊括了藍牙各種配對情況，下面將和大家一起來解讀ble_app_hrs配對相關代碼

如果你對Nordic nRF5 SDK和softdevice不是很熟的話，建議你先看一下這篇文章：手把手教你開發(fā) BLE 數(shù)據(jù)透傳應用程序 ，以建立Nordic開發(fā)的一些基礎知識，然后再往下看。 跟沒有paring的ble應用代碼相比，有paring的ble應用只多了一個初始化函數(shù)：peer_manager_init()，peer_manager_init實現(xiàn)代碼如下所示：

peer_manager_init里面注冊了一個回調函數(shù)：pm_evt_handler，用來添加一些用戶自定義的處理，例子代碼pm_evt_handler的實現(xiàn)如下所示：

至此，一個just works的藍牙配對例子就算完成了，是不是有點懵？感覺太簡單了以至于有點接受不了。沒關系，下面我們在這個例子上加一些額外的功能，以加深大家對它的理解。

5. 改變ble_app_hrs配對方式

°把ble_app_hrs配對方式改成LESC with numeric comparison： 原始ble_app_hrs為just work方式的LESC配對，我們現(xiàn)在把它改成最高安全級別的numeric comparison LESC。我們的開發(fā)板沒有顯示器，因此我們將通過日志的方式把數(shù)字比較值輸出，同時把button3的按下作為yes確認，button4的按下作為reject確認。

何實現(xiàn)numeric comparison？前面我也提過，如果SDK有現(xiàn)成的例子，直接參考例子來；如果SDK沒有現(xiàn)成的例子，那么就參考softdevice工作時序圖。關于LESC numeric comparison，從機端的工作流程如下所示：https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.s132.api.v7.0.1%2Fgroup___b_l_e___g_a_p___p_e_r_i_p_h___l_e_s_c___b_o_n_d_i_n_g___n_c___m_s_c.html

這里要強調一下，時序圖會把有可能需要用到事件和API都列出來，但不意味著列出來的事件和API都需要你那哪些事件和API需要用戶自己處理呢？一個原則：全文搜索一下，只要peer manager已經(jīng)調用過的API，你就不用處理；而流程圖中剩下的API就需要你自己去處理了。

比如上面這個例子，sd_ble_gap_sec_params_reply已經(jīng)被peer manager模塊處理了，所以你不用處理；而BLE_GAP_EVT_PASSKEY_DISPLAY和sd_ble_gap_auth_key_reply只在passkey和numeric comparison配對方式中才會出現(xiàn)，peer manager沒有對其進行處理，因此需要用戶自己處理。為此，我們在ble_evt_handler中加上分支：BLE_GAP_EVT_PASSKEY_DISPLAY，并按照流程圖的要求加上相應的處理，代碼如下所示：

上面只是顯示了passkey，如前所述，如果button3按下我們回復BLE_GAP_AUTH_KEY_TYPE_PASSKEY；如果button4按下我們回復BLE_GAP_AUTH_KEY_TYPE_NONE。相關代碼如下所示：

如前所述，配對方式是由IO輸入輸出能力確定的，而且numeric comparison是具備MITM能力的，為此我們還需要修改如下兩個地方：

蘋果手機是不能手動發(fā)起配對請求的，為了讓蘋果手機自動發(fā)起配對請求，我們將如下characteristic的安全級別提高：（注：除了這種方法，我們也可以通過從機主動發(fā)起安全請求來達到同樣的目的）。

我這里以PCA10040/Keil5工程為例來編譯，請編譯工程：nRF5SDK160098a08e2examplesle_peripheralle_app_hrspca10040s132arm5_no_packs。

將編譯好的代碼下載到開發(fā)板中，測試的時候，我們先連接開發(fā)板，然后使能CCCD，此時不管Android手機還是蘋果手機，都會跳出配對對話框，同時顯示出配對碼，如下：

開發(fā)板也把配對碼打印出來了，如果兩者一致，按下button3，整個配對流程順利完成，開發(fā)板會打印如下信息：

上述代碼已上傳到百度云盤，大家可以去百度云盤下載：

代碼鏈接

鏈接：https://pan.baidu.com/s/1FKTfY3Q_zBVvviO7KC7Gyg#list/path=%2Fblog

密碼：y8fb

ble_app_hrs_nc.rar，然后解壓縮到SDK根目錄examplesble_peripheral，打開Keil5工程：

SDK根目錄examplesble_peripheral ble_app_hrs_ncpca10040s132arm5_no_packs，就可以直接編譯和運行。

6. 關于配對的一些小貼士

°蘋果手機的一點不同： 安卓手機允許用戶手動發(fā)起paring請求，而蘋果手機則沒有這個功能。因此，即使你的characteristic沒有使能安全級別，安卓手機還是可以跟你的設備完成配對的，而蘋果手機則不支持這個功能，蘋果手機要不要跟設備進行配對，不能由人來控制的，只能由蘋果iOS來控制。 欲觸發(fā)蘋果iOS發(fā)起配對請求，有兩種方法：

一是將某個characteristic加上安全認證權限，這樣iOS在服務發(fā)現(xiàn)過程中就會自動發(fā)起配對請求，以滿足characteristic的安全認證級別；

二是從機端主動發(fā)起安全請求，iOS收到從機的安全請求后，會等待用戶的授權確認從而發(fā)起配對請求。這兩種方法在ble_app_gls中都有體現(xiàn)，大家可以參考相關代碼。

°重連加密等級： 綁定成功后，如果發(fā)生重連，那么主機應該自動發(fā)起加密連接請求，以對連接進行加密。一般來說，在連接沒有成功加密前，主從機不要做敏感數(shù)據(jù)的交互，否則softdevice API會報NRF_ERROR_FORBIDDEN。對于有MITM保護的加密連接，在收到PM_EVT_CONN_SEC_SUCCEEDED這個事件后，設備應該去檢測連接的安全等級是否符合要求，具體可參考ble_app_gls例子的做法。 °Servicechanged（服務改變）： 設備跟手機綁定成功后，手機再次重連這個設備時，就會自動跳過service discovery過程，換句話說，配對的時候手機會把設備所有服務和characteristic的handle保存下來，二次重連的時候，直接用以前保存的handle值去操作設備。

但是，如果設備的服務改變了，此時手機再用之前的handle去操作設備，就會出問題。為了解決這個問題，在GATT主服務里面引入了service changed characteristic，如下所示：

有了這個characteristic，當設備的服務發(fā)生改變時，設備就可以通過這個characteristic發(fā)送一個indicate PDU給到手機，從而手機知道設備的服務已發(fā)生了改變，此時手機會重新發(fā)起service discovery流程，以重新獲得service和characteristic最新的handle列表。欲添加service changed characteristic，你只需在sdk_config.h文件中打開如下兩個宏：

然后當服務發(fā)生改變時，調用pm_local_database_has_changed()，協(xié)議棧就會自動發(fā)起service changed indicate PDU給手機，從而引起手機重走服務發(fā)現(xiàn)過程。

°刪除主機端綁定信息： 如果手機端刪除了綁定信息，為了安全起見，設備端也需要跟著一起刪除綁定信息，否則手機無法再次跟設備進行配對，這個是最理想的情況，但是我們有的設備沒有任何輸入接口，無法手動刪除綁定信息，這個時候能不能有一種辦法可以讓手機跟設備進行二次配對呢？

為此，Nordic提供了一種workaround，在藍牙事件回調函數(shù)里面，加上如下代碼即可：

if(p_evt->evt_id== PM_EVT_CONN_SEC_CONFIG_REQ)

{

pm_conn_sec_config_tcfg;

cfg.allow_repairing=true;

pm_conn_sec_config_reply(p_evt->conn_handle, &cfg);

}

這樣，即使用戶把手機端paring信息刪掉，設備端paring信息沒有刪掉，手機還是可以跟設備進行二次配對的。

°刪除從機端綁定信息： 跟上面相反，如果設備端bonding信息被刪除了，而手機端bonding信息沒有被刪除，這種情況下如何實現(xiàn)二次配對？

最安全的方式，讓用戶主動刪除手機端綁定信息，但是很多開發(fā)者希望，用戶體驗好一點，也就是說，碰到這種情況希望手機能自動刪除綁定信息，這個能不能實現(xiàn)跟手機有很大關系，首先我們確保協(xié)議棧返回LL_REJECT_IND or LL_REJECT_EXT_IND，錯誤碼為“PIN or key missing”，一般而言，手機收到這個PDU后，都會自動刪除bonding信息。

如果上述方法行不通的話，那么發(fā)送完LL_REJECT_IND后再調用斷開函數(shù)（sd_ble_gap_disconnect），同時將斷開原因設為BLE_HCI_AUTHENTICATION_FAILURE即可。

°同時綁定多個設備： Nordic SDK是支持一個設備同時跟多個主機綁定，只要設備存儲空間足夠大，那么可以綁定的設備數(shù)就不設限。nRF5 SDK中bonding信息也是通過fds來存儲的，也就是說綁定信息和用戶Flash數(shù)據(jù)共享同一塊空間，如果需要綁定多個設備，那么FDS_VIRTUAL_PAGES這個宏的值必須進行修改，以保證分配的Flash空間可以同時容納bonding信息和用戶Flash數(shù)據(jù)。

一般來說，如果需要綁定多個設備，請設置一個最大綁定數(shù)，比如8個，這樣，一旦檢測到綁定數(shù)達到8了，就可以把以前老的bonding設備刪除，從而節(jié)省存儲空間。那如何知道哪個設備是老設備哪個設備是新設備？這個是通過peer rank來實現(xiàn)的，大家只要使能PM_PEER_RANKS_ENABLED這個宏，就可以自動實現(xiàn)排序。

°循環(huán)綁定測試： 很多開發(fā)者喜歡做循環(huán)綁定測試，即同一部手機不斷跟同一個設備進行配對，然后刪除配對信息，然后再進行配對，他們測試下來發(fā)現(xiàn)：

達到一定次數(shù)后，設備就工作不正常了，這個是由于當bonding信息不斷累積而不進行刪除的話，那么分配給fds的Flash空間就會耗盡，從而導致異常出現(xiàn)（最新的SDK會在Flash存儲空間耗盡時，自動刪除最老設備的綁定信息，但即使這樣，對用戶Flash數(shù)據(jù)的操作影響還是很大）。

解決這個問題的方法就是設定一個最大bonding數(shù)，達到這個數(shù)目后，刪除老bonding信息，從而達到循環(huán)利用Flash空間的目的。當然如果你的fds只是用來存儲bonding信息而不做其他用戶數(shù)據(jù)操作的話，那么就沒有必要加上這個功能了。

°白名單與綁定： 雖然白名單和綁定二者沒有任何聯(lián)系，但是我們一般都把兩者結合起來一起使用，以達到我們的使用期望。當兩個設備綁定成功后，我們就可以將對方的mac地址或者IRK放入白名單中，同時開啟白名單廣播，這樣設備只跟白名單中的主機進行連接，白名單以外的設備在controller層面就被過濾掉了，從而提高私密性以及連接效率。

這種情況下，哪怕是合法的設備，如果之前沒有跟設備綁定，那么它也無法跟設備建立連接。換句話說，如果你想把新設備加入到白名單中，那么首先需要禁止白名單廣播而采用普通廣播，然后跟新設備進行配對，成功后再把新設備身份信息加入到白名單中。白名單與綁定的例子具體可參考：ble_app_hids_keyboard。

°Authenticated payloadtimeout： 大家都知道藍牙連接有一個supervision timeout時間，也就是說，當建立連接的兩個設備，任何一方在supervision timeout（比如4s）時間內，沒有給對方發(fā)送任何藍牙空口包，此時認為連接已斷開，并觸發(fā)supervision timeout事件。

當設備雙方建立加密連接后，不僅有上述的supervision timeout，還有一個authenticated payload timeout，authenticated payload timeout默認為30s，它的意思是，兩個設備加密后，30s內必須有一個有數(shù)據(jù)的空口包交互，而不能一直發(fā)空包，否則認為authenticated payload timeout。

Authenticated payload timeout是協(xié)議棧自動管理的，對軟件開發(fā)來說是透明的，每30s時間到，如果期間沒有任何有效數(shù)據(jù)包交互（一直在發(fā)空包），協(xié)議棧會自動發(fā)送一個ping request給對方，以避免authenticated payload timeout的出現(xiàn)（注：這里的協(xié)議棧既可以是設備的協(xié)議棧，也可以是手機的協(xié)議棧）。

有時候不想等到30s超時到了再發(fā)送ping request，大家可以在connected事件中，調用如下API以提前發(fā)出ping request。

當然，如果你能保證每30s時間內，手機和設備之間肯定會有有效數(shù)據(jù)包交互，或者手機端能及時準確地發(fā)出ping request，那么上述過程就完全沒有必要了。