蓝牙Legacy Pairing流程概述

Legacy pairing 从名字上看能够知道它是老式设备采用的配对方法。

配对的最终目的是为了生成key，key能够给链路加密，保证双方设备通讯的安全性。那配对流程的讲述其实就是key的生成过程。

key的生成是通过各类各样的算法，这里不会针对具体的算法讲述，而是着重描述其流程，以及key生成过程当中的逻辑推理。

Legacy pairing 的流程能够分为以下的几个阶段：

1. 随机数的生成
2. key的选择以及生成。
3. key的验证
   
   

下面先看一下 legacy pair 最终创建链路的流程图：

上图中对应pair的1，2，3阶段标出如图示。

首先大概描述一下 整个的流程：

1. controller端会和对端的设备进行LMP feature exchange 的交互—>
2. 交互以后肯定配对算法legacy pairing（以前未配对过状况。若是host端有key，那么先走authentication流程，该流程若失败继续走legacy pairing）—>
3. controller端向host请求pin code
4. controller 得到了pin code以后生成随机数发送给对方。
5. 对端也进行pin code 的请求，并生成相应的随机数发送给对方。（这里描述的是能够配对的状况，不可配对场景后面会描述）
6. 双方发送 key给对方，并生成最终的link key
7. 进行authentication的操做
8. 通知各自的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 流程中已经有描述,这里再也不描述.