CC2640 R2是德州儀器推出的一款面向 Bluetooth Smart 應用的低功耗無線 MCU。該芯片集成有Cortex M3內核，可以運行TI的BLE協議棧，具有功耗低，外設種類豐富，射頻性能好等特點。與CC2640相比，R2版本的芯片將部分協議棧遷移到了片內的ROM中，留給客戶的應用程序更多的Flash空間。CC2640R2芯片架構及核心特點如下圖1所示。

而CC2640R2F本身集成有可以支持藍牙5.0的PHY，TI協議棧支持部分藍牙5.0的協議，如High speed，Long Range等等。基于CC2640R2F可以實現很多炫酷的應用。不過有時候，有些應用并沒有按鍵或者屏幕等輸入設備，要求APP輸入密碼與BLE從機配對后方可讀取BLE設備的數據，這篇文章就跟大家詳細聊聊如何用用戶自定義的密碼進行配對。

本文所使用的軟硬件平臺如下：

本文是以hid_emu_kbd例程為參考。其他工程比如SimpleBLEPeripheral或者其他，都可以參照這個來修改。HID設備對BLE來說比較特殊，BLE的HID profile是規定HID設備必須配對和綁定的。

下圖是配對和綁定的基本流程。Initiator是連接中的主設備，responder是連接中的從設備。

BLE的配對與綁定則發生在連接之后。綁定是在配對之后發生的事，需不需要綁定取決于用戶在代碼里的設置。

上圖的phase 1和phase2是配對的過程。Phase 3是綁定的過程。要不要進行phase 3，在phase 1發送配對請求的時候就已經決定了，這個決定就是用戶在代碼里面的配置。

如果要用戶在配對過程中人為輸入密碼或進行其他認為操作，是在phase 2。而具體的誤認為操作方式，也是在phase 1中決定，這個決定也是用戶在代碼里面的配置。其實phase 2能用到的配對有很多種方式，最簡單的就是just works的方式，用大家都知道的000000作為配對密碼，這個方式很不安全，非常容易被破解。其實BLE到了4.2以上的版本，已經有了用DH（Diffie–Hellman key exchange）方式交換密碼，這個方式已經很安全，且密碼也是隨機產生的。

有些應用場景可能需求比較特殊，產品需要自定義的配對密碼，所以要達到這個目的，就需要我們靈活配置配phase 1中的各個參數，這也是這篇文章的目的。

我們繼續以hid_emu_kbd為例，BLE配對phase 1所需要的幾個重要參數的配置在hidemukbd.c里，如下：

第一個關鍵參數是PAIRING_MODE，配對是由GAPBOND_PAIRING_MODE_INITIATE一端發起的，可以是主機，也可以是從機。本文中由手機（手機）發起配對請求，從機（CC2640R2）則被動等待，所以需要將宏定義配置為GAPBOND_PAIRING_MODE_WAIT_FOR_REQ。

第二個關鍵參數是MITM_MODE，MITM即Man In The Middle保護，如果MITM為FALSE，則說明不需要人參與中間，后面相應的IO capabilities設置也會被忽略，但是為了使配對需要Passcode才能成功，必須要把MITM_MODE的宏定義設置為TRUE。

第三個關鍵參數是IO_CAPABILITIES，表示本機是否有輸入或者顯示的功能，比如GAPBOND_IO_CAP_DISPLAY_ONLY，表示可以將密碼顯示在屏幕上給操作人看，如果有I/O接口可以輸入密碼，也可以選擇GAPBOND_IO_CAP_KEYBOARD_ONLY。本文中將I/O capabilities的屬性設置為GAPBOND_IO_CAP_DISPLAY_ONLY，如下：

這樣做的目的就是告訴主機，我這邊能顯示配對密碼，最終用戶作為MITM，需要在主機那邊（手機上）跳出的窗口里輸入我從機這邊顯示的配對密碼就行。到這一步，phase 2要用的配對的方式就確定好了。但是這樣設置的話從機這邊顯示的密碼是隨機產生的6位數，并不是我們想要的自定義的固定6位數。

×注意，即使實際的從設備產品不帶顯示功能（沒屏幕），IO_CAPABILITIES配置成GAPBOND_IO_CAP_DISPLAY_ONLY，也是可以的，前提就是用自定義的固定6位數作為配對密碼，不然就會導致產生的6位隨機數沒地方顯示，就會無法完成配對。

接下來就來設置固定的6位數配對密碼來達到我們的目的。

CC2640R2的修改方式CC2541不同，CC2541可以參考這個帖子：https://e2echina.ti.com/question_answer/wireless_connectivity/bluetooth/f/103/t/112619

首先看一下哪里設置這個自定義配對密碼passcode的6位數。CC2640R2的這個Passcode隱藏的比較深，在bcomdef.h里，把宏定義改成你自己需要的密碼就可以了。這里設置成123412，注意這個密碼必須是6位。

那么這個默認自定義passcode是怎么被用上的呢？

首先，就是要在初始化的時候注冊bond manager的回調：

這個回調的HidDev_PasscodeCB（）就是處理passcode請求的回調函數。

當配對的phase 2被配置成前面提到的方式時，配對過程會觸發passcode請求，就會調用HidDev_passcodeCB（）。最終會觸發HidDev_processPasscodeEvt（）：

所以可以看到，只要其中pHidDevCB->passcodeCB這個回調為NULL，那么就會使用默認自定義密碼，這樣就能達到目的。（如果這個回調不為NULL，那么就會調用這個回調來獲取密碼，那很有可能是應用層用戶手動輸入密碼或者其他方式。）

pHidDevCB這個回調是在應用層用戶自己初始化的：

第三個回調函數就是passcodeCB，這個修改為NULL。

這個回調結構體是在HidDev_Register（）被調用，并初始化給pHidDevCB指針的。

修改完了，為了調試的方便，我們把斷開連接后自動廣播打開，在IAR開發環境中，右擊工程 -> Options -> C/C++ Compiler -> Preprocessor中Define Symbols里，把AUTO_ADV的值改為TRUE。

如果是用iPhone作為主機的話，有幾個連接參數要改一下，不然iOS會拒絕連接參數更新請求。

下面到了見證奇跡的時刻，拿出你的手機，以iPhone為例，由于是HID的工程，可以用iPhone自帶的藍牙界面：（如果不是HID工程，iOS上的lightblue app或者TI的sensorTag app都能做演示）

搜索到設備：

點擊搜索到的HID Keyboard，這樣會發起連接請求，自動跳出密碼框：

輸入正確的預設6位密碼123412并點擊配對：

配對成功連接建立完成：

如果輸入密碼錯誤，那么會連接建立失敗，重新回到最初界面：

為了加深理解，我們可以從空中抓包的log來看一下過程。下圖是配對成功后，連接進行加密：

那么可以看到加密以后的數據就都是紅的，這是因為sniffer沒法解析了，通過MITM方式配對是比較安全的模式。

那么如果iPhone上密碼輸入錯誤，非指定密碼，CC2640R2就會直接回復Pairing Failed給iPhone：

iPhone就會立即斷開連接：

最后，靈活運用前面提到過的配對參數搭配，能達到不同的配對場景效果。我們這里只是舉了一個例子，讀者有興趣的話可以自己嘗試一下各種搭配，這樣對理解BLE的安全機制也會很有幫助。

審核編輯：何安