传感器设备威胁模型
本文档描述 IoT 传感器设备的威胁模型。清晰阐明威胁模型有助于指导开发工作，也可用于帮助确定这些工作的优先级。
此设备包含某种类型的传感器（例如温度传感器或管道中的压力传感器），并将数据发送到运行微控制器的 SoC。该微控制器连接到云服务，并将传感器数据转发给该服务。云服务还可以向设备发送配置数据以及软件更新镜像。总体示意图见图 1：
在此传感器设备中，传感器通过 SPI 总线与 SoC 连接，SoC 具有用于与云服务通信的网络接口。这些接口的具体特性可能会以意想不到的方式影响威胁模型，因此需要考虑各种变体（例如，使用通过某种总线连接的独立网络接口 SoC）。
该模型还侧重于通过 MQTT-over-TLS 协议进行通信，因为这似乎已被广泛使用 [1]。
资产
威胁模型需要考虑的一个方面是设备运行中涉及的资产。以下列表列举了本模型中包含的资产：
引导加载程序：这是包含在设备端闪存中的小型代码/数据镜像，是首先运行的代码。为了建立信任根，此镜像必须不可变。本模型假设 SoC 提供了一种保护闪存某个区域免受后续写入的机制，并且会在生产早期将该镜像烧录到设备后执行此保护 [th-imboot]。
应用固件镜像：此资产由微控制器运行的固件其余部分组成。之所以作出这种区分，是因为当发现安全漏洞时，镜像的这一部分需要定期更新。对此镜像更新的要求包括：
镜像只能替换为已授权的镜像 [th-authrepl]。
当有已授权的替换镜像可用时，应及时完成更新 [th-timely-update]。
镜像更新应被视为原子操作，这意味着当镜像运行时，闪存中应完整包含更新后的镜像，或完整包含旧镜像 [th-atomic-update]。
根证书列表：为了对云服务（服务器）进行身份验证，IoT 设备必须具有允许为该服务器证书签名的根证书列表。对于基于云提供商的服务，此列表通常由服务提供商提供。由于根证书可能过期，也可能被撤销，因此需要定期更新此列表 [th-root-certs] 和 [th-root-check]。
客户端密钥：为了向服务验证客户端身份，客户端必须持有某种密钥。这通常是私钥，一般是 RSA 密钥或 EC 私钥。在与服务器建立通信时，设备会将此密钥用作 TLS 建立过程的一部分，或用它签署通信中使用的消息。
此密钥通常由服务提供商或其他位置运行的软件生成，并且必须安全地安装到设备上。策略可能要求定期更换此密钥，这就需要一种更新客户端密钥的方法。通常，服务会允许同时存在两个或三个有效密钥，以便在旧密钥仍在使用时完成此更新。
必须保护这些密钥不被读取，并且只有尽可能少的必要代码才能访问它们 [th-secret-storage]。
当前日期/时间：TLS 证书验证需要知道当前日期和时间，以确定当前时间是否处于证书的有效期内。此外，基于令牌的客户端身份验证通常要求客户端签署一条包含令牌有效时间窗口的消息。证书验证要求设备对日期和时间的认知准确到大约一天以内。令牌生成通常要求时间准确到 5-10 分钟以内。
可以通过查询外部时间服务器来近似获得安全时间。安全 NTP 可能超出 IoT 设备的能力范围。时间不正确的主要风险是拒绝服务（设备拒绝有效证书），以及生成时间无效的令牌。攻击者有可能诱使设备生成在未来有效的令牌，但攻击者还必须伪造服务器证书才能拦截这些令牌 [th-time]。
传感器数据：从传感器本身接收并发送到服务的数据应无修改、无篡改地传输。
设备配置：设备需要保存各种配置数据，例如要连接的服务的 hostname、时间服务器的地址、向服务发送传感器数据的频率和参数等。随着配置变化，这些配置数据需要定期更新。只应允许来自已授权方的更新 [th-conf]。
日志：为了协助分析安全问题，设备应记录与安全相关的事件信息。IoT 设备通常存储空间有限，因此需要仔细选择要记录的日志。也可以将这些日志事件发送到云服务，以便存储在资源更充足的环境中。应记录的事件类型包括：
固件镜像更新：系统应记录新镜像的下载以及镜像成功更新的时间。
客户端密钥变更：应记录客户端密钥的变更和新密钥。
设备配置变更。
通信
除资产外，威胁模型还考虑系统各实体之间传输数据或资产的位置。
闪存内容：闪存设备包含多个区域。闪存内容可由 SoC 的 CPU 通过编程方式修改。
引导加载程序：如资产部分所述，引导加载程序是闪存设备中包含初始运行代码的一小部分。应在设备生命周期的早期写入此部分，然后将闪存设备配置为永久禁止修改此部分。此配置还应防止通过 JTAG 或 SWD 调试器等外部接口进行修改。
引导加载程序负责验证应用镜像的签名，并在需要更新时根据更新镜像更新应用镜像。
引导加载程序在安装更新镜像之前应验证其签名。
引导加载程序只能接受版本号比当前镜像更新的更新镜像。
应用镜像：应用镜像包含设备正常运行期间执行的代码。在运行此镜像之前，引导加载程序应验证镜像的数字签名，以避免运行被篡改的镜像。闪存/系统应配置为在引导加载程序完成后，CPU 无法写入应用镜像。
更新镜像：这是闪存中用于保存新版应用镜像的区域。应用会在正常运行期间下载并存储此镜像。完成下载后，应用可以触发重启，引导加载程序即可安装新镜像。
密钥存储：闪存中的某个区域将用于存储客户端密钥。此区域由应用镜像的一个子集进行读写。应将应用配置为保护此区域，防止不需要访问它的代码进行读取和写入，并考虑应用大部分代码中可能存在的漏洞。泄露密钥内容会使攻击者能够假冒此设备。
初始密钥应在配置活动中写入设备，该活动与设备正常运行不同。后续更新可以在通过安全通道接收的服务通信指示下进行。
配置存储：应有一个区域用于存储其他配置信息。在资源受限的设备上，允许将其与密钥存储放在同一区域，但这会增加可访问密钥存储区域的代码量，因此需要审查更多代码。
日志存储：设备可以有一块闪存区域用于写入日志事件。
传感器/执行器接口：在本设计中，传感器或执行器通过 SPI 等总线与 SoC 通信。硬件设计应使攻击者难以拦截此总线。所需技术取决于传感器数据的敏感性和用途，范围从将传感器安装在 MCU 所在的同一块 PCB 上，到用环氧树脂灌封整个设备。
与云服务的通信：设备与云服务之间的通信将通过公共互联网进行。因此，应假设攻击者可以任意拦截此通道，例如返回伪造的 DNS 结果，或针对与云服务的通信发起中间人攻击。
设备与云服务的所有通信都应使用 TLS [th-all-tls]。TLS 协议栈应配置为仅使用通常认为安全的密码套件 [2]，包括前向保密。通信应通过以下方式加以保护：
密码套件选择：设备只应允许使用公认安全的密码套件进行通信 [th-tls-ciphers]。
服务器证书验证：应验证服务器提供的证书 [th-root-check]。
客户端身份验证：客户端应使用只有该特定设备知道的密钥向服务验证自身身份。有多种可选方式，所采用的技术通常由所使用的特定服务提供商规定 [th-tls-client-auth]。
TLS 客户端证书：TLS 协议允许客户端提供证书，并声明其知道该证书所描述的密钥。通常，这些证书将存储在服务提供商处。这些证书可以是自签名的，也可以由 CA 签名。由于服务提供商会维护有效证书列表（并将其映射到设备身份），让这些证书由 CA 签名不会增加额外的安全性，但可能有助于管理这些证书。
基于令牌的身份验证：客户端也可以使用 MQTT CONNECT 数据包的 password 字段来验证自身身份。但是，密钥本身不得在此数据包中传输。而应使用基于令牌的协议，例如 RFC 7519 中定义的 JSON Web Token (JWT)。这些令牌通常有效期较短（例如 1 小时），以防止被拦截后被重用。在设备验证服务器身份之前，不得发送令牌。
随机数/熵源：密码通信需要生成安全伪随机数。设备应使用现代且公认的密码随机位生成器来生成这些随机数。它应使用 SoC 内以硬件实现的非确定性随机位生成器（真 RBG），或使用由 SoC 内熵源播种的确定性随机位生成器（伪 RBG）。有关已批准的 RBG 的信息，请参见 NIST SP 800-90A；有关测试设备熵源的信息，请参见 NIST SP 800-90B [th-entropy]。
与时间服务的通信：理想情况下，设备应包含维护安全时间的硬件。但是，大多数在用的 SoC 不支持此功能，因此有必要查询外部时间服务。有关此协议，请参见 RFC 4330 及引用的 RFC，其中描述了可用于从网络时间服务器查询当前时间的简单网络时间协议。
设备生命周期：IoT 设备将经历从生产到销毁和处置的生命周期。此生命周期中影响安全的方面包括初始配置、正常运行、重新配置和销毁。
初始配置：在初始配置阶段，需要烧录引导加载程序、初始应用镜像、设备密钥和初始配置数据 [th-initial-provision]。此外，还应安装引导加载程序的闪存保护。在这些信息中，只有设备密钥需要因设备而异。此密钥应得到安全保管，并在烧录完成后销毁设备外部的所有副本 [th-initial-secret]。
正常运行：正常运行包括本文档其余部分描述的行为。
重新配置：有时需要重新配置设备，例如用于不同的应用。一种方法是保留相同的设备密钥，并替换配置数据以及与该设备关联的云服务数据。也可以烧录新的设备密钥，但如果这样做，必须安全地进行，并在新密钥烧录到设备后销毁外部副本 [th-reprovision]。
销毁：为防止设备密钥被用于假冒设备，在设备退役时，应使该特定设备的密钥失效 [th-destruction]。可能的做法包括：
对设备进行硬件销毁。
安全擦除包含密钥的闪存区域 [3]。
从服务中移除设备身份和证书。
其他考虑事项
除上述内容外，联网设备通常需要一种配置方式，使其连接到所在网络环境。实现方式有很多，重要的是这些配置方法不得绕过上述安全要求。
威胁
必须使用不可变的引导加载程序启动。
应用镜像只能替换为已授权的镜像。
应用更新应及时完成。
应用更新应是原子操作。
TLS 必须具有受信任根证书列表。
必须有一种安全存储客户端密钥的机制。只有尽可能少的必要代码才能访问这些密钥。
系统必须对当前日期/时间有中等准确的认知。
系统必须接收并保存配置数据。
系统必须记录安全相关事件，并将其存储在本地或发送到服务。
与云服务的所有通信都应使用 TLS。
TLS 应配置为仅允许公认的密码套件（包括前向保密）。
设备应使用所述方法之一向云提供商验证自身身份。
TLS 层应使用由 SoC 内熵源播种的现代且公认的密码随机位生成器。
设备在部署前应加载每设备专属密钥。
初始密钥应得到安全保管，并在设备完成配置后尽快销毁所有外部位置的副本。
重新配置设备应安全地进行。
设备退役时，应使设备密钥失效。