研究背景与问题

现有方案局限

• 远程证明（RA）的局限：传统 RA 依赖中心验证器，存在单点故障，无法应对 Pub-Sub 网络的异步通信、睡眠设备（如电池供电设备周期性断开）和恶意代理攻击（如 DoS）。
• 现有方案不足：多数方案需同步通信和时间同步，计算 / 通信开销高，不支持动态设备（如 LegIoT 仅支持 1000 节点）

一个典型的方案：cRA

Collective Remote Attestation (cRA，集体远程证明) 是一种针对大规模物联网（IoT）设备的安全机制，用于批量验证多个远程设备（证明者）的可信状态，解决传统一对一远程证明（RA）在设备数量增长时的效率低下和资源浪费问题。

• 场景：适用于物联网中需要同时验证数十、数百甚至数万设备的场景，例如智能城市中的传感器网络、工业物联网中的设备集群等。

• 两类模式： 根据验证者与证明者的交互模式，cRA 可分为两类

  • (1) 一到多（One-to-Many）cRA
    • 特点：单个可信验证者批量验证多个证明者，通常采用树状拓扑（如根验证者→子节点→叶节点）聚合证明结果。
    • 代表方案：SEDA、LISA、SeED 等。
    • 缺陷：
      • 单点故障：依赖中央验证者，若其被攻击则整个系统失效。
      • 同步通信假设：要求所有设备在验证期间保持在线并同步响应，无法适应睡眠设备（如电池供电设备周期性断开）或动态网络拓扑。
      • 缺乏按需验证：只能批量验证整个网络，无法单独验证某个设备的状态。
      • 它们不适用于证明者由不同实体控制的场景
  • (2) 多到多（Many-to-Many）cRA
    • 特点：设备可同时担任证明者和验证者，通过分布式交互实现互信（如 P2P 网络）。
    • 代表方案：LegIoT、PASTA、SAFEd 等。
    • 缺陷：
      • 扩展性差：随着设备数量增加，分布式验证的通信和计算开销呈指数级增长（如 LegIoT 仅支持约 1000 节点）。
      • 信任假设强：部分方案依赖可信第三方或固定网络结构，不适用于多方互疑的物联网场景。

Pub/Sub 物联网网络

本节介绍了发布 / 订阅（Pub/Sub）网络模型在物联网中的应用，阐述其架构特点及适用于动态环境的原因。

1. Pub/Sub 协议的适用性
   • 动态环境适配：Pub/Sub 协议能够容忍通信中断和延迟，因此非常适合物联网中设备频繁加入 / 离开、网络拓扑动态变化的场景（如智能城市、工业物联网）。
   • 异步通信优势：无需设备间直接连接或同步在线，降低了对实时性的依赖，符合物联网设备（如传感器）的低功耗、间歇性通信需求。
2. Pub/Sub 网络的三大实体
   • 发布者（Publishers）：生成数据的设备（如温度传感器、摄像头），通过代理发布特定主题（Topic）的消息（如 “温度数据”“视频流”）。
   • 订阅者（Subscribers）：请求特定主题数据的设备或系统（如数据分析平台、用户终端），通过代理获取感兴趣的消息。
   • 代理（Brokers）：
     • 中间枢纽：负责接收发布者的消息，根据主题过滤和存储，并推送给对应的订阅者。
     • 解耦作用：发布者与订阅者无需知道彼此的存在或地址，通过代理间接通信，简化了网络复杂度。
3. 通信流程示例
   • 发布者连接到代理，声明要发布的主题（如 “room/temp”）并发送消息；
   • 订阅者向代理订阅主题（如 “room/temp”）；
   • 代理在接收到发布者的消息后，将其分发至所有订阅该主题的订阅者。
4. 关键特性
   • 异步性：发布者与订阅者的交互非实时，支持离线消息存储和延迟获取；
   • 拓扑透明性：设备无需感知网络拓扑，只需通过主题通信，提升了网络扩展性；
   • 松耦合：发布者和订阅者可独立升级或更换，不影响整体系统运行。

     挑战

     CH1：异步通信导致传统 cRA 机制失效

• 核心矛盾：
  传统 cRA 依赖同步挑战 - 响应模式（验证者主动发送挑战，证明者实时回复），但 Pub/Sub 网络中发布者与订阅者完全解耦，无直接连接，验证者无法直接向证明者发起请求。

• 具体影响：

  1. 状态不可知：Pub/Sub 设备仅通过主题通信，无法获取对方实时在线状态或身份，而传统 cRA 需验证者知晓证明者是否可通信；
  2. 拓扑动态性：网络拓扑实时变化（如设备移动、断连），传统 cRA 依赖的固定连接（如树状结构、P2P 网络）无法适应，导致验证请求路由失败；
  3. 同步机制失效：现有方案（如 SEDA、LegIoT）要求设备在验证期间持续在线，Pub/Sub 的异步特性使 “一次性全网验证” 不可行。

     CH2：睡眠设备与断连导致验证请求积压

• 场景痛点：
  电池供电设备（如传感器）为节能定期进入睡眠模式，或因网络故障临时断连，导致验证请求在代理处积压。

• 具体影响：
  1. 资源浪费：设备唤醒后需处理大量历史请求，重复执行高耗能的证明计算（如哈希、签名），加速电池损耗，甚至延迟正常数据采集任务；
  2. 响应延迟：积压请求可能因超时失效，导致验证结果滞后，无法及时检测设备是否被攻陷；
  3. 协议不兼容：传统 cRA 假设设备始终在线（如 DARPA 要求心跳机制），无法处理 “离线 - 唤醒” 周期中的状态验证。

CH3：恶意代理引发分布式拒绝服务（DDoS）攻击

• 风险来源：
  Pub/Sub 代理多为第三方服务，可能被攻击者控制，向证明者发送大量伪造验证请求（如数千次虚假挑战）。
• 技术难点：
  1. 无差别攻击：恶意代理利用 Pub/Sub 的广播特性，向多个证明者批量发送伪造请求，耗尽设备计算资源（如低端 MCU 的 CPU 时间）；
  2. 密钥管理困境：传统对称加密需代理与设备共享密钥，但动态大规模网络中密钥分发复杂，且代理不可信时密钥易泄露；
  3. 攻击隐蔽性：伪造请求看似合法（如伪装成订阅者的验证需求），难以通过简单过滤机制识别。

SCRAPS 核心设计

• 目标：实现可扩展、异步、支持睡眠设备的集体远程证明（cRA）。
• 角色
  • 制造商：生产可信传感设备，并在区块链上部署制造商合约
  • 传感器（证明者）：定期向代理验证者提交自身状态；- 内置信任锚（如硬件安全模块或软件安全微 visor），确保证明过程不可篡改。
  • 验证者：通过查询区块链上的代理验证器获取传感器的可信状态（如 “可信”“不可信”）。
  • 代理验证器（ProxyVerifier）
    • 基于区块链智能合约的不可信第三方，代表验证者执行证明逻辑。
• 关键组件
  • 代理验证器：基于区块链的智能合约，作为不可信第三方，代理验证者收集证明证据，实现 “一到多” 逻辑拓扑，支持 “多到多” 查询。
  • 制造商智能合约：存储设备可信配置（如参考测量值 M、证明类型 RA_type、可靠性函数 F_rel (t)）。
• 工作流程
  • 预部署：制造商部署智能合约，管理员部署代理验证器合约。
  • 运行阶段
    • 注册：证明者（发布者）用公钥注册到区块链。
    • 证明：证明者主动向代理验证器提交包含区块 ID 的签名证据，代理验证器通过制造商合约验证证据有效性。
      • 传感器（证明者）周期性唤醒，计算当前内存状态的哈希值（Meas），并使用私钥对哈希值和区块链最新区块 ID签名，生成证明证据（AttestTX）；
      • 通过不可信代理（Broker）将 AttestTX 提交至代理验证器；
      • 代理验证器从制造商合约获取该设备的可信哈希值M，对比 Meas 是否一致，并通过区块 ID 验证时间有效性（如$(t \leq T_{min})$时视为完全可信）。
    • 查询：验证者（订阅者）查询代理验证器获取证明者状态（如 “可信”“不可信”“待证明”）。
• 用例case
  • 发布者：空气质量检测设备
  • 订阅者：研究机构

攻击模型

• 敌手能力
  • 窃听（eavesdrop）：可拦截并读取网络中的任何消息
  • 篡改（alter）：修改传输中的消息内容
  • 伪造（concoct）：生成并注入虚假消息
  • 拒绝服务（DoS）：干扰或阻断正常通信
• 信任假设
  • 代理验证器（ProxyVerifier）继承底层区块链的安全性
  • 成功证明后的 Tmin 时间内，设备被视为可信状态