[参考译文] AM6442：扩展 Yocto tiboot3.bin 构建以支持 HSM

尊敬的 David：

我不确定我是否能够遵循您的要求。

请澄清：

1) 1)您是否请求为 HS-SE 器件构建 tiboot3.bin 并使用自定义密钥对器件进行编程？

2) 2)您是否在 Yocto 外部本地构建了 u-boot 并验证了 tiboot3.bin？

谢谢

Yogesh

澄清：

1) 1)不、我们知道如何使用自定义密钥文件为 HS-SE 器件构建 tiboot3.bin。

2) 2)不、我们尚未尝试在 Yocto 外部构建 u-boot (真的不想这样做)

所以、为了重新说明这个问题、我们认为使用自定义密钥文件构建安全二进制文件的 Yocto 流程是这样的。 但在使用 HSM 时、密钥会远程存储(在 HSM 内)、并且需要通过令牌进行访问。 为了实现这一点、'openssl'必须使用'engine'或'provider'进行扩展、然后将额外的参数传递给'openssl'以指示应该使用哪个 HSM 和 KEY 进行签名操作。

那么问题是-我们如何利用 Yocto 中的 TI 工具来实现这一点？

尊敬的 David：

我们还没有研究 使用 HSM 服务器的密钥对映像进行签名。 请给我们更多的时间来重新讨论这个问题。

谢谢

Yogesh  

尊敬的 David：

我将本着社区的精神与大家分享到目前为止学到的知识-尽管在我看来、TI 或我们认为 SOM 制造商应该就这一最基本的安全功能提供支持。

这是一个粗略的编辑、我相信可能会有一个更优雅的解决方案、但通过编辑/修补 openssl.py args 参数(大约149行和230行)、可以使用如下内容：

Args =['REQ'、'-new'、'-x509'、'-engine'、'PKCS11'、 '-keyform'、'engine'、'-nodes'、
'-outform'、'DER'、'-out'、cert_fname、'-config'、 config_fname、
'-SHA512'、'-key'、'PKCS11：model=...']

并向 cipe-sysroot-native/etc/ssl/openssl.cnf 添加如下内容：

Engine = engine_section

[发动机部分]
PKCS11 = PKCS11_SECTION

[PKCS11_部分]
engine_id = PKCS11
Dynamic_path =/usr/lib/x86_64-linux-gnu/engines-3/pkcs11.so
module_path =...
init_args =...

我可以通过访问 HSM 中的 SMPK 私钥成功为引导加载程序二进制文件签名。

我无法从 local.conf 传递密钥路径和使用隐藏变量的 HSM 引脚值。 因此、如果您在这些方面取得了任何进展、请分享您的调查结果。

此致、

Chris

克里斯,这是一个*巨大的*帮助,谢谢。

是的、这属于黑客攻击、我希望 TI 提供支持的解决方案-但至少这为我提供了一条前进的道路。

有一个类似的论坛问题、涉及如何使用 HSM 来创建"opt-keywriter"可执行文件、以便首先熔断保险丝。 我想这会更复杂、好像 AES 密钥也参与了这个过程；但那是"纯粹的"TI 脚本、我认为需要由 TI 自己来解决。

David、

您对密钥编写器脚本的描述是正确的。  虽然更深入地了解了 AES 密钥的使用方式、但它仅保护公钥的哈希(不需要保护)和 SMEK (目前尚未使用-至少在 Yocto 不使用)。  下面是我在创建熔断保险丝所用认证时使用 HSM 所做的编辑：

需要对 gen_keywr_cert_helpers.sh 进行以下更改
第224行
OpenSSL dgst -发动机 PKCS11 -密钥表引擎-签名"PKCS11：..." 输出"2美元"- SHA512 "3美元"

第234行

gen_keywr_cert.sh 需要进行以下更改：
第705行
OpenSSL req -新-x509 -发动机 PKCS11 -密钥表单发动机-key \

希望这对您有所帮助、

Chris

Chris、

这只是"一般"的帮助！！

正如我所说的、我没有深入探究这种级别的 TI 脚本、但这澄清了背后发生的大部分事情。

在 TI 应用手册或等效的工具中看到这一点真的很好、因为我可以肯定的是、我们不是唯一一个想要使用 HSM 进行生产签名的人！

David

谢谢克里斯！！  感谢提供指导。

David、

在切换到 binman 之前、TI 正在使用 k3-image-gen 工具对图像进行签名。 想法是使用开源工具对可扩展的图像进行签名。

我们同意 TI 应提供应用手册/常见问题解答来扩展 binman 以使用 HSM 服务器进行签名。

我们 计划提供 工作参考 演示 3/21. 即可完成对 bin-man 和 Yocto 集成的更改。 将尝试在中发布这篇文章 2025年第2季度 .

如果您已经在尝试 Chris 的建议并遇到任何问题、请随时与我们联系。

谢谢

Yogesh

Yogesh、

这将是惊人的！！ 谢谢你。

我承认这让我们陷入了一个棘手的处境、因为我们目前预计本季度将在这一切都在运营的情况下向客户交付产品；但从 TI 获得一个支持性集成的时间表可能有助于设置我们的交付功能集。

请随时让我尝试您希望使用的任何原型

此致、

David

先生们、

到目前为止、我还不知道该主题。

我们实施 HSM 集成的方式与 Chris 完全相同。 我们还认为、TI 应该基本上在中提供相应的修改 /tools/binman/btool/openssl.py 并将该修改引入主线。

从用户的角度来看、我们建议增强 ti_secure 和 ti_secure_rom 条目(请参阅 https://docs.u-boot.org/en/stable/develop/package/entries.html#entry-ti-secure-entry-containing-a-ti-x509-certificate-binary) 、以便可以选择性地定义两个额外属性、例如"engine"和"keyform"。 只要定义了一个或两个可选属性、就应使用相应的附加选项调用 OpenSSL。

这将使我们与现有的"keyfile"属性一起将加密操作卸载到 HSM。

此致

Walter

Yogesh、

第二季度计划是否仍在正轨上？ 您是否已经能够分享工作基准？

你还能谈谈克里斯的说法, AES 密钥不是用来加密实际的二进制,而是公共密钥或 SMEK 的哈希?

拥有完整 HSM 流程的完整工作参考将非常有帮助、因为这是我们目前几乎在所有地方都会遇到的痛点。

我已经能够很深入地了解它如何组合在一起、但一个指南中的某种组合仍然会很有帮助。

还有一些分布式信息、因此如果有可能编写详细说明所有签名、加密行为、所有交互工具/组件是什么以及如何在生成/签名/加密/配置期间通过 HSM 保护关联的签名/加密密钥的整个生命周期的完整指南或应用手册、将非常感谢、使 TI 比其他制造商当前提供的要好。

此致、

Jesse

我们在这里有一个需要注意的地方...

由于 k3-binman.dtsi 和 k3-am64x-binman.dtsi 文件的处理方式,用于访问 HSM 的 PKCS11字符串被存储在 dtb 中(连同我早期尝试的密码 pin !!)

这不是最安全的程序！！ 对文件名使用 OK、但对密钥名称不使用。

因此、如果可以在编译的 dtb 外部"提供 key-access 信息、或者可以有一种方法在将关键信息打包到最终二进制文件之前从 dtb 中剥离关键信息、那就很好了。 (很棘手、因为需要在 DTB 签名之前完成此操作)

此致、

David

这的确是一个重大的监督。

关键的生命周期安全和正确的管理应该从一开始就开始,很高兴你提出这个问题!