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

[参考译文] CC3230SF：检查 OTA 代码签名和根 CA 的证书到期日期

admin
Guru**** 2925550 points

Other Parts Discussed in Thread: CC3230SF, CC3235SF, SYSCONFIG

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

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1641743/cc3230sf-certificate-expiration-date-check-for-ota-code-signing-and-root-ca

器件型号： CC3230SF
Thread 中讨论的其他器件： CC3235SF、 SysConfig

尊敬的 TI 支持团队：

我们目前正在生产模式下使用 CC3230SF、并正在使用安全文件系统进行 OTA 更新。

在我们最近的测试中、我们注意到我们的定制供应商/代码签名证书（用于对 ota.cmd 清单进行签名并生成 te ota.sign 文件）已过期。 然而、令我们惊讶的是、CC3230SF 仍然能够成功验证签名并安装 OTA 更新、而不会引发任何安全警报。

我们发现了一些较旧的论坛帖子、这些帖子表明 NWP 可能会出于代码签名的目的忽略到期日期、以防止设备在现场闪烁。

您能否就 OTA 和安全文件系统操作期间的 NWP 行为阐明以下几点：

  1. 代码签名证书：CC3235SF 网络处理器在验证 ota.sign 文件时是否有意忽略代码签名证书的到期日期（“非“字段）？

  2. 目录中的根 CA：是否同一逻辑适用于存储在证书目录中的根 CA？ 如果根 CA 过期、设备是否仍接受来自它的签名？

  3. 未来行为：假设我们可以继续使用过期代码签名证书在现场更新我们的设备是否安全、或者是否有计划在将来的 Service Packs/ROM 更新中强制执行到期日期？

对此有一个明确的答案、将极大地帮助我们规划长期 OTA 迁移策略。

提前感谢您的支持！

此致

Thomas

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

    尊敬的 Thomas：

    对延迟深表歉意。 我在这方面没有很多经验、但您可以尝试几件事：

    要测试 CA 证书是否有效、可以使用我们拥有的虚拟根 CA、您可以将日期设置为 2026 年 9 月之后的某个日期、以查看连接是否被拒绝。

    若要测试 OTA 证书到期是否经过验证、您可以使用 OTA-example-cert 目录下的证书、并创建安全的 OTA 下载、查看证书是否失败。 您还需要设置 2027 年 8 月以后的日期。  

    根据我所做的研究、我希望 CA 证书能够得到验证、但可能不会得到 OTA 证书。

    如果您有任何其他问题、请告诉我。

    此致、

    Josh Prushing

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

    您好、Josh、

    感谢您回复我和我们的建议。

    在尝试虚拟 CA 方法之前、我实际上在我这边运行了一个非常实用的测试、以了解 CC3235SF 如何处理日期验证。

    我完全阻止了路由器中端口 123 (NTP) 上的传出流量、以防止设备同步其内部 RTC。 之后、我全新刷写了 CC3235SF 并触发了安全的 OTA 更新。

    结果：OTA 更新成功下载并完成、没有任何错误。

    由于设备绝对无法获取当前时间（并且可能在证书有效期之外的默认 epoch 日期启动）、因此我得出的结论是、notAfternotBefore在 OTA 过程中、设备不会严格验证证书的到期 () 或开始 () 日期、如果内部时钟未同步、它会完全跳过日期检查。

    如果未设置 RTC 时间、NWP 或 OTA 库是否有意绕过日期验证？

    再次感谢您的帮助！

    此致、

    Thomas

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

    尊敬的 Thomas：

    otauser.h 中有一个用于 OTA_SERVER_AUTH_IGNORE_DATA_TIME_ERROR 的#define、我相信这可能是 OTA 更新成功的原因。  稍后 在 OtaHttpClient.c 中引用该函数、其中、如果定义了该函数、则会忽略一个错误。

    不确定您的供应商代码是否定义了该代码、如果定义了、您能否将其注释掉并再次运行您的实验？  

    此致、

    Josh Prushing

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

    您好、Josh、

    感谢您的关注、感谢您的关注 OTA_SERVER_AUTH_IGNORE_DATA_TIME_ERROR！

    此标志处理与 OTA 服务器的 HTTPS 连接的日期/时间验证是绝对正确的。 我们实际上正在将该 OTA_IF 模块与自己的自定义 OTA 供应商集成结合使用、因此管理服务器身份验证无疑是难题的一部分。

    但是、我的主要问题实际上是关于 第二 层验证的：通过硬件/引导加载程序对 MCU 映像本身进行签名验证。

    下载存档后、它将被提取并根据我们通过 SysConfig 编程到 SFLASH 中的证书链（例如我们的 GeoTrust/DigiCert 证书）验证 MCU 映像的加密签名。 我的 NTP 阻塞测试表明、即使设备没有有效的 RTC 时间、此特定的硬件级签名验证仍然通过。

    您能否说明一下这一具体步骤？ 内部引导加载程序/NWP 签名验证（不是 HTTPS 服务器身份验证）是否有意忽略证书 notBefore 和 notAfter 到期日期？

    再次感谢您的持续支持！

    此致、

    Thomas

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

    尊敬的 Thomas：

    感谢您对所需内容的澄清！

    看起来签名验证中根本没有日期验证。 因此、您是正确的、内部引导加载程序不会 在签名验证中检查 notBefore/notAfter 到期日期。

    如果您有任何其他问题、请告诉我！

    此致、

    Josh Prushing