CCC3.0数字车钥匙 蓝牙OOB配对
前言
随着科学技术的不断发展,车钥匙经历了从传统机械钥匙到高频、低频电子钥匙再到当前数字钥匙的转变。因为手机或手镯已经成为人们生活中不可缺少的电子产品,人们开始考虑用手机或手镯代替以前的车钥匙,蓝牙作为数字车钥匙的重要组成部分,本文将介绍它CCC3.0中关于蓝牙OOB匹配的部分,至于蓝牙模块之间的配对特性交换,不讨论认证和密钥生成分发。
1、蓝牙的几种配对方法
1. Numeric Comparision
双方都显示6位数字,用户可以检查数字是否一致。如果是一致的,则允许配对,如手机前的配对。
2. Just Works
用于配对未显示无输入的设备,可主动启动配对,用户看不到配对过程,如连接蓝牙耳机。
3. PassKey Entry
要求配对目标输入本地设备上显示的6位数,输入正确,如连接蓝牙键盘。
4. OOB(out of band)
所谓带外野,就是不使用蓝牙通道的配对,比如使用NFC近场通信或红外无线通信属于OOB方式 这种方法给了开发者很高的自由度,配对机制可以自己制定,但安全性取决于外部机制的安全性。
二、蓝牙OOB配对简单流程
1. BLE Pairing OverView
一般将主机Master称为发起端 Initiator,从机Slave称为响应端 Responder Phase1:配对特性交换阶段 Phase2:配对密钥生成阶段 Phase3:配对密钥分发阶段 我们主要讲解一下 Phase1蓝牙配对特性交换阶段: => 发起端Initiator通过向响应端发送配对请求命令Responder,参考蓝牙核心规范5.0(BT core_v5.0.pdf)。 => 响应端Responder接到主机端的配对请求后,将配对反馈命令发送到主机端,以完全交换配对特性。简而言之,通过两个响应命令,我们可以知道对方蓝牙模块的一些端口的输入和输出能力以及它们是否具备OOB认证等能力。
- BLE DHKey Consult 在这里,我们将解释如何协商对称密钥,即启动端和响应端将生成自己的公共和私人密钥对,保留自己的私钥,然后交换公钥,然后 DHKey = P256(Ska,Pkb) = P256(Skb,Pka) ,如果你想知道为什么这是平等的,如果你感兴趣,你可以去看看ECDH说明椭圆加密算法。 产生公共和私人密钥对后,使用相同的命令交换公钥,然后计算DHKey计算不需要以任何方式发送给对方,也就是这样完成的DHKey密钥协商。
3. BLE OOB Authentication
相信对蓝牙有所了解的同学对上图的步骤比较清楚,这里简要总结一下上图流程的主要功能如下:
(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
临时密钥 TK
配对特征交换时, 各自将自己的综合能力发送给对方的设备,最终根据两个设备的能力选择这种方式 TK 值的共享BLE4.事实上,在0协议规范中有三种决定方法TK值:
(1)Just Work(只工作):两种设备默认使用TK值(6 个 0)。这是一个不可靠的加密链路,不能防止MITM攻击。这 在使用这种方法时,可靠的前提是确保配对绑定 MITM 攻击,那么加密数据在后续连接中不能被其他设备窃听,保护未来加密链路的安全,但不能保护配对绑定过程
(2)Passkey Entry(输入密码):输入密钥: 两个设备中 ,一 蓝牙设备在自己的显示屏上显示随机6位数;看到这6位数后,操作人员将这6位数输入另一个蓝牙设备,以实现两个设备TK值一样
(3)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 就是利用三个随机数参与功能函数 s我们都知道,蓝牙配对绑定的第三阶段主要是密钥分发,用于未来的加密链路 LTK(长期密钥),IRK(地址分析密钥),CSRK(连接签名分析密钥),当然,如此重要的数据需要用密文传输,那么加密数据包的密钥就是会话密钥SessionKey(SK),从SK可以看到需要的计算公式LTK只有参与,设备在第一次配对绑定时,需要对数据包进行加密和传输,此时TLK还是没有分享,怎么办? 只能将STK当做 LTK参加会话密钥SK以后计算LTK共享之后,就不会再使用STK,所以这个短命的密钥 STK是临时使用,所以叫短期密钥。
BLE LL 链路加密握手(三次加密握手)
计算第三阶段STK主机通过链路层使用后主机 LL_ENC_REQ 发起加密请求计算会话密钥SK参数会话密钥分散值 SKDm发送给从机和CCM初始化向量的使用 IVm 值、计算 LTK 的 EDIV 和 RAND 所有参数都发送给从机。IV和SKD都是伪随机数。从机通过 LL_ENC_RSP 计算加密应答 SK 相关参数也发送给主机,主从之间通过 LL_START_ENC三次加密握手。第一次,从机将通过明确的方式进行 LL_START_ENC_REQ 开始向主机发送加密请求,并将自己的数据包设置为加密接收;第 2 第二,当主机收到从机开始加密请求的明文时,主机发送加密开始加密请求响应包LL_START_ENC_RSP 第三次,由于接收设置为加密模式,主机应能够成功接收 发 送 的 密 文 LL_START_ENC_RSP , 然后从机器发送加密LL_START_ENC_RSP包给主机从而完成 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数据交换就到此为止吧!