0、开篇：

  对于熟悉BLE的朋友，蓝牙OOB这个词肯定不陌生，一般来说蓝牙OOB就是主从机交换BTAddrA/BTAddrB、Ca/Cb和ra/rb这三个参数。比较安全的方法就是将这三个参数通过蓝牙以外的方式传输，比如使用NFC、红外这样的近场通信方式。但CCCR3规范是事先将三个参数加密，然后通过蓝牙将这些参数传输给对方。这样一来机密性满足了，还降低了系统成本以及开发复杂度。
  关于蓝牙的OOB在《配对特征交换》里面有具体的介绍，可以具体看一下蜗牛哥的文章《CCC3.0学习笔记_蓝牙OOB配对》，本文主要对ccc3.0蓝牙OOB准备阶段的细节展开。

1、CCCR3规范上可以将蓝牙OOB分为三个部分：

  Part1：蓝牙OOB准备阶段蓝牙通道交换的报文；
  Part2：Ex_Payload、IVx、Tagx来源（x代表1/2/无）；
  Part3：标准的蓝牙OOB流程。

Part1：蓝牙OOB准备阶段蓝牙通道交换的报文：

  在此阶段蓝牙主要交换两条包报文：First_Approach_RQ （FA_RQ）和 First_Approach_RS（FA_RS），其方向分别是Device->Vehile和Vehile->Device;

First_Approach_RQ （FA_RQ）

  报文如下（记住有哪几个参数就行）:

  参数描述如下（后面会对参数的来源做解析）

First_Approach_RS （FA_RS）

  具体报文如下（记住有哪几个参数就行）:

  参数描述如下（后面会对参数的来源做解析）

Part2：Ex_Payload、IVx、Tagx来源（x代表1/2/无）：

  在Part1部分已经引出了OOB前所需要的所有参数，结合着参数的生成步骤，看一下这些参数是怎么来的，如下图所示。
  A和B步骤，双端设备各自生成自己的PKx/SKx、Cx、rx（x代表Device或Vehicle）
  E1_Payload、Tag1是在步骤C过程中生成的，IV1在CCCR3规范里面没指定，充当的是noise的角色，应该是一个8字节长度的随机数。 E1_Payload是将DK_Identifier使用AES_128_CCM加密算法，以Kble_intro作为密钥，IV1作为noise生成的，在计算过后也就生成了Tag1作为E1_Payload的认证标签。
  在上面我们谈到DK_Identifier和Kble_intro是从哪里来的呢？
  DK_Identifier是一个8字节长度的数据，在第一次靠近请求之前双端如果已经有key_slot(1-8字节可变)存在的话，那么DK_Identifier就是在key_slot（slot_identifier）基础上前置补足（补0）八字节的数据；否则就按照Listing 15-6规则生成的随机数。
  Kble_intro以及接下来的步骤中提到的Kble_oob_master在18.4.9章节已经导出，也就是说在进行First_Approach_RQ之前已经是已知的数据。
  步骤D中，我们已经有了DK_Identifier和Kble_oob_master这两个数据之后，就可以派生出密钥：Kble_oob，具体派生公式如下：

  步骤E中，我们有了密钥Kble_oob，就可以使用AES_128_CCM对AddrA||Ca||ra加密计算出E2_Payload，同理，IV2也是个Noise，Tag2也是E2_Payload的认证标签。
  以上所有数据都有了，那么就可以发送First_Approach_RQ给Vehile，Vehile使用同样的方法派生出Kble_oob，从而解密出Device端的AddrA、Ca和ra。同样，也将自己的AddrB、Cb和rb以及Kble_oob、IV使用AES_128_CCM加密，向Device端发送First_Approach_RS。
  经过这两条报文都交换了之后，双端都拥有了对端的OOB数据，那么接下来就是进行标准的OOB配对加密流程就可以了。

Part3：标准的蓝牙OOB流程

  标准的OOB流程在CCCR3规范里面具体的流程如下：

  至于更详细的解析可以参考蓝牙核心规范、《LTK生成》以及《密钥分发》：

3、参考：CCCR3核心规范1.0.0

1）19.2.1.2 章节：Bluetooth LE Pairing and Encryption Setup
2）19.3.4章节：Supplementary Service Message - First Approach
3）Figure 19-16: Bluetooth LE Secure OOB Pairing Prep