OTA技术交流(uptane)-V1
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
11
三、Uptane详细设计
3.1、DirectorRepo与Primary的交互过程
Primary
(5)primary根据指向 timestamp stamp的url来 下载metadata和image.
(1)发送 Version manifest
到Director
百度文库
(4)director给 primary返回一个 指向timestamp的
Role
Purpose
root
Serves as the certificate authority for the repository. Distributes and revokes the public keys used to verify the root,
timestamp, release, and targets role metadata.
2>真实性:timestamp/snapshot/target 是由 root中指定的 key签名,而root则是由上一次的root去签 名的。
Director target
9
三、Uptane详细设计
2.2、Role Metadata 属性
10
三、Uptane详细设计
3、Repository:ImageRepo和 DirectorRepo
三、Uptane详细设计
1、总体框架
TimeServer
DirectorRepo
同步Metadata
获取时间 上报 version manifest 下载Metadata,加密image 下载Metadata,image
车载ECU
Primary
Full verification 分发Metadata,Image
目录
一、 OTA威胁模型
二、 Uptane设计特点 三、 Uptane详细设计 四、
可定制优化 五、 现OTA实现 六、 Uptane落地
1
一、OTA威胁模型
OTA非常重要： ➢ 改进现有功能 ➢ 添加新功能 ➢ 更新软件bug 但是也非常容易遭受攻击：
2
二、Uptane设计特点
1、TUF（The Update Framework）设计特点
基本特点：
DirectorRepo还包含一个DB
包含了车辆和ecu信息: .车辆标识符(例如VIN) .ECU标识符(例如序列号) .哪个ECU是Primary .用于验证 version manifests或每ECU加密的ECU key,以及关联信息如加密算法等 .所有车辆上所有ecu的所有可用image的元数据,以及不同ecu的image之间的依赖和冲突.这用于依赖解析
2.1、Role Metadata 举例
Image target
设计特点： 1>metadata被分成了4部分，分别由4种role签署，每种role的都有不同key(key个数,过期时间 均可定制),并通过version和过期时间来方便管理; 2>root 指定了每种role的key信息,实现key的分发和撤销; 3>target指定了真正image的metadata, ImageRepo和DirectorRepo的target metadata的区别是：前 者包含了所有的image的metadata,后者仅仅包含了需要下发的image 的metadata和自定义数据; 4>timestamp 指向snapshot，snapshor又指向target和root,
targets
Indicates metadata, such as the cryptographic hashes and file sizes of images. May delegate this responsibility to other,
custom-made roles.
8
三、Uptane详细设计
3
二、Uptane设计特点
2、Uptane 对TUF的改进
相比通用计算设备，汽车： 1>暴露的攻击面更多，但安全要求性更高 2>供应商多，管理复杂 3>车载ECU很多，且计算能力弱，存储空间小，差异性大 4>车载ECU没有可靠的时钟
4
二、Uptane设计特点
5
三
Uptane 详 细 设 计
1 总体架构 2 Role 3 Repository 4 TimeServer 5 车载端下载&安装 6 车载端验证过程 7 生产预置 8 安全性总结
url
Director Process
Timestamp Metadata
Snapshot Metadata
(2)查询db,处 理依赖解析
inventory database
(3)根据依赖解析结 果,生成需要安装的 image的metadata,和
可能需要加密的
image
Targets Metadata
链式验证:层层推进，安全强度高
1>完整性:timestamp -- > snapshot -- > target 和root ，每层分别验证 sha256,version,length,expire primary下载metadata时即按此顺序依次下载和验证,而Repo生成metadata时是倒过来的。
Partial verification
ImageRepo
7
三、Uptane详细设计
2、角色（Role）
设计目的：通过 1>多个独立key（职责分离）签署metdata，2>key的有效 管理 来加强Repository的安全 作用:不同的role使用不同的key签署metadata的不同片段 有四种基本类型role：root, targets, snapshot, 和timestamp 关系和和作用如下：
Encryted Image
(2)(3)详细过程
1)解析version manifest得到VIN;根据VIN,从数据库中 查询该车每个ECU的信息: .比如是否是primary; .是否需要加密image; .用于加密image和验签的key等; 2)检查manifest的准确性,至少确保: .db中的每个ECU记录也在manifest中 .manifest的签名与发送此manifest的primary的ECU key一致; .manifest中对secondary签名与secondary ECU key一 致; 还有一些额外检查: .比如primary是否在一直重复相同的manifest. 如果检查失败，将记录事件到db中,丢弃此次请求; 当然OEM可能需要人工干预以确保该车能够更新升级; 3)决定哪些image应该接下来被安装. .首先从manifest中提取信息，比如name，hash，当前 ECU已经安装的iamge. .然后行依赖解析，计算哪些最新image可以安全的同时 安装;
timestamp Indicates whether there is any new metadata or image on the repository.
snapshot Indicates which images have been released at the same time by the repository.
三、Uptane详细设计
3.1、DirectorRepo与Primary的交互过程
Primary
(5)primary根据指向 timestamp stamp的url来 下载metadata和image.
(1)发送 Version manifest
到Director
百度文库
(4)director给 primary返回一个 指向timestamp的
Role
Purpose
root
Serves as the certificate authority for the repository. Distributes and revokes the public keys used to verify the root,
timestamp, release, and targets role metadata.
2>真实性:timestamp/snapshot/target 是由 root中指定的 key签名,而root则是由上一次的root去签 名的。
Director target
9
三、Uptane详细设计
2.2、Role Metadata 属性
10
三、Uptane详细设计
3、Repository:ImageRepo和 DirectorRepo
三、Uptane详细设计
1、总体框架
TimeServer
DirectorRepo
同步Metadata
获取时间 上报 version manifest 下载Metadata,加密image 下载Metadata,image
车载ECU
Primary
Full verification 分发Metadata,Image
目录
一、 OTA威胁模型
二、 Uptane设计特点 三、 Uptane详细设计 四、
可定制优化 五、 现OTA实现 六、 Uptane落地
1
一、OTA威胁模型
OTA非常重要： ➢ 改进现有功能 ➢ 添加新功能 ➢ 更新软件bug 但是也非常容易遭受攻击：
2
二、Uptane设计特点
1、TUF（The Update Framework）设计特点
基本特点：
DirectorRepo还包含一个DB
包含了车辆和ecu信息: .车辆标识符(例如VIN) .ECU标识符(例如序列号) .哪个ECU是Primary .用于验证 version manifests或每ECU加密的ECU key,以及关联信息如加密算法等 .所有车辆上所有ecu的所有可用image的元数据,以及不同ecu的image之间的依赖和冲突.这用于依赖解析
2.1、Role Metadata 举例
Image target
设计特点： 1>metadata被分成了4部分，分别由4种role签署，每种role的都有不同key(key个数,过期时间 均可定制),并通过version和过期时间来方便管理; 2>root 指定了每种role的key信息,实现key的分发和撤销; 3>target指定了真正image的metadata, ImageRepo和DirectorRepo的target metadata的区别是：前 者包含了所有的image的metadata,后者仅仅包含了需要下发的image 的metadata和自定义数据; 4>timestamp 指向snapshot，snapshor又指向target和root,
targets
Indicates metadata, such as the cryptographic hashes and file sizes of images. May delegate this responsibility to other,
custom-made roles.
8
三、Uptane详细设计
3
二、Uptane设计特点
2、Uptane 对TUF的改进
相比通用计算设备，汽车： 1>暴露的攻击面更多，但安全要求性更高 2>供应商多，管理复杂 3>车载ECU很多，且计算能力弱，存储空间小，差异性大 4>车载ECU没有可靠的时钟
4
二、Uptane设计特点
5
三
Uptane 详 细 设 计
1 总体架构 2 Role 3 Repository 4 TimeServer 5 车载端下载&安装 6 车载端验证过程 7 生产预置 8 安全性总结
url
Director Process
Timestamp Metadata
Snapshot Metadata
(2)查询db,处 理依赖解析
inventory database
(3)根据依赖解析结 果,生成需要安装的 image的metadata,和
可能需要加密的
image
Targets Metadata
链式验证:层层推进，安全强度高
1>完整性:timestamp -- > snapshot -- > target 和root ，每层分别验证 sha256,version,length,expire primary下载metadata时即按此顺序依次下载和验证,而Repo生成metadata时是倒过来的。
Partial verification
ImageRepo
7
三、Uptane详细设计
2、角色（Role）
设计目的：通过 1>多个独立key（职责分离）签署metdata，2>key的有效 管理 来加强Repository的安全 作用:不同的role使用不同的key签署metadata的不同片段 有四种基本类型role：root, targets, snapshot, 和timestamp 关系和和作用如下：
Encryted Image
(2)(3)详细过程
1)解析version manifest得到VIN;根据VIN,从数据库中 查询该车每个ECU的信息: .比如是否是primary; .是否需要加密image; .用于加密image和验签的key等; 2)检查manifest的准确性,至少确保: .db中的每个ECU记录也在manifest中 .manifest的签名与发送此manifest的primary的ECU key一致; .manifest中对secondary签名与secondary ECU key一 致; 还有一些额外检查: .比如primary是否在一直重复相同的manifest. 如果检查失败，将记录事件到db中,丢弃此次请求; 当然OEM可能需要人工干预以确保该车能够更新升级; 3)决定哪些image应该接下来被安装. .首先从manifest中提取信息，比如name，hash，当前 ECU已经安装的iamge. .然后行依赖解析，计算哪些最新image可以安全的同时 安装;
timestamp Indicates whether there is any new metadata or image on the repository.
snapshot Indicates which images have been released at the same time by the repository.