面向 Bluetooth Smart 应用的低功耗无线 MCU

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的安全机制也会很有帮助。

审核编辑：何安