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

Paring（配對）和bonding（綁定）是實(shí)現(xiàn)藍(lán)牙射頻通信安全的一種機(jī)制，有兩點(diǎn)需要注意：一是paring/bonding實(shí)現(xiàn)的是藍(lán)牙鏈路層的安全，對應(yīng)用來說完全透明，也就是說，不管有沒有paring/bonding，你發(fā)送或接收應(yīng)用數(shù)據(jù)的方式是一樣的，不會因?yàn)榧恿藀aring/bonding應(yīng)用數(shù)據(jù)傳輸需要做某些特殊處理；二安全有兩種選項(xiàng)：加密或者簽名，目前絕大多數(shù)應(yīng)用都是選擇加密，后續(xù)我們也會以加密為重點(diǎn)進(jìn)行講述。實(shí)現(xiàn)藍(lán)牙通信安全，除了paring/bonding這種底層方式，用戶也可以在應(yīng)用層去實(shí)現(xiàn)相同功能，兩者從功能上和安全性上沒有本質(zhì)區(qū)別，只不過應(yīng)用層自己實(shí)現(xiàn)的話，需要自己選擇密碼算法，密鑰生成，密鑰交換等，如果你不是這方面的專家，你的應(yīng)用就有可能會存在安全漏洞。Paring/bonding則把上述過程標(biāo)準(zhǔn)化，放在了藍(lán)牙協(xié)議棧中，并且其安全性得到了充分評估，用戶可以 “無感的” 用上安全的藍(lán)牙通信。

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

1. 基本概念解讀

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

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

Bonding（綁定），配對過程中會生成一個(gè)長期密鑰（LTK，long-term Key），如果配對雙方把這個(gè)LTK存儲起來放在Flash中，那么這兩個(gè)設(shè)備再次重連的時(shí)候，就可以跳過配對流程，而直接使用LTK對藍(lán)牙連接進(jìn)行加密，設(shè)備的這種狀態(tài)稱為bonding。如果paring過程中不存儲LTK（不分發(fā)LTK）也是可以的，paring完成后連接也是加密的，但是如果兩個(gè)設(shè)備再次重連，那么就需要重走一次paring流程，否則兩者還是明文通信。在不引起誤解的情況下，我們經(jīng)常把paring當(dāng)成paring和bonding兩者的組合，因?yàn)橹籶aring不bonding的應(yīng)用情況非常少見。在不引起混淆的情況下，下文就不區(qū)分paring和bonding的區(qū)別，換句話說，我們會把paring和bonding兩個(gè)概念等同起來進(jìn)行混用。

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

SMP（security manager protocol），安全管理協(xié)議，SMP著重兩個(gè)設(shè)備之間的藍(lán)牙交互命令序列，對paring的空中包進(jìn)行了嚴(yán)格時(shí)序規(guī)定。

OOB（out of band，帶外），OOB就是不通過藍(lán)牙射頻本身來交互，而是通過比如人眼，NFC，UART等帶外方式來交互配對信息，在這里人眼，NFC，UART通信方式就被稱為OOB通信方式。

Passkey，又稱pin碼，是指用戶在鍵盤中輸入的一串?dāng)?shù)字，以達(dá)到認(rèn)證設(shè)備的目的。低功耗藍(lán)牙的passkey必須為6位。

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

MITM（man in the middle），MITM是指A和B通信過程中，C會插入進(jìn)來以模擬A或者B，并且具備截獲和篡改A和B之間所有通信報(bào)文的能力，從而達(dá)到讓A或者B信任它，以至于錯把C當(dāng)成B或者A來通信。如果對安全要求比較高，需要具備MITM保護(hù)能力，在SM中這個(gè)是通過認(rèn)證（authentication）來實(shí)現(xiàn)的，SM中實(shí)現(xiàn)認(rèn)證的方式有三種：OOB認(rèn)證信息，passkey以及numeric comparison，大家根據(jù)自己的實(shí)際情況，選擇其中一種即可。

LESC（LE secure connections），又稱SC，藍(lán)牙4.2引入的一種新的密鑰生成方式和驗(yàn)證方式，SC通過基于橢圓曲線的Diffie-Hellman密鑰交換算法來生成設(shè)備A和B的共享密鑰，此密鑰生成過程中需要用到公私鑰對，以及其他的密碼算法庫。LESC同時(shí)還規(guī)定了相應(yīng)的通信協(xié)議以生成該密鑰，并驗(yàn)證該密鑰。需要注意的是LESC對paring的其他方面也會產(chǎn)生一定的影響，所以我們經(jīng)常會把LESC看成是一種新的配對方式。

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

TK（Temporary Key，臨時(shí)密鑰），legacy paring里面的概念，如果采用just work配對方式，TK就是為全0；如果采用passkey配對方式，TK就是passkey；如果采用OOB配對方式，TK就是OOB里面的信息。

STK（short term key，短期密鑰），legacy配對里面的概念，STK是通過TK推導(dǎo)出來的，通過TK對設(shè)備A和B的隨機(jī)數(shù)進(jìn)行加密，即得到STK。

LTK（long term key，長期密鑰），legacy配對和LESC配對都會用到LTK，如前所述，LTK是用來對未來的連接進(jìn)行加密和解密用的。Legacy paring中的LTK由從設(shè)備根據(jù)相應(yīng)的算法自己生成的（LTK生成過程中會用到EDIV（分散因子）和Rand（隨機(jī)數(shù)）），然后通過藍(lán)牙空中包傳給主機(jī)。LESC配對過程中，先通過Diffie-Hellman生成一個(gè)共享密鑰，然后這個(gè)共享密鑰再對設(shè)備A和B的藍(lán)牙地址和隨機(jī)數(shù)進(jìn)行加密，從而得到LTK，LTK由設(shè)備A和B各自同時(shí)生成，因此LTK不會出現(xiàn)在LESC藍(lán)牙空中包中，大大提高了藍(lán)牙通信的安全性。

IRK（Identity Resolving Key，藍(lán)牙設(shè)備地址解析密鑰），有些藍(lán)牙設(shè)備的地址為可解析的隨機(jī)地址，比如iPhone手機(jī)，由于他們的地址隨著時(shí)間會變化，那如何確定這些變化的地址都來自同一個(gè)設(shè)備呢？答案就是IRK，IRK通過解析變化的地址的規(guī)律，從而確定這些地址是否來自同一個(gè)設(shè)備，換句話說，IRK可以用來識別藍(lán)牙設(shè)備身份，因此其也稱為Identity information。IRK一般由設(shè)備出廠的時(shí)候按照一定要求自動生成。

Identity Address（設(shè)備唯一地址），藍(lán)牙設(shè)備地址包括public，random static， private resolvable，random unresolved共四類。如果設(shè)備不支持privacy，那么identity address就等于public或者random static設(shè)備地址。如果設(shè)備支持privacy，即使用private resolvable藍(lán)牙設(shè)備地址，在這種情況下，雖然其地址每隔一段時(shí)間會變化一次，但是identity address仍然保持不變，其取值還是等于內(nèi)在的public或者random static設(shè)備地址。Identity Address和IRK都可以用來唯一標(biāo)識一個(gè)藍(lán)牙設(shè)備。

IO capabilities（輸入輸出能力），是指藍(lán)牙設(shè)備的輸入輸出能力，比如是否有鍵盤，是否有顯示器，是否可以輸入Yes/No兩個(gè)確認(rèn)值。

Key size（密鑰長度），一般來說，密鑰默認(rèn)長度為16字節(jié)，為了適應(yīng)一些低端的藍(lán)牙設(shè)備處理能力，你也可以把密鑰長度調(diào)低，比如變?yōu)?0個(gè)字節(jié)。

2. Paring流程及命令

Paring包含三個(gè)階段：

階段1：配對特性交換，即交換各自都支持哪些配對特性，比如支不支持SC，支不支持MITM，支不支持OOB，以及它的輸入輸出能力等

階段2：密鑰生成階段，legacy paring和LESC paring兩者的區(qū)別就在這里，因此后續(xù)我們會分開闡述legacy paring和SC paring的階段2

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

SC paring：LTK生成

階段3：通過藍(lán)牙空中包分發(fā)一些秘密信息。Legacy paring需要分發(fā)LTK，IRK等，而SC paring只需分發(fā)IRK。秘密信息分發(fā)之前，必須保證連接已加密。

Paring流程如下所示：

2.1 階段1：配對特性交換

配對特性交換涉及三條PDU命令：

Paring_Request

Paring_Response

Security_Request

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

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

2.2 階段2：密鑰生成

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

Just works

Numeric comparison（LESC才有）

Passkey

OOB

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

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

下面分legacy paring和sc paring對配對流程進(jìn)行講解。

2.2.1 legacy paring

Legacy paring整個(gè)配對流程是圍繞STK生成來做的，設(shè)備的認(rèn)證是通過設(shè)備A和B經(jīng)由TK生成一個(gè)確認(rèn)數(shù)，如果這個(gè)確認(rèn)數(shù)相同，則認(rèn)證通過。

如前所述，legacy paring需要先生成TK，TK的生成方式取決于配對方式：

Just works。TK默認(rèn)為全0

Passkey。TK由6位passkey擴(kuò)展而來

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

然后生成確認(rèn)數(shù)，算法如下所示

生成STK的算法如下所示：

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

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

這里強(qiáng)調(diào)一下，配對完成之后，連接就會加密，而且加密的密鑰是STK，而不是LTK。

2.2.2 LESC paring

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

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

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

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

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

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

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

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

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

LTK

EDIV

Rand

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

IRK

Identity address

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

IRK

Identity address

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

2.4 綁定，重連和加密

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

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

2.5 配對命令一覽表

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

3. Nordic SDK配對流程

第2章是低功耗藍(lán)牙通用配對流程，那么如何實(shí)現(xiàn)這個(gè)配對流程呢？也就是說，我該調(diào)用哪些API去實(shí)現(xiàn)配對流程，這些API調(diào)用的順序又是如何，具體會產(chǎn)生哪些協(xié)議棧事件，該如何處理這些協(xié)議棧事件，這就涉及到協(xié)議棧的實(shí)現(xiàn)。Nordic藍(lán)牙協(xié)議棧softdevice提供詳細(xì)的工作流程圖，以指導(dǎo)用戶如何調(diào)用softdevice API去實(shí)現(xiàn)想要的配對流程，詳細(xì)的配對流程圖請參考infocenter如下界面：

比如S132協(xié)議棧，其從機(jī)端配對流程圖鏈接為：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，從機(jī)端顯示passkey，主機(jī)端輸入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，產(chǎn)生的softdevice事件，以及softdevice事件如何處理，都一一闡明，大家只要按照這個(gè)流程圖來做，就可以完成期望的配對。更讓人省心的是，Nordic SDK已經(jīng)把幾種典型的配對場景做成了例子，大家可以直接就拿過來用，連上面的配對流程圖都不用看，就可以輕松完成自己的配對應(yī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等，基本上囊括了藍(lán)牙各種配對情況。后面會以ble_app_hrs為例來詳細(xì)講解如何實(shí)現(xiàn)低功耗藍(lán)牙配對。

4. 配對例程ble_app_hrs解讀

nRF5 SDK把藍(lán)牙配對做成了一個(gè)模塊：peer_manager，也就是說，所有關(guān)于paring的工作都由peer manager自動完成，用戶無需去了解softdevice底層API的使用方法，大家直接參考nRF5 SDK里面的例程就可以完成自己的配對應(yīng)用開發(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等，基本上囊括了藍(lán)牙各種配對情況，下面將和大家一起來解讀ble_app_hrs配對相關(guān)代碼。

如果你對Nordic nRF5 SDK和softdevice不是很熟的話，建議你先看一下這篇文章：手把手教你開發(fā)BLE數(shù)據(jù)透傳應(yīng)用程序，以建立Nordic開發(fā)的一些基礎(chǔ)知識，然后再往下看。

跟沒有paring的ble應(yīng)用代碼相比，有paring的ble應(yīng)用只多了一個(gè)初始化函數(shù)：peer_manager_init()，peer_manager_init實(shí)現(xiàn)代碼如下所示：

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

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

5. ble_app_hrs配對方式改成LESC with numeric comparison

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

如何實(shí)現(xiàn)numeric comparison？前面我也提過，如果SDK有現(xiàn)成的例子，直接參考例子來；如果SDK沒有現(xiàn)成的例子，那么就參考softdevice工作時(shí)序圖。關(guān)于LESC numeric comparison，從機(jī)端的工作流程如下所示：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

這里要強(qiáng)調(diào)一下，時(shí)序圖會把有可能需要用到事件和API都列出來，但不意味著列出來的事件和API都需要你去處理，因?yàn)榇蟛糠质录虯PI都被peer manager模塊處理好了，只有哪些靈活的無法預(yù)先確定的事件和API才會留給用戶自己去處理。那哪些事件和API需要用戶自己處理呢？一個(gè)原則：全文搜索一下，只要peer manager已經(jīng)調(diào)用過的API，你就不用處理；而流程圖中剩下的API就需要你自己去處理了。比如上面這個(gè)例子，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沒有對其進(jìn)行處理，因此需要用戶自己處理。為此，我們在ble_evt_handler中加上分支：BLE_GAP_EVT_PASSKEY_DISPLAY，并按照流程圖的要求加上相應(yīng)的處理，代碼如下所示：

case BLE_GAP_EVT_PASSKEY_DISPLAY:
{
      char        passkey[BLE_GAP_PASSKEY_LEN + 1];
      memcpy(passkey, p_ble_evt->evt.gap_evt.params.passkey_display.passkey, BLE_GAP_PASSKEY_LEN);
      passkey[BLE_GAP_PASSKEY_LEN] = 0x00;
      NRF_LOG_INFO("=== PASSKEY: %s =====",   nrf_log_push(passkey));
      NRF_LOG_INFO("Press Button 3 to confirm, Button 4 to reject");
}
break;

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

static void num_comp_reply(bool accept)
{
    uint8_t    key_type;
    ret_code_t err_code;
        NRF_LOG_INFO("m_conn_handle %d", m_conn_handle);
        if (m_conn_handle == BLE_CONN_HANDLE_INVALID)
        {
            return;
        }
    if (accept)
    {
        NRF_LOG_INFO("Numeric Match");
        key_type = BLE_GAP_AUTH_KEY_TYPE_PASSKEY;
    }
    else
    {
        NRF_LOG_INFO("Numeric REJECT");
        key_type = BLE_GAP_AUTH_KEY_TYPE_NONE;
    }

    err_code = sd_ble_gap_auth_key_reply(m_conn_handle,
                                         key_type,
                                         NULL);
    APP_ERROR_CHECK(err_code);
}

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

#define SEC_PARAM_MITM                1
#define SEC_PARAM_IO_CAPABILITIES     BLE_GAP_IO_CAPS_DISPLAY_YESNO

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

hrs_init.hrm_cccd_wr_sec = SEC_MITM;

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

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

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

上述代碼已上傳到百度云盤，大家可以去百度云盤下載：ble_app_hrs_nc.rar，然后解壓縮到SDK根目錄examplesble_peripheral，打開Keil5工程：SDK根目錄examplesble_peripheral ble_app_hrs_nc*pca10040s132arm5_no_packs*，就可以直接編譯和運(yùn)行。

6. 關(guān)于配對的一些小貼士

蘋果手機(jī)的一點(diǎn)不同

安卓手機(jī)允許用戶手動發(fā)起paring請求，而蘋果手機(jī)則沒有這個(gè)功能。因此，即使你的characteristic沒有使能安全級別，安卓手機(jī)還是可以跟你的設(shè)備完成配對的，而蘋果手機(jī)則不支持這個(gè)功能，蘋果手機(jī)要不要跟設(shè)備進(jìn)行配對，不能由人來控制的，只能由蘋果iOS來控制。欲觸發(fā)蘋果iOS發(fā)起配對請求，有兩種方法，一是將某個(gè)characteristic加上安全認(rèn)證權(quán)限，這樣iOS在服務(wù)發(fā)現(xiàn)過程中就會自動發(fā)起配對請求，以滿足characteristic的安全認(rèn)證級別；二是從機(jī)端主動發(fā)起安全請求，即security request，對應(yīng)的API為pm_conn_secure，或者直接調(diào)用pm_handler_secure_on_connection。iOS收到從機(jī)的安全請求后，會等待用戶的授權(quán)確認(rèn)從而發(fā)起配對請求。這兩種方法在ble_app_gls中都有體現(xiàn)，大家可以參考相關(guān)代碼。

重連加密等級

綁定成功后，如果發(fā)生重連，那么主機(jī)應(yīng)該自動發(fā)起加密連接請求，以對連接進(jìn)行加密。一般來說，在連接沒有成功加密前，主從機(jī)不要做敏感數(shù)據(jù)的交互，否則softdevice API會報(bào)NRF_ERROR_FORBIDDEN。對于有MITM保護(hù)的加密連接，在收到PM_EVT_CONN_SEC_SUCCEEDED這個(gè)事件后，設(shè)備應(yīng)該去檢測連接的安全等級是否符合要求，具體可參考ble_app_gls例子的做法。

Service changed（服務(wù)改變）

設(shè)備跟手機(jī)綁定成功后，手機(jī)再次重連這個(gè)設(shè)備時(shí)，就會自動跳過service discovery過程，換句話說，配對的時(shí)候手機(jī)會把設(shè)備所有服務(wù)和characteristic的handle保存下來，二次重連的時(shí)候，直接用以前保存的handle值去操作設(shè)備。但是，如果設(shè)備的服務(wù)改變了，此時(shí)手機(jī)再用之前的handle去操作設(shè)備，就會出問題。為了解決這個(gè)問題，在GATT主服務(wù)里面引入了service changed characteristic，如下所示：

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

#define PM_SERVICE_CHANGED_ENABLED  1
#define NRF_SDH_BLE_SERVICE_CHANGED 1

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

刪除主機(jī)端綁定信息

如果手機(jī)端刪除了綁定信息，為了安全起見，設(shè)備端也需要跟著一起刪除綁定信息，否則手機(jī)無法再次跟設(shè)備進(jìn)行配對，這個(gè)是最理想的情況，但是我們有的設(shè)備沒有任何輸入接口，無法手動刪除綁定信息，這個(gè)時(shí)候能不能有一種辦法可以讓手機(jī)跟設(shè)備進(jìn)行二次配對呢？為此，Nordic提供了一種workaround，在藍(lán)牙事件回調(diào)函數(shù)里面，加上如下代碼即可：

        if (p_evt->evt_id == PM_EVT_CONN_SEC_CONFIG_REQ)
        {
                pm_conn_sec_config_t cfg;
                cfg.allow_repairing = true;
                pm_conn_sec_config_reply(p_evt->conn_handle, &cfg);
        }

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

刪除從機(jī)端綁定信息

跟上面相反，如果設(shè)備端bonding信息被刪除了，而手機(jī)端bonding信息沒有被刪除，這種情況下如何實(shí)現(xiàn)二次配對？最安全的方式，讓用戶主動刪除手機(jī)端綁定信息，但是很多開發(fā)者希望，用戶體驗(yàn)好一點(diǎn)，也就是說，碰到這種情況希望手機(jī)能自動刪除綁定信息，這個(gè)能不能實(shí)現(xiàn)跟手機(jī)有很大關(guān)系，首先我們確保協(xié)議棧返回LL_REJECT_IND or LL_REJECT_EXT_IND，錯誤碼為“PIN or key missing”，一般而言，手機(jī)收到這個(gè)PDU后，都會自動刪除bonding信息。為了確保手機(jī)會刪除bonding信息，從機(jī)最好能主動發(fā)起安全請求，即主動發(fā)送security request給主機(jī)。如果上述方法行不通的話，那么發(fā)送完LL_REJECT_IND后再調(diào)用斷開函數(shù)（sd_ble_gap_disconnect），同時(shí)將斷開原因設(shè)為BLE_HCI_AUTHENTICATION_FAILURE再試一下。

同時(shí)綁定多個(gè)設(shè)備

Nordic SDK是支持一個(gè)設(shè)備同時(shí)跟多個(gè)主機(jī)綁定，只要設(shè)備存儲空間足夠大，那么可以綁定的設(shè)備數(shù)就不設(shè)限。nRF5 SDK中bonding信息也是通過fds來存儲的，也就是說綁定信息和用戶Flash數(shù)據(jù)共享同一塊空間，如果需要綁定多個(gè)設(shè)備，那么FDS_VIRTUAL_PAGES這個(gè)宏的值必須進(jìn)行修改，以保證分配的Flash空間可以同時(shí)容納bonding信息和用戶Flash數(shù)據(jù)。一般來說，如果需要綁定多個(gè)設(shè)備，請?jiān)O(shè)置一個(gè)最大綁定數(shù)，比如8個(gè)，這樣，一旦檢測到綁定數(shù)達(dá)到8了，就可以把以前老的bonding設(shè)備刪除，從而節(jié)省存儲空間。那如何知道哪個(gè)設(shè)備是老設(shè)備哪個(gè)設(shè)備是新設(shè)備？這個(gè)是通過peer rank來實(shí)現(xiàn)的，大家只要使能PM_PEER_RANKS_ENABLED這個(gè)宏，就可以自動實(shí)現(xiàn)排序。

循環(huán)綁定測試

很多開發(fā)者喜歡做循環(huán)綁定測試，即同一部手機(jī)不斷跟同一個(gè)設(shè)備進(jìn)行配對，然后刪除配對信息，然后再進(jìn)行配對，他們測試下來發(fā)現(xiàn)：達(dá)到一定次數(shù)后，設(shè)備就工作不正常了，這個(gè)是由于當(dāng)bonding信息不斷累積而不進(jìn)行刪除的話，那么分配給fds的Flash空間就會耗盡，從而導(dǎo)致異常出現(xiàn)（最新的SDK會在Flash存儲空間耗盡時(shí)，自動刪除最老設(shè)備的綁定信息，但即使這樣，對用戶Flash數(shù)據(jù)的操作影響還是很大）。解決這個(gè)問題的方法就是設(shè)定一個(gè)最大bonding數(shù)，達(dá)到這個(gè)數(shù)目后，刪除老bonding信息，從而達(dá)到循環(huán)利用Flash空間的目的。當(dāng)然如果你的fds只是用來存儲bonding信息而不做其他用戶數(shù)據(jù)操作的話，那么就沒有必要加上這個(gè)功能了。

白名單與綁定

雖然白名單和綁定二者沒有任何聯(lián)系，但是我們一般都把兩者結(jié)合起來一起使用，以達(dá)到我們的使用期望。當(dāng)兩個(gè)設(shè)備綁定成功后，我們就可以將對方的mac地址或者IRK放入白名單中，同時(shí)開啟白名單廣播，這樣設(shè)備只跟白名單中的主機(jī)進(jìn)行連接，白名單以外的設(shè)備在controller層面就被過濾掉了，從而提高私密性以及連接效率。這種情況下，哪怕是合法的設(shè)備，如果之前沒有跟設(shè)備綁定，那么它也無法跟設(shè)備建立連接。換句話說，如果你想把新設(shè)備加入到白名單中，那么首先需要禁止白名單廣播而采用普通廣播，然后跟新設(shè)備進(jìn)行配對，成功后再把新設(shè)備身份信息加入到白名單中。白名單與綁定的例子具體可參考：ble_app_hids_keyboard

Authenticated payload timeout

大家都知道藍(lán)牙連接有一個(gè)supervision timeout時(shí)間，也就是說，當(dāng)建立連接的兩個(gè)設(shè)備，任何一方在supervision timeout（比如4s）時(shí)間內(nèi)，沒有給對方發(fā)送任何藍(lán)牙空口包，此時(shí)認(rèn)為連接已斷開，并觸發(fā)supervision timeout事件。當(dāng)設(shè)備雙方建立加密連接后，不僅有上述的supervision timeout，還有一個(gè)authenticated payload timeout，authenticated payload timeout默認(rèn)為30s，它的意思是，兩個(gè)設(shè)備加密后，30s內(nèi)必須有一個(gè)有數(shù)據(jù)的空口包交互，而不能一直發(fā)空包，否則認(rèn)為authenticated payload timeout。Authenticated payload timeout是協(xié)議棧自動管理的，對軟件開發(fā)來說是透明的，每30s時(shí)間到，如果期間沒有任何有效數(shù)據(jù)包交互（一直在發(fā)空包），協(xié)議棧會自動發(fā)送一個(gè)ping request給對方，以避免authenticated payload timeout的出現(xiàn)（注：這里的協(xié)議棧既可以是設(shè)備的協(xié)議棧，也可以是手機(jī)的協(xié)議棧）。有時(shí)候不想等到30s超時(shí)到了再發(fā)送ping request，大家可以在connected事件中，調(diào)用如下API以提前發(fā)出ping request：

ble_opt_t opt;
memset(&opt, 0, sizeof(opt));
opt.gap_opt.auth_payload_timeout.conn_handle = m_conn_handle;
opt.gap_opt.auth_payload_timeout.auth_payload_timeout = 2000;  //20s timeout
err_code = sd_ble_opt_set(BLE_GAP_OPT_AUTH_PAYLOAD_TIMEOUT, &opt);

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

審核編輯 黃宇