深入NXP蓝牙SDK开发（x）---深挖BLE蓝牙协议栈配对过程（1）_配对特性交换

最新推荐文章于 2024-07-10 11:31:09 发布

蔡蔡狗

最新推荐文章于 2024-07-10 11:31:09 发布

阅读量3.4k

点赞数 5

分类专栏： NXP低功耗蓝牙SDK开发文章标签：蓝牙协议栈安全软件框架 c算法

本文链接：https://blog.csdn.net/suitcalaw/article/details/119341894

版权

NXP低功耗蓝牙SDK开发专栏收录该内容

3 篇文章 10 订阅

订阅专栏

深入NXP蓝牙SDK开发（x）--深挖BLE配对过程

本文内容可在SIG蓝牙联盟发布的Core_v4.2里找到，比较分散。

0、开篇：

BLE配对有两种方式：传统配对（ LE legacy pairing ）、安全连接配对（ LE Secure Connections pairing ）；BLE4.2以下版本只支持传统配对方式，BLE4.2及以上版本支持以上两种个配对方式；
传统配对方式有三种加密方法：Just Works 、Passkey Entry、Out Of Band (OOB) ，安全连接配对方式比传统配对方式多一种加密算法：（ Just Works 、Passkey Entry、Out Of Band (OOB) 、Numeric Comparison ）。
用一张表格表示他们之间的关系能使你更加清晰明白他们的关系：

BLE4.2以前（不包含BLE4.2）	BLE4.2及以上版本
传统配对	传统配对 / 安全配对
Just Works / Passkey Entry / Out Of Band (OOB)	Just Works / Passkey Entry / Out Of Band (OOB) / Numeric Comparison

1、配对过程整体预览

1.1. 下面这张图就是蓝牙配对过程的总体框图：（图里面的步骤，耐心看完，不会的单词查一下词典，非常重要）
LE Pairing Phases
我们称呼 master作为发起端（Initiator）；slave作为响应端（Respoinder）。
发起端和响应端需要先建立LL连接再够进行配对过程(蓝色框框部分：Established LL connection)；配对过程分为三个阶段：
Phase 1：配对特性交换
Phase 2：配对密钥生成（STK/LTK）
Phase 3：密钥的分发；

2、配对特性交换：

2.1 特性交换的报文

配对特性交换的内容决定了后续第二阶段的密钥生成方式以及第三阶段需要分发那些密钥，简单来说这个阶段双端设备只交换了一条报文，具体字段内容如下：
Pairing Packet
（1）Code字段：Code = 0x01：发起者发出的配对请求包（Pairing_Request）；Code = 0x02：响应者发出的配对请求响应包（Pairing_Response）；
（2）IO Cap（IO Capability）：IO能力，IO中的I表示键盘输入能力，O表示的是显示类的输出能力。蓝牙联盟SIG给协议栈定义了三种输入能力及两种输出能力：

输入能力	输出能力
No input / Yes or No / Keyboard	No output / Numeric output

No input：没有任何输入能力，即设备不能够被输入数字以及确认等输入能力； Yes or No：键盘有输入能力，但只有两个按钮 YES 和 NO ；Keyboard：拥有全数字键盘，能够输入数字0-9，还能有个确认的按键； No output：设备没有显示类的输出能力； Numeric output ：设备有显示类输出能力，能够显示6位十进制数字。
以上能力，一个设备只能选择一种输入能力以及一种输出能力，由设备具有的输入输出能力组合成下面这张综合能力表：
IO Capabilities Mapping
蓝牙联盟定义的综合能力对应的数值如下：（知道一下就行，不看也罢，对理论分析配对过程影响不大）
IO Capability Value

（3）OOB（OOB data flag）：众多机器以及文章将它翻译成：带外；这翻译也没令我感觉到多大的不适。表述的是蓝牙设备除了蓝牙这种数据交互能力外，有可能还会具备第三方超短距离的数据交互通道，比如NFC，红外等外设。蓝牙联盟定义的OOB能力对应的数值：（支持带外，则将此字段设为0x01，反之设定为0x00；0x02-0xff：保留）
在这里插入图片描述
（4）AuthReq：此字段为复合字段，包含了Bonding_Flags、MITM、SC、Keypress四个子字段；对应着携带了绑定标志、防止中间人攻击、安全配对、keypress这些，统称为身份验证要求标志，具体内容：
Authentication Requirement Flag
（4.1）Bonding_Flags：绑定标志位，若设为1，则启用绑定功能，在下一次连接的时候就不需要再进行配对过程：设为0，则为非绑定，再次连接的时候，设备需要重新过一遍配对加密流程；具体数值意义如下表：
Bongding_Flag
（4.2）MITM：中间人攻击保护：置位启用该功能；对于MITM的定义，请自行搜索，很容易理解；
（4.3）SC：该位为1，开启安全配对模式，设为0，则为传统配对模式。值得注意的是，只有双端设备都支持安全配对模式（即BLE4.2以上版本）且同时将SC设为1才可开启安全配对模式，否则的话，只能进行传统配对模式。
（4.4）Keypress:此字段管控这键盘输入，只有在使用Passkey Entry 加密方法，以及双端设备此位都设置为1才能被使用，否则的话，此为会被忽略。笔者推测这就是我们经常用手机连接蓝牙所需要输入PIN密码的功能一样，这就是这个功能的开关。
（5）Maximum Encryption Key Size ：看到报文的第五个字段，表示后续交换的密钥需要交换多长的长度，即最大的加密密钥大小，这个值蓝牙联盟定义在7到16个字节，用户可自行选择。
（6）Initiator Key Distribution ：这也是一个复合字段，这个复合字段管控着后续需要分配哪些密钥，比如IRK、LTK、CSRK等（上文我们已经提到过第三个阶段是密钥分配的，那么就是说这个字段管控第三阶段的进行）看表：
LE Key Distribution Format
对于这个字段笔者还不是太熟悉，在对蓝牙标准的理解以及蓝牙配对过程详解这篇文章的帮助下，解析一下这个字段。
（6.1）EncKey : 这个是长期密钥 LTK 分发使能位，LTK 分发之后会接着分发由 LTK 派生的 EDIV 和 Rand 这两个密钥。此位只在传统配对模式有效，因为安全连接配对模式是直接协商生成 LTK 的，并不需要分发LTK给对方；EDIV 和Rand这两个密钥都是每次在 LTK 新产生的时候紧随着 LTK 一起产生的，如果 LTK 不变，那么这两个密钥也不需要改变。那么这两个密钥是干什么用的呢？这两个密钥是在第一次绑定成功后，在下一次重新连接时，双端不需要再进行配对过程，而是通过 LL 层直接发起链路加密，这个时候发起端的 LL 层会通过加密命令发送 EDIV 和 Rand，响应端收到这两个密钥以及其他一些参数之后就可以确定对方的 LTK，如果 LTK 与自己储存的 LTK 不匹配，则需要重新发起配对过程。所以这也是绑定的奥义所在，加速了后续的连接速度。
（6.2）IdKey：此位是 IRK 分发使能位，使能该位会分发 IRK（Identity Resolving Key ：身份解析密钥），BLE 里加入了“随机地址 / 私有可解析地址”这一概念，通过不断改变自身的Mac的地址来躲避不信任设配的一些请求；所以位了信任的设备认识自己，就让对方通过 IRK 来解析自己的Mac地址来发送消息。
（6.3）Sign：签名密钥，若果希望使用加密模式2的安全方式，BLE会在上层应用中加密，此加密就应用到签名，若果签名数据正确，则对端有权访问自己的服务和特征里的具体数据，否则就拒绝访问本机所有的数据并且断开连接，一般我们只用到加密模式1这种加密方式，并不需要签名。
（6.4）LinkKey：LinkKey是一个1位字段。当SMP在LE传输上运行时，LinkKey字段设置为1，以指示设备希望从LTK派生链路密钥。当发起方和响应方密钥分发/生成字段中的两个设备都将LinkKey设置为1时，应使用从LTK计算BR/EDR链路密钥的程序。不支持LE安全连接的设备应将该位设置为零，并在接收时忽略该位。当SMP在BR/EDR传输上运行时，LinkKey字段应设置为零，并在接收时忽略。
（7）Responser Key Distribution ：参考（6）。

以上就是配对特性报文的所有内容，经过此报文交换后，对端都获得了彼此的相关信息。那么接下来解析一下报文是如何决定第二阶段配对方式的选择以及加密方法的选择的。

2.2、特性交换报文对配对阶段2 的决策

蓝牙协议栈对于决策加密方法并不是公平的，它也给各个能力编排了优先权，最高决策权的是OOB，然后到MITM，最后才是IO Cap；没听懂？没关系，看下图：Initiator下方一行是发起者的OOB | MITM 能力；Responder右方一列是响应者的OOB | MITM 能力。首先协议栈会决策OOB，若有双端OOB为Set，那么会直接使用OOB加密方法，忽略MITM以及IO Cap能力，这就是OOB的霸权。双端若有任一方OOB 为Not Set那么决策权交给了MITM，双端MITM 均为Not Set则选择Just Works的加密方式。双端任一方或者双方MITM为Set，那么决策权就会交给IO Cap（IO Cap会进一步决策，下面内容会详细分析），本部分OOB |MITM 的选择结束。
OOB and MITM for LE Legacy pairing
再看下面一张图，哎是不是跟上一张图很像啊！这两张图是有讲究的，上面一张图是传统配对方式下的OOB|MITM优先权的映射表；那么下面一张图就是安全配对方式下的OOB|MITM优先权的映射表；他们唯一的区别是传统配对方式是双端都要支持OOB才能使用OOB进行身份验证，而安全配对方式比传统配对方式高级一点点，只要双端任意一端 OOB为Set，即可使用OOB进行身份验证。其他的跟传统配对方式一毛一样！
OOB and MITM for LE Secure Connection Pairing

在报文第二个字段 IO Cap中双端获得了对方得分的io 综合能力；Initiator下面一行是发起端的综合能力，Responder对应的一列示响应端的综合能力，组成下面一表格，选择出最后决定的加密方式进行配对。
在这里插入图片描述

至此我们获得了第二阶段所需的配对方式选择，加密方法已经完成了选择就可以进行配对第二个阶段的配对进程了：配对密钥的生成（STK | LTK）。

2.3、特性交换报文对配对阶段3 的决策

在报文第6、7字段交换的信息，我们也已经知道了需要交换哪些秘钥，早就为第三个阶段秘钥分配做好了准备，在第二个阶段结束后立刻就可以进行第三个阶段进程：密钥的分发（配对就是这么效率，这么赶）。
篇幅过于长了，别着急，第二阶段马上就来，我们深入了解一下配对第二个阶段都干了些什么，以及配对方式、加密方法为什么会对第二阶段产生影响。为什么配对三个阶段只有第二个阶段配对过程有差别。会给出详细的过程以及解析。同时以上内容也希望各位大佬提出不妥的地方，一起进步，冲冲冲！