使用安全元件进行固件验证的实现示例

Microchip的微控制器与安全元件相结合如何提供帮助？

微控制器中的不可变启动存储器是任何通过安全启动和安全固件升级实现固件验证的应用中非常重要的功能。最新的PIC24F低功耗微控制器（MCU）和高性能dsPIC33数字信号控制器（DSC）具有ICSP™写禁止和CodeGuard™ Security的闪存OTP，可实现不可变的安全启动。ICSP 写禁止是一种访问限制功能，激活后，通过外部编程器和调试器以及读写保护功能限制对所有闪存的访问。激活后，ICSP 写禁止功能可防止 ICSP 闪存编程和擦除操作，并使闪存的行为类似于一次性可编程 （OTP） 存储器。CodeGuard 安全功能支持将闪存程序内存分段为两个具有不同权限的专用区域。第一个内存区域是引导段，它保存实现固件验证例程的引导加载程序代码。此引导段可以对自身和内存的应用程序区域的所有自写进行写保护。CodeGuard 安全性与 ICSP 写禁止功能的闪存 OTP 一起使引导加载程序不可变。正如我们之前提到的，我们必须记住，在当前的上下文中，不可变并不意味着无法访问或不可读，但无法通过远程数字攻击进行修改。第二个内存区域称为保存应用程序映像的常规段。

在 CodeGuard Flash 安全性的引导段中实现的固件验证码（不允许更改）向利用 CryptoAuthlib 库的安全元素发出 ECDSA 验证命令。来自加密身份验证系列信任平台的 TrustFLEX ATECC608 安全元件配备了安全密钥存储和基于硬件的加密加速器，能够在几毫秒内运行 ECDSA 验证操作，并且它还将安全地保护将用于在代码签名和/或代码摘要上执行此加密功能的公钥。公钥现在存储在安全元件的不可变安全内存区域中，利用防篡改和侧信道攻击保护进行物理保护。现在访问和更改密钥和代码要困难得多。查看我们的软件库，了解MPLAB代码配置器（MCC）支持的PIC24F MCU和dsPIC33 DSC，MPLAB®代码配置器（MCC）是一个免费的图形编程环境，可生成无缝、易于理解的C代码以插入到您的项目中。MCC 中的 CryptoAuthlib 库简化了 TrustFLEX ATECC608 与 PIC24 或 dsPIC33 器件的接口，并可实现各种安全功能。您可以通过 MCC 16 位引导加载程序库添加固件验证和安全固件升级功能。有关更多信息，请访问我们的嵌入式安全设计中心，了解如何实施安全启动和 OTA。您还可以参考 ShieldsUP 安全网络研讨会 #26：使用 dsPIC33 DSC、PIC24F MCU 和 ATECC608 器件简化安全应用设计

MCU 和 ATECC608 TrustFLEX 之间的交易图是怎样的？

信任平台设计套件（TPDS）软件工具是开始使用Microchip安全元件的起点。打开 TPDS 时，可以选择用例和开发平台。然后，该工具将详细说明所选用例的实际事务图。

例如，下面是经典微控制器和 TrustFLEX ATECC608 之间的固件验证事务图。它显示了主机MCU如何计算固件摘要，将该摘要作为质询发送到安全元素，安全元素尝试使用预先配置的公钥以加密方式验证摘要+签名，最后接收来自安全元素的响应。您可以看到主机MCU用于与安全元件通信的实际CryptoAuthLib API调用，例如“atcab_secureboot_MAC”，以及对MCU和安全元件之间实际发生的情况的简单描述。

 

图 1：使用 TrustFLEX ATECC2 的固件验证用例的信任平台设计套件 V608 事务图

在此方案中，该工具将引导您完成以下期间需要发生的情况：

- 原型制作阶段：

非对称密钥对由工具生成用于原型设计

公钥由 TPDS 再次通过您的笔记本电脑进行配置，用于原型设计目的。对于生产，Microchip提供安全密钥配置服务

使用私钥对代码图像进行签名，以创建代码图像的签名

- 启动时：

主机MCU计算摘要

主机MCU将摘要和签名发送到安全元件

安全元件验证并响应有效/无效

主机 MCU 接收响应，指示固件的有效性

固件被授权在MCU中运行

如果您的微控制器没有 BootROM 功能，但您仍然想使用安全元件怎么办？

现在想象一下，您的设计基于经典的32位微控制器，例如SAMD21 ARM® Cortex® M0+，并且没有BootROM功能。这是当今绝大多数设计的情况，更换为新的微控制器涉及重新认证成本和时间，而这些成本和时间并不总是负担得起的。

在这种情况下，您需要假设您的微控制器代码可以更改。如果从微控制器到安全元件的ECDSA验证命令可以更改，后果是什么？如果代码仍然已签名，并且您的微控制器内没有用于验证的密钥，则可能会受到影响，但不会影响您的整个设备群（假设您使用的是公钥基础设施）。这是由于安全元件使您的公钥保持隔离，它将保护队列的其余部分。需要考虑的几个问题可能包括：

是否值得花时间对代码进行逆向工程，以简单地关闭您必须物理访问的设备？在大多数情况下，可能不会。这会影响设备队列吗？每个设备都必须物理访问，这是不切实际的。从远程攻击的角度来看，如果我们假设需要 OTA 更新来验证真正签名的代码并且代码中没有密钥，则可能不会。

此外，您能否信任您的合同制造商，提供将验证您的代码的加密密钥？如果答案是否定的，则安全元件的价值将翻倍，因为Microchip提供安全的密钥配置服务，可以在我们的安全工厂内秘密加载密钥，以消除合同制造商的密钥暴露并绕过中间人。计划您想要更改CM的那一天，如果密钥位于安全元件中，则只需使用Microchip更改送货地址即可。

最后，损益（P&L）与财务风险水平的成本影响是一个巨大的考虑因素。我们已经看到客户使用我们的安全元件，因为它是一种非常经济高效的密钥解决方案。一旦您在嵌入式系统中加载密钥，您就可以自定义该微控制器或微处理器。想象一下，您的处理器大约是 3-5 美元，现在您已经定制了您的控制器，这些控制器是不可取消、不可退回的多美元硅片，放在您的货架上。安全元件大大降低了财务风险。

物流供应链障碍和在MCU中安全配置“验证”密钥的成本增加

微处理器通常比微控制器具有更丰富的安全功能，但这两种解决方案都需要有一个安全的物理边界，密钥和加密算法都将位于该边界。不幸的是，这种设计很难以经济高效的方式实现，因为安全边界会对处理器或控制器的芯片成本产生重大影响。单体解决方案的成本并不是唯一需要增加的成本，但完全支持此类架构的技术支持、处理多用户权限的各种工具以及安全处理密钥配置的供应链物流继续增加复杂性和风险。让我们从损益的角度来看这个问题。让我们想象一下 100，000 个微处理器单元，它们都装有密钥，这使得所有这些处理器都是自定义的。现在想想你货架上的库存成本，无论你是分销商，还是一个OEM，这个成本都会打击你的损益，并随着时间的推移增加你的项目风险，因为项目不断被自然地推迟。

更具可扩展性的架构是使用Microchip CryptoAuthentication™配套设备，如ATECC608 TrustFLEX。密钥被隔离在经济高效的安全密钥存储中，几乎可以运送到世界任何地方（根据 EAR99 出口法规）。安全密钥配置服务消除了密钥暴露给供应链中间商，减少了攻击面。

总之，您需要考虑安全启动的固件验证、运行时代码验证和 OTA 更新后的安全基础，以及在处理加密密钥时的各种供应链风险和成本。将安全元件（如 ATECC608）与微控制器（如 dsPIC33 DSC 或 PIC24F MCU）与具有不可变启动功能的组合是设计的绝佳基础选择。如果微控制器没有 bootROM 功能，但依赖于安全元件来物理隔离公钥，则您的威胁模型和风险评估可能会在大多数应用程序中验证此类架构。

审核编辑：郭婷