本文主要介绍CCC3.0采用BLE进行车主配对时,关于蓝牙OOB配对的内容。
首先,介绍下BLE Pairing的一些基础知识,有一些基本概念。之后,再着重介绍CCC规范定义的BLE OOB配对流程。
下面先简单介绍下BLE 5.0协议栈中,关于BLE Pairing的一些基本知识。具体可详见BLE 5.0 Vol 3 Part H。
BLE Pairing包含3个阶段,Phase 1和Phase2是必须支持的,Phase 3是可选的:
Phase 1:特性交换阶段Pairing Feature Exchange
Phase 2:密钥生成阶段
(LE legacy pairing): Short Term Key (STK) Generation
(LE Secure Connections): Long Term Key (LTK) Generation
Phase 3: 密钥的分发阶段Transport Specific Key Distribution
具体如下图:
备注:一般将主机Master称为发起端 Initiator,从机Slave称为响应端 Responder
首先BLE主从设备在Phase 1:Pairing Feature Exchange先交互相关信息,用来决定Phase2采用如下哪种方法:
Just Works
Numeric Comparison (Only for LE Secure Connections)
Passkey Entry
Out Of Band (OOB)
Pairing启动时,由发起设备发起Pairing Feature Exchange。Pairing Feature Exchange主要交互如下信息:
1) IO capabilities,
2) OOB authentication data availability,
3) authentication requirements,
4) key size requirements
5) which transport specific keys to distribute
其中IO capabilities, OOB authentication data availability, authentication requirements等信息用来决定Phase 2的方法。
Phase1蓝牙配对特性交换流程如下:
1) 发起端Initiator是通过发送Pairing Request给到响应端Responder。
2) 响应端Responder接收到主机端的配对请求之后,将发送Pairing Response命令至发起端Initiator。
即通过两条命令交互,知道对方蓝牙模块所具备的端口输入输出能力,以及是否具备OOB认证等能力。
通过Phase1主要决定如下两个信息:
1) 采用LE legacy pairing还是LE Secure Connections?
2) 采用哪种配对方法Just Works、Passkey Entry、Numeric Comparison、还是OOB?
下面分别展开粗略描述:
根据Pairing Request和Pairing Response中的AuthReq中的SC位来确认是否支持LE Secure Connections。
如果设备支持LE Secure Connections,则上图的SC字段设置为1,否则设置为0。
如果两个设备都支持LE Secure Connections,则使用LE Secure Connections,否则使用LE legacy pairing。
LE legacy pairing产生STK;(legacy pairing时不会生成LTK,但之后的加密启动流程中,BLE从节点自己生成LTK)
LE Secure Connections产生LTK;
注意:LE legacy pairing过程虽然只产生了STK,但在之后的加密启动流程中,BLE从节点会自行生成LTK。
即在下图的Step3中产生了STK。
上图的Step3再展开则为下面的启动加密流程图,即在该流程中产生了LTK。
1.2.2 采用哪种配对方法Just Works、Passkey Entry、Numeric Comparison、还是OOB?
首先根据上图Pairing Request和Pairing Response中的OOB data flag以及AuthReq中的MITM来确认是采用OOB、IO Capabilities、Just Works还是Check MITM。
具体采用哪一个详见下面两张图:
若是采用IO Capabilities,则继续根据主从设备双方的IO Capabilities参数(Table3.4)来选择哪种配对方式,具体详见下图Table2.8。
Phase2有两种配对方式,分别为LE legacy pairing与LE Secure Connections。具体采用哪一种进行配对是与Phase1的特性交互有关,如上章节Phase1的介绍。
LE legacy pairing 生成如下2个keys
1) Temporary Key (TK): 128位临时密钥,用于在配对过程中生成STK。
2) Short Term Key (STK): 128位的临时密钥,用于对配对后的连接进行加密。
LE Secure Connections生成如下1个key
1) LTK (Long Term Key): 128位密钥,用于对配对后的连接和后续连接进行加密。
根据Phase2采用LE legacy pairing或LE Secure Connections,后续密钥分发的内容会有些差异,具体描述如下。
具体详见BLE5.0协议栈Vol3, Part H 3.6.1
Slave通过相关命令发送如下数据给Master:
LTK using Encryption Information command
EDIV and Rand using Master Identification command
IRK using Identity Information command
Public device or static random address using Identity Address Information command
CSRK using Signing Information command
Master通过相关命令发送如下数据给Slave
LTK using Encryption Information command
EDIV and Rand using Master Identification command
IRK using Identity Information command
Public device or static random address using Identity Address Information command
CSRK using Signing Information command
具体详见BLE5.0协议栈Vol3, Part H 3.6.1
Slave通过相关命令发送如下数据给Master:
IRK using Identity Information command
Public device or static random address using Identity Address Information command
CSRK using Signing Information command
Master通过相关命令发送如下数据给Slave
IRK using Identity Information command
Public device or static random address using Identity Address Information command
CSRK using Signing Information command
所谓的OOB配对,一般是指采用带外的方式(非BLE,如采用NFC)来交互一些信息。
一般的OOB配对,其实就是在非BLE通信的方式下交互如下6个参数:
A/B:主/从设备的地址,CCC规范中将这两个参数定义为BTAddrA和BTAddrB。
ra/rb:主/从设备的随机数
Ca/Cb:主/从设备分别通过PKa,ra和PKb,rb计算出来的加密数。
即,DeviceA将BTAddrA/ra/Ca发送给DevcieB;
DeviceB将BTAddrB/rb/Cb发送给DevcieA。即下图的红框部分。具体也可详见BLE5.0协议栈Vol3, Part H 2.3.5.6.4。
CCC规范的OOB配对,也需要交互如下6个参数:
BTAddrA/BTAddrB:主/从设备的地址。
ra/rb:主/从设备的随机数
Ca/Cb:主/从设备分别通过PKa,ra和PKb,rb计算出来的加密数。
但是CCC规范采用还是用蓝牙的方式来交互如上6个参数。
具体实现方式如下:
1、手机事先将BTAddrA/ra/Ca等三个参数加密,然后通过蓝牙将这些参数传输给车辆。
2、车辆解密出真正的BTAddrA/ra/Ca。
3、车辆也事先将BTAddrB/rb/Cb等三个参数加密,然后通过蓝牙将这些参数传输给手机。
4、手机解决出真正的BTAddrB/rb/Cb。
这样既满足了安全性,还能降低系统成本(不需要NFC等其他通信方式)。
CCC规范中将上面描述的这些OOB交互的内容,放在了配对绑定流程的最前面,即下图第一个步骤的Bluetooth LE Secure OOB Pairing Preparation。
如下流程图实现了OOB配对的6个参数的互相交互。
BTAddrA和BTAddrB:主/从设备的地址
ra/rb:主/从设备的随机数
Ca/Cb:主/从设备分别通过PKa,ra和PKb,rb计算出来的加密数。
上面说的BLE OOB配对是通过Supplementary Service message中的First Approach messages来进行交互的。
First Approach messages主要用于车主和朋友手机的BLE OOB安全配对。共包含两个命令,First_Approach_RQ和First_Approach_RS。
CCC规定通过DK Message Format格式来发送数据,采用Supplementary Service message的Message Type,如下图,具体也可详见CCC规范19.3章节。
上面三表可以梳理为下图:
该消息由手机发送给车辆,以共享手机的OOB数据。手机OOB数据包括两个加密有效载荷的组合,即E1_Payload和E2_Payload。
E1_Payload和E2_Payload分别使用Kble_intro和Kble_oob进行加密。
在CCC规范章节19.3.4 .1 First_Approach_RQ有详细描述该命令的数据结构.
上面两表可以梳理为下图:
该消息由车辆发送给手机,以共享车辆OOB数据。
该车辆OOB数据是使用Kble_oob密钥加密的。
在CCC规范章节19.3.4 .2 First_Approach_RS有详细描述该命令的数据结构。
上面两表可以梳理为下图:
1) BLE协议栈的BLE Pairing包含3个阶段。
a. Phase 1:特性交换阶段Pairing Feature Exchange
b. Phase 2 :密钥生成阶段
c. Phase 3: 密钥的分发阶段Transport Specific Key Distribution
2) Phase2里又分为两种配对
a. LE legacy pairing: Short Term Key (STK) Generation 或
b. LE Secure Connections: Long Term Key (LTK) Generation
3) CCC协议采用的是LE Secure Connections配对,并采用的是OOB配对方式。
4) OOB配对,要求手机和车辆需提前交互如下参数:
a. BTAddrA和BTAddrB:主/从设备的地址
b. ra/rb:主/从设备的随机数
c. Ca/Cb:主/从设备分别通过PKa,ra和PKb,rb计算出来的加密数。
5) 传统的OOB配对,一般是通过带外(非BLE,如NFC)通信来实现BTAddrA/BTAddrB、ra/rb、Ca/Cb等6个参数的交互。
6) CCC规定的OOB配对还是通过BLE进行通信,实现这6个参数的交互,如下:
a. 手机将BTAddrA/ra/Ca加密发给车辆,车辆解密后存储起来,用于后续的配对流程。
b. 车辆将BTAddrB/rb/Cb加密发给手机,手机解密后存储起来,用于后续的配对流程。
7) CCC中定义的交互这6个参数的流程叫BLE Secure OOB Pairing Preparation,具体详见CCC规范的Figure19-16。