物联网设备的固件安全性

　　在过去的几年中，物联网（IoT）被吹捧为下一个大事件以及蹩脚的物联网。这两种描述都是有道理的。保护不力的物联网设备已被用于许多分布式拒绝服务（DDoS）攻击，并且据称有用且友好的设备已侵犯其隐私并暴露其用户的个人信息。

　　我相信这些设备的开发人员和制造商正在关注，因此，他们可能会解决身份验证/授权，不安全的Web界面，不良的网络服务和加密等明显问题，以及在发现安全性或其他缺陷时无法更新软件。我担心的是，他们没有对传统计算行业发现的艰难发现给予足够的关注。

　　一旦简单而明显的安全漏洞得到纠正，作恶者将转向其他攻击面。计算机制造商必须处理的这些其他漏洞无疑将成为物联网黑客的下一个目标。本文重点介绍系统启动/固件以及该空间中物联网设备的潜在安全问题。最重要的是，如何处理它们。

　　为什么物联网固件是一个问题

　　物联网生态系统中的许多人似乎认为他们的设备是简单，一次性的一次性设备，例如您运送和忘记的基本设备或嵌入式系统。随着越来越多的物联网设备不断被开发，这种看法是有问题的。

　　根据定义，物联网设备是互联网连接的。这意味着网络堆栈，通信协议，设备和云中的应用程序可以利用设备提供的数据以及这种连接所暗示的所有攻击。这种连接性使这些设备成为理想的目标，任何安全漏洞都为攻击者打开了大门。

　　由于物联网设备的复杂性和范围，在大多数情况下，它们必须在现场进行更新。这些设备的数量及其使用模式驱动更新功能自动和远程启动。这为那些改变他们的软件来改变他们的行为的人提供了另一个攻击媒介。

　　这种攻击媒介并不是一个新现象。自互联网出现以来，网络连接的计算机系统一直在处理它们。问题在于，物联网设备的开发人员已经将他们的小工具视为简单，单一用途的设备，不易受到恶意行为的影响，因此不容易受到攻击。好吧，事实证明恰恰相反。坏人可以窃取用户的数据，使用设备监视用户防火墙内的网络基础设施，或者将设备用作攻击其他系统的启动平台。

　　该怎么办

　　从根本上说，物联网设备的软件/固件必须受到保护，就像在通用计算机系统中必须保护代码一样。这包括初始化设备硬件，加载和启动设备软件（系统和应用程序）的固件和软件，以及更新物联网设备固件和软件的过程。

　　平台固件和启动安全性

　　自计算早期以来，已经创建了平台固件来初始化系统硬件并加载初始软件。对于传统计算平台，该软件通常是从磁盘加载的操作系统，但即使在没有传统操作系统的嵌入式平台上，软件通常也从缓慢的非易失性存储加载到更快的RAM内存中以进行正常操作。当 IBM 创建他们的 PC 时，他们为此任务开发了称为 BIOS（基本输入/输出系统）的固件。这个原始的BIOS被克隆并在许多平台上使用;然而，随着计算系统变得越来越复杂，处理器很难模仿1970年代PC的行为;一个新的标准诞生了。虽然简单的嵌入式和 SoC 系统转向了 U-Boot 和核心引导等单片解决方案，但大多数大型和通用系统都遵循 UEFI 标准。

　　可扩展固件接口 （EFI） 设计最初是由英特尔为新一代处理器创建的，消除了 BIOS 的大部分架构限制。英特尔试图将EFI作为整个行业BIOS的一般替代品，但由于它由单个主要行业参与者“拥有”，因此对这个想法有一些抵制。相反，英特尔为行业贡献了设计，并帮助建立了统一可扩展固件接口（UEFI）论坛来管理未来的架构。今天，UEFI论坛由300多家公司组成，负责UEFI标准的开发和演变。

　　UEFI论坛采取的举措之一是系统启动时的安全性，并且不可避免地需要更新其固件/软件。已经表明，如果攻击者可以在系统启动和启动过程中获得对系统的控制，他们可以完全“拥有”该系统发生的情况。最终，攻击者可以在启动后禁用软件中提供的保护，并加载他们选择的任何其他程序。此外，他们甚至可以在启动之前就修改普通软件以完成其投标。如果坏人能够尽早控制系统，那么该系统可能会完全受到损害。

　　如果代码更新过程遭到破坏，情况也是如此。如果黑客创建自己的代码并将其与系统制造商最初提供的代码交换，则上面列出的所有坏事也可以在系统更新受损的系统中完成。

　　UEFI 规范提供了标准接口描述和旨在显著限制此类威胁的体系结构。用于保护系统免受这些威胁的两种主要技术是：

　　安全启动 – 要求对系统的所有软件组件进行加密签名，否则将不允许它们运行。这可以防止在系统启动期间运行受损的组件，从而维护可以一直延续到应用程序软件本身的信任根。

　　胶囊更新 - 这要求所有系统更新都以加密方式签名，并提供工具以确保系统固件/软件无法回滚到安全性较低的版本。

　　UEFI 是唯一将这些安全功能作为其行业标准的一部分的固件解决方案。此外，虽然许多安全研究人员和黑客一直在测试其设计，但没有人能够发现安全架构中的任何缺陷。一些实现存在缺陷，但不是设计。

　　UEFI 还提供了更多与安全相关的功能，但它们超出了本文的范围。我建议您访问 http://www.uefi.org 网站，了解规格、白皮书和培训材料。

　　那么，为什么不是每个人都使用 UEFI 固件呢？

　　如果UEFI架构为这些安全威胁提供了“解决方案”，为什么不是每个人都使用它？我相信有几个主要原因：

　　许多物联网开发人员来自嵌入式/SoC领域，其中整体式启动解决方案很普遍。尽管U-Boot和核心引导等解决方案存在局限性，但开发人员倾向于使用他们知道并且感到满意的内容。

　　关于UEFI固件存在许多误解和“替代事实”，这些事实限制了它在某些社区中的接受程度。这些误解的例子是：它太慢了;它太大了;架构太复杂;它不是“开放的”等。这些在 uefi.org 网站上的UEFI白皮书中在很大程度上被揭穿了。

　　我该何去何从？

　　因此，我希望我已经说服您至少考虑将UEFI作为下一个物联网设备的固件设计替代方案。如何开始？

　　下载最新的 UEFI 规范并尝试阅读封面以涵盖它可能不是最好的开始方式。首先，UEFI 是一个接口规范，而不是一个实现。该规范支持许多设备中可能不需要的功能，并且该规范的大小乍一看似乎令人生畏（2000 多页！只有少数基本功能需要符合规范，您可以根据需要从其他功能中进行选择。uefi.org 网站上有许多教育材料，书籍和演示文稿。

　　作为接口规范，它不驱动所描述的服务的实际代码实现。Tianocore.org 提供了一个开源示例实施，以及不错的文档，其中包括多个英特尔参考平台的完整实施以及可用于为其他平台创建解决方案的代码。还有针对 ARM 处理器和平台的绑定，ARM 人员提供了一个文档，描述了基于 ARM 的设备上对 UEFI 的要求。我甚至听说在底层核心引导代码库上分层的UEFI接口的实现。完全取决于您的实现是什么样的，以及需要和实现哪些功能。

　　有几家独立的固件供应商很乐意帮助你为设备创建自定义 UEFI 实现。

　　底线

　　物联网设备是真正的网络连接计算设备，具有所有伴随的风险。安全性较弱的物联网设备不仅会危及设备本身及其数据，还会危及本地网络和整个互联网中的其他设备。随着这些设备的创建者修复了某些设备显示的明显安全限制，坏人将寻找其他攻击媒介。这些攻击面将包括攻击设备固件和软件更新机制。为了让您的客户和其他利益相关者满意，您应该考虑为 IoT 设备实现 UEFI。

　　审核编辑：郭婷