Legacy pairing 从名字上看可以知道它是老式设备采用的配对方法。
配对的最终目的是为了生成key，key可以给链路加密，保证双方设备通信的安全性。那配对流程的讲述其实就是key的生成过程。
key的生成是经过各种各样的算法，这里不会针对具体的算法讲述，而是着重描述其流程，以及key生成过程中的逻辑推理。
Legacy pairing 的流程可以分为如下的几个阶段：
- 随机数的生成
- key的选择以及生成。
- key的验证
下面先看一下 legacy pair 最终建立链路的流程图：
上图中对应pair的1，2，3阶段标出如图示。
首先大概描述一下 整个的流程：
- controller端会和对端的设备进行LMP feature exchange 的交互—>
- 交互之后确定配对算法legacy pairing（之前未配对过情况。如果host端有key，那么先走authentication流程，该流程若失败继续走legacy pairing）—>
- controller端向host请求pin code
- controller 获得了pin code之后生成随机数发送给对方。
- 对端也进行pin code 的请求，并生成相应的随机数发送给对方。（这里描述的是可以配对的情况，不可配对场景后面会描述）
- 双方发送 key给对方，并生成最终的link key
- 进行authentication的操作
- 通知各自的host ：link key 已经生成。
下面详细描述一下 Legacy pairing 的流程的各个阶段所做的具体的事情。
首先看看随机数的生成：
这里涉及到一个问题：什么样的双方是可以配对的？
主要有如下的几种场景：
1.responder 有一个可变的pin，这种情况可以配对，其随机数交互的流程如下：
上面的 legacy pair 最终建立链路的流程图就是属于这种情况，当initiator发送random给responder的时候，responder回复LMP accepted
2.responder 有一个固定的pin，这种情况也可以配对，其随机数交互的流程如下：
在这种情况下，双方使用的随机是responder 发送过来的随机数。
3.双方有一个固定的pin ，那这种情况双方是无法配对的。其交互流程如下:
上面讲的这个随机数是干嘛的呢？
它是双方设备计算Kinit 用的，这个Kinit 最后又会被用来计算link key。下面先看看这个Kinit的计算：如下图：
使用的算法是E2 其中 L‘ = pin 的长度 ，这里的RAND就是上面交互的随机数，pin的话 老式机器一般都是4个0，那么从上图可以推出双方的Kinit应该是一样。
接下里看第二阶段：key的选择以及生成。
关于key的选择，这里存在两种key：unit key和comb key ，那么两种key 对应于什么样的应用场景呢？
1.如果其中有一方使用unit key，那么双方就使用unit key作为link key。
2，如果双方都给对方发送unit key，那么使用master的unit key作为link key。
3.如果双方都发送LMP_comb_key，那么双方就使用他们两者的key经过计算得到的key。
关于最终key的使用，其互相交互的流程如下：
接下来先看一下 key生成的大局流程图：
由于前面的分析，现在看到这个图应该也不难理解的，可以发现之前的随机数是用来计算Kinit，Kinit又会被用来计算link key。
那下面就来分析一下，Kinit是 如何经过计算出link key。
首先来看看 unit key 是如何计算出来的
key的计算如下所示：
上面生成K之后，用下图的算法和对方交换key
关于上图中的蓝牙地址也是双方根据pin code预先设定好的，下面的图是key的交换的过程。
下面再看看 combination key 的生成
这里需要解释 是K，当处于未配对状态，这个K = Kinit，其余的流程 上图已经明显，最后可以知道KAB = KBA
到这里key的生成已经完成。
最后是一步key的验证：
关于key的验证，其套路还是不变的。主要就是通过交换随机值以及通过随机值和link key以及其他共享信息计算出来的值 ，来互相验证。
其流程如下图：
这里需要注意的就是，上图只是展示单方面的验证，验证过程是双向的。
另外注意的是这里的随机不是上面的随机值了，可以发现其名字不一样了，这个随机值是在authentication 的过程中重新生成的。
相关的air log如下：
从上面的log 可以看出 其验证是双向的.
到此关于key的验证就结束了.
一般情况还会有一个encryption的流程,其实这个流程是不属于配对流程的,并且在ssp 流程中已经有描述,这里不再描述.