i.MXRT1061 Security Boot

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

i.MXRT1061 Security Boot

跳至解决方案
2,631 次查看
lizboxy
Contributor I

Hi,Sir:

咨询下RT1061芯片加密启动的问题,请给点建议,谢谢!

1.在对安全性中等级别的场合可以仅使用HAB签名方式验证image合法性,此处是芯片硬件处理并且efuse只能烧写一次,那么秘钥(私钥)就是静态并且不可更改的?

2.我们现在使用的是XIP方式在片外Flash上执行代码,外置Nor Flash大小为4MBimage包含bootloader引导 + App业务代码,分别存储在Flash的不同起始地址(通过remap跳转),那么如果要使用芯片的BEEOTFAD)进行最高等级的image加密,芯片是把所有的image解密完后一起copyRAM中才能执行吗,我疑惑的点是RAM空间会小于image固件大小?

3.HAB签名机制和BEEOTFAD)可以一起开启吗?

4.动态的加解密是否会影响芯片的执行效率,BEEOTFAD)降低的效率有多大?

5.OTFAD支持多区域不同Key的加密方式,那么bootloader使用KEY1App使用KEY2bootloader remap跳转到App还可以使用OTFAD进行bootloaderApp的解密吗?

6. 针对包含多段image的产品,我们想对两个产品都进行签名+解密,1061芯片硬件是否支持此方案?

0 项奖励
回复
1 解答
2,621 次查看
jeremyzhou
NXP Employee
NXP Employee

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.
-------------------------------------------------------------------------------

在原帖中查看解决方案

0 项奖励
回复
2 回复数
2,622 次查看
jeremyzhou
NXP Employee
NXP Employee

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.
-------------------------------------------------------------------------------

0 项奖励
回复
2,600 次查看
lizboxy
Contributor I

之前的问题确认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在线升级的例程,供参考?

  1. 硬件加密efuse只能烧写1次(熔断式)?有没有相关Guaid文档说明烧写方式?
  2. 关于MIMX.RT1051芯片内部512KB RAMITCM / DTCM / OCRAM)分配问题,由于我们会用到以太网功能此处DTCM是否是必须的,以及三种内存的合理分配,能否把ITCM/DTCM设置为0?
  3. 有用到两片Flash,其中QSPI Flash2MB)存储image代码供芯片Boot进行XIP,另外一块普通SPI Flash8MB)用于存储配置信息,升级固件包,日志信息(频繁更新,读写),贵司的其他客户在处理此类场景时是否有其他方案?能否就用一个大容量QSPI Flash?十分感谢!
0 项奖励
回复