YTM32B1ME05密钥管理方案咨询

[ganyongchao]

Secure_Boot_Prepare里面有个HCU KEY的灌装参考下

[White_Adam]

ganyongchao 这个我了解，我在问题中描述了是通过软件接口和密钥明文写入，我的问题也基于这种写入密钥的方式。该方案在我的开发调试阶段验证功能有效性是没有问题的。但是我作为零部件供应商，客户应该是不会给我原始密钥明文的吧？包括就算我拿到了明文，难道在量产阶段我要使用一版软件先启动写入密钥，然后再刷入另一版集成了安全启动逻辑的软件吗？无法通过别的手段直接注入到OTP这种内存中吗？

[ganyongchao]

White_Adam 密钥管理是一个独立的功能，包括密钥产生、密钥申请、密钥灌装等，一般需要一个独立流程环节实现，比如在产线上从终端客户授权服务器上申请下载KEY，然后灌装到生产件里面，然后正常烧录产品应用软件

[White_Adam]

ganyongchao YTM32B1ME05支持硬件级的密钥注入吗？可以直接绕开软件写入密钥？

[ganyongchao]

White_Adam 主要两个方式：

1. 通过一个test code比如Secure_Boot_Prepare去烧录KEY；
2. 通过类似离线烧录器的设备定制开发烧录KEY脚本程序；

[White_Adam]

ganyongchao
对于方法1：这种方式似乎还是需要接触密钥原文？并且还是类似的问题，我需要先刷写运行一次样件？

[ganyongchao]

White_Adam 是的，密钥产生后总能接触到KEY的，保密规避处理就设计把这个KEY产生到灌装的过程黑盒化

[White_Adam]

ganyongchao 这怎么黑盒化？找一个保密人员由他将密钥编写到test code中，编译生成刷写文件释放出去？

[ganyongchao]

White_Adam 跟KEY的管理方商议。

[White_Adam]

ganyongchao 那安全启动密钥怎么办？ME05的安全启动是需要使用密钥明文生成签名文件的，这个过程如何保证安全性？

[Frankie]

可以用CUST_KEY 保护全部key, 作为ROOT_KEY，在受控安全的环境下烧录CUST_KEY.

[White_Adam]

ganyongchao 你好，密钥和客户确定是我方自己生成。目前有个问题是刷写步骤过于冗余，按照开发阶段的方案，最少需要刷写三次软件。1、刷软件写密钥；2、刷安全启动程序（这一步可以直接和项目代码一起刷写）；3、刷写验签文件。按照产线原则，尽量一次刷写完成。并且如果是一机一密，在产线上生成验签文件会让这个过程更加麻烦，要增加工序。请问这个过程是否可以精简？有无现有方案？

[Diga]

1. 可以通过离线烧录器直接烧密钥，而不是通过先烧软件再写密钥
2. 可以把 secure boot 固件，与你的应用程序 + 验签部分，合并成一个固件给产线，固件合成的步骤应该不需要在产线上实现

[White_Adam]

Diga 验签文件和工程hex可以合成吗？验签文件是bin格式，而且我看其数据的地址段是完全覆盖了secure boot 固件和应用程序的。