[参考译文] PROCESSOR-SDK-AM62X：PROCESSOR-SDK-AM62X：用于签署 fitImage 的密钥的参考：Part2

您好：

keys 目录已从 SDK v10中的"board/ti/keys"更改为"arch/arm/mach-k3/keys"。

Unknown 说：

当 KEYREV=2时、是否使用备份密钥来验证 fitImage？

是的、如果您使用备份密钥签署了 fitImage、则将使用备份密钥对其进行验证。

此致、

Prashant

您好 、Prashant、

我将 board/ti/keys 中的 cutMpk.pem 和 custMpk.key 修改为 cutBMpk.*。

我构建了 tiboot3.bin、tispl.bin 和 u-boot.img、并使用它们的引导 AM625。

我当时没有更改 fitImage、所以它由 custMpk 签名。

我预计启动 fitImage 失败、但成功了。

当 KEYREV 都为1和2时、为什么可以引导 fitImage 签名的 custMpk？

当 KEYREV 为2时、由 custMpk 签名的引导映像无法启动、因此我确信可以修改签名密钥并正确更新 KEYREV。

 

最棒的餐厅

Koji

您好：

Unknown 说：

I 预计无法启动 fitImage、但成功了。

这是预期结果。 fitImage 的信任根来自 A53 U-Boot 中的签名节点。

为了确保只启动 BMPK 签名的 fitImage、您必须使用 BMPK 对 fitImage 签名、重建 U-Boot、然后替换电路板上的 U-Boot 映像。 然后、使用除 BMPK 之外的任何密钥签名的 fitImage 将无法启动。

此致、

Prashant

您好 、Prashant、

我省略了以下配置：

• tiboot3.bin (由 custBMpk 签名)
• tispl.bin (由 custBMpk 签名)
• u-boot.img (由 custBMpk 签名)
• fitImage (签名 CustMpk )

它成功引导。

这是预料之中的吗？

 

此致、

Koji

Unknown 说：

这是否符合预期？

这是因为 A53 U-Boot DTB 的签名节点仍包含 SMPK 公钥、因此 SMPK 签名的 fitImage 可成功引导。

如果您通过 BMPK 签名 fitImage 并重新编译 A53 U-Boot、则签名节点将包含 BMPK 公钥。 在这种情况下、之前成功引导的 fitImage 将无法引导。

Unknown 说：

由于 A53 U-Boot DTB 的签名节点仍然包含 SMPK 公钥、因此 SMPK 签名的 fitImage 成功启动。

那么、fitImage 是否使用 DTB 中的 SMPK 哈希来检查完整性、而不是电子保险丝中的 BMPK 哈希？

 

此致、

Koji

Unknown 说：

那么、fitImage 是否使用 DTB 中的 SMPK 哈希值进行了检查？而不是 eFUSE 中的 BMPK 哈希值？

正确。 如果在用 BMPK 签名 fitImage 后重新编译 U-Boot、则哈希值会更新为 DTB 中的 BMPK。 然后,只有 BMPK 签名的 fitImage 成功启动!

谢谢 Prashant。

我明白了。

[引述 userid="531297" url="~/support/processors-group/processors/f/processors-forum/1514931/processor-sdk-am62x-processor-sdk-am62x-reference-for-the-key-used-to-sign-fitimage-part2/5825962 #5825962"]

广桥浩司说：

那么、fitImage 是否使用 DTB 中的 SMPK 哈希来检查完整性、而不是电子保险丝中的 BMPK 哈希？

正确。

[/报价]

这与任何 SDK 版本是否相同？

 

此致、

Koji