[参考译文] TDA4VM：J721E：GP 板上用于 SBL 和系统固件的自适应安全启动

您好 Sarath、

1、在这种情况下、是否可以跳过 SBL 和系统固件引导映像中的 X509 证书生成？  如果没有、对 X509 证书的需求是什么？在引导 SBL 和系统固件时如何处理证书？

 即使对于 GP 器件、也需要 X509 证书。 ROM 代码使用 X509 验证二进制的哈希值
证书结构、即使不执行身份验证也是如此。

 X509 证书有以下重要用途：

-哈希验证:如果 GP 设备上使用 RSA 解生成密钥进行签名, ROM 将验证二进制的哈希
-引导元数据:证书包含关键引导信息（组件大小，加载地址，引导内核信息）

[引述 userid=“699087“ url=“~/support/processors-group/processors/f/processors-forum/1659260/tda4vm-j721e-aadapt-secure-boot-on-the-gp-board-for-sbl-and-system-firmware

2、请分享 X509 证书的格式与需要编码的必需参数吗？

[/报价]

有关引导加载程序映像所需的强制扩展/参数、请转至 TRM 的“引导映像格式“部分。

3、如果没有提供身份验证、是否必须 在证书中放入密钥？
[/报价]

对于 GP 器件、您应该使用 RSA 取消生成密钥（虚拟密钥）。

此致
Diwakar

尊敬的 Diwakar：

感谢您的回答

我假设您的说明同时适用于 SBL 和系统固件。

请您查看以下有关 GP 器件的后续问题。

1. 请  在 PDK 中共享 RSA 取消生成密钥（虚拟密钥）的路径。
2. 哈希验证是必需的还是有跳过它的选项? （我们有其他特定于项目的选项来评估完整性）
3. 如何将 RSA 取消生成密钥（虚拟密钥）用于 GP 器件中的 SBL 和系统固件？

此致、

Sarath

您好 Sarath、

[引述 userid=“699087“ url=“~/support/processors-group/processors/f/processors-forum/1659260/tda4vm-j721e-aadapt-secure-boot-on-the-gp-board-for-sbl-and-system-firmware/6399790

• 请  在 PDK 中共享 RSA 取消生成密钥（虚拟密钥）的路径。

[/报价]

密钥可在 //packages/ti/build/makerules.中找到

散列验证是强制性的还是有跳过它的选项？ （我们有其他特定于项目的选项来评估完整性）

不,我们不能跳过这一步。另外,我们如何检查完整性,并在加载前在引导加载程序阶段验证映像?

] RSA 取消生成密钥（虚拟密钥）如何用于 GP 器件中的 SBL 和系统固件？

此密钥用于对 GP 器件上的引导加载程序 (SBL/SPL) 和 TIFS 证书进行签名。

此致
Diwakar

尊敬的 Diwakar：

感谢您的更新。

是否 可以 在 SBL 和系统固件中使用客户特定的密钥而不是 RSA 取消生成的密钥（虚拟密钥）？

我们使用内部开发的系统固件 、而不是 TI 提供的系统固件。

此致、
Sarath

您好 Sarath、

如果我们使用客户密钥而不是 ROM 取消生成密钥、那么 ROM 将只对映像进行完整性检查、而不是先进行证书验证、然后进行映像完整性检查。

此致
Diwakar

尊敬的 Diwakar：

这是否意味着  对于 SBL 和系统固件、将跳过下图中标记的步骤 1a、1b、2a、2b 和 2c、并且仅执行步骤 3a 和 3b？

此外、电子保险丝值是否需要更改以使用客户密钥、或者我们是否可以保留 TI 提供的默认电子保险丝值？

此致、
Sarath

尊敬的 Diwakar：

在查看您最近的评论以及上一个说明（复制如下）时、我对客户密钥的使用感到困惑。

换言之、对于使用任一密钥（RSA 去生成（伪）密钥除外）签名的二进制、会跳过哈希验证。

请大家也看一下。

此致、

Sarath

尊敬的 Diwakar：

今天我就这个主题进行了一些测试、并想分享观察到的行为。

测试 1：
SBL 更改：

1. 生成的 x509 证书、不包括映像完整性扩展（第 4.5.4.2 节、OID 1.3.6.1.4.1.294.1.2、如 TRM 中所述）。
2. 使用客户特定的 RSA 密钥（1024 位）签署证书。

系统固件更改：

1. 已生成 包含引导信息 (OID 1.3.6.1.4.1.294.1.1) 和映像完整性 (OID 1.3.6.1.4.1.294.1.2) 扩展的证书。
2. 使用 RSA 取消生成（虚拟）密钥对证书签名。

观察到的结果：
系统引导成功并将应用程序映像加载到其他内核上。

测试 2：
SBL 更改：
     与测试 1 中相同
系统固件更改：

1. 生成不带映像完整性扩展的 x509 证书（第 4.5.4.2 节、OID 1.3.6.1.4.1.294.1.2）。
2. 使用客户特定的 RSA 密钥（1024 位）签署证书。

观察到的结果：
系统未正确引导。 当 SBL 按预期加载并尝试加载系统固件时、SBL 报告等待系统固件确认的超时、指示系统固件验证期间出现故障。

摘要：
使用客户密钥进行的二进制哈希验证和证书签名适用于 SBL。但是、相同的方法不适用于系统固件。 在这种情况下、二进制的哈希验证和使用 RSA degenerate (dummy) 密钥进行签名似乎都是强制性的。

请您分享您对观察结果的想法。

此致、
Sarath

您好 Sarath、

我记得您使用的是 HS-Prime 器件、为什么我们在这里讨论了 GP 器件？ 流程会根据器件类型而变化。

其中我们讨论了器件类型为黄金的参考线程。

e2e.ti.com/.../tda4vm-firewall-descriptions

此致
Diwakar

尊敬的 Diwakar：

如前所述、该工程使用内部开发的系统固件、器件类型为 GP。

可以通过检查 DMSC0_SEC_Mgr_0_SYS_STATUS 寄存器来验证它。

此致、
Sarath

您好 Sarath、

好的、那么之前关于“做素“的陈述是不正确的。 让我在最后做类似的实验、并根据结果联系我们的内部 ROM 团队。

此致
Diwakar

尊敬的 Diwakar：

很好。
很抱歉混淆。  SPRUIM0C 文档中有关 DMSC 固件的第 9.3 章 PRIME 中提到的信息有一些错误地提示、只有 HS-Prime 允许第三方自定义固件。

您还可以查看我的 prevoius 问题。

这是否意味着   对于 SBL 和系统固件、将跳过下图中标记的步骤 1a、1b、2a、2b 和 2c、并且仅执行步骤 3a 和 3b？

此致、
Sarath

您好 Sarath、

快速实验结果：我在从 SBL 和 TIFS 中删除除 1.3.6.1.4.1.294.1.1 之外的所有扩展后进行了测试、并使用自定义密钥对两个映像签名。可能看到器件正在引导。

使用非 ROM 签名的 SBL 证书会取消生成密钥：

[ req ]
distinguished_name = req_distinguished_name
x509_extensions = v3_ca
prompt = no
dirstring_type = nobmp

[ req_distinguished_name ]
C = US
ST = SC
L = Dallas
O = "Texas Instruments.
OU = PBU
CN = Albert
emailAddress = Albert@ti.com

[ v3_ca ]
basicConstraints = CA:true
1.3.6.1.4.1.294.1.1 = ASN1:SEQUENCE:boot_seq

[ boot_seq ]
certType = INTEGER:1
bootCore = INTEGER:16
bootCoreOpts = INTEGER:2
destAddr = FORMAT:HEX,OCT:41C00100
imageSize = INTEGER:307176

使用 ROM 取消生成密钥签名的 TIFS 证书。

[ req ]
distinguished_name = req_distinguished_name
x509_extensions = v3_ca
prompt = no
dirstring_type = nobmp

[ req_distinguished_name ]
C = US
ST = SC
L = Dallas
O = "Texas Instruments.
OU = PBU
CN = Albert
emailAddress = Albert@ti.com

[ v3_ca ]
basicConstraints = CA:true
1.3.6.1.4.1.294.1.1 = ASN1:SEQUENCE:boot_seq

[ boot_seq ]
certType = INTEGER:2
bootCore = INTEGER:0
bootCoreOpts = INTEGER:0
destAddr = FORMAT:HEX,OCT:00040000
imageSize = INTEGER:262112

引导日志：

你是否在你的末端看到了同样的行为 这是 TDA4 类的第一个器件、因此我需要检查 ROM 在该时间点的行为情况。

此致
Diwakar

尊敬的 Diwakar：

当我通过从 SBL 和系统固件证书中删除除 1.3.6.1.4.1.294.1.1 之外的所有证书扩展进行测试、并使用自定义字节密钥对两者进行签名时、系统无法引导。 加载系统固件后、SBL 报告超时并等待确认。

使用同一 SBL、我为系统固件启用了证书扩展 1.3.6.1.4.1.294.1.1 和 1.3.6.1.4.1.294.1.2、并使用 ROM 退化密钥对其进行了签名。 完成此配置后、器件已成功引导。

此致、
Sarath

您好 Sarath、

您到底有 EVM 吗？ 我可以与您分享二进制文件、您也可以在结束时进行测试。

我使用 TI 虚拟密钥对 TIFS 和 SBL 二进制文件进行签名、而不是 在证书中使用 1.3.6.1.4.1.294.1.1 扩展的 ROM 取消生成密钥

此致
Diwakar

尊敬的 Diwakar：

感谢您的更新。

您能否分享 所使用的 TI 虚拟密钥的大小？
它是 1024 位的 RSA 密钥吗?

请分享你的证书和虚拟密钥,以便我可以尝试他们与我的二进制.

关于 EVM 可用性、我将在内部进行检查、然后返回。

此致、
Sarath

尊敬的 Diwakar：

感谢您的更新。

今天的进一步调试揭示了使用自定义密钥签名系统固件并仅包含 1.3.6.1.4.1.294.1.1 证书扩展时发生的问题。
导致该问题的原因是安全 ROM 向 SBL 发送系统固件上传请求确认所花费的时间超过预期值。

通过增加 SBL 中进行此确认的等待时间、可以解决该问题。
当使用自定义密钥对系统固件进行签名时、ROM 代码似乎需要更多的时间来发送确认。

随着 SBL 中等待确认的时间增加、系统现在可以正常启动、
使用自定义密钥对 SBL 和系统固件进行签名并使用仅包含 1.3.6.1.4.1.294.1.1 扩展的证书时。

您能否与您的内部 ROM 团队核实此行为并分享反馈？

下面、我总结一下结论、以避免任何误解。
请告诉我是否需要进行任何更正。
摘要：

即使在 GP 器件上、ROM 代码也需要针对 SBL 和系统固件使用 TI 定义的映像格式。 此格式始终需要在引导加载程序和系统固件二进制文件之前有 x509 证书。

x509 证书有以下重要用途：

• 哈希验证： 在 GP 设备上、如果使用 RSA degenerate 密钥进行签名、ROM 将验证二进制的哈希值。
• 启动元数据： 证书包含基本的启动信息、例如二进制大小、加载地址和启动内核详细信息。

如果使用自定义密钥（而不是 TI 提供的 ROM 生成信号密钥）对映像签名、则 ROM 代码会跳过完整性检查。 在 GP 器件上、没有电子保险丝或任何机制来针对任何类型的密钥进行身份验证、因此无需更改默认 eFuse 值。

此致、
Sarath

您好 Sarath、

很高兴听到这个问题得到解决。

[引述 userid=“699087“ url=“~/support/processors-group/processors/f/processors-forum/1659260/tda4vm-j721e-aadapt-secure-boot-on-the-gp-board-for-sbl-and-system-firmware/6405756

您能否与您的内部 ROM 团队核实此行为并分享反馈？

[/报价]

我们有这方面的计时号吗？ 我将与 ROM 团队分享。

如果需要更正、请告知我。
[/报价]

您的理解是正确的。

此致
Diwakar

尊敬的 Diwakar：

请在下面找到时序详细信息

我们有这方面的计时号吗？ 我将与 ROM 团队分享。

当使用 TI RSA 取消生成（虚拟）密钥对系统固件进行签名、并使用包含扩展名 1.3.6.1.4.1.294.1.1 和 1.3.6.1.4.1.294.1.2 的证书时、SBL 在发送系统固件上传请求后的 5ms 内收到确认。

当使用自定义密钥对系统固件进行签名并使用仅包含 1.3.6.1.4.1.294.1.1 扩展的证书时、会在 20ms 内收到确认。

此致、

Sarath

您好 Sarath、

感谢分享的信息,让我有时间检查这. 我们还在最后进行时间测量

此致
Diwakar