[参考译文] CC3235S：Gangimage 中已签名的 MCU 映像：证书文件名

您好 Johann、

我们想到了几个想法：

1.您能否尝试在 Uniflash 中对 LaunchPad 进行编程映像(创建和编程)？ 这将跳过 Gang 编程步骤。 我想将此问题隔离为 Uniflash 问题或文件位置问题。

2.证书文件应位于根文件夹中。  

3.证书链应有效。 证书是自签名的，每个证书都必须引用根证书之前的级别。 下面是一个直观描述：

 

如果您尚未找到这些 内容、SimpleLink 证书处理指南 和 UniFlash ImageCreator 指南 可能会有所帮助。

谢谢、
Jacob

您好、Jacob、

感谢你的答复。  
回复3)是的、我已经这么做了。 我们的验证路径如下所示："我的签名证书"(实际名称不同)->"DigiCert 可信根 G4"(中间证书)->根目录。
我已将这两个证书添加到 Gang 映像(其 Common Name 属性作为文件名)、并选择了我们的证书用于 mcuimg。

在您的图片中、供应商证书标记为"Cert-XXX.der"-这与参考文档关于 组映像布局的描述不匹配-文件名是不带扩展名的证书的通用名称、正确吗？

在进行进一步整理后、我在  GANG 编程期间将 SL_ERROR_FS_FILE_NOT EXISTS 升级为 SL_ERROR_FS_CERT_CHAIN_ERROR_SECURITY_ALERT (-10292)。

根据其他线程(例如 https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/639835/cc3220-fs_security_alert_cert_chain_error-when-loading-image)、这与不受信任的链有关。
如何验证 我添加到 Gang 映像的链是否确实受根目录的信任？  SimpleLink CC32xx 根证书目录页面仅列出根证书的名称。

我在文档中发现了另一小部分信息：

使用更新的服务包后、固件支持其他证书链验证类型：
–RSA 1024至4096
–SHA 1-512

此类证书可在 OTA 更新中使用、但不能在量产线上使用。

我们的证书确实是 RSA-4096、对于最新的 ServicePack、哪一项应该是正常的、对吧？ 但是：

此类证书可在 OTA 更新中使用、但不能在量产线上使用。

这是否意味着、一个成组图像只能包含使用高达2048位的证书创建的签名？

您好 Johann、

如何验证 我添加到 Gang 映像的链是否确实受根目录的信任？  

如果您使用的是 Windows、则可以将证书重命名为.cer、以便 Windows 将该文件识别为证书。 然后、您可以看到证书的颁发位置。 我在上面的图中向您展示了这一点；根证书是向 自己颁发的。 所有其他证书都必须有返回根证书的路径。  

这是否意味着、一个成组图像只能包含使用高达2048位的证书创建的签名？

你是对的。 首先、Gang 映像仅支持256或128字节的签名(取决于算法)。

从 证书处理指南：

之后、在 OTA 闪烁的情况下、签名可能会大得多(RSA 为4096)：

这是由于 ROM 的限制。

此致、

Jacob

[引用 userid="456020" URL"~/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1024455/cc3235s-signed-mcu-image-in-gangimage-certificate-file-name/3789380 #3789380"]如果您使用的是 Windows，则可以将证书重命名为.cer，以便 Windows 将该文件识别为证书。 然后、您可以看到证书的颁发位置。 我在上面的图中向您展示了这一点；根证书是向 自己颁发的。 所有其他证书都必须有返回根证书的路径。  [/报价]

这仅告诉我 Windows 系统是否可以验证链到 Windows 信任存储中的根。 它不告诉我 是否所有中间证书都正确存储 在 Gangimage 中、中间证书最终存储在 TI 受信任根目录中。


回复：2048位限制：我将尝试获取 另一个具有2048位的签名证书。

您好 Johann、

[引用 userid="488356" URL"~/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1024455/cc3235s-signed-mcu-image-in-gangimage-certificate-file-name/3789662 #3789662">这仅告诉我 Windows 系统是否可以验证 Windows 信任存储中的根链。 它不会告诉我 是否所有中间证书都正确存储 在 Gangimage 中、中间证书最终会存储在 TI 可信根目录中。

为了确保我们排除了常见问题、首先请确保您的证书都位于根文件夹中。 接下来，确保根证书已向自己颁发了证书。 然后，其他中间证书应具有根证书的参考路径。 例如：

	根	大约	供应商
颁发给：	C	B	A
签发人：	C	C	B

这是您的证书链的样子吗？

谢谢、
Jacob

您好、Jacob、

这是我们的证书链：

根目录：
发行人：C =美国、O = DigiCert Inc、OU = www.digicert.com、CN = DigiCert 受信任根 G4
主题：C =美国、O = DigiCert Inc、OU = www.digicert.com、CN = DigiCert 受信任根 G4

中级：
发行人：C =美国、O = DigiCert Inc、OU = www.digicert.com、CN = DigiCert 受信任根 G4
主题：C =美国、O ="DigiCert、Inc."、CN = DigiCert 受信任的 G4代码签署 RSA4096 SHA384 2021 CA1


供应商：
发行人：C =美国、O ="DigiCert、Inc."、CN = DigiCert 受信任的 G4代码签署 RSA4096 SHA384 2021 CA1
主题： ...


这三个文件通过 openssl 正确验证：

$ openssl verify -verbose -ca. file <(cat DigiCertCA.CRT TrustedRoot.crt) sign-cert.crt
Sign-cert.crt：好的


我已将所有三个文件(作为 DER)添加到 Gang 映像中、即  DigiCert 可信根 G4、 DigiCert 可信 G4代码签名 RSA4096 SHA384 2021 CA1和签名证书

现在、我要尝试编写一个新的安全文件。 我已验证签名是否正确：

$ openssl dgst -验证 signing.pubkey.pem -signature ../mcuimg.bin.sig ./mcuimg.bin
已验证是否正常

使用时  

sl_FsClose (fd、"签名证书"、签名、signature_len)； 

我始终得到错误 -10290：sl_error_fs_wrong_signature_or_Certificic_name_length。

是否有任何方法可以手动确认该链是否正确地最终到达 TI 根目录中？ 证书目录的自述文件列出了"DigiCert 受信任根 G4"、但这并不意味着它指的是完全相同的证书。

您好 Johann、

您的证书链对我来说是正确的。 我将检查并查看我是否可以重现此问题、或者其他工程师有什么想法。  

我将在星期三之前对此主题做出回应。

谢谢、

Jacob

我们支持 DigiCert 可信根 G4 (以及文件中提到的任何其他根 CA)、但问题与"DigiCert 可信 G4代码签名 RSA4096 SHA384 2021 CA1"有关。

 我们在引导加载程序 ROM 代码中不支持 SHA384和 RSA4096 (如前所述、仅在 OTA 之后才能支持这些方法)-因此 Gang 编程将失败。

 DigiCert 目前似乎存在问题、因为他们在新的中间和根 CA 认证集中仅使用 SHA384。

目前、我们只能建议 从另一个 CA 获取证书。

BR、

Kobi  

您好、Kobi、

Jacob 已在主题中进一步解释了此问题。

此错误也会在 OTA 期间发生、 根据用户指南、其中应支持使用大于2048bit 的密钥创建的最新服务包和根目录签名。

您好 Johann、

请允许我再为您介绍一下。 我将在明天为您提供更多信息。

谢谢、
Jacob

您好 Johann、

根据您在 OTA 过程中提到的错误、我认为网络处理器日志将有所帮助。 您能否按照 本指南 (第20节)向我们提供日志？

谢谢、

Jacob