• 状态 Resolved
  • 已锁定 已锁定
  • 回复 3 回复
  • 订户 1 订户
  • 视图 145 视图
  • 用户 0 会员在此处
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] TMS320F280041：针对代码安全的建议、鉴于客户需要能够更新固件...

admin
Guru**** 2537260 points


请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1031390/tms320f280041-advice-for-code-security-given-the-need-for-customers-being-able-to-update-firmware

器件型号：TMS320F280041

所以... 我们的器件最终位于仅最终用户可访问的位置。  我们需要提供在现场执行固件更新的能力、而不会影响代码安全性。

用户接收到固件的 Intel hex 文件、该文件已使用修改后的 RNG 中的固定假随机序列与所有数据区域进行异或重写。  我们在器件中有一个引导加载程序、在接收到传入的固件映像时对其进行解扰。   不可能有很多更新... 因此、如果有人想要计算 RNG 序列、则不会有太多的样本需要使用。

我们接下来将配置 DCSM 区域1、以保护所有 RAM、闪存和 JTAG 访问。

我们是否遗漏了任何东西？   这显然不是很好的安全性、但我们只是想使它变得足够困难、使我们的客户不可能尝试复制我们的产品。

  • 0
    TI__Guru**** 2537260 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好！

    [引用 userid="51282" URL"~/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1031390/tms320f280041-advice-for-code-security-given-the-need-for-customers-being-able-to-update-firmware ]]我们接下来将配置 DCSM 区域1以保护所有 RAM、闪存和 JTAG 访问。

    您拥有的内容应该很好。 以下是对此需要注意的几点 -

    1. 执行固件更新的引导加载程序代码应位于 Z1的安全闪存中、仅当需要复制到 Z1的安全 RAM 中并执行以执行任何闪存操作时。
    2. 用户 OTP (安全设置)只能在解锁区域后更新、因此我假设这些设置不会作为固件升级的一部分进行更改。

    此致、

    Vivek Singh

  • 0
    TI__Guru**** 2537260 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    1)那么、我想知道这一点。

    闪存 API 文档根本没有提到如何链接 API 中的库或特定函数以复制到 RAM、这一点我感到奇怪。  我现在不得不查看闪存 API 示例项目文件、以便在 device_support/.../common/cmd/...中找到 CMD 文件(在我查看示例的源代码之前)

    当然、由于它已经在 ROM 中... 似乎错失了一个机会、无法使 ROM 版本从安全内存中正常工作。  也许我可以从基于 ROM 的链接中检查映射文件、并确定一些不涉及安全存储器的函数的位置、并在 CMD 文件中将其标记为链接到 DSECT ROM 区域？  然后、我可以避免将这些特定的函数复制到闪存或 RAM 中。  我只需确保 API 的.bss 区域位于不安全的存储器中(可能是 M0？)。

    我曾问过另一个有关 CMD 页面定义的问题、我试图解决这个问题。  (编辑：如果页面问题可以解决、我不需要执行奇怪的技巧来保存 RAM)

    2)嗯、是的。。。。 除了可能的引导加载程序函数、首先创建安全区域...  我们不确定目前如何对生产中的器件进行编程。  我们可能不需要它。。。 如果我们采用 SCI 引导方式、我们可以将其作为引导流的一部分。  我的意思是、目前每个可能在 DCSM 区域1下安全的存储器区域都是这样受保护的。  我唯一能想到的改变就是将某些区域设置为 EXEONLY。。。 虽然我想用它，但我目前还不够勇敢。  我们可以将此类更改仅保留给制造流程、而不是在现场更新中执行的操作。

  • 0
    TI__Guru**** 2537260 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    [引用 userid="51282" URL"~/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1031390/tms320f280041-advice-for-code-security-given-the-need-for-customers-being-able-to-update-firmware/3814524 #3814524"]嗯、是的... 除了可能的引导加载程序函数以首先创建安全区域外

    默认情况下、器件将解锁、因此您应该能够创建安全区域列表时间而不会出现任何问题。

    [引用 userid="51282" URL"~/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1031390/tms320f280041-advice-for-code-security-given-the-need-for-customers-being-able-to-update-firmware/3814524 #3814524"]我们可以将此类更改仅保留给制造工艺、而不是在现场更新中执行的操作。

    是的、这会很好。

    此致、

    Vivek Singh