CCC3.0学习笔记_蓝牙OOB配对

系列文章目录

第四章 CCC3.0数字车钥匙学习入门之蓝牙OOB配对


文章目录

  • 系列文章目录
  • 前言
  • 一、蓝牙的几种配对方式
    • 1. Numeric Comparision
    • 2. Just Works
    • 3. PassKey Entry
    • 4. OOB(out of band)
  • 二、蓝牙OOB配对简要流程
    • 1. BLE Pairing OverView
    • 2. BLE DHKey Consult
    • 3. BLE OOB Authentication
    • 4. BLE Long Term Key Generate
  • 三、CCC3.0中关于OOB部分要求
    • 1. First Approach Request Message(FA-RQ)
    • 2. First Approach Response Message(FA-RS)
    • 3. Device-Vehicle OOB Data Exchange
  • 四、实际应用举例说明
  • 总结

前言

随着科技不断发展,车钥匙经历了传统机械钥匙到高低频的电子钥匙再到目前的数字钥匙的转变,由于现在手机或者手环等成为人们生活中必不可少的随身携带的电子产品,于是人们开始寻思着用手机或手环来代替先前的车钥匙,而蓝牙作为数字车钥匙的一个重要部件,本文将介绍CCC3.0中关于蓝牙OOB配对的那部分内容,至于蓝牙模块之间的配对特性交换,认证以及密钥生成分发则不在讨论的范围内。

一、蓝牙的几种配对方式

1. Numeric Comparision

   配对双方都显示一个6位的数字,由用户来核对数字是否一致,如果是一致的就允许配对,比如手机之前的配对。

2. Just Works

   用于配对没有显示没有输入的设备,主动发起连接即可配对,用户看不到配对过程,比如连接蓝牙耳机。

3. PassKey Entry

要求配对目标输入一个在本地设备上显示的6位数字,输入正确即可配对,比如连接蓝牙键盘。

4. OOB(out of band)

所谓带外野就是不使用蓝牙通道方式完成的配对,比如使用NFC近场通讯或红外无线传播方式就属于OOB方式
这种方式就给了开发者很高的自由度,配对的机制可自行制定,但是安全性则取决于带外机制的安全性了。

二、蓝牙OOB配对简要流程

1. BLE Pairing OverView

CCC3.0学习笔记_蓝牙OOB配对_第1张图片

一般将主机Master称为发起端 Initiator,从机Slave称为响应端 Responder
Phase1:配对特性交换阶段
Phase2:配对密钥生成阶段
Phase3:配对密钥的分发阶段
我们主要讲解一下 Phase1蓝牙配对特性交换阶段:
=> 发起端Initiator是通过发送一条配对请求命令给到响应端Responder,配对请求命令格式自行参考蓝牙核心规范5.0(BT+core_v5.0.pdf)。
=> 响应端Responder接收到主机端的配对请求之后,将发送一条配对反馈命令至主机端来完整配对特性交换的阶段。简而言之就是通过两条应答命令知道对方蓝牙模块所具备的一些端口输入输出能力以及是否具备OOB认证等能力。

2. BLE DHKey Consult

CCC3.0学习笔记_蓝牙OOB配对_第2张图片
这里说明一下对称密钥是如何协商的,就是发起端和响应端都会生成自己的公私密钥对,保留各自的私钥,然后互换公钥,然后就会有 DHKey = P256(Ska,Pkb) = P256(Skb,Pka) ,如果你好奇这个为什么会相等,感兴趣的话可以去看看ECDH椭圆加密算法的讲解。
产生公私密钥对之后用同样的一条命令实现公钥的互换,然后计算的DHKey是各自计算的并不需要通过任何方式去发送给对方,就是通过此种方式完成DHKey密钥协商的。

3. BLE OOB Authentication

CCC3.0学习笔记_蓝牙OOB配对_第3张图片
相信对蓝牙有所了解的同学对上述图片的步骤比较清楚,此处就简要总结上图流程主要完成的功能如下:

  1. 上一步已经说明了基于ECDH双方都产生了各自的公私密钥对并交换公钥(PKa/SKa & PKb/SKb)
  2. 发起端会使用两个公钥(PKa/PKb/ra) 来计算Ca,同理响应端会使用(PKa/PKb/rb) 来计算Cb
    如图中计算时使用 f4 功能函数。
  3. 图中发起端将(A,ra,Ca) 发送到响应端,而响应端将(B,rb,Cb) 发送到发起端,这就是交换所谓的OOB数据,可以理解为这是蓝牙OOB配对的数据准备阶段。
  4. 后面就是比对的操作了,因为发起者将 ra/Ca给到响应方,那么响应方就可以利用接收到的随机数ra代入到双方制定的加密算法中就可以计算出一个Ca,我们可以称之为 R_Ca (意思是接收方根据接收的随机数计算得到的),就是将计算的 R_Ca 与接收到的 Ca 进行比较,同理发起方接收到rb的时候也是做了同样的操作,这样双方都完成了Ca和Cb的验证操作。
  5. 从图中可以看到,当验证通过之后双端会选择随机数 Na 和 Nb 并进行交换。

4. BLE Long Term Key Generate

CCC3.0学习笔记_蓝牙OOB配对_第4张图片

  • 临时密钥 TK
    配对特征交换时, 各自将自己的综合能力发送给对方设备,最后根据两个设备的能力最终选择那种方式实现 TK 值的共享。在BLE4.0协议规范中其实是有三种方式决定TK值:
    Just Work(只工作):两设备使用的是默认的TK值(6 个 0)。对于这种方式是一个不可靠的加密链路,它不能防止MITM攻击。这 种方式使用时可靠的前提是,确保在配对绑定是能保证没有 MITM 攻击,那么在之后的连接中加密的数据是无法被其它设备窃听的,也就是说这种方式能保护将来加密链路安全,但是不能保护配对绑定过程
    Passkey Entry(输入密码):对于输入密钥来说: 两个设备中 ,一 个蓝牙设备在自己的显示屏上显示随机6位数;而操作人员看到这6位数后,将这6位数在另一个蓝牙设备中输入,从而实现两个设备的TK值一样
    Out of Band(带外):带外是使用另一无线方式将数据传给蓝牙设备,如果带外本身能防止MITM的攻击,那么传送的TK值肯定是受保护的。而且这种方式下的TK值是128bit的随机数,虽然还是有概率被第三方猜中,但是猜中128bit随机数的概率远比输入密码时的6bit的随机数要小。

  • 身份确认值 Mconfirm 与 Sconfirm的计算
    假定现在是使用 OOB配对方式,那么临时密钥 TK 就是一个128bit的随机数,然后发起端和响应端都使用功能函数 c1完成各自的身份确认值得计算,后面还是会进行同样的操作,接收端自身用Mrand来计算出 R_Mconfirm数值与发送方给过来的Mconfirm进行比对,而发送方泽使用Srand计算出 T_Sconfirm与接收方反馈回来的Sconfirm也进行一次比对,两边的确认值比对完了就完成了身份的确认。

  • 短期密钥 STK
    从上图中可以看到短期密钥STK其实是一个对称密钥,其计算公式 STK = s1(TK,Srand,Mrand),可以看出短期密钥STK 就是利用三个随机数参与功能函数 s1得到的密钥,我们都知道在蓝牙配对绑定过程中的第3阶段主要是进行密钥分发的,是未来的加密链路中使用到的 LTK(长期密钥),IRK(地址解析密钥),CSRK(连接签名解析密钥),如此重要的数据当然需要使用密文进行传输咯,那加密数据包的密钥就是会话密钥SessionKey(SK),从SK的计算公式可以看到需要LTK的参与才行,那么设备在第一次进行配对绑定时就需要对数据包进行加密再传输,而此时TLK还是没有共享的,怎么办呢? 只能将STK当做 LTK去参与会话密钥SK的计算,如果后面LTK共享之后,就不会再使用STK,所以这个短命的密钥 STK就是临时使用一下,所以就称之为短期密钥了。

  • BLE LL 链路加密握手(3次加密握手)
    第3阶段计算出STK后主机通过链路层使用 LL_ENC_REQ 发起加密请求,并将用来计算会话密钥SK的参数会话密钥分散值 SKDm发送给从机,以及CCM使用的初始化向量 IVm 值、计算 LTK 的 EDIV 和 RAND 参数都发送给从机。IV和SKD都为伪随机数。从机通过 LL_ENC_RSP 加密应答把计算 SK 相关的参数也发送给主机,这时主从之间通过 LL_START_ENC进行3次加密握手。第1次,从机通过明文的方式将 LL_START_ENC_REQ 开始加密请求发送给主机,并将自己接收数据包方式设置为加密接收;第 2 次,当主机接收到从机的开始加密请求的明文后,主机发送加密的开始加密请求应答包LL_START_ENC_RSP 给从机,并将自己的接收设置为加密接收;第3次,因为从机已经将接收设置为了加密模式,所以应该能成功接收到主机 发 送 的 密 文 LL_START_ENC_RSP , 之后从机发送加密的LL_START_ENC_RSP包给主机从而完成 3 次加密握手过程。

  • 加密链路下的密钥分发
    图中所示的第3阶段就是长期密钥TLK的交换,同时分发了IRK 和签名密钥CSRK

三、CCC3.0中关于OOB部分要求

1. First Approach Request Message(FA-RQ)


手机端通过蓝牙 DK message 将自身 OOB数据的密文数据发送到车辆端,车辆端接收密文数据以后需要使用AES-CCM 解密算法获取明文数据。

2. First Approach Response Message(FA-RS)


车辆端的蓝牙模块也需要将自身的OOB 数据加密之后发送到手机端,同理手机端也是需要解密后才能拿到车辆端的OOB明文数据的。

3. Device-Vehicle OOB Data Exchange

四、实际应用举例说明

在实际的项目实施过程中,UWB模块是专门用于进行蓝牙链路通讯的,而智能进入控制上面是有SE加密芯片的,由加密芯片SE来处理所有数据端的加解密工作,那么UWB作为蓝牙是智能进入控制器和手机之间通讯的桥梁,手机与UWB模块是进行蓝牙通讯的,而UWB与智能进入控制器之间是进行CAN网络来传输数据的,所以呢UWB通常是将手机端的蓝牙数据打包成CAN数据然后通过CAN网络发送给智能进入控制器,而智能进入控制器需要传送信息给到手机的时候,也是将信息先通过CAN网络给到UWB再通过蓝牙发送至手机。

这样一来,UWB在接收到手机端的OOB密文数据的时候,再加上自身的OOB明文数据一起打包成CAN数据发送到智能进入控制器,智能进入控制器将OOB明文和密文一起发送至SE加密芯片,加密芯片解密手机的OOB密文同时加密车辆端蓝牙模块的明文,处理的数据返回给智能进入控制器。

总结

以上就是今天要讲的内容,为了尽量讲清楚CCC里面关于OOB数据,顺带先讲解了一下蓝牙模块的OOB配对相关的知识,这样更容易理解,关于OOB数据交换就到此为止吧!

你可能感兴趣的:(CCC数字钥匙,汽车)