如何在MCAL框架下实现Secure Boot

[yxydoctor]

节前已经实现了boot+app+串口的固件现场升级方案。借助UID进行了简单加密。显然这种土方法加密方式是不严谨的。

32B1H内置Secure Boot固件，支持包含代码加密在内的一些安全启动功能，感觉上跟NXP的流程差不多。简单学习了一下，还是比较困惑。以NXP的为例：

1 - Secure Boot固件是驻留在ROM中的一段代码，开机后会先运行，这点都是一样的；

2 - Secure Boot启动配置项：包括是否启用安全boot，是否启用加密，是否启用看门狗，加密所用的密钥等等设置项，NXP是放在熔丝里面进行配置的且有专用的配置工具。32B1H是放在用户固件里面的，通过YTC进行配置，但好像是不支持MCAL平台。

3 - 最核心的固件加密：密钥，加密算法，代码加密region，这些参数也是通过上位机软件进行配置的。配置完毕后会对原生的BIN文件打包，最后烧录到芯片。

4 - 整个过程是不需要用户自己编一行代码的，只是按需要设置和配置即可。这是说得通的。因为如果固件的加解密过程由用户代码实现，感觉这个加密过程本身就是不保密的。

5 - NXP的解密支持静态解密，也支持在线动态解密，就是说烧录到flash的用户固件就是密文而不是明文。但没看到云途这方面的介绍。

6 - 固件加密，用户更关心的是固件安全性和完整性，固件加密也不是为了学习什么加密算法。

罗嗦了半天其实就是一句话：怎么借助32B1H内置Secure Boot固件，实现用户固件的加密。比如：现在有“用户BOOT+用户App”两段代码：
用户BOOT最好是能加密，而用户App不能加密，但需要验签其完整性，因为用户App最初可能是空的，是由用户BOOT通过串口烧录进去的。如果都加密，可能用户BOOT代码也不跑了那就糟糕了。

[xianghan]

1 云途烧录到flash的是明文，不支持密文。
2 App的加解密可以在二级boot（用户boot）里调用加密引擎实现。
3 Secure boot通常只针对二级boot（用户boot）进行验签。
4 固件的安全性可以通过关闭JTAG保护实现，完整性依赖Hash或者签名值。

[yxydoctor]

xianghan 您的意思好像是指mcu自带的硬件secure boot本身并不支持加解密，签名验签，相关操作还是需要在二级boot里面自行实现。

或者说32B1H的硬件secure boot的功能重点指的并不是固件加解密。

[Diga]

Secure Boot 只有验签功能，即对指定区域验证签名，保证代码完整性与安全性。
签名由上位机实现。

[yxydoctor]

Diga 是您说的这个意思. 按xianghuan所说, Secure boot只针对二级boot。那就先考虑二级boot问题。
步骤1：写用户密钥到NVR；
步骤2：借助YTC配置Secure boot，但官方例程不是针对MCAL环境下的；不确定直接secure_boot_config.c文件拷贝到MCAL环境下是否适用；
步骤3：再通过YTC对RAW的HEX打包，目的应该是附上BVT需要的一些参数信息。

整个过程应该是不需要涉及到FLASH和HCU，Secure boot本身应该是已经自带这两个模块驱动了。

现在是知道一点流程；但看官方例程又比较迷糊。

这是NXP烧录上位机提供加密界面（也是硬件），一目了然。密钥，加密模式，受保护区可按需配置。

[Diga]

https://forum.ytmicro.com/topic/90/ytm32b1mc-安全启动demo?_=1738809563575
可以参考该帖，另外该帖下有 SecureBoot 的应用笔记可以参考

[yxydoctor]

Diga 谢谢回复。这篇应用笔记之前看过。所以才会知一惑二。既然secure boot属于硬件加密，本就不应该需要flash，hcu这些驱动模块，这样的话，加解密，签名就跟MCAL环境无关了。配置配置就行。但从官方例程看，不是这么回事。

二级boot（用户自己的boot）本就包含了看门狗，Fls写用户App功能，不考虑二级boot加解密的话，其实这时候这个所谓的硬件secure boot其实是多余的。

哎，回头再看一下加解密例程把。看看能不能由二级boot对app固件做点保密工作。