在stage1认证完成后，就可以进行phase2的第三步，计算LTK了。
图3-101 Phase2第三步：LTK计算
LTK由DHKey派生，使用的是f5算法，F5算法基于 AES-CMAC 实现，属于对称加密算法，计算是很快的，一般controller会带有AES硬件加速，这个就更快了。
F5算法用来生成MacKey和DHKey。
从hcilog上可以看到，这个过程有几个LE Encrypt 命令下发给controller，就是因为F5算法会用到AES128加密算法。
图3-102 f5算法用到了AES128加密
接下来进入Phase2的验证dhkey阶段
图3-103 验证dhkey阶段
这里主要是使用f6算法，会使用上文f5生成的mackey进行签名验证，如果验证成功配对就完成了。验证dhkey需要做一些AES计算，在抓包文件中可以看到host多次下发encrypt command，这些都在几个毫秒之内就完成了，并不占用过多时间。
图3-104 authentication stage2
这之后就可以生成加密通道进行通信了，sniffer如果不知道LTK的话是无法解密后续的通信的，像这样：
图3-105 进入加密通信
3.14.4.4 Phase3：最后的"钥匙交接仪式"
配对的完整流程还剩下phase3，还有一些剩余的工作要做，我们必须解密一下，好在LTK我们软件端是可以知晓的，btstack的ltk存放位置在这个结构体：
图3-106 btstack存放ltk位置
从jlink调试口可以观察到这个变量的值，输入到Ellisys之后，就可以解密后续的报文了：
图3-107 解密后得到Phase3报文
BLE的安全配对Phase3阶段，双方会继续交互一些specific Key，具体有哪些Key，在Phase1阶段的feature exchange的时候，双方都已经做了声明。像我们这次抓包我们就发送了IRK，IRK是蓝牙协议中用于解析可解析私有地址（Resolvable Private Address） 的密钥，确保设备地址变化时仍能识别同一设备，在配对（Bonding）后，IRK与长期密钥（LTK）共同存储，用于后续快速安全连接。
综上，BLE安全配对的大致流程如下：
第一步（Phase1），双方通过pairing feature exchange交换得到双方的配对和认证方式。
第二步（Phase2），双方交换public key，这个过程很快，因为这个public key是蓝牙初始化的时候事先计算好的，这个计算主要是使用私钥与椭圆曲线基点相乘（如A = a * G）生成公钥。交换完后随即双方开始dhkey计算，生成Dhkey，这个会比较慢，基于对方公钥和本地私钥计算共享密钥，涉及模幂运算，耗时很长。BLE的安全配对比legacy配对慢很多主要是生成dhkey的ECDH算法是秒级的，因为BLE芯片首要考虑功耗而不是性能，所以低端芯片一般没有硬件ECDH加速。
计算完dhkey之后，双方进入认证的第一阶段，使用f4算法确认confirm value和随机数是否对应，这个过程类似于legacy的认证，在Just works的模式下，无法抵抗中间人攻击。
不过安全连接还有认证第二阶段，这个阶段的工作是，首先用f5计算长期秘钥LTK和MacKey，前者用于加密数据，后者用于认证，这两个key都是DHKkey派生的，所以中间人攻击就不好使了。然后用f6算法，使用Mackey进行第二次认证，这个通过以后，后续进入第三步。
第三步（Phase3），双方通过加密通道分发特定的秘钥，可能包括IRK、CSRK等等，目的是为了后续的快速安全重连、防止设备被追踪等等。