DICE标准如何为物联网设备提供强大的安全性

自物联网问世以来，人们一直担心安全漏洞。例如，在题为“物联网：互联世界中的隐私和安全”的报告中，联邦贸易委员会指出，“物联网设备可能会带来各种潜在的安全风险，这些风险可能会被利用来伤害消费者：(1)允许未经授权访问和滥用个人信息；(2) 促进对其他系统的攻击；(3) 制造安全风险。” 为了减轻此类安全问题，物联网设备的设计需要具有强大的安全性。

传感器节点等物联网端点通常对成本敏感，并且通常使用资源受限的无线微控制器 (MCU)。换句话说，它们有限的片上内存和安全功能可能会阻止在桌面或服务器环境中使用某些安全标准。为了提供专门针对资源受限设备的安全标准，创建开放标准和规范以在从 IoT 端点到云服务器的设备中实现更安全计算的 Trusted Computing Group 开发了设备身份组合引擎 (DICE) 标准。

在本文中，我将探讨 DICE 标准的目标是什么以及它是如何工作的，包括服务器端需要什么来利用 DICE 的功能。

DICE 标准的核心目标

DICE 标准旨在通过以下方式增强物联网设备的安全性：

保护设备身份。物联网设备通常通过加密密钥进行身份验证。如果攻击者能够发现此密钥的价值，他们就可以轻松冒充物联网设备。DICE 可以创建设备身份，该身份可以很好地防止未经授权的访问。

远程重新配置。如果物联网设备确实因恶意软件或发现私钥而受到威胁，则必须能够远程更新应用程序固件映像和/或重新加密物联网设备。DICE 使 IoT 供应商能够通过向其推送新映像来恢复 IoT 设备，从而自动生成新的传输层安全 (TLS) 客户端证书链。

远程软件证明。为了获得最佳性能和安全性，物联网应用程序必须确认所有连接的物联网设备都在运行正确且最新版本的应用程序固件。DICE 在 TLS 证书中包含固件映像测量值（例如哈希）和版本号等证明信息，使 IoT 服务器能够验证 IoT 设备上运行的映像是否正确。

保护静态数据并不是 DICE 的主要关注点，因为典型的物联网设备（例如湿度或温度传感器）不会处理对黑客特别敏感或有价值的数据。但是，DICE 确实支持包装密钥的概念，它是一种对称密钥，用于加密需要持久保存的重要数据，例如加密密钥或设备配置。

除了其安全目标之外，DICE 标准还旨在最大限度地减少实现其安全性所需的资源。DICE 需要基于硬件的机密和限制未经授权的程序对其进行访问的机制。它使用 X.509 证书中的扩展在 IoT 设备和服务器之间交换身份和证明数据。由于证书已经是物联网设备连接到服务器的标准 TLS 身份验证过程的一部分，因此这种实现的开销很小。为了适应物联网应用的不同性质并为开发人员提供灵活性，DICE 标准并未规定单一的实施方法，而是阐明了一组可以通过多种方式实现的设计原则。

将安全应用于物联网设备的另一个挑战是，了解最先进的安全技术所需的学习曲线非常重要。许多嵌入式开发人员缺乏设计安全系统的经验，如果项目出现延误，可能会导致产品安全目标的妥协。半导体供应商通常会为其特定的无线 MCU 实施 DICE 标准，从而简化在物联网设备设计中使用 DICE 所需的工作。

DICE 的工作原理

为了有效地支持资源受限的设备，DICE 标准避开了对复杂安全硬件的要求。它的主要要求是基于硬件的机密，然后用于逐步启动受信任的计算库。在无线 MCU 应用中，引导过程通常分为三个步骤，如图 1 所示。具有高级操作系统或可信执行环境的更复杂的系统将需要更多的引导步骤。在本文中，我将重点介绍典型无线 MCU 应用所需的启动步骤。

图 1：启用 DICE 的 MCU 在使用自签名证书时如何启动应用程序：前两个阶段侧重于 DICE 相关功能以最大程度地降低复杂性，而第三阶段则启动主 MCU 应用程序。（图片：德州仪器公司）点击图片查看大图。

第一个引导步骤会生成复合设备标识符 (CDI)。我将在此步骤中执行的软件和硬件称为 DICE 引擎。要生成 CDI，DICE 引擎需要唯一设备密钥 (UDS)。物联网设备制造商可以直接将 UDS 编程到硬件中。或者，DICE 引擎可以使用另一个安全的预编程唯一身份（例如密钥对）来导出它。

UDS 确实有一些额外的安全要求。只有 DICE 引擎可以访问 UDS，并且必须有适当的硬件支持 DICE 引擎才能在将控制权传递给下一个引导步骤之前锁定对 UDS 的访问。

为了导出 CDI，DICE 引擎测量在第二个引导步骤中运行的代码，通常通过单向安全散列，然后使用基于散列的消息身份验证代码 (HMAC) 函数将散列与 UDS 组合。一旦 CDI 计算完成，DICE 引擎就会擦除寄存器、缓存或内存中可能帮助攻击者推断 UDS 的任何数据。此时，DICE 引擎将控制权交给启动过程的第二步。

第二个引导步骤的初始作用是创建设备身份密钥对（称为 DeviceID）及其关联的证书。然后，此引导步骤会创建别名密钥对和关联的证书链。我将在第二个引导步骤中执行的软件称为第 0 层。为了保护 DICE 引擎和第 0 层免受攻击，DICE 标准要求 DICE 实现代码必须驻留在片上 ROM 中或需要签名固件从半导体供应商更新。

第 0 层从 CDI 派生 DeviceID 密钥对。要创建 DeviceID 证书，第 0 层遵循两个路径之一，具体取决于用户的配置。一种方法是创建自签名证书。另一种是创建证书签名请求 (CSR) 并使用适当的证书颁发机构 (CA) 在外部对其进行签名。DICE 标准要求外部签名操作必须在第 0 层之外执行，因为保持第 0 层简单且没有可利用的错误非常重要。

除了创建设备 ID 和证书链外，第 0 层还创建别名密钥对及其关联的证书。为了派生别名密钥对，第 0 层使用单向哈希通过测量第 1 层映像（实际应用程序固件映像）并将 FWID 与 CDI 结合来创建固件标识符 (FWID)。因此，别名密钥对值直接与应用程序固件映像相关。第 0 层使用 DeviceID 证书对 Alias 证书进行签名，从而将它们链接在一起。

DeviceID（及其相关证书）的目的是为设备的生命周期提供身份证明。为了保持 DeviceID 的高度安全，第 0 层会在启动过程的下一步开始之前擦除 DeviceID 私钥的任何痕迹。由于 DeviceID 私钥仅在启动过程中可用，基于 DICE 的物联网设备不需要更复杂的安全机制，例如可信执行环境来在一般应用程序执行期间保护 DeviceID。如果需要更新第 0 层，则 DeviceID 将需要更改，因为它的输入之一是第 0 层的哈希值。但是，第 0 层软件很简单，其目的是永远（或很少）更新它。

别名密钥对及其关联证书的目的是为物联网设备上运行的固件版本提供证明。与 DeviceID 不同，第 0 层将别名密钥对传递到启动过程的下一步——应用程序固件映像。然后，应用程序可以将此密钥对用作其他加密相关操作的基础，例如为数据密封创建新的密钥对。

IoT 设备使用 Alias 证书链与 IoT 服务器进行 TLS 客户端身份验证。由于 Alias 密钥对和证书直接与设备上运行的应用程序固件映像相关联，因此在 IoT 设备上安装新应用程序映像的无线 (OTA) 更新将产生新的 Alias 密钥对和证书. 这是 DICE 的一个非常强大的方面，因为它使物联网供应商能够通过向设备发送自动重新加密的新图像来将受损的物联网设备恢复到安全状态。

如前所述，DICE 使用 TLS 和 X.509 证书与服务器通信。因为几乎每个物联网设备最终都将通过 TLS 连接与物联网服务器进行通信（非 IP 设备将需要网关），这种方法本质上为物联网设备增加了最小的开销。为了协助身份和证明，DICE 为 X.509 证书添加了新的标准扩展，例如对象标识符 (OID) 和包含证明相关数据的附加字段，例如用于生成 FWID 和版本号的哈希函数。OID 使证书能够说明它是用于设备身份还是证明或两者兼而有之。

当物联网设备尝试连接到物联网网络时，除了标准的 TLS 身份验证协议外，物联网服务器还需要执行远程认证。远程证明涉及从证书中提取 FWID 并将其与物联网服务器期望在物联网设备上运行的图像的哈希值进行比较。因为运行在 IoT 服务器上的设备管理系统需要管理每个连接的 IoT 设备的软件更新，它应该已经知道 IoT 设备上正在运行的软件版本，并且可以访问相关的固件映像哈希。

物联网供应商不需要在物联网服务器或其他任何地方维护 UDS 值数据库。这进一步增强了基于 DICE 的物联网应用程序的安全性，因为它消除了通过使用成功渗透物联网供应商的企业信息技术系统的攻击来发现 UDS 值的可能性。

结论

DICE 标准使开发人员能够在低成本物联网设备中实现更有效的安全级别。DICE 可以提供安全、持久的身份和软件证明，使物联网服务器能够验证物联网设备是否运行正确的软件。DICE 还支持安全远程重新配置受感染的物联网设备。

物联网设备开发人员可以轻松采用 DICE 标准，因为它已经在无线 MCU 上预先实现，例如TI SimpleLinkWi-Fi CC323x。TI SimpleLink Wi-Fi CC323x 上的 DICE 实施使物联网设备供应商能够在制造过程中或在现场部署物联网设备时从外部签署 DICE 证书。

审核编辑：汤梓红