Secure Boot and the Manufacturing Chain: Implementation and Impact
作者:Frederic Hoerni : The Embedded Kit
让我们考虑一种常见情况:开发团队与制造商是两个独立的实体,可能是位于不同国家的不同公司。本文将聚焦于基于Arm处理器的产品。
这是《嵌入式工具包》为您带来的安全启动系列文章的最后一篇。本文将重点讨论如何将设计投入生产制造。
我们需要防止机密信息泄露,在本安全启动系列文章的语境下,我们将特别关注用于保护启动过程的私钥。
基于这些原因,我们需要一个第三方签名实体,如下图所示:
1. 开发团队设计软件镜像
开发团队设计一个集成了安全启动功能的软件镜像。他们使用开发密钥测试整个机制。这些密钥因完全不具备保密性而不可信任。最终,团队将镜像交付给签名实体。
他们还需向签名实体提供工具和文档,以便其能够使用其他密钥进行签名。使用其他密钥签名通常也意味着将相关的公钥插入到软件镜像中。
2. 由签名实体进行签名
签名实体可以是个人或部门,他们拥有私钥,并将这些私钥(出于保密目的)存储在物理或数字保险库中。
在我们关于如何在基于Linux的平台启用安全启动的第一篇文章中,我们讨论了一个由根密钥(ROOTKEY)和用户密钥SWK1构成的信任链。在此示例中,签名实体必须对软件镜像执行以下步骤:
· 将SWK1的公钥插入到引导加载程序中
· 使用ROOTKEY对引导加载程序进行签名
· 使用SWK1对内核和根文件系统进行签名
· 计算ROOTKEY公钥的哈希值,该值将被烧录到产品的OTP位中
为了完成这些步骤,他们将使用开发团队提供的工具和文档。对于引导加载程序的签名,MPU或SOC供应商通常会提供与其特定芯片匹配的专用工具。例如,恩智浦(NXP)提供代码签名工具(CST),意法半导体(STMicroelectronics)提供STM32CubeIDE。
密钥ROOTKEY和SWK1通常存储在数字保险库中,可以通过PKCS#11接口使用它们进行签名。私钥本身永远无法被提取,但仍可通过发送请求来使用,例如:"使用标签为SWK1的密钥签署此数据"。
使用像openssl这样的工具,命令行示例如下:
text
复制
下载
openssl pkeyutl \
-engine pkcs11 -keyform engine \
-sign -inkey "pkcs11:object=SWK1;pin-value=1234" \
-in rootfs.img -out rootfs.img.sig
生成的软件镜像和哈希值应交付给制造商。
3. 制造商进行产品供应
制造商必须为每个产品供应软件镜像和ROOTKEY的哈希值。
软件镜像被安装到产品的存储介质上(eMMC、NOR闪存、NAND闪存、SSD等)。
ROOTKEY哈希值被烧录到处理器的OTP位中。此操作不可逆也无法修改,因此务必以可靠的方式确保为每个产品正确烧录。
对于imx8m处理器,在u-boot中典型的命令集如下:
text
复制
下载
# 烧录哈希值
fuse prog -y 6 0 0xDADD030D
fuse prog -y 6 1 0x8B5D3EA7
fuse prog -y 6 2 0x4EC5A321
fuse prog -y 6 3 0x836FF123
fuse prog -y 7 0 0x6578C108
fuse prog -y 7 1 0xE7483AAB
fuse prog -y 7 2 0x51FE0260
fuse prog -y 7 3 0x25F904DA
# 锁定设备
fuse prog -y 1 3 0x02000000
可能还需要采取其他措施,例如禁用JTAG访问。
此后,生产线应验证产品能否正确启动。
进一步探讨
以上我们概览了具备安全启动功能产品的制造步骤。
要进一步深入,您需要考虑更多主题,例如密钥轮换。在产品生命周期中是否需要更改产品上的ROOTKEY和SWK1?在制造过程中是否需要更换这些密钥,并为不同批次的产品使用不同的密钥?
此外,从处理器的角度来看,实现安全启动的方式在很大程度上取决于处理器供应商。从开发者的角度来看,如果在这方面能有某种标准化,将有助于更便捷地应用这项技术。
还有一些主题本文未涉及,例如为终端产品配置特定凭证(如Wi-Fi密码)。这需要额外的安全机制(加密等)。
最后,我们没有讨论针对供应链攻击的防护。在这种攻击中,攻击者试图在制造产品所装载的软件镜像中插入后门。然而,由于《网络弹性法案》(美国)的要求,供应商绝对需要通过安全风险评估来应对此类风险。(译自Embedded Computing Design)
