YTM32B1MC 安全启动Demo

[Diga]

zhai MC03 的 Secure Boot 应该可以对任意合法的Flash 内容进行校验。如果你希望同时对你的 bootloader 与 app 进行校验，增加一个 Secure Boot Section（文档中有提及）即可，即一个 section 用来校验 bootloader，一个 section 用来校验 app。需要注意的是，如果你用 bootloader 去更新了你的 app，那么就需要修改签名值，因为 app 的签名也发生了更改，否则 Secure Boot 会无法跳转到你的 bootloader

[PJzhang]

Diga 这个无法查看的？

[HEX]

Diga 请问下“bootloader 去更新了你的 app，那么就需要修改签名值”这个是什么意思？是我分别把bt和app文件都导入yt config重新生成下hex就行嘛？后续每次更新APP都导入yt config生成hex，下载这个hex就行？

[Diga]

bootloader 是客户用来更新 app 的东西，跟 secure boot 不一样，类似次级boot

1. 如果 secure boot 的验签内容中只包含 bootloader，即只对次级 boot 进行加密，那客户通过次级 boot 去更新客户的 App 是不受 secure boot 影响的
2. 如果 secure boot 的验签内容同时包含 bootloader 与 app，那么客户在每次更新完 app 后，需要重新进行加密，去生成新的签名值。如果希望通过 YT Config Tool 去生成签名值，需要将 次级 boot，App 与 BVT信息 合成一个 hex 后，让工具生成签名

[HEX]

Diga
1.YT Config Tool 目前仅支持生成bin文件嘛，app升级使用的UDS协议，仅支持hex、srec等文件的升级。
2.secure boot 进行验签执行时间有数据嘛？

[Diga]

YCT 目前仅支持输入 hex文件，输出 bin文件
验签时间跟验签 size 强相关，加密内容越少肯定时间越短，加密用的是 AES-CMAC

[HEX]

Diga
你好，目前Secure boot存在如下疑惑请帮忙解释下：
（1）使用通过YCT上位机对原始HEX文件签名生成密文下载到芯⽚后，我通过JLink将FLASH中的数据读出来之后发现和原始的HEX文件内容相同，请问下解密的过程是在哪里处理的？


（2）上位机对HEX文件签名之后附加的签名信息是在bin文件的哪个部分？

[Diga]

Demo 的话，应该是放在 BVT 那里

[Diga]

这个是签名算法，不对你的代码进行修改

[HEX]

Diga

（1）这是ME0的demo，左边是通过上位机签名生成的带签名信息的可执行文件，右边是原始的hex文件，从表现上看，已经对我的程序进行了修改，不知道我的理解对不。
（2）当通过jlink下载带签名信息的可执行文件后，在通过jlink将芯片数据读取之后发现是原始数据，这个解密是在哪里进行的？

[Diga]

ME0 的 BVT 位置在 block 的最后一个 sector 吧
你贴的是你的代码段，0x4000 是你程序的 vector table
左右不一样是因为左边的是你没设置 bin 文件的偏移地址吧