Hi,Sir:
咨询下RT1061芯片加密启动的问题,请给点建议,谢谢!
1.在对安全性中等级别的场合可以仅使用HAB签名方式验证image合法性,此处是芯片硬件处理并且efuse只能烧写一次,那么秘钥(私钥)就是静态并且不可更改的?
2.我们现在使用的是XIP方式在片外Flash上执行代码,外置Nor Flash大小为4MB,image包含bootloader引导 + App业务代码,分别存储在Flash的不同起始地址(通过remap跳转),那么如果要使用芯片的BEE(OTFAD)进行最高等级的image加密,芯片是把所有的image解密完后一起copy到RAM中才能执行吗,我疑惑的点是RAM空间会小于image固件大小?
3.HAB签名机制和BEE(OTFAD)可以一起开启吗?
4.动态的加解密是否会影响芯片的执行效率,BEE(OTFAD)降低的效率有多大?
5.OTFAD支持多区域不同Key的加密方式,那么bootloader使用KEY1,App使用KEY2,bootloader remap跳转到App还可以使用OTFAD进行bootloader和App的解密吗?
6. 针对包含多段image的产品,我们想对两个产品都进行签名+解密,1061芯片硬件是否支持此方案?
已解决! 转到解答。
Hi,
非常感谢使用NXP产品,很高兴为你提供技术支持!
1.在对安全性中等级别的场合可以仅使用HAB签名方式验证image合法性,此处是芯片硬件处理并且efuse只能烧写一次,那么秘钥(私钥)就是静态并且不可更改的?
-- 是的。
2) 我们现在使用的是XIP方式在片外Flash上执行代码,外置Nor Flash大小为4MB,image包含bootloader引导 + App业务代码,分别存储在Flash的不同起始地址(通过remap跳转),那么如果要使用芯片的BEE(OTFAD)进行最高等级的image加密,芯片是把所有的image解密完后一起copy到RAM中才能执行吗,我疑惑的点是RAM空间会小于image固件大小?
-- 首先,i.MX RT1061支持BEE加密启动,其次,BEE不是将代码拷贝到RAM中执行,而是直接在外部Flash中运行,实时解密的。
3)HAB签名机制和BEE(OTFAD)可以一起开启吗?
-- 不能。
4)动态的加解密是否会影响芯片的执行效率,BEE(OTFAD)降低的效率有多大?
-- 测试结果下降几乎可以忽略,性能相非加密启动模式下降2.5%左右。
5) 针对包含多段image的产品,我们想对两个产品都进行签名+解密,1061芯片硬件是否支持此方案?
-- i.MX RT1061可以最多支持实现两段地址区间内的分别加密,实现时建议将两段bin 文件合并后统一烧录。
Have a great day,
TIC
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
Hi,
非常感谢使用NXP产品,很高兴为你提供技术支持!
1.在对安全性中等级别的场合可以仅使用HAB签名方式验证image合法性,此处是芯片硬件处理并且efuse只能烧写一次,那么秘钥(私钥)就是静态并且不可更改的?
-- 是的。
2) 我们现在使用的是XIP方式在片外Flash上执行代码,外置Nor Flash大小为4MB,image包含bootloader引导 + App业务代码,分别存储在Flash的不同起始地址(通过remap跳转),那么如果要使用芯片的BEE(OTFAD)进行最高等级的image加密,芯片是把所有的image解密完后一起copy到RAM中才能执行吗,我疑惑的点是RAM空间会小于image固件大小?
-- 首先,i.MX RT1061支持BEE加密启动,其次,BEE不是将代码拷贝到RAM中执行,而是直接在外部Flash中运行,实时解密的。
3)HAB签名机制和BEE(OTFAD)可以一起开启吗?
-- 不能。
4)动态的加解密是否会影响芯片的执行效率,BEE(OTFAD)降低的效率有多大?
-- 测试结果下降几乎可以忽略,性能相非加密启动模式下降2.5%左右。
5) 针对包含多段image的产品,我们想对两个产品都进行签名+解密,1061芯片硬件是否支持此方案?
-- i.MX RT1061可以最多支持实现两段地址区间内的分别加密,实现时建议将两段bin 文件合并后统一烧录。
Have a great day,
TIC
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
之前的问题确认Ok,由于是第一次用,现有新的问题,还请再看看给点指导,谢谢!
目前,有两款RT1061/RT1051,均会在设备端添加硬件加密启动机制(secutiry boot)即使用到MIMX.RT系列芯片efuse,此处我们希望了解并得到更多信息包括但不限于:
1.1 批量生产时,MIMX.RT芯片内部efuse熔丝如何烧录,必须在线烧写还是可以批量脱机处理?
1.2 MIMX.RT芯片有不同的启动模式,针对任何一种启动模式只要烧录了efuse那么将自动启用security boot机制还是需要另外配置IO;
1.3 针对多段image的情况(bootloader + app),是否可以将bootloader用户级代码合并到(ROM boot)中,或者芯片内部的ROM是否可以供我们修改(替换,由我们自主开发)以适配功能层面的需求;即ROM的开放程度,能否提供的源代码?或者函数接口及相应的Application Note来支持自行修改?
1.4 是否有OTA在线升级的例程,供参考?