Secure Simple Pairing，简称SSP，其流程主要分为六个部分：
- • IO capabilities exchange
- • Public key exchange
- • Authentication stage 1
- • Authentication stage 2
- LINK KEY CALCULATION
- LMP AUTHENTICATION AND ENCRYPTION
接下来将逐个介绍这个六个部分的内容。
IO capabilities exchange
在ssp的过程中，有两个角色：“Initiator ”和“Responder ”，他们是如何确认的呢？主动发起 IO capabilities exchange流程的那一方就是Initiator，而另一方就是Responder 。
IO capabilities exchange 是干嘛的呢？
在平常的配对中，有如下的场景：
- 手机和键盘配对，我们会被要求在键盘上面输入字符。
- 手机和音箱配对的时候，我们往往不需要额外的操作。
- 手机和手机的配对的时候，我们往往要在两只手机的屏幕上面都要点击一下配对。
上面的场景就是配对的设备之间经过IO capabilities exchange之后来确定了双方进行配对所选取的最合适的配对算法。配对算法有如下的几种：
- Numeric comparison
- Passkey entry
- Out of band
手机和键盘进行配对的场景就属于Passkey entry，而手机和音箱的配对属于Numeric comparison，Out of band 是属于带外数据的通信，这里基本用不到，不作细节介绍。
那么接下来的一个问题是：IO capabilities exchange 和配对算法的选取的具体的映射关系是什么样的呢？
请看下图：
上面这个图是根据设备的input和ouput的能力来归结出来的一个综合的IO能力，下面这张图是根据这个IO能力来选择不同的流程：
上面两张图都是比较容易理解的，这里举两个例子来说明一下（往往是如下的情况，并不绝对，严格来说还是要看IOcap）：
|
initiator
|
responder
|
配对算法选取
|
|---|---|---|
| TV | 音箱 |
Numeric Comparison |
| TV | 手机 |
Numeric Comparison: |
| TV | 键盘 |
Passkey Entry: Initiator |
最后看看这一流程的空中交互：
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
这个配对协议的使用场景，上面已经分析过，这里再次重复一下。
- 当双方的设备都有output的能力的时候，比如两个手机进行配对，这个时候两只手机的界面需要用户去确认的。
- 当一方设备有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流程分析完毕。