梳理项目,发现了之前很多没有思考的地方。
以下资料来源: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 对应的私钥
完成私钥公钥对应。