Secure Boot需要信任根公钥（Root of Trust Public Key，ROTPK）的原因在于它为整个安全启动过程提供了一个基本的、可信赖的起点。这个起点是确保系统安全性的关键部分，用以确保用以验证启动代码的公钥的完整性和真实性，是建立信任链的基础。本文主要讨论，如何保证信任链的“根”的安全性。
在系统芯片（SoC）和其他嵌入式系统中常用的“信任链”（Chain of Trust）安全启动流程。以下是关键方面的概述：
在ARM公司的Platform Security Boot Guide中，对3章 Security Requirements中对信任链的提供方式做了要求。在此规范要求至少有一个被称为信任根公钥（Root of Trust Public Key，ROTPK）的公钥，该公钥负责使用公钥加密技术安全地验证第一阶段的代码。其原则是：
1. Background
Secure Boot需要信任根公钥（Root of Trust Public Key，ROTPK）的原因在于它为整个安全启动过程提供了一个基本的、可信赖的起点。这个起点是确保系统安全性的关键部分，用以确保用以验证启动代码的公钥的完整性和真实性，是建立信任链的基础。本文主要讨论，如何保证信任链的“根”的安全性。
在系统芯片（SoC）和其他嵌入式系统中常用的“信任链”（Chain of Trust）安全启动流程。以下是关键方面的概述：
信任链概念
2. Supply chain scenarios
在ARM公司的Platform Security Boot Guide中，对3章 Security Requirements中对信任链的提供方式做了要求。在此规范要求至少有一个被称为信任根公钥（Root of Trust Public Key，ROTPK）的公钥，该公钥负责使用公钥加密技术安全地验证第一阶段的代码。其原则是：
例如，SoC供应商可能能够使用内置的ROTPK安全地启动他们自己的代码，然后使用单独的OEM ROTPK来验证OEM固件。OEM ROTPK可能在供应链的不同点进行配置，那里可能有运营流程来减少配置过程中的风险。
当评估使用公钥哈希与使用证书哈希在安全启动（Secure Boot）过程中作为信任根的安全性时，重要的是要理解这两种方法的不同特点和它们在实际应用中的含义。
使用公钥哈希：
使用证书哈希：
使用CMAC/HMAC：
2.1 Single provider
下图展示了最简单的案例，比如一个受限制的或嵌入式设备，其中制造商控制着整个软件栈和签名过程。制造商提供了信任根公钥（ROTPK）。在这种情况下，不可能进行撤销。
Note，这种情况仅对超受限的微控制器（MCU）或简单的外围设备有益。参考：https://documentation-service.arm.com/static/5fae7507ca04df4095c1caaa?token= 3.4.1 Single Provider
如果系统拥有多个软件提供商，并且具有足够的计算能力去验证证书链，那么建议创建单独的签名密钥，以减轻私有镜像签名密钥丢失的风险。
2.2 Multiple dependent providers
信任链的第一个环节是信任根公钥的管理，它用于验证所有后续的证书和镜像。一个示例场景如下：
如果一个镜像签名者需要更换他们的镜像签名密钥，那么他们必须联系信任根公钥（ROTPK）的所有者（下图中的根证书颁发机构，Root CA）。这需要镜像签名者和根证书颁发机构（即ROTPK的所有者）之间保持持续的商业关系。
2.3 Multiple Independent Providers
该系统可能包含足够的片上存储空间，以容纳多个独立的信任根公钥（ROTPK）。每个ROTPK提供一个独立的信任链，允许不同的制造商独立于彼此授权和撤销固件签名密钥。例如，一个ROTPK可以对应于SoC供应商，而另一个可能对应于原始设备制造商（OEM）。或者，OEM拥有一个ROTPK，同时允许客户安装一个单独的ROTPK来验证非安全处理环境（NSPE）固件。下图展示了一个简化的独立提供商的信任链。
2.4 CMAC/HMAC作为认证的方式
在安全引导中，通常有两种不同的方法用于检查真实性和完整性，根据AUTOSAR的标准https://www.autosar.org/fileadmin/standards/R22-11/FO/AUTOSAR_TR_SecureHardwareExtensions.pdf ：
使用CMAC/HMAC作为真实性和完整性检查（低安全性，高性能，节约空间）
使用RSA/ECDSA非对称密钥验签作为真实性和完整性检查（高安全性，运算时间长，占用空间大）
使用CMAC或HMAC算法可以导致快速启动时间。该解决方案的最大挑战是加密密钥和参考MAC的存储。用于对称算法的私钥需要安全地存储在受保护的安全环境（如HSM）中。此外，由于MAC生成和MAC验证使用相同的密钥，因此默认情况下不提供不可否认性。可以总结为：
使用CMAC/HMAC的这种方法，显然是降低安全性追求性能和资源的节约。对于那些对于boot时间严苛的ECU或者资源受限的ECU中，会使用该方法。例如：s32k144，RH850 。
2.2 Multiple dependent providers
在一些性能强大的SoC中，采用multiple dependent providers的形式，即采用证书的HASH写入eFUSE作为信任根。例如NXP的rt1170就是该设计。
从NXP的产品线可以看到，NXP将统一实现，High Assurance Boot标准应用于NXP的SoC及MCU，NXP的很多产品线都开始逐步的采用，参考 https://variwiki.com/index.php?title=High_Assurance_Boot 这些产品是：
德州仪器的最新的Sitara Processor中也采用了证书的方式，参考：https://www.ti.com/lit/pdf/spry305
NVIDIA的Jetson系列的Processor也采用了证书的方式（也支持single provider，只使用公钥的形式），https://docs.nvidia.com/jetson/archives/r35.4.1/DeveloperGuide/text/SD/Security/SecureBoot.html
2.3 Multiple Independent Providers
这个暂时没有找到这样的设计。只存在于ARM的secure boot guideline里。
2.4 小结
总结：
从总结主流的SoC和MCU，在secure boot中，供应商更喜欢使用Multiple dependent providers的形式，主要考虑：
一个标准的secure boot应该是：