蓝牙secure simple pair 概述

Secure Simple Pairing，简称SSP，其流程主要分为六个部分：

1. • IO capabilities exchange
2. • Public key exchange
3. • Authentication stage 1
4. • Authentication stage 2
5. LINK KEY CALCULATION
6. LMP AUTHENTICATION AND ENCRYPTION

 

 

接下来将逐个介绍这个六个部分的内容。

 IO capabilities exchange

在ssp的过程当中，有两个角色：“Initiator ”和“Responder ”，他们是如何确认的呢？主动发起 IO capabilities exchange流程的那一方就是Initiator，而另外一方就是Responder 。

 IO capabilities exchange 是干吗的呢？

在日常的配对中，有以下的场景：

1. 手机和键盘配对，咱们会被要求在键盘上面输入字符。
2. 手机和音箱配对的时候，咱们每每不须要额外的操做。
3. 手机和手机的配对的时候，咱们每每要在两只手机的屏幕上面都要点击一下配对。
   
   
   

上面的场景就是配对的设备之间通过IO capabilities exchange以后来肯定了双方进行配对所选取的最合适的配对算法。配对算法有以下的几种：

1. Numeric comparison
2. Passkey entry
3. Out of band 

手机和键盘进行配对的场景就属于Passkey entry，而手机和音箱的配对属于Numeric comparison，Out of band 是属于带外数据的通讯，这里基本用不到，不做细节介绍。

那么接下来的一个问题是：IO capabilities exchange 和配对算法的选取的具体的映射关系是什么样的呢？

请看下图：

上面这个图是根据设备的input和ouput的能力来归结出来的一个综合的IO能力，下面这张图是根据这个IO能力来选择不一样的流程：

上面两张图都是比较容易理解的，这里举两个例子来讲明一下（每每是以下的状况，并不绝对，严格来讲仍是要看IOcap）：

initiator	responder	配对算法选取
TV	音箱	Numeric Comparison with automatic confirmation on both devices
TV	手机	Numeric Comparison: Both Display, Both Confirm
TV	键盘	Passkey Entry: Initiator Display,Responder Input.

最后看看这一流程的空中交互：

OIcap的整个流程图以下：

ssp的第二个阶段是Public key exchange

首先看一下这个部分流程图：

这里交换的public key其实设备本身生成的，还有一个screct key，这二者组成一对key。从上图能够看出，当获得了对方了public key以后就进行了DHKey的计算，DHKey最终会参与到link key的计算当中。

由于public key比较大，它是分多比包来传输的。从上图能够看出它是先传输的header部分，而后在传输palyload部分。

air log中该过程的交互以下：(下图只展现了responder-->initiator部分)

 

Authentication Stage 1

这一部分主要介绍两种配对协议：

Numeric Comparison Passkey Entry Authentication

首先来看看

Numeric Comparison

这个配对协议的使用场景，上面已经分析过，这里再次重复一下。

1. 当双方的设备都有output的能力的时候，好比两个手机进行配对，这个时候两只手机的界面须要用户去确认的。
2. 当一方设备有output的能力，可是另外一方设备是no input or output的时候，好比手机和音箱进行配对的时候，这种状况和上一种的状况的区别是不要用户去确认，这种状况其实也能够称为just work

下面从btsnoop中看一下二者的区别：下面是（TV和TV配对）

若是用户不去确认屏幕上面显示的value，那么最终就会出现LMP response timeout的错误：

而若是用户在屏幕上面点击取消配对的话，那么相应的log以下:

这边抓了一下air log发现，如是在确认界面直接点击取消配对的话，那么controller端是直接发送LMP Detach的报文，那么在对方的host就只会收到一个disconnection event。

在spec中规定是要下一次initiator进行DHKey check的时候，responder才通告验证失败：

 

以上是关于该协议的流程部分，下面看一下该协议的算法部分：

上面的图片都有注释，比较容易看懂，这里就再也不过多解释。在配对章节的基本思想都是以下：

一方经过随机值rand与某个配对算法（以前协商好的）计算出一个confirm值，而后把rand值和confirm值发送给对方，让对方去check。

 

接下来看 这一阶段的另外一个配对协议Passkey Entry Authentication

这个配对协议的典型应用场景就是键盘和TV的配对。

下面看一下其流程：

从上面的流程图能够看出来，其校验的套路仍是同样，首先按照某种算法计算出confirm 值，并发送给对方，而后双方再交换各自参与计算confirm值的random值，而后依次使用对方发送过来的值进行计算看是否和对方发送过来的confirm值相等。

下面看一下 校验过程的详细流程图：

上面的流程图也很容易理解，参照上面的注释应该能看懂，这里不作过多注释。下面看一下该流程在air log中的表现：

下面是对应的btsnoop：

上面两张图是对应于按键的输入流程输入流程。输入完成以后开始计算：注意上面流程图显示了计算要计算20次，下图简单展现几回交互过程：

 

接下来看看Authentication Stage 2

这一阶段主要的工做就是DHKey的验证，这个流程很是的简单，以下：

DHKey校验完成以后，那么以后的流程就是要生成link key了。这里须要说明一下的是 DHKey是在前面进行public key交换以后就生成了。

 

下面来看看link 能够的生成过程：LINK KEY CALCULATION

其link key的计算算法以下：

咱们能够看出，其中输入参数都是双方已经校验过的，而且参数是一致的，若是双方计算不出错的话，输出的link key也是一致的。

从上面的这个图能够看出来，双方计算了link key以后还会再进行一轮校验，以保证生成的link key确实是同样的。相应的air 中的状况以下：

 

到此link key就生成了，这个key标志着配对完成。以后只要二者没有删除link key，仍是能够回连的。回连的流程就不会再走一系列的生成key的动做，而是直接验证link key。

 

最后来看看encryption的过程：

在air 中的交互以下：

上面的流程是生成KC，下面是key做用于数据包的示意图：

 

这个流程的意思就是经过link key以及一些其余的信息生成一个Kc，而后Kc又参与某种算法生成Kcipher，最终由这个key 对接下来发送的数据进行加密。这里要注意的是加密是针对于baseband层的payload，加密并不会对header进行加密。

到此ssp流程分析完毕。