本文引自：https://blog.bluetooth.com/bluetooth-pairing-part-5-legacy-pairing-out-of-band
之前章节有介绍了Passkey和Numeric Comparison等配对方法。今天将介绍另外一种方法：OOB。
OOB关联模型适用于使用带外机制来发现设备、以及交换或传送将在配对过程中使用的加密信息等场景。
OOB对于开发者来说是一项灵活的选择，能够让他们定义自己的配对机制，因此安全级别取决于带外保护功能。
1. 第一阶段：配对特性交换
在“BLE SM (1)”中有讲到类似表1的表格。这是Pairing Request/Response 的框架结构。在该表中，有“OOB Data Flag”字段，长度是1个字节。
*表一：Pairing Request/Response 的框架结构
关于“OOB Data Flag”的定义，可参考表二：
*表二：OOB Data Flag
“OOB Data Flag”定义了用于指示OOB认证数据是否可用的值。
2. 低功耗传统配对
当两台蓝牙设备都使用低功耗传统配对时，这一过程是很容易理解的。有关传统配对方法选用的详细信息，请查看表三。
我已经在此表中对选用OOB的单元格进行了黄色标注，这样就一目了然：
（1）如果使用OOB进行配对，两台设备必须设置其OOB数据标志；
（2）如果其中一台设备设置了OOB数据标志，而另外一台没有设置，则两台设备都需要检查在表一中的“AuthReq”字段中的
MITM标志。如果其中任何一台设备设置了MITM标志，则可通过IO 能力与配对方法的映射来选择配对方法。有关映射的
详细信息，请参阅蓝牙5和新规格第3卷H部分表2.8。
（3）其他情况，则使用直接连接(Just works)方法配对；
*表三：OOB 配对规则速查表
*图一：OOB配对流程图
图一中，高亮标注的部分与Passkey章节相同，之后，两台设备的安全管理器SM将：
首先：创建两边的随机值Mrand和Srand。之后，带外机制可用于交换信息，假如设备地址和128位临时密钥(TK)值，以助于设备发现。
如Passkey章节所讲，TK值是由伪随机数引擎产生的128位随机数，引擎应符合蓝牙核心规范的要求。
（1）通过公式c1计算Mconfirm和Sconfirm，对于任何加密工具箱，均可参阅蓝牙5核心规范第3卷H部分第2.2章节；
（2）交换Mconfirm，Sconfirm和Mrand。
（3）响应设备通过发起设备传送的Mrand值来再次执行Mconfirm的计算，来验证计算出的值和Mconfirn的值是否一致。
1）如果响应设备计算得出的Mconfirm与发起设备传送的Mconfirm值不匹配，则配对过程中止，响应设备会发送原因代码为“确认失败(confirm Value Failed)”的配对失败指令；
2）如果响应设备计算得出的Mconfirm与发起设备传送的Mconfirm值匹配，则响应设备会向发起设备发送Srand；
（4）发起设备通过响应设备传送的Srand值来再次执行Sconfirm的计算，来验证计算出的值和Sconfirn的值是否一致。
1）如果发起设备计算得出的Sconfirm与响应设备传送的Sconfirm值不匹配，则配对过程中止，发起设备会发送原因代码为“确认失败(confirm ValueFailed)”的配对失败指令；
2）如果发起设备计算得出的Sconfirm与响应设备传送的Sconfirm值匹配，则发起设备会计算出短期密钥(STK),并通知controller启用加密；
3. 总结：OOB的简洁之处
目前，低功耗蓝牙已经成为智能手机和平板电脑的标配，设备间采用蓝牙进行连接的方法多种多样。在这些 方法中，还有一种通过蓝牙连接设备的常用方法就是使用NFC进行一键配对。由于NFC的传输范围非常有限，一些开发者在设备之间借助NFC确保两台设备正确的进行配对。
因此NFC可以为OOB配对提供良好的通信接口。当使用OOB进行配对时，用户的体验略有不同。例如，用户的智能手机和手环两台设备都具有低功耗蓝牙和NFC接口。用户先让两台设备相接触，然后会看到配对选项。如果选择是，这配对成功。
所以这是一种一键式的体验，交换的信息在两台设备中都能使用，是不是超酷？