哈希链将这里讨论的加密概念合并为一系列数据包，从而实现数学上的连接。 如图8所示，第一个包（数字0）包含下一个包的摘要。 与实际的软件应用程序数据不同，第一个数据包的负载是签名。 第二个包（编号1）有效负载包含二进制的一部分和第三个包的摘要（编号2）。 客户端验证第一个数据包中的签名，并缓存摘要 H0，以供以后使用。 当第二个数据包到达时，客户端哈希负载并将其与 H0进行比较。 如果它们匹配，客户端可以确定这个后续数据包来自受信任的服务器，而不需要进行签名检查。 生成这个链的代价高昂的任务留给了服务器，当每个数据包到达时，客户机必须简单地缓存和哈希，以确保数据包到达时没有损坏，具有完整性，并经过验证。

图8 将哈希链应用于包序列

实验验证

本文中提到的解决存储器、通信和安全设计难题的超低功耗微控制器是 ADuCM3029和 ADuCM4050。 这些微控制器包含为 OTA 更新讨论的硬件外设，如闪存、 SRAM、加密加速器和真正的随机数发生器。 用于这些微控制器的设备家族包（DFP）为在这些设备上构建 OTA 更新解决方案提供软件支持。 DFP包含外围驱动程序，为硬件提供了简单、灵活的接口。

硬件配置

为了验证这里讨论的概念，使用 ADuCM4050创建了一个 OTA update 软件参考设计。 对于客户端，ADuCM4050 EZ－KIT 通过使用无线收发器连接到 ADF7242。 客户机设备如图9所示。 对于服务器，开发了一个在 Windows PC 上运行的 Python 应用程序。 Python 应用程序通过串行端口与另一个 ADuCM4050 EZ－KIT 进行通信，后者也有 ADF7242与客户端相同的设置。 然而，图9中右边的 EZ－KIT 不执行 OTA 更新逻辑，只是将从ADF7242收到的数据包转发给 Python 应用程序。

图9 实验性硬件设置

软件组件

如图3所示的软件参考设计对客户端设备的闪存进行分区。 主要的客户端应用程序被设计为可移植和可配置的，这样就可以在其他配置或其他硬件平台上使用。 图10显示了客户端设备的软件架构。请注意，虽然有时将整个应用程序称为 SSBL，但是在图10中以及从现在开始，从逻辑上将真正的 SSBL 部分（蓝色）与 OTA 更新部分（红色）分开，因为后者不一定需要像前面讨论的那样完全在同一个应用程序中实现。 图10所示的硬件抽象层层保持了 OTA 客户端软件的可移植性，并且独立于任何底层库（如橙色所示）。

图10 客户端软件体系架构

软件应用程序实现了图3中的引导序列，一个从服务器下载新应用程序的简单通信协议，以及哈希链。 通信协议中的每个数据包都有12字节的元数据头、64字节的有效负载和32字节的摘要。此外，它还具有以下特点：

缓存： 支持不缓存或缓存一页闪存，具体取决于用户配置。

目录： ToC 被设计用于只保存两个应用程序，并且新的应用程序总是被下载到最老的位置，以保留一个回退应用程序。 这就是所谓的 A／B更新方案。

消息传递： 根据用户配置，对消息传递的 ADF7242或 UART 提供支持。 使用 UART 进行消息传递消除了图9中左边的 EZ－KIT，使得右边的部分留给了客户端。 这种在线更新方案对于初始化系统和调试非常有用。

实验结果

除了满足功能需求和通过各种测试之外，软件的性能也是决定项目成功与否的关键。 两个通常用来衡量嵌入式软件性能的指标是占用空间和指令周期。 占用空间是指软件应用程序在SRAM和Flash中占用的空间。 指令周期是指软件用来执行特定任务的微处理器时钟周期数。 虽然它类似于软件运行时，但它解释了这样一个事实，即在进行 OTA 更新时，软件可能会进入低功耗模式，因为在那里微处理器是非活动的，并且没有消耗周期。 虽然软件参考设计没有针对这两个度量标准进行优化，但是它们对于测试程序和比较设计权衡都是有用的。

图11和图12显示了 OTA 更新软件参考设计在 ADuCM4050上实现的内存大小，不使用缓存。 这些数字是根据图10所示的组件进行分区的。 如图11所示，整个应用程序使用约15kb 的闪存。 考虑到 ADuCM4050包含512kb 的闪存，这个数据太小了。 真正的应用软件（为OTA更新过程开发的软件）只需要1．5 kB 左右，其余部分用于 DFP、 Micro－ECC 和 ADF7242堆栈等库。 这些结果有助于说明 SSBL 在系统中应该扮演的角色的设计权衡。 大多数15 kB 的内存占用用于更新过程。 SSBL本身只占用大约500个字节的内存空间，另外还有1到2 kB 的 DFP 代码用于设备访问，比如 Flash 驱动程序。

图11 闪存占用空间（字节）

图12 SRAM占用空间（字节）

为了评估软件的开销，在每次收到数据包时执行指令周期计数，然后查看每个包所消耗的平均指令周期数。 每个数据包都需要 AES－128解密、 SHA－256散列、对闪存的写入以及一些包的元数据验证。 在数据包有效负载为64字节且没有缓存的情况下，处理单个数据包的开销为7409周期。 使用26Mhz时钟，处理时间约为285微秒。 该值是使用位于 ADuCM4050 DFP （未调整周期）的循环计数驱动程序计算的，是100kb 二进制下载（大约1500个数据包）期间的平均值。

每个包的最小开销可归因于 DFP 中的驱动程序在执行总线事务时利用 ADuCM4050上的直接内存访问（DMA）硬件外设，以及驱动程序在每个事务期间将处理器置于低功耗睡眠状态。 如果禁用 DFP 中的低功耗休眠，并将总线事务改为不使用 DMA，那么每个数据包的开销将增加到17，297个周期。 这说明了设备驱动程序的有效使用对嵌入式软件应用程序的影响。 虽然每个数据包的数据字节数很少，因此开销也很低，但是每个数据包的数据字节数增加一倍，达到128，只会在循环中产生一个小的增长，因此对于同样的实验，需要8，362个指令周期。

指令周期和占用空间还说明了前面讨论的缓存包数据而不是每次写入闪存的权衡。 启用一页闪存缓存后，每个数据包的开销从7，409减少到5，904个周期。 这20％ 的减少是由于对大多数包跳过了Flash 写操作，并且只在缓存满的时候执行一次Flash 写操作。 这种减少是以SRAM为代价的。 如果没有缓存，HAL只需要336个字节的 SRAM，如图12所示。 然而，当使用缓存时，必须保留相当于一整页闪存的空间，这将 SRAM 的利用率增加到2，388个字节。 HAL 的闪存利用率也略有提高，因为需要额外的代码来决定什么时候必须刷新缓存。

这些结果证明了设计决策对软件性能的切实影响。 没有放之四海而皆准的解决方案ーー每个系统都有不同的需求和限制，而且 OTA 的更新软件需要进行调整以解决这些问题。 希望本文对设计、实现和验证 OTA 更新软件解决方案时遇到的一些常见问题和解决方案提供一些帮助，真正弄懂如何实现物联网设备的OTA。

参考资料：

Nilsson， Dennis Kengo and Ulf E． Larson． “Secure Firmware Updates over the Air in Intelligent Vehicles．” ICC Workshops—2008 IEEE International Conference on Communications Workshops， May 2008．

更多内容，请关注本公众号：wireless＿com