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)榧恿?paring/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)橹?paring 不 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 碼，是指用戶在鍵盤中輸入的一串?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ò)鍵盤輸入的，而 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è)備的輸入輸出能力，比如是否有鍵盤，是否有顯示器，是否可以輸入 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)?10 個(gè)字節(jié)。

2、Paring 流程及命令

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

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

SC paring：LTK 生成

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

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

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

2、Paring_Response：

3、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。

對(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ì)方式如下所示。

2.2.2 LESC paring

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

公鑰交換后，設(shè)備 A 和 B 就開始獨(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 adresss

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

IRK

Identity adresss

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

2.4 綁定，重連和加密

°如果配對(duì)的兩個(gè)設(shè)備生成了 LTK 及其他秘密信息：  如上所述，如果配對(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è)備斷開再次重連的時(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ì)流程

°如下為 SM 中用的 PDU 命令列表：  那么如何實(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)用開發(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 不是很熟的話，建議你先看一下這篇文章：手把手教你開發(fā) BLE 數(shù)據(jù)透?jìng)鲬?yīng)用程序 ，以建立 Nordic 開發(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ì)方式

°把 ble_app_hrs 配對(duì)方式改成 LESC with numeric comparison：  原始 ble_app_hrs 為 just work 方式的 LESC 配對(duì)，我們現(xiàn)在把它改成最高安全級(jí)別的 numeric comparison LESC。我們的開發(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 都需要你那哪些事件和 API 需要用戶自己處理呢？一個(gè)原則：全文搜索一下，只要 peer manager 已經(jīng)調(diào)用過(guò)的 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 配對(duì)方式中才會(huì)出現(xiàn)，peer manager 沒(méi)有對(duì)其進(jìn)行處理，因此需要用戶自己處理。為此，我們?cè)?ble_evt_handler 中加上分支：BLE_GAP_EVT_PASSKEY_DISPLAY，并按照流程圖的要求加上相應(yīng)的處理，代碼如下所示：

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

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

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

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

nRF5SDK160098a08e2examplesle_peripheralle_app_hrspca10040s132arm5_no_packs。

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

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

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

代碼鏈接

鏈接：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，就可以直接編譯和運(yùn)行。

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

°蘋果手機(jī)的一點(diǎn)不同：  安卓手機(jī)允許用戶手動(dòng)發(fā)起 paring 請(qǐng)求，而蘋果手機(jī)則沒(méi)有這個(gè)功能。因此，即使你的 characteristic 沒(méi)有使能安全級(jí)別，安卓手機(jī)還是可以跟你的設(shè)備完成配對(duì)的，而蘋果手機(jī)則不支持這個(gè)功能，蘋果手機(jī)要不要跟設(shè)備進(jìn)行配對(duì)，不能由人來(lái)控制的，只能由蘋果 iOS 來(lái)控制。  欲觸發(fā)蘋果 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)求，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 文件中打開如下兩個(gè)宏：

然后當(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ī)端綁定信息，但是很多開發(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 信息。

如果上述方法行不通的話，那么發(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è)備存儲(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è)試：  很多開發(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í)開啟白名單廣播，這樣設(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)為連接已斷開，并觸發(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ì)軟件開發(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。

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

低功耗藍(lán)牙密鑰NFC