保护物联网：安全启动，嵌入式设备的“信任根”

介绍

这是我们关于物联网（IoT）安全问题的第二份应用说明。电子设备的安全性是当今互联世界中的“必备条件”。有大量证据1为了表明当物联网上设备的安全性受到损害时，您必须谨慎，甚至怀疑该设备和整个物联网。您肯定不能依靠被黑客入侵的设备进行安全的数据交换、处理或存储。

在我们的第 1 部分应用说明《保护物联网：第 1 部分，公钥加密保护连接设备》中，我们重点关注安全风险的识别，并认为最好的安全性嵌入在电子设备中。我们强调了对策，特别是基于公钥的算法。

现在，在本后续第2部分应用笔记中，我们将重点介绍安全启动，它实际上是“信任之根”，也是电子设备可信度的基石。请注意，此讨论假定读者了解密码学中私钥和公钥之间的区别。您可以快速参考我们之前的应用说明，在谷歌搜索这些术语时找到大量讨论。在这里，我们将演示如何方便地实现设备安全性，以及如何在现场更新设备。DeepCover安全微控制器将作为支持信任的设备的示例，以保护物联网。®®

信任根始于受信任的软件

防止试图破坏电子设备外壳（即硬件）的攻击的唯一解决方案是使用微控制器，该微控制器从内部不可变存储器开始执行软件（请注意，并非每个微控制器都具有此设置和功能）。存储在微控制器中的软件被认为是固有的受信任的（即信任根），因为它不能被修改。这种坚不可摧的保护可以通过只读存储器（ROM）来实现。或者，如果存在适当的安全性，微控制器内部的闪存（EEPROM）存储器也可用于存储信任根软件。要么有一种保险丝机制，使这个闪存在软件写入后不可修改（作为ROM），要么有一个适当的身份验证机制，只允许授权人员在闪存中写入信任根软件。如果这个早期的软件可以在不受控制的情况下进行修改，则无法保证信任。“早期”意味着它是微控制器上电时执行的第一个软件。因此，需要此初始软件的固有可信度。如果该软件值得信赖，则可用于在放弃微控制器控制权之前验证应用程序的签名。它就像一座建立在坚实基础上的城堡。

引导到安全状态

上电时，器件的微控制器开始从受信任位置（例如 ROM、受信任的内部闪存）运行信任根代码。此代码的主要任务是在成功验证其签名后启动应用程序代码。签名的验证（参见下面的器件所有权）是使用先前加载到微控制器中的公钥完成的，使用方法1：自我认证或方法2：分层认证，在我们的第1部分应用笔记中讨论。为了方便读者，我们使用下面的侧边栏来重现对验证和保证公钥的完整性、真实性和身份的方法的讨论。

开发人员仍然可以以通常的方式使用这些受保护的微控制器来编写软件、通过JTAG加载和执行软件以及调试。安全的微控制器不会使开发更加困难。

发布软件并对代码进行签名

一旦软件完全完成并经过测试，然后由认证实验室或内部验证机构审核和批准，就必须发布。发布用于安全启动的软件需要一个额外的重要步骤：二进制可执行代码签名。事实上，对代码进行签名会“密封”代码（如果不检测到这些修改，则无法进一步修改代码）并对其进行身份验证（审批者的身份已完全确定）。代码是密封的，因为如果修改，关联的签名将变得无效 - 数字签名的完整性将不再完整。该代码也经过身份验证，因为它是由一个独特的、未公开的私钥签名的，私钥由其所有者——负责签署代码的人——小心翼翼地保护。

对代码进行签名是认证软件的重要步骤。软件一旦获得外部或内部验证机构的批准，就不能更改。

取得设备的所有权

通过个性化微控制器中的信任根（处理安全启动的不可变代码）来获取设备的所有权。但我们还需要将软件审批者拥有的公共代码验证密钥加载到设备中（参见第1部分应用笔记）。请记住，此密钥是基本密钥，应受信任。

有两种方案可以个性化信任根。一种方法使用较小的键层次结构，而另一种方法没有键。我们现在将研究这两种方法。

在第一种方法（图 1）中，设备的信任根已包含一个根公共“密钥验证密钥”（作为信任根的一部分本质上受信任）。我们称之为主根密钥 （MRK）。简单地重述，该密钥在信任根中硬编码，用于验证公共代码验证密钥 （CVK）。（请参阅边栏中的方法 2。因此，公共CVK必须在加载到微控制器之前进行签名。对于此签名操作，签名实体是信任根的所有者（即，拥有与信任根中硬编码的公钥匹配的私钥的芯片制造商）。一旦公共 CVK 被信任根加载并接受，信任根的密钥将不再使用，除了在每次启动时内部重新检查 CVK 以确保它未被修改或损坏，或者更新公共 CVK。CVK 现在用于验证二进制可执行代码。此个性化步骤具有显著的潜在优势：它可以在不安全的环境中执行，因为只有正确签名的公钥才能加载到设备中。此外，此个性化步骤并不是一个很大的障碍，因为可以在所有设备上部署相同的CVK。请注意，CVK 可以存储在外部不受保护的内存中，因为它在使用前经过系统地重新验证。

图1.代码验证密钥 （CVK） 由 MRK 验证，然后用于验证可执行代码，然后执行它。

第二种更简单的个性化信任根的方法不使用先验密钥。因此，公共CVK必须加载到内部存储器中，该存储器只能由从该内部存储器运行的受信任软件写入，或者加载到不可修改的存储器中，例如安全环境中的一次性可编程（OTP）存储器或锁定闪存（EEPROM）。需要一个受信任的环境来确保预期的公钥不会被恶意密钥替换，因为信任根无法验证此密钥。此密钥还必须由校验和（CRC-32 或哈希）在内部保护，以确保该密钥没有完整性问题。或者，为了节省宝贵的 OTP 空间，密钥可以存储在不受保护的内存中，但其校验和值存储在内部 OTP 内存中。

如此处所述，可以想象一个多方签名方案，其中多个实体（例如，软件审批者和外部验证机构）必须对可执行代码进行签名。人们还可以想象更复杂的层次结构，具有不同的代码验证密钥，更中间的密钥验证密钥，甚至多个根密钥。使用的最终过程实际上取决于应用程序所需的上下文和安全策略。

在此个性化步骤中，可以永久设置其他微控制器选项，例如禁用JTAG。虽然在开发过程中很有用，但必须在生产部件上禁用JTAG，否则可以绕过信任根。

在制造过程中下载应用程序代码 - 一个简单而可信的过程

制造过程中的一个步骤包括将先前密封/签名的二进制可执行代码加载到设备中。

公钥方案具有以下独特优势：

不需要多样化。

不涉及任何秘密。

二进制可执行代码由软件审批者密封，无法修改。

 

因此，签名的二进制可执行代码可以在任何地方加载。只有此代码可由电子设备加载和执行;其他二进制可执行代码将被拒绝。

在此过程中使用公钥加密非常有价值，因为不会对制造过程施加任何安全限制。

部署、现场维护

基于安全启动的设备与其他设备一样部署在现场。但是，若要更新字段中的可执行代码，必须使用软件审批者的私钥对其进行签名，并通过适当的方式（如本地接口或网络链接）将其加载到设备中。

如果软件审批者的代码签名密钥被泄露，则还可以在字段中替换关联的公共 CVK，前提是新密钥由先前加载到设备中的公钥验证密钥签名。（此密钥验证密钥是“吊销后更新”密钥。但是，泄露根密钥 （MRK） 不是一种选择，因为无法在字段中替换此根密钥。适当的私钥管理策略确实可以降低这种风险。

密码学是不够的

现在假设遵循了适当的密钥管理和良好的保护实践。还要假设制造安全、信任和信心得到保证。现在，最后，假设选择了良好的密码学，例如标准化算法，足够长的密钥，高质量的随机数。尽管如此，一些主要的安全威胁仍然存在，并严重暴露了设备的资产。

公钥存储在锁定的闪存位置，即不能再修改。如果预编程公钥或安全启动的完整性基于闪存或OTP存储器中的锁定机制，则完整性的强度仅取决于此锁定技术的强度。任何能够击败这项技术的攻击者，都可以击败目标资产本身的完整性。

同样，应对数字签名进行软件检查。因此，除了符合算法之外，还有几种方法可以验证软件 - 一些方法健壮，而另一些则不那么可靠。鲁棒性意味着抵抗错误（有意或无意）、意外问题、错误、异常环境条件（例如，低温、电源故障导致的电源不良）或损坏的字节。这些约束通常通过设备的软件和硬件验证来解决和管理。

但稳健性也意味着抵抗特定的、蓄意的、集中的攻击。这些恶意攻击可以随机执行，而无需真正了解平台（即“黑匣子”攻击）。或者攻击可能是在对设备进行认真研究之后进行的（即，攻击范围从“灰色”到“白盒”攻击，对应于攻击者对平台的理解水平）。在每个实例中，攻击者都在寻找可以转换为攻击路径的弱点或限制。

两个简单的例子说明了这个想法。我们的第一个示例涉及软件良好实践，它要求您在处理输入数据之前检查输入数据的边界和长度。使用静态分析工具来评估代码源质量也是良好做法的一部分。这些操作可帮助开发人员和审核员轻松改进和保证代码质量。人们还认识到，高效的开发人员将检测格式错误的字节束。遗憾的是，为了尽快交付新软件，这些检查并没有定期实施，因为此外，这些“良好实践”控制增加了开发时间、测试和验证时间以及代码大小，并且通常被认为与基本功能相比不那么重要甚至没有必要。因此，在实施通信协议后可能会出现缓冲区溢出（图2），即使是那些理论上安全的协议，如TLS，或内存到存储器的副本，如在运行应用程序之前从外部NAND闪存到RAM的副本。这些缓冲区溢出通常是对常规操作软件的功能良好的攻击。

图2.缓冲区溢出效果。

另一个示例涉及进程选择，称为故障攻击（图 3）。从上一节中可以同意，数字签名检查对于检测数据/代码中的任何完整性/真实性故障非常强大。实际上，在将字节复制到应用程序的运行内存之前，可以对存储它们的字节执行检查。但在其他一些操作方案中，字节复制是在检查发生之前执行的。这意味着这些字节几乎可以使用/运行，即使它们与数字签名不匹配。如果攻击者能够通过触发电源故障（图 3）或任何其他类型的小的非破坏性故障来跳过检查步骤，则正常进程可能会受到干扰并跳过检查操作，从而使加载的字节能够作为真实代码运行。

一般来说，使安全机制仅依赖于单一的实现机制会削弱这种安全性，并促使攻击者专注于规避实现。

图3.故障攻击的影响：故障通过改变测试条件结果来修改程序的正常路径。

实施最佳解决方案

目前，像MAX32590这样的安全微控制器具有信任根，其中包含预加载的不可变根密钥。在这些安全微控制器中包含MRK的信任根位于ROM或内部OTP或出厂时锁定的内部闪存中。由于用于存储密钥的内存技术是不可变的，因此可以保证 MRK 的完整性。最后，仍对密钥计算校验和，以确保在实际使用该密钥之前不会发生故障。

要初始化自定义的预加载密钥，客户将其公共 CVK 提交给制造商进行签名。制造商使用存储在 HSM 中的私钥对客户的公钥进行签名（即认证）2这是严格控制的。然后，他们将签名的公钥发送回给客户。此过程很快，在首次发布软件之前只需要一次（请注意，在软件开发过程中不需要此安全步骤）。然后，客户可以加载制造商的密钥并将其替换为自己的密钥，并下载其签名的二进制可执行代码。

这个过程非常灵活，因为每个部件上都编程了相同的键，从而使个性化过程变得非常容易。制造商甚至可以在零件制造之前就使用客户的密钥对零件进行个性化（即定制），从而大大减少了客户的麻烦。此个性化步骤也可以由客户自己完成。作为一个有趣的责任转移，后一个关键的个性化步骤允许客户自己拥有微控制器的所有权。最后，DeepCover安全微控制器（如MAX32550）中的ROM代码允许在现场撤销和更换密钥，而不会失去信任。

需要注意的是，这个关键的认证过程是不能绕过的。它不是可选的。即使是开发中的安全部件也执行这些相同的原则，但只有一个区别：它们可以在激活测试密钥的情况下以非常有限的数量提供，以减少在开发或零件评估期间客户密钥的暴露。

仅仅为今天设计一个安全的解决方案是不够的。最实用的解决方案也将为未来的升级而设计。最值得信赖的安全设备（如 DeepCover 设备）支持面向未来的 RSA（高达 2048 位）和 ECC（最多 521 位）签名方案。此外，PCI PTS实验室已经审核了他们的代码。此外，硬件加速器使启动时的代码验证几乎不可见，因此安全协议不会在启动过程中造成任何额外的负担。当代码从闪存复制到可执行 RAM 时，数字内容摘要是动态计算的。然后，签名验证过程只需要很少的额外时间。

DeepCover器件将这些安全机制与其他保护措施相结合，例如JTAG-ICE停用，这使得代码转储、修改或替换变得不可能，因为只有一种机制可以解决灵活/可编程部件上的任何安全问题。所有“门”要么关闭，要么锁上钥匙，以给利益相关者提供充分的信心。

结论

我们已经看到，安全启动是一种廉价但至关重要的安全机制，可用于物联网上的设备或几乎任何需要保护资产的应用程序。即使使用这种安全启动，整体开发和制造过程仍然非常简单明了。额外的步骤只是：在每个设备中加载一个公共代码验证密钥（CVK），并对要加载到设备的二进制可执行代码进行签名。

我们以前说过这一点，但再说一遍是有价值的。我们不允许任何违反电子交易、核电站等关键系统或植入式医疗设备的安全漏洞。安全启动（信任根）是保护物联网的一个步骤。它使这种信任成为可能并且易于实施。

审核编辑：郭婷