01_CCC3.0数字钥匙_蓝牙OOB配对过程

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->Vehicle和Vehicle->Device;

First_Approach_RQ （FA_RQ）

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

Message	Message ID	Parameters
First_Approach_RQ	0x0E	E1_Payload、IV1、Tag1、E2_Payload、IV2、Tag2

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

Parameters	Length (bytes)	Description
E1_Payload	8	E1_Payload is an encrypted (AES-128-CCM) DK_Identifier using Kble_intro key. If a slot_identifier is available during first approach, the DK_Identifier is an 8-byte padded slot_identifier. If no slot identifier is available during first approach, the DK_Identifier is an 8-byte random number generated according to Listing 15-6.
IV1	8	IV used by device for encrypting E1_Payload using Kble_intro
Tag1	4	AES-CCM authentication tag for E1_Payload using Kble_intro
E2_Payload	38	E2_Payload is encrypted (AES-128-CCM) BTAddrA (6 Byte) && Ca (16 Byte) && ra (16 Byte) using Kble_oob as shared secret. The BTAddrA, Ca and ra are Bluetooth address of the device, Calculated Value on the device, and Random Value on the device, respectively (see Figure 19-16).
IV2	8	IV used by device for encrypting E2_Payload using Kble_oob
Tag2	4	AES-CCM authentication tag for E2_Payload using Kble_oob

First_Approach_RS （FA_RS）

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

Message	Message ID	Parameters
First_Approach_RS	0x0F	E_Payload、IV、Tag

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

Parameters	Length (bytes)	Description
E_Payload	38	E_Payload is encrypted (AES-128-CCM) BTAddrB (6 Byte) && Cb (16 Byte) && rb (16 Byte) using Kble_oob as shared secret. The BTAddrB, Cb and rb, are the Bluetooth address of the vehicle, Calculated Value on the vehicle, and Random Value on the vehicle, respectively (see Figure 19-16).
IV	8	IV used by vehicle for encrypting vehicle OOB data using Kble_oob.
Tag	4	AES-CCM authentication tag for E_Payload using Kble_oob

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由在进行SPAKE2+之后派生的系统密钥过程中派生，也就是说在进行First_Approach_RQ之前已经是已知的数据。
  步骤D中，我们已经有了DK_Identifier和Kble_oob_master这两个数据之后，就可以派生出密钥：Kble_oob，具体派生公式如下：

Keys = HKDF-SHA256(64, Kble_oob_master, DK_Identifier )
Kble_oob = Keys[0:15]

  步骤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