企业官网建设流程全解析

BLE配对Just Works”是指蓝牙低功耗（Bluetooth Low Energy，简称BLE）配对模式中的一种简化配对机制，主要用于设备之间的快速连接，无需用户手动输入密码或确认配对请求。BLE4.2之后，这种配对方式实际上也有一些区别，可以支持Secure Connection，之前是经典的配对。

工作原理

1. 自动配对：设备在首次连接时自动完成配对过程，无需用户干预。
2. 无交互设计：不要求用户输入PIN码、点击确认或进行其他操作。
3. 安全性：虽然便捷，但“Just Works”模式的安全性相对较低，因为它不提供身份验证或防中间人攻击（Man-in-the-Middle）的保护。

协议规范

整体流程

核心文档Vol3：Host Part H：Security Manager Sepcification Appendix C Message Sequence exchange

BLE的配对过程主要有下面4个步骤：

1、配对特性交换，确认双方IO能力，是否支持SC等，决定Step2使用Just Words，OOB还是其他；

2、根据Step1的能力，自动选择一个方式；-- 本文介绍Just Words，后面案例会让他选这个。

3、生成STK，加密通信链路，生成LTK等相关信息。

4、传输分发的密钥信息，根据不同的配对有区别。

步骤一 配对请求

标准的流程，配对第一步，目的是主从机收集下能力集，决定使用哪种方式配对。

步骤二 Just Works配对

在配对特性交换后，自动选择Just Works，密钥输入或OOB方式。下面假设选择了Just Works的配对，进入下面的步骤。

步骤三 STK密钥生成

主从机分别同步c1的计算comfirm值（16字节）和random值（16字节），并进行交换和确认。

具体公式如下：c1 (k, r, preq, pres, iat, rat, ia, ra) = e(k, e(k, r ⊕ p1) ⊕ p2)

实际就是对上述数据进行aes-128的加密计算，具体细节参考Vol3 Part H 2.3.5.5 LE legacy pairing phase 2.

从计算的数据内容看，参数因子是相同，因此其实不管使用什么算法都是一直的confirm值。当主从机拿到TK=0，LP_RAND_R,LP_RAND_I，再通过s1生成相同的STK。

s1的定义s1(k, r1, r2) = e(k, r’)，r’ = r1’ || r2’

步骤四 分发密钥信息

密钥信息分发内容取决于配对时候能力的差异，简单理解，双方支持什么就交换什么。下面是所有可能的情况。这里密钥信息传输使用步骤三生成的STK进行加密传输。

从机发送给主机

1、LTK，Long Term Key，长密钥绑定后保存到Flash

2、EDIV，Rand，检索长密钥，绑定后保存到Flash

3、IRK，设备地址解析密钥，绑定后保存到Flash中，如果设备使用随机可解析地址，使用该密钥进行解析公共地址（也可以是静态随机地址）

主机发送给从机相同的信息，从协议规范描述看，双向交互信息后都会保存到Flash中。主机的发送给从机的信息，主要是考虑主机可能切换到从机的情况。所有从这个角度说，如果主机和从机角色不变，那么主机和从机进行加密通信，使用的是从机发送给主机的相关信息，包括LTK，EDIV，Rand等。

上述已完成了整个Just Works的配对绑定流程，绑定成功后主机和从机会保存上述相关密钥信息，主要包括LTK，EDIV，Rand，BD_ADDR，IRK等信息。下次主机或从机再次发起绑定，直接回复相关信息即可进行加密通信。

步骤五 链路层密钥生成

这部分内容在规范文档中，没有在Part H部分进行详细的说明，需要具体参考Vol 6：Low Energy Controller Part B：Link Layer Specification 5.1.3 Encryption procedure

在步骤四之前或之后（理论上都可以），主机会发起开始加密请求报文，具体流程如下。对于的表协议文档Vol 6：Low Energy Controller Part D Message Sequence Charts 6.6 Start encryption

主机发送的LL ENC REQ命令中包含Rand，EDIV，SKD_C，IV_C

从机回复的LL ENC RSP命令中包含SKD_P，IV_P

对于已经绑定的设备来说，主机发送的Rand， EDIV是一个非0的有效值，即绑定时候保存的从机发送的EDIV和Rand值，通过这些值，从机可以查询到对应的LTK值。

如果还没有完成绑定，主机发送的Rand， EDIV都是0。

主机和从机分别将SKD_P和SKD_C拼接成SKD，SKD_P作为高位；IV_P和IV_C拼接成IV，IV_P作为高位。

SKD = SKD_P || SKD_C
IV = IV_P || IV_C

主机和从机分别通过SKD和LTK计算得到链路层密钥Session Key，具体计算如下。解释下将LTK作为密钥，对SKD（16字节）进行AES-128加密，生成的结果作为Session Key。

Session Key = e(LTK, SKD)

后面BLE的链路加密全部使用这个Session Key进行加密和解密。当然整个过程中，还要很多异常的情况和处理，此处不再详细的描述，细节需要参数规范文档。

这里还要一点，IV的有什么作用？哪里会使用到呢？

抓包分析

为了更好的理解和学习，抓包使用了2种手段，一种是手机端的HCI log抓包，一种是BLE无线空口报文。手机端的HCI log对于安卓手机来说相对比较简单，一般使用adb就可以方便导出，iPhone可能需要考虑下。BLE无线抓包，目前使用最多的应该是ellisys的设备，但是设备价格也是最高的，最基本的也是10w+以上。这边使用的抓包工具相对少一些，品牌Rfcreations，软件使用blueSpy。

配对请求

手机上HCI Log，手机发送配对请求，然后接收到配对请求回复。

手机上基本能力全开了

设备是一个遥控器使用HID协议，IO能是没有输入和输出，所有绑定只有使用Just Works，不支持SC（安全加密），不支持MITM防中间人攻击，keypress只支持输入认证情况。

对应的无线报文如下，其实没有太大区别，内容上一致。

STK密钥生成

手机Hci log如下，手机发送confirm，设备回复，手机发送random，设备回复。具体计算参考协议规范中的介绍。

无线抓包也是相同的情况

加密请求

在实际和设备测试过程中，发现分发密钥之前主机开始进行加密情况，这种情况下，实际上设备还没有配对成功，所以Random和EDIV是0

手机Hci log

对应的无线抓包如下。

分发密钥

手机上hci log，手机接收设备的LTK，EDIV，Rand，发送LTK，EDIV，Rand，IRK和自己的公共地址。只有设备拿到手机IRK，下次连接才能正确的解析手机的这个可解析随机地址。

无线报文如下，和手机端的log可以完全对应。

总结

BLE配对根据设备IO能力分别多种，上述主要介绍了Just Works的legacy pairing的方式，对于BLE4.2之前的版本使用的方式，这种方式最大的问题就是安全不高，目前新的BLE协议基本上已经很少使用，尤其是安全性要求较高的设备。

所以从这种最简单最经典的配对方式进行介绍BLE配对绑定的过程。后续会根据实际的情况在分别介绍pin码输入，OOB等相关配对的方式。

当前网络上有很多关于BLE的配对的过程介绍，但是对于链路密钥生成基本都没有提及和说明，因此这边对所有的规范重新学习和整理一下，方便有需要的朋友进行学习。在过程中，有任何问题和疑问可以评论区反馈和互动