工具/软件：
Prashant & TI 团队--
我们的客户正在使用 TI SK-AM64B 板来实现安全启动解决方案。 他们试图为 TI AM64板执行代码签名并生成组合启动映像 、目前无法这样做。 我们想了解以下内容。
- 为 HS-SE 器件构建 SBL (次级引导加载程序固件)、系统固件、电路板配置二进制文件
- 如何签署这些二进制文件
- 如何连接它们以便使用企业证书为 HS-SE 器件生成已签名的二进制文件。
它们当前正在将 U-boot 用于进程、ROM 引导加载程序未引导这些二进制文件。 我们希望了解构建安全二进制文件以使 ROM 引导加载程序能够接受的过程。
此外、 参考信息：
U-Boot 存储库： https://github.com/phytec/u-boot-phytec-ti (正在使用 PHYTEC SOM)
U-Boot 标签/哈希：v2023.04_09.00.00.011-phy / 187feb2c7f6c545b5ef2c704442dbd4d62d080cd
为了简要说明应该如何使用他们的 U-Boot 版本中的签名步骤、我将简要介绍一下、因为我假设至少有一些关于构建系统的粗略知识、以及此客户和应用程序的遗留知识(离线电子邮件)。 编译过程以运行"binman"结束、该运行从器件树文件中获取输入、该文件告诉它应放置不同编译对象的位置、以创建启动过程需要运行的各种二进制文件。 此过程的一部分是获取给定的私钥、在本例中为 TI Dummy'custMpk.pem'密钥、生成具有扩展的公钥：
- swrv
- EXT_BOOT_INFO
- SBL
- sysfw
- sysfw_data
- sysfw_inner_cert
使用以下命令：`openssl req -new -x509 -key custMpk.pem -nodes -outform der -out ./cert.tiboot3-am64x_sr2-hs-phycore-som.bin.ti-secure-rom -config ./config.tiboot3-am64x_sr2-hs-phycore-som.bin.sha512-secure-rom -secure -rom -config`
我们认为到目前为止、他们已经能够重现此过程、但到目前为止有一个不同之处：CCoE 证书缺少'sfw_data'扩展、正在努力解决此差异。
证书作为 tiboot3.bin 二进制文件的第一段附加为"ti-secure-rom"。 此部分"ti-secure-rom"目前是唯一经过修改、使用自定义和预生成的证书而不是使用 binman 生成的证书的部分。 如果二进制文件的其他部分需要更新才能使此过程正常工作、那么这就是我们需要了解的一些信息。
他们 确实注意到编译的"ti-sysfw"部分有一些有趣的二进制文件、这些似乎是 TI 生成的二进制文件、一个附加了-enc、另一个附加了-cert 查看'-cert'二进制文件的模数、它似乎来自与 TI 虚拟密钥不同的私钥。 团队内部的聊天倾向于将此作为一个可能的痛点、同时需要使用企业密钥签名； 我们相信、无论设备类型或密钥如何、这些都将按原样使用。 这也是可能需要一些清理的东西。
他们最初尝试将证书附加到 tiboot3.bin 是天真的、只是切断虚拟密钥并在最终二进制文件中将其替换为企业密钥。 主要是因为他们担心二进制中的地址混乱(企业密钥更大)、所以最终修改了 binman 而不是跳过生成并使用自定义密钥。 这样、地址将根据证书大小动态更新。 我们非常确定、这些修改(至少是专门针对 tiboot3.bin 的"ti-secure-rom"部分)是实心的。
"直接集成 HSM 或密钥？" -密钥正在直接使用。
如果您需要任何澄清细节或有其他问题、请告知我们。 我们也可以在需求出现时要求提供更多信息。 如果您想要分析生成的任何二进制文件、请告知我、我们可以尝试让客户执行该操作。 也有人要求我们打电话。
CY、
CY
