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

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

1. 基本概念解讀

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

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

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

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

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

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

MITM（man in the middle），MITM是指A和B通信過(guò)程中，C會(huì)插入進(jìn)來(lái)以模擬A或者B，并且具備截獲和篡改A和B之間所有通信報(bào)文的能力，從而達(dá)到讓A或者B信任它，以至于錯(cuò)把C當(dāng)成B或者A來(lái)通信。如果對(duì)安全要求比較高，需要具備MITM保護(hù)能力，在SM中這個(gè)是通過(guò)認(rèn)證（authentication）來(lái)實(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通過(guò)基于橢圓曲線的Diffie-Hellman密鑰交換算法來(lái)生成設(shè)備A和B的共享密鑰，此密鑰生成過(guò)程中需要用到公私鑰對(duì)，以及其他的密碼算法庫(kù)。LESC同時(shí)還規(guī)定了相應(yīng)的通信協(xié)議以生成該密鑰，并驗(yàn)證該密鑰。需要注意的是LESC對(duì)paring的其他方面也會(huì)產(chǎn)生一定的影響，所以我們經(jīng)常會(huì)把LESC看成是一種新的配對(duì)方式。

Legacy paring，在LESC引入之前的密鑰生成方式，稱為legacy paring，換句話說(shuō)，legacy paring是相對(duì)LESC來(lái)說(shuō)的，不支持LESC的配對(duì)即為legacy paring（legacy配對(duì)）。

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

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

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

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

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í)間會(huì)變化一次，但是identity address仍然保持不變，其取值還是等于內(nèi)在的public或者random static設(shè)備地址。Identity Address和IRK都可以用來(lái)唯一標(biāo)識(shí)一個(gè)藍(lán)牙設(shè)備。

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

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

2. Paring流程及命令

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

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

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

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

SC paring：LTK生成

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

Paring流程如下所示：

2.1 階段1：配對(duì)特性交換

配對(duì)特性交換涉及三條PDU命令：

Paring_Request

Paring_Response

Security_Request

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

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

2.2 階段2：密鑰生成

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

Just works

Numeric comparison（LESC才有）

Passkey

OOB

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

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

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

2.2.1 legacy paring

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

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

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

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

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

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

生成STK的算法如下所示：

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

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

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

2.2.2 LESC paring

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

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

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

以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

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

IRK

Identity address

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

2.4 綁定，重連和加密

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

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

2.5 配對(duì)命令一覽表

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

3. Nordic SDK配對(duì)流程

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

比如S132協(xié)議棧，其從機(jī)端配對(duì)流程圖鏈接為：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的配對(duì)流程圖如下所示，鏈接為：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

上述配對(duì)流程圖把用到的API，產(chǎn)生的softdevice事件，以及softdevice事件如何處理，都一一闡明，大家只要按照這個(gè)流程圖來(lái)做，就可以完成期望的配對(duì)。更讓人省心的是，Nordic SDK已經(jīng)把幾種典型的配對(duì)場(chǎng)景做成了例子，大家可以直接就拿過(guò)來(lái)用，連上面的配對(duì)流程圖都不用看，就可以輕松完成自己的配對(duì)應(yīng)用。Nordic提供的配對(duì)例子有：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)牙各種配對(duì)情況。后面會(huì)以ble_app_hrs為例來(lái)詳細(xì)講解如何實(shí)現(xiàn)低功耗藍(lán)牙配對(duì)。

4. 配對(duì)例程ble_app_hrs解讀

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

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

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

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

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

5. ble_app_hrs配對(duì)方式改成LESC with numeric comparison

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

如何實(shí)現(xiàn)numeric comparison？前面我也提過(guò)，如果SDK有現(xiàn)成的例子，直接參考例子來(lái)；如果SDK沒(méi)有現(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í)序圖會(huì)把有可能需要用到事件和API都列出來(lái)，但不意味著列出來(lái)的事件和API都需要你去處理，因?yàn)榇蟛糠质录虯PI都被peer manager模塊處理好了，只有哪些靈活的無(wú)法預(yù)先確定的事件和API才會(huì)留給用戶自己去處理。那哪些事件和API需要用戶自己處理呢？一個(gè)原則：全文搜索一下，只要peer manager已經(jīng)調(diào)用過(guò)的API，你就不用處理；而流程圖中剩下的API就需要你自己去處理了。比如上面這個(gè)例子，sd_ble_gap_sec_params_reply已經(jīng)被peer manager模塊處理了，所以你不用處理；而B(niǎo)LE_GAP_EVT_PASSKEY_DISPLAY和sd_ble_gap_auth_key_reply只在passkey和numeric comparison配對(duì)方式中才會(huì)出現(xiàn)，peer manager沒(méi)有對(duì)其進(jìn)行處理，因此需要用戶自己處理。為此，我們?cè)赽le_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);
}

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

#define SEC_PARAM_MITM                1
#define SEC_PARAM_IO_CAPABILITIES     BLE_GAP_IO_CAPS_DISPLAY_YESNO

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

hrs_init.hrm_cccd_wr_sec = SEC_MITM;

我這里以PCA10040/Keil5工程為例來(lái)編譯，請(qǐng)編譯工程：nRF5SDK160098a08e2examplesble_peripheralble_app_hrspca10040s132arm5_no_packs

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

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

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

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

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

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

重連加密等級(jí)

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

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

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

有了這個(gè)characteristic，當(dāng)設(shè)備的服務(wù)發(fā)生改變時(shí)，設(shè)備就可以通過(guò)這個(gè)characteristic發(fā)送一個(gè)indicate PDU給到手機(jī)，從而手機(jī)知道設(shè)備的服務(wù)已發(fā)生了改變，此時(shí)手機(jī)會(huì)重新發(fā)起service discovery流程，以重新獲得service和characteristic最新的handle列表。欲添加service changed characteristic，你只需在sdk_config.h文件中打開(kāi)如下兩個(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é)議棧就會(huì)自動(dòng)發(fā)起service changed indicate PDU給手機(jī)，從而引起手機(jī)重走服務(wù)發(fā)現(xiàn)過(guò)程。

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

如果手機(jī)端刪除了綁定信息，為了安全起見(jiàn)，設(shè)備端也需要跟著一起刪除綁定信息，否則手機(jī)無(wú)法再次跟設(shè)備進(jìn)行配對(duì)，這個(gè)是最理想的情況，但是我們有的設(shè)備沒(méi)有任何輸入接口，無(wú)法手動(dòng)刪除綁定信息，這個(gè)時(shí)候能不能有一種辦法可以讓手機(jī)跟設(shè)備進(jìn)行二次配對(duì)呢？為此，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信息沒(méi)有刪掉，手機(jī)還是可以跟設(shè)備進(jìn)行二次配對(duì)的。

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

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

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

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

循環(huán)綁定測(cè)試

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

白名單與綁定

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

Authenticated payload timeout

大家都知道藍(lán)牙連接有一個(gè)supervision timeout時(shí)間，也就是說(shuō)，當(dāng)建立連接的兩個(gè)設(shè)備，任何一方在supervision timeout（比如4s）時(shí)間內(nèi)，沒(méi)有給對(duì)方發(fā)送任何藍(lán)牙空口包，此時(shí)認(rèn)為連接已斷開(kāi)，并觸發(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é)議棧自動(dòng)管理的，對(duì)軟件開(kāi)發(fā)來(lái)說(shuō)是透明的，每30s時(shí)間到，如果期間沒(méi)有任何有效數(shù)據(jù)包交互（一直在發(fā)空包），協(xié)議棧會(huì)自動(dòng)發(fā)送一個(gè)ping request給對(duì)方，以避免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è)備之間肯定會(huì)有有效數(shù)據(jù)包交互，或者手機(jī)端能及時(shí)準(zhǔn)確地發(fā)出ping request，那么上述過(guò)程就完全沒(méi)有必要了。

審核編輯 黃宇