系统安全启动总结思考

梳理项目，发现了之前很多没有思考的地方。

以下资料来源：NXP 公开资料

专有名词

Imx8qxp：NXP 芯片系列

OTP：单次编程属性。

efuse：保险熔断区

fuse：写入保险熔断区

close：保险熔断

SRK：安全根密钥 secure root key

目的：通过对镜像签名，达到系统可信加载。防止不可信镜像和被破坏的镜像的加载。

方式：通过签名验签方式进行可信身份认证。

准备阶段：

1、证书相关的准备，生成 证书（多个）和对应私钥（多个）。

2、对证书处理、生成table.bin （多证书集合）、table_fuse_sha512.bin(将table.bin sha512处理，64字节、作为根密钥 )

3、打开编译选项，获取镜像偏移地址。uboot.img 大小略为 1.6M

4、编写 uboot.txt 文档。采用签名工具指定对应的私钥进行镜像签名

输入：偏移地址，公钥（table) 公钥子序号（index） 私钥 待签名镜像（uboot 和 spl）

输出：签名后的镜像 镜像后缀 table

5、fuse 写入、table_fuse_sha512.bin 采用16进制处理后进行 fuse 写入。

uuu 模式写入

ahab 状态查询

ahab 熔断 。熔断后，写入的值无法更改。

 

6、系统自处理。

加载后采用镜像后的偏移地址，获得公钥表（table） 和应该使用的子序号。然后进行 sha512 处理。处理后和 fuse 内容比对。

对比成功则认为证书可信，

采用 table （序号公钥）对镜像进行验签，验签成功，镜像可信。

正常启动。

思考：

1、产线过程产线工人进入uuu 模式进行设置，会影响整个产线效率。

2、车机启动---uuu 模式--完成设置-再重启， 两次车机启动。还是效率问题。

在 boota 阶段。通过系统启动源码修改完成 fuse 写入、

写入后直接加载后直接代码里完成 ahab status 检测和 close 熔断。

引入问题：代码可信问题。也就是相当于把超级密钥写入了代码里。

（同态加密变异引入--是否可以解决这类问题）

签名：

签名输入txt详情： 包含公钥和序号

 相关 key 的关系：

大小：

 摘要：可以看出公钥xxx   5e 开头的摘要

 12345678 对应的摘要

对应关系：12345678 对应的私钥

 完成私钥公钥对应。