CCC数字钥匙设计【BLE】--车主配对之BLE OOB配对

本文主要介绍CCC3.0采用BLE进行车主配对时，关于蓝牙OOB配对的内容。

首先，介绍下BLE Pairing的一些基础知识，有一些基本概念。之后，再着重介绍CCC规范定义的BLE OOB配对流程。

1、BLE Pairing基础知识

下面先简单介绍下BLE 5.0协议栈中，关于BLE Pairing的一些基本知识。具体可详见BLE 5.0 Vol 3 Part H。

1.1 Pairing阶段介绍

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

1.2 Phase1：特性交换阶段Pairing Feature Exchange

首先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？

下面分别展开粗略描述：

1.2.1 采用LE legacy pairing还是LE Secure Connections？

根据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。

1.3 Phase 2 密钥生成阶段（LE legacy pairing或LE Secure Connections）

Phase2有两种配对方式，分别为LE legacy pairing与LE Secure Connections。具体采用哪一种进行配对是与Phase1的特性交互有关，如上章节Phase1的介绍。

1.3.1 LE legacy pairing: Short Term Key (STK) Generation

LE legacy pairing 生成如下2个keys

1) Temporary Key (TK): 128位临时密钥，用于在配对过程中生成STK。

2) Short Term Key (STK): 128位的临时密钥，用于对配对后的连接进行加密。

1.3.2 LE Secure Connections: Long Term Key (LTK) Generation

LE Secure Connections生成如下1个key

1) LTK (Long Term Key): 128位密钥，用于对配对后的连接和后续连接进行加密。

1.4 Phase 3密钥的分发阶段Transport Specific Key Distribution

根据Phase2采用LE legacy pairing或LE Secure Connections，后续密钥分发的内容会有些差异，具体描述如下。

1.4.1 当Phase2采用LE legacy pairing时

具体详见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

1.4.2 当Phase2采用LE Secure Connections时

具体详见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

2、CCC的BLE OOB配对

2.1 BLE协议栈中规定的OOB配对

所谓的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。

2.2 CCC规范的OOB配对

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。

2.2.1 BLE Secure OOB Pairing Preparation

如下流程图实现了OOB配对的6个参数的互相交互。

BTAddrA和BTAddrB：主/从设备的地址

ra/rb：主/从设备的随机数

Ca/Cb：主/从设备分别通过PKa,ra和PKb，rb计算出来的加密数。

2.2.2 通过First_Approach_RQ/First_Approach_RS交互

上面说的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章节。

上面三表可以梳理为下图：

2.2.2.1 First_Approach_RQ

该消息由手机发送给车辆，以共享手机的OOB数据。手机OOB数据包括两个加密有效载荷的组合，即E1_Payload和E2_Payload。

E1_Payload和E2_Payload分别使用Kble_intro和Kble_oob进行加密。

在CCC规范章节19.3.4 .1 First_Approach_RQ有详细描述该命令的数据结构.

上面两表可以梳理为下图：

2.2.2.2 First_Approach_RS

该消息由车辆发送给手机，以共享车辆OOB数据。

该车辆OOB数据是使用Kble_oob密钥加密的。

在CCC规范章节19.3.4 .2 First_Approach_RS有详细描述该命令的数据结构。

上面两表可以梳理为下图：

3、总结

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。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/news/354201.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

Linux 查看内存状态

Linux 查看内存状态

# 查看系统内存 命令：free 注：默认k单位显示注：-m 以MB注：-g以GB 单位显示total used free shared buffers cached Mem: 497 463 33 0 13 124 -/ buffe…
阅读更多...
Altium Designer导入pcb原件之后都是绿的

Altium Designer导入pcb原件之后都是绿的

转载于:https://www.cnblogs.com/chulin/p/8342041.html
阅读更多...
在JConsole和VisualVM中查看DiagnosticCommandMBean

在JConsole和VisualVM中查看DiagnosticCommandMBean

我已经将JConsole用作合适的通用JMX客户端已有很多年了。 该工具通常随Oracle JDK一起提供，并且易于使用。 在JMX交互方面，JConsole优于VisualVM的最大优点是JConsole带有内置的MBeans选项卡，而必须为VisualVM中的相同功能应用插件。 但是&am…
阅读更多...
人人商城生成app教程_人人商城APP打包教程（APICLOUD版）

人人商城生成app教程_人人商城APP打包教程（APICLOUD版）

一.APP环境搭建和配置编译1.登录APICLOUD后台新建应用step1 注册账号注册apicloud 账号并登录APICLOUD控制台step2 新建应用再账户下面找到开发控制台>开发控制台>创建应用 填写应用名和说明，必选Native App创建Native App2 .开发工具下载安装APICLOUD开发工具…
阅读更多...
WPF快速入门系列(2)——深入解析依赖属性

WPF快速入门系列(2)——深入解析依赖属性

一、引言 感觉最近都颓废了，好久没有学习写博文了，出于负罪感，今天强烈逼迫自己开始更新WPF系列。尽管最近看到一篇WPF技术是否老矣的文章，但是还是不能阻止我系统学习WPF。今天继续分享WPF中一个最重要的知识点——依赖属性。 二…
阅读更多...
圆台下料展开计算方法_怎么画 圆锥台展开图

圆台下料展开计算方法_怎么画 圆锥台展开图

展开全部1、 画出圆台的主视抄图(等腰梯形)袭：圆台的上bai下底直径为等腰梯形du的上zhi下底，圆台的高为等dao腰梯形的高；2、将等腰梯形补画成等腰三角形；(图中的虚线三角形即为补画部分)；3、以三角形的顶点为圆心&…
阅读更多...
.31-浅析webpack源码之doResolve事件流(3)

.31-浅析webpack源码之doResolve事件流(3)

放个流程图： 这里也放一下request对象内容，这节完事后如下(把vue-cli的package.json也复制过来了)： /*{ context: { issuer: , compiler: undefined },path: d:\\workspace\\doc,request: ./input.js,query: ,module: false,directory: false…
阅读更多...
c++ 虚函数，纯虚函数的本质区别

c++ 虚函数，纯虚函数的本质区别

转载博客：https://mp.weixin.qq.com/s?__bizMzAxNzYzMTU0Ng&mid2651289202&idx1&sn431ffd1fae4823366a50b68aed2838d4&chksm80114627b766cf31f72018ef5f1fe29591e9f6f4bd72018e7aea849342ca6f0a271fb38465ae#rd 学习C的多态性&…
阅读更多...
云通讯短信验证码实例

云通讯短信验证码实例

1.注册登录云通讯 http://www.yuntongxun.com/user/login 2.创建应用得到应用相关信息 3.下载对应相关的Demo示例　　http://www.yuntongxun.com/doc/rest/sms/3_2_2_3.html 4.send.php文件添加代码方便后续操作 session_start(); //随机验证码 $code rand(100000,999999)…
阅读更多...
java 数组 内存_图解Java数组的内存分配

java 数组 内存_图解Java数组的内存分配

1. Java数组是静态的Java是静态语言，所以Java的数组也是静态的，即：数组被初始化后，长度不可变静态初始化：显式指定每个数组元素的初始值，系统决定数组长度String[] books new String[]{"疯狂Java讲义…
阅读更多...
libgdx和Kotlin –类[2D平台原型]

libgdx和Kotlin –类[2D平台原型]

这篇文章是libgdx和Kotlin文章的后续文章。 我已经决定开发一个简单的2D平台程序的原型（沿着我的早期文章中的Star Assault进行介绍），但是我一直在使用和学习Kotlin，而不是Java。 对于本教程，该项目应处于上一篇文章…
阅读更多...
spring jmx_JMX和Spring –第2部分

spring jmx_JMX和Spring –第2部分

spring jmx这篇文章从本教程的第1部分继续。 嗨，在我的上一篇文章中，我解释了如何通过Spring设置JMX服务器以及如何通过身份验证和授权保护对它的访问。 在本文中，我将展示如何实现一个简单的MBean，该MBean允许用户在运行时更改L…
阅读更多...
LeetCode：位运算实现加法

LeetCode：位运算实现加法

LeetCode：位运算实现加法 写在前面 位运算符 实现加法的思路 两个加数，比如5(101)和6(110)，如何不用加法就能得出两者之和呢？ 我们知道二进制计算中，如果使用异或将会产生无进位的两者之和，而两数相与将会产…
阅读更多...
[机器学习] 模型评价参数，准确率，召回率，F1-score

[机器学习] 模型评价参数，准确率，召回率，F1-score

很久很久以前，我还是有个建筑梦的大二少年，有一天，讲图的老师看了眼我的设计图，说：“我觉得你这个设计做得很紧张”，当时我就崩溃，对紧张不紧张这样的评价标准理解无能。多年后我终于明白老师当…
阅读更多...
java记录登陆时间_Spring security如何实现记录用户登录时间功能

java记录登陆时间_Spring security如何实现记录用户登录时间功能

一、原理分析spring security提供了一个接口 AuthenticationSuccessHandler,该接口中只有一个方法，用来进行登录成功后的操作public interface AuthenticationSuccessHandler {/*** Called when a user has been successfully authenticated.** param request the r…
阅读更多...
bzoj3680

bzoj3680

$模拟退火$ $这种全局最优的问题用模拟退火$ $模拟退火就是每次向四周随机移动，移动的幅度和温度成正比，如果新的位置更优就接受，否则按一定概率接收，概率和温度成正比$ $最后稳定后再在最优解附近蹦跶几下看看有没有更好的$ $你问…
阅读更多...
01背包（修订版）

01背包（修订版）

由于时间比较充裕，重新修订一部分。 这次把一些补充的放进来，其他的基础说明见后半部分 这些一共说明：01背包、完全背包、多重背包 将会详细说明。 三种背包混合、二维背包、分组背包、依赖背包、泛化背包 将大致说明。 01背包 如上次说明一…
阅读更多...
java 马踏棋盘优化_我所知道的十大常用算法之马踏棋盘算法（深度搜索、贪心思想优化 ）...

java 马踏棋盘优化_我所知道的十大常用算法之马踏棋盘算法（深度搜索、贪心思想优化 ）...

前言需求今天我们学习的是马踏棋盘算法，我们还是从一个场景里引入看看马踏棋盘算法也被称为骑士周游问题将马随机放在国际象棋的66棋盘Board0～5的某个方格中提示：马按走棋规则(马走日字)进行移动要求：每个方格只进入一次&#xff…
阅读更多...
app engine_App Engine中的Google Services身份验证，第2部分

app engine_App Engine中的Google Services身份验证，第2部分

app engine在本教程的第一部分中， 我介绍了如何使用OAuth进行Google API服务的访问/身份验证。 不幸的是，正如我稍后发现的那样，我使用的方法是OAuth 1.0，显然现在Google正式弃用了OAuth 1.0，改用OAuth 2.0版本。 显然…
阅读更多...
Django知识总结(一)

Django知识总结(一)

壹 ● 有关http协议 一 ● 全称 超文本传输协议(HyperText Transfer Protocol) 二 ● 协议 双方遵循的规范 http协议是属于应用层的协议(还有ftp, smtp等), 即浏览器请求消息和服务器响应消息的一系列规则 三 ● http协议的特性 http是无状态、无连接的协议(stateless, connect…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023