论文阅读：Things, Trouble, Trust: On Building Trust in IoT Systems

摘要

物联网目前面临着很多大量的安全和隐私挑战，其中一个突出的问题是如何在远程的IoT设备上建立可信。针对这个问题一个典型的方案是利用远程证实，远程证实是一个不同的安全服务，目的在于弄清一个可能被攻击到的远程设备的当前状态。远程证实覆盖了从重量级的基于硬件的安全技术，到相对轻量级的基于软件的技术范围，也包括了一些混杂了软件（控制流完整性）、以及硬件特征（PUFs）等的技术。本文从IoT的视角上调研了艺术级的证实技术的landscape，并且说明其中的大多数方案将在IoT可信建立中担任重要的角色。

介绍

IoT一个重要的特征在于它包括了大量了低成本的、资源受限的设备，大量的设备引起的这些约束导致了重要的安全和隐私挑战。一个重要的挑战在于面对恶意软件的脆弱性。尽管恶意软件不是一个新的威胁，IoT却加宽、放大了攻击表面。这些威胁清晰的催发了验证远程IoT设备是否处于一个预料之中的状态。
本文两个主要目标：

• 提供一个对在IoT中完成证实的overview
• 展示多种类型的证实能够适应这种环境设定

证实可以分为这两个方面：

• 获取prover的当前状态的进程（度量进程）
• 将证据传输给verifier的协议

威胁模型：

最普遍的威胁模型是一个受到攻击的prover想要谎报当前状态给verifier，对应有很多种敌手类型：

• 远程敌手：利用恶意软件远程影响prover
• 本地敌手：偷听、妨碍prover的通信过程
• 物理非侵入式敌手：能够执行侧信道攻击
• 秘密的物理侵入式敌手：能够物理地抓取prover存储的任何信息
• 物理侵入式敌手：除了物理抓取prover存储的任何信息外，还能够修改状态或者硬件组件

当代的针对于IoT设备的研究聚焦于如何减轻远程敌手的威胁。这主要有三个原因：

• 最普遍的类型，由于来源于远程，最容易防卫
• 潜在攻击范围最大
• IoT设备不能承受安全硬件的开销

证实方式

基于安全硬件的证实

基于TPM的证实除了对物理侵入式敌手外，其他都能防御

1. 动态可信根

   基于TPM的证实一个很大缺点在于：TPM Quote时有着潜在的大量的度量值，这使得验证一个quote极耗时间。动态可信根DRTM就是用来解决这个问题。DRTM允许度量从用户指定的任何点开始。在DRTM启动之后，平台将执行一个局部的CPU重置，重置PCR的子集到一个初始状态。

2. 基于SGX的证实

   对DRTM的概念进行扩展，SGX为应用程序软件提供了一个硬件加强的隔离执行环境。Enclave隔离并且保护程序内容，避免被其他软件干扰，并且提供了enclave之间或者与远程的证实方式。

3. 基于属性的证实

   之前提到的几种方式均属于二进制证实，因为证实证据基于软件二进制。二进制的证实方式是很脆弱的，任何配置的改变或者软件升级将会导致不同的二进制hash值，即使prover依旧是处于一个可信的状态。验证者因此要求维护一个所有可信值的列表。为了减轻这个约束的影响，基于属性的证实方式将二进制度量转换为对于系统属性的一些陈述。

基于硬件的证实方式要求有一个明确的可信anchors，比如TPM或者SGX功能的CPU。然而，由于成本以及复杂性的考虑，IoT系统基本不可能拥有这些trust anchors.

基于软件的证实方式

基于软件的方式没有硬件可信根，因而，不能假设prover上有安全的地方来保存secrets，也不能依赖于prover执行了可信的代码。相反，基于软件的证实方式利用侧信道信息，比如说执行某个特定计算prover所需要的时间。

许多文献里研究了基于软件的证实方式，Pioneer使用一个函数计算了设备的内存的校验值，这种方式会有运行时的反作用，因为这个函数的每次使用带来了额外的时间消耗，比如说延迟。基于时间的校验值也应该被应用到嵌入式设备中，然而也存在许多脆弱点。
通常来说，所有现有的基于软件的证实技术对敌手能力作出了很强的假设，也仅仅在verifier与prover直接通信的情况下才有效。这是因为：

• Multi-hop必然会导致来回传输的延迟，对于任何基于时间的度量都会引入误差
• Verifier必须能够检测到本地敌手的攻击，以防其与被攻击的prover合谋。

如果能够保证这两点，基于软件的证实方式同样能够应对上面提到的所有敌手模型。值得注意的是，基于软件证实在网络环境中不可行。

混合证实

为了克服软件证实带来的限制，大量混合证实方案被提出。混合证实的目标在于，在最小修改硬件的情况下能够应对除了物理侵入式敌手外的所有类型敌手，而且是在网络环境中。

最小化可信anchors

SMART架构为低端设备提供了动态可信根，没有指定特殊的内存管理或者保护特征。SMART架构有四个组件：

• 在ROM中的一个证实只读内存代码区域
• ROM中保存的一个只能被SMART访问的密钥存储区域
• MCU访问控制，使得非SMART不能访问安全密钥存储以及中断SMART代码执行
• 如果这些组件有报错，则进行重置与内存擦除

对于verifier来说，ROM中的证实代码会计算prover的内存的校验值，并返回给verifier。

TrustLite是低端嵌入式系统中的一个普遍的安全架构，允许一些特殊软件模块（trustlets）与OS独立的隔离。TrustLite给出了EAMPU（执行感知的内存保护单元）作为内存保护。EAMPU确定只有trustlet的代码能够访问trustlet内容。

TyTAN通过允许在运行时动态加载与卸载应用程序、实时调度保证与安全的IPC等提供了更灵活地架构。

基于PUF的证实

基于软件证实方式要求prover与verifier直接相连，也不能验证底层硬件。而对于SMART、TrustLite而言，如果考虑到物理敌手，由于能够直接获取到prover的key，敌手很容易来伪造或者克隆prover。
PUF（Physically Unclonable Function）是一个特殊的物理结构，能够利用芯片制造商的侧信道，根据每个输入生成一个唯一的与硬件相关的输出。PUF能够将正式绑定到一个特定prover的指定硬件上，因而可以在混合证实进行利用以替换掉访问受限的设备密钥。

然而，环境对于PUF的影响较大，比如说电力供应波动等。PUF要求：

• 一个低成本、低消耗的PUF的注册过程
• 维护一个很大的PUF数据库

基于控制流图的证实

代码的可信还包括运行时行为，静态的证实方案只考虑二进制代码的可信而忽略他们的运行时，从而不能检测到劫持程序使得软件崩溃的控制流，而敌手可以修改堆栈来转移控制流。有论文中给出了使用代码重用技术的内存攻击方式，在不用注入恶意代码的情况下，使得良性代码带上恶意程序。

本文作者尝试着在嵌入式设备上提供一个运行时的证实机制，该机制能够提供对程序执行路径精确的证实。程序的执行路径能够被加密成执行指令的分支、或者是累积哈希。在这两种情况中，执行路径都可以被认为是软件执行的指纹。

运行时证实相对于其他运行时防卫技术有一些优势，比如说控制流图完整性（CFI）。CFI强制实施以确保没有违背控制流情况发生，而运行时证实将报告执行的控制流。

挑战

• 能够处理大量的IoT设备
• 处理异构设备
• 嵌入式设备资源受限

可扩展性

大多数论文聚焦于一个prover与一个verifier，事实是有很多情况要求一个verifier证实一个prover组（集群）。

第一个尝试解决集群证实的论文是SEDA: Scalable Embedded Device Attestation。对应的两点要求是：1）能够提供一个比对每个节点进行证实更有效的方式来证实一个集群，2）与现有的完整性证实方案独立。

初始化阶段：D8加入集群，对所有邻居进行join协议，这将与每个邻居建立一对证实密钥。

证实的原则是递归进行。Verifier选择一个节点，如D1，发送一个nonce，D1产生一个会话标识q。通过attdev协议，D1将证实请求（N，q）发送给所有邻居，等待回复，以此类推，从而形成一个以D1为根的树，证实报告将从叶子节点汇聚到根节点。

prover的视角

真实环境中，敌手可能扮演成verifier，形成对prover的未认证的证实，从而进行DDoS攻击。