3.13.3 Legacy配对
首先，我们回复的paring response中，可以看到我们不支持secure connection，所以我们走的是legacy配对模式。
图3-74 secure连接不支持
然后，master在pairing confirm包中回复了confirm value。
图3-75 master发送confirm value
这个数值是master端生成一个随机数后，将这个随机数作为输入，通过c1算法算出来的，叫做Mconfirm，接下来我们本地也需要生成一个随机数，通过c1算一下，算出来一个Sconfirm发给对方。
图3-76 配对phase2基本完成
到这一步我们的Sconfirm已经发过去了，流程进行到了这里
图3-77 just works配对流程
接下来我们卡死在check for confirm value match这里。
图3-78 confirm value fail
需要研究下C1算法了。
BLE的C1算法是蓝牙传统配对（Legacy Pairing）中用于生成确认值（Mconfirm/Sconfirm）的核心函数，以计算Mconfirm为例：
Mconfirm = c1(TK, Mrand, Pairing Request command, Pairing Response command, initiating device address type, initiating device address, responding device address type, responding device address)
其输入参数如下：
C1算法输入参数
临时密钥（TK）
128位临时密钥，由配对双方通过Passkey Entry等方式协商生成（如用户输入的6位数字扩展为128位）。
随机数（Rand）
主设备生成的128位随机数 Mrand 或从设备生成的 Srand13。
设备地址（BD_ADDR）
双方设备的MAC地址（Initiator Address）和从设备的MAC地址（Responder Address）23。
双方设备的地址类型
Public还是Random的
双方的配对命令
Pairing Request Command和Pairing Response Command
上面这些参数中，蓝牙地址、地址类型、随机数都是空中包明文传输的，只有临时秘钥Tk是不可知的，但是在Just Works的场景下，Tk是固定值0，这也是为什么Just Works是不放置中间人攻击的，适合于安全需求较低的场景。
我们现在出现的情况显然是，C1计算的值和对端不一致，需要对比一下C1算法的输入哪里出了问题。
图3-79 C1算法过程
这里展开说两句，C1算法需要调用两次AES-128算法，对于这个算法，一般蓝牙controller是支持硬件加速的，所以我们可以采用图中的方式，将明文通过HCI LE Encrypt Command发送给controller，由controller进行AES-128计算后，通过HCI event返回host, 来减轻HOST的负担。支持这个命令的前提是，蓝牙初始化的时候，当Host询问controller支持哪些命令的时候，controller得把对应的位置上。
图3-80 Read Local Supported Commands
在代码里，我们是使能的：
图3-81 支持LE ENCRYPT COMMAND
当然，btstack也支持在host来直接进行AES计算，只要打开USE_BTSTACK_AES128这个宏就可以了。
仔细检查上述变量的值，我们发现了问题所在：
图3-82 发现参数错误
再往前翻一下，很快找到了根源
图3-83 初始化返回给host的蓝牙地址就是反的
原因找到了，我们的蓝牙地址是01:23:45:67:89:ab，对方在计算C1的时候也是采用的这个蓝牙地址作为参数来进行计算，但是当我们本地进行计算的时候，选用的蓝牙地址的来源不是实际的蓝牙地址，而是这个从HCI Send Read BD ADDR Command所得到的蓝牙地址，导致错误。
看了一下CEVA的controller协议栈，果然针对这个命令回复是有bug的：
图3-84 ceva返回读蓝牙地址命令的问题
修改一下，按照网络字节序交换一下：
图3-85 修改read bd addr命令回复代码
这样之后，后续的配对过程就很顺畅了，最终的数据都是加密的：
图3-86 数据加密了
C1算法就像情侣默契测试：
输入：双方生日（设备地址）、恋爱宣言（配对指令）、测试题（随机数）
陷阱：地址字节序反了就像把生日8月5日记成5月8日
验证：硬件加密加速相当于找算命先生合八字