• 状态
  • 已锁定 已锁定
  • 回复 7 回复
  • 订户 0 订户
  • 视图 177 视图
  • 用户 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.

[参考译文] LP-MSPM0G3519：如何将密钥加载到密钥库中（CSC +.secret 与其他配置方法）

admin
Guru**** 2910880 points

Other Parts Discussed in Thread: MSPM0G3507, MSPM0G3519, UNIFLASH

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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1564964/lp-mspm0g3519-how-to-load-keys-into-keystore-csc-secret-vs-other-provisioning-methods

器件型号：LP-MSPM0G3519
Thread 中讨论的其他器件：MSPM0G3519、MSPM0G3507、 UNIFLASH

工具/软件：

在 MSPM0G3519 上、我想阐明将密钥加载到中的正确方法 密钥库 。
从 TRM 和 SDK 中、我的理解是：

  • 密钥通常在期间加载到密钥库中 客户安全代码 (CSC) 初始化阶段 使用。 DL_KEYSTORECTL_writeKey()

  • 在提供的 SDK 示例中、密钥包括 在源代码中硬编码 并.secret通过链接器脚本放入闪存部分中、然后写入 Keystore。 (aesadv_cmac_256_enc_dec.c)
    （这是我的理解，如果我错了，请更正）  

    我的问题是：

    1. 是将密钥硬编码到.secret闪存中、然后通过 CSC 将其写入 Keystore 仅支持该选项 或者是否有替代方案？  

    2. 对于生产、什么是 推荐的安全配置流程 确保每个器件都具有唯一的密钥、而不会在源代码中暴露明文密钥？

    3. 我的要求是我希望这样做 以加密格式将密钥存储在闪存中 、然后使用闪存读取 API 来读取它并将其加载到密钥库中。 该流程是否可行/受支持、或者密钥库是否只能在加载时接受明文密钥？


    附加说明 (MSPM0G3507)：
    在 MSPM0G3507 上、我仅看到 基本 AES 加速器 在这里 无密钥库控制器 。 在这种情况下、TI 建议的安全配置方法是什么、因为密钥只能通过软件加载到 AES 寄存器中？

  • 0
    TI__Guru**** 2910880 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    （这是我的理解，如果我错了，请更正） 

    没错。

    将硬编码密钥.secret写入闪存、然后通过 CSC 将其写入 Keystore 仅支持该选项 或者是否有替代方案？  [/报价]

    KETSTORE 是一种在器件复位后需要配置的外设、例如正常 UART/ADC。

    因此、唯一的方法是在引导阶段 (CSC) 复位后对其进行配置

    对于生产、什么是 推荐的安全配置流程 确保每个器件都具有唯一的密钥、而不会在源代码中暴露明文密钥？

    1. SWD 禁用或使用密码启用。

    2.默认情况下禁用 BSL 读取存储器功能,客户也可以直接禁用所有 BSL 功能。

    我的要求是我要的 以加密格式将密钥存储在闪存中 、然后使用闪存读取 API 来读取它并将其加载到密钥库中。 该流程是否可行/受支持、或者密钥库是否只能在加载时接受明文密钥？

    如果将密钥保存为加密格式、则需要在 ReadKey API 中对其解密、然后将明文密钥写入密钥库。

    在 MSPM0G3507 上、我看到了 基本 AES 加速器 在这里 无密钥库控制器 。 在这种情况下、TI 建议的安全配置方法是什么、因为密钥只能通过软件加载到 AES 寄存器中？

    在 G3507 中,我们无法保护应用代码读取的 AES 或其他安全信息。

    像这样: 4.4.3 读取 — 执行保护,您不能禁用应用程序代码来读取这个区域（读取 API 函数和密钥在这里）。

    此外,在 G3507 中没有像 G3519 那样的 InitDone 位。

    因此、大部分安全功能应由客户设计、因为 G3507 硬件的安全功能有限。

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

    Hello 、

    感谢您的详细答复。 我现在知道 CSC 在复位后运行、其工作是：

    • 从.secret闪存区域读取密钥材料

    • 调用DL_KEYSTORECTL_writeKey()可将这些密钥推入密钥库插槽

    我有几个跟进说明：

    1. Uniflash 配置：
      是否可以.secret使用带有单独十六进制/二进制文件（例如，最多包含四个密钥）的 Uniflash 直接对该区域进行编程？ 如果是、您是否有任何生成和刷写此类.secret文件的参考或示例流程？

    2. 加密密钥存储：
      您提到、如果密钥以加密格式保存、则必须在 ReadKey API 中对其解密、然后才能写入密钥库。 您能否确认 TI SDK 是否提供对 ReadKey API 内密钥解密的内置支持、或者我们是否需要在调用之前自行实施解密步骤DL_KEYSTORECTL_writeKey()？

    再次感谢您的指导。

    此致、
    Kasirajan

  • 0
    TI__Guru**** 2910880 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    [引述 userid=“596640" url="“ url="~“~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1564964/lp-mspm0g3519-how-to-load-keys-into-keystore-csc-secret-vs-other-provisioning-methods/6027034 Uniflash 配置：
    是否可以.secret使用带有单独十六进制/二进制文件（例如，最多包含四个密钥）的 Uniflash 直接对该区域进行编程？ 如果是、您是否有任何用于生成和刷写此类.secret文件的参考或示例流程？

    可能的情况下、启用 Uniflash 的擦除必要存储器区域。

    固件中的密钥可以通过标头地址及其长度进行访问。

    您可以将密钥直接以明文放入.secret 段的起始地址中。

    Key CAN 可通过 CSC 代码/固件编程到 M0 中。

    在调用之前、我们是否需要自己实施解密步骤DL_KEYSTORECTL_writeKey()？

    你需要解密它,因为你控制你的 crypton 算法。

    只需临时确保写入密钥库的密钥必须是纯文本、MSPM0 密钥库并不关心其他部分。

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

    你好、

    感谢您先前的澄清。 我想再确认一点 密钥的机密性和完整性 在配置 Uniflash 时。

    根据您的回答、我了解：

    • .secret可以通过使用明文密钥的 Uniflash 对该区域进行编程。

    • 在引导时、CSC 可以调用DL_KEYSTORECTL_writeKey()以将这些密钥移动到密钥库中。

    • 如果我们要在闪存中以加密形式存储密钥,我们（客户）必须在调用之前在 CSC 中实现解密DL_KEYSTORECTL_writeKey(),因为密钥库只接受明文。

    我最关心的是周围 机密性和完整性 ：

    1. 如果我们将密钥以明文形式存储在闪存中（即使在）.secret,那么禁用 SWD/JTAG 并启用闪存保护是否足以在生产中实现机密性?

    2. 我们将密钥存储在一个位置 加密表单 在闪存中解密并在 CSC 内解密：

      • 我们是否需要同时实现解密算法 和 自我完整性验证？ 请在此处提供一些建议  

      • 或者、在加载到 Keystore 之前、TI 是否提供任何内置支持来帮助确保密钥材料的机密性和完整性？

    我想确认 推荐的安全生产流程 ：

    • 明文密钥 IN.secret + JTAG 是否已禁用？

    • 或.secret CSC 中的加密密钥+客户管理的解密+验证？

    这将帮助我们确定安全和实施工作之间的适当平衡。

    谢谢、
    Kasirajan

  • 0
    TI__Guru**** 2910880 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    如果我们将密钥以明文形式存储在闪存中（即使在中）.secret、则会禁用 SWD/JTAG 并启用足够的闪存保护以在生产中实现机密性吗？

    禁用 SWD、默认情况下会禁用 BSL 读取功能。

    无法通过其他方式从外部引脚访问器件。

    我们是否需要同时实现解密算法 和 自我完整性验证？ 请在此处提供一些建议 

    是的、您需要。

    您可以尝试使用 M0 中的 AES 模块进行解密。 另外、我认为加密密钥的解密密钥也是保存在闪存中的明文。

    加密算法取决于您自己的要求。

    或者 TI 是否提供任何内置支持、以便在加载到 Keystore 之前帮助确保密钥材料的机密性和完整性？

    作为信任区域、整个 CSC 代码都应考虑周到。

    因为通过启用 NONMAIN 闪存权限配置并禁用 SWD、CSC 区域会受到保护。

    由于 M0 只能从地址 0x0 开始、CSC 控制该器件。

    因此 CSC 和您的负载密钥功能应该是可信且安全的。

    MSPM0 SDK 提供的 CSC 代码“按原样“、我们提供了一个示例代码来向您展示如何处理此类操作。

    .secret禁用+ JTAG 中的明文密钥？

    实际上、M0 使用 SWD 接口。

    是的、禁用 SWD 并将密钥置于机密部分。

    此外、您还可以选择禁用 BSL（用于固件程序的引导加载程序）。

    在 NONMAIN 中设置静态写保护。

    此外、在 CSC 中为 CSC 代码设置闪存读取/exe 权限。

    或.secret客户管理的解密+ CSC 中的加密密钥？

    这是一个更安全的地方。

    两种方法都可以、由于上述说明、由于访问限制、我们 可以假设 CSC 是安全的、因为任何非法访问都将被阻止。

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

    您好、Helic、

    我已经开始实施。 我遵循 aesadv_cmac_256_enc_dec为 TIClang 提供示例。
    不过、我正在使用 IAR ARM 9.60.3 与 .icf 链接器文件中。

    我尝试应用中提到的相同链接器配置 aesadv_cmac_256_enc_dec示例并移植到我的工程中。
    但在我的情况下,期间 复位处理程序 、 INITDONE 标志已设置。

    我想我可能遗漏了一些东西 — 我想澄清一下。




    我认为这种行为可能与有关 启动过程 。
    您能否确认是否在引导过程中处理此问题？
    如果是、我应如何调整 BCR 配置 中的示例 IAR ARM 9.60.3 编译器？




  • 0
    TI__Guru**** 2910880 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    但在我的情况下、在这期间 复位处理程序 、 INITDONE 已设置标记。

    在 CCS/ticlang 的正常启动序列中、在复位处理程序之后会设置 INITDONE、这是正常行为。

    设置安全功能后、INITDONE 将触发 SYSRST、此复位也会触发 CPU 跳回 resetHandler。

    我在这里没有看到任何问题。

    或者、如果要调试 CSC->INITDONE？->设置安全进程、需要在 BOOTRST 之后的第一个 resetHandler 处添加一个断点。

    BOOTRST 将清除 INITDONE 状态。