面向存储系统的隔离式时间防御（OSDI 2026）
原题：Timelock Drive: Isolated Time-Based Defense for Storage Systems
一句话总结：Timelock Drive（TD）把“写入后在一段时间内不可修改”的约束下沉到物理块和一个约 400 行、形式化验证的隔离检查器，将版本系统移出 TCB；借助主机侧不可信元数据缓存，原型在 SSD 上的执行和吞吐开销分别约为 0.4% 和 0.5%，但恢复需要扫描追加日志，且安全性依赖单调时钟、入侵时间可确定等前提。
问题与动机
备份和版本系统通常与被保护主机共享软件栈。获得管理员凭据或控制 OS、文件系统和备份软件后，攻击者可以删除旧版本、修改版本索引，或绕过版本系统中的保留策略。把时间锁逻辑放进版本系统并不能消除这类风险；论文指出，已有存储侧方案也可能被 trimming attack 绕过。
TD 的目标是把时间保护变成存储设备提供的原语：物理块写入并 timelock 后，即使主机软件和版本系统完全被攻陷，也不能在期限内修改它。版本系统只负责分配块、维护版本和回收空间，不进入 TD 的 TCB。
这个接口带来一个结构性矛盾。普通文件系统和版本系统会覆盖检查点、空闲空间表和版本索引；TD 却禁止覆盖任何仍处于 timelock 的块，包括它自己的元数据。论文因此同时解决两件事：构造不覆盖的 TD 元数据管理机制，以及在其上构造可恢复的安全版本系统。
关键观察 / 隐含假设
-
观察 1：时间保护必须独立于版本策略，才能让版本系统不进入 TCB。 论文第 2 节和第 8 节将已有方案的风险归因于较大的、包含版本管理逻辑的 TCB。TD 只验证物理块的状态迁移，版本策略可以在不可信主机上更新。
- 依赖假设：物理设备控制器、持久化时钟和 TD-ATA 接口确实与主机隔离，主机无法绕过检查器访问底层盘。
- 可能失效场景：商用设备中的固件、DMA、管理命令或未验证的接口若能直接改写介质，论文的接口级保证不能覆盖这些路径。
-
观察 2：追加日志消除了覆盖需求，但运行时扫描日志不可接受。 TD 元数据必须记录冻结、解冻、过期时间和 time-of-lock；状态变化不能回写旧条目。因此 TD-log 采用追加写入。论文第 3.4 节的缓存敏感性实验显示，主机写密集负载下，检查器侧 1 MB 缓存仍会因日志扫描产生超过 30% 的开销。
- 设计假设：主机可以保存完整元数据缓存，而检查器只需保存每个元数据块的 freshness counter。缓存不可信，但每次命令携带 BLAKE3 HMAC 和计数器，检查器重新验证。
- 可能失效场景：主机内存损坏、缓存重建频繁发生或日志增长远超实验规模时，恢复扫描会成为明显停顿；2 MB/TB 的计数器空间也建立在特定元数据布局和写入粒度上。
-
假设 1：入侵检测延迟小于 rollback length。 安全版本系统把新数据 timelock 至少 R 时间；恢复时依靠入侵时间之前的 time-of-lock 选择版本。论文将 R>L 作为基本安全条件。
- 证据强度：强。第 2 节定义了 L 和 R，第 4.2、4.7 节给出状态分类和恢复论证。
- 边界：若入侵时间无法可靠确定，或者攻击者在检测前等待超过 R，TD 不能保证保留可恢复版本。
-
假设 2：检查器时钟跨重启单调不减，断电时只暂停倒计时。 这是第 2 节明确给出的时钟模型，类似 TPM 的非易失安全计数器。
- 证据强度：中。Dafny 验证了给定模型下的状态机和日志重放，但没有验证物理时钟、Rust 透传函数或实际控制器硬件。
核心方法
TD 在普通 SSD/HDD 与主机之间加入隔离的 TD-checker。接口支持读、写、timelock、批量 timelock-update，以及恢复时逐块扫描日志。块先进入 frozen 状态；用户可以显式 unfreeze，但随后仍处于 countdown 状态，直到原始 timelock 时长耗尽才回到 free。这样即使攻击者在写入后立刻发起 unfreeze，也不能立即覆盖该块。
TD 元数据采用追加日志。每个条目记录块的状态、时长、time-of-lock 和过期时间，并以与数据相同的保护时长写入。批量更新把多个小条目合并到块中，降低块级写入的空间浪费。检查器不保存完整元数据，只保存 freshness counters；主机提供元数据和 HMAC，检查器验证地址、密钥、计数器和状态转移是否一致。
主机侧版本系统也采用追加日志。文件系统写入逻辑地址时，版本系统把新版本放入物理 free block，并在 epoch 结束时对数据和版本元数据执行有序持久化：先写数据，再写版本元数据，最后写 TD 元数据和 timelock 记录。write barrier 保证恢复时不会看到指向尚未持久化数据的元数据。
恢复只信任 TD 上的内容。版本系统扫描逻辑地址到物理地址的日志，使用 time-of-lock 丢弃入侵之后锁定的条目，并选择每个逻辑地址最近的入侵前版本。论文还给出增量 checkpoint、元数据垃圾回收和多盘 recovery barrier；多盘场景通过跨盘写入同步 sentinel 来处理各盘时钟不一致。
检查器的 Dafny 实现约 400 行，验证两类性质：字节级实现遵循抽象状态机，不存在跳过冻结状态的路径；断电后重放 TD-log 能重建与正常执行等价的元数据状态。
设计取舍
- 把元数据缓存交给不可信主机：换取运行时低延迟和小型 TCB，代价是每次写入都要携带并验证 HMAC；缓存损坏或重启后必须完整扫描日志。
- 纯追加日志：避免覆盖 timelocked 元数据，代价是恢复时间随日志长度增长，并需要定期垃圾回收。论文第 7.5 节显示，长时间、高频写入时 LVM 的固定元数据开销可能低于 TD。
- 块级时间锁而非版本级策略：使策略灵活、版本系统不可信，代价是版本系统必须实现空间管理、日志压缩、碎片整理和跨层 crash safety。
- 增量 checkpoint：减少每次写入的保护数据，但最多丢失一个 epoch 的更新。原型使用一小时 epoch，这个损失相对论文假设的数周检测延迟较小。
实验与结果
- 在 18 个不同 ransomware family 样本上，TD 均恢复了文件系统状态（§7.2）。
- 在企业、邮件服务器、Web、文件服务器和 OLTP 的多条存储 trace 上，TD 相比无安全机制的 log-structured block-device baseline 产生可忽略的延迟和 I/O 开销（§7.3.1，图 5）。
- 在 ext4 和 Filebench 写密集工作负载上，吞吐开销可忽略（图 6）。SSD 上额外开销仍低于 1%；论文摘要给出的代表性结果是执行开销 0.4%、吞吐开销 0.5%（§7.3.3）。
- 检查器侧缓存的敏感性实验显示，1 MB cache 在写密集 trace 上仍会因日志扫描产生超过 30% 开销；为避免 cache miss，估计需要每 TB 存储约 2 GB cache（§7.3.4，图 7）。
- 恢复时间与版本日志长度、写入次数成正比，略慢于 LVM snapshot（§7.4，图 8）。每 100,000 次操作的 TD 元数据和版本元数据合计最高略超过 3 MB；部分 trace 可回收约四分之一到三分之一日志空间（§7.5，图 5c）。
论断—证据表
| 论断 | 证据 | 评测边界 | 置信度 |
|---|---|---|---|
| 被 timelock 的块不能被主机绕过状态机修改 | Dafny refinement proof（§6.1） | 验证的是模型、Dafny 实现和未验证的 Rust 透传假设，不是商用控制器全栈 | 中 |
| 主机侧缓存能避免追加日志的运行时扫描 | cache sensitivity（§7.3.4，图 7） | 主要为给定 trace、缓存大小和单机原型；恢复与重建仍需扫描 | 强 |
| TD 的正常运行时开销很低 | trace、Filebench、HDD/SSD 实验（§7.3，图 5–6） | 4 TB HDD、1 TB SSD、100,000 命令和指定工作负载；未覆盖商用硬件集成后的固件开销 | 中 |
| 入侵后可恢复最近的入侵前版本 | 状态分类与 time-of-lock 恢复算法（§4.2、§4.7），18 个样本测试（§7.2） | 要求入侵时间可确定、R 大于检测延迟、时钟可靠；样本数量有限 | 中 |
批判性分析
论证链条
论文的主链条是闭合的：主机完全不可信，因此只把不可覆盖约束放进隔离检查器；不可覆盖又排除了普通元数据更新，于是用追加日志和主机侧可验证缓存解决性能；版本恢复再利用物理块的 time-of-lock。形式化证明覆盖了检查器状态机和日志重放，实验覆盖了缓存、运行时开销、恢复和空间增长。
主要跳步在系统边界。论文的安全结论依赖检查器确实拦截所有写入路径、时钟不可被回拨、介质内容不会被物理篡改。Dafny 模型把 ATA 透传和磁盘持久化抽象成可信函数；因此“约 400 行 TCB”不等于端到端硬件实现已经被验证。
假设压力测试
workload 改变后，主机缓存仍需保存几乎全部 TD 元数据。高频随机写、频繁掉电或频繁恢复会放大日志扫描和恢复停顿。大规模多盘部署还需要 recovery barrier 和时钟漂移 guard window，论文没有给出多盘性能或故障实验。
安全性还依赖“入侵前版本在正常运行时未被错误 unfreeze”。若版本系统在入侵前存在 bug，提前释放了唯一版本，TD 只能忠实保护错误状态，不能修复版本策略错误。论文的 TCB 缩小因此把部分正确性责任转移到了 untrusted VS 和恢复程序的设计。
实验可信度
工作负载覆盖了多种存储 trace、Filebench 和 18 个 ransomware 样本，足以支持原型开销和基本恢复能力的判断。baseline 是无安全机制的 log-structured block device，因此不能单独证明 TD 优于所有安全版本系统；LVM 对比只覆盖延迟和恢复，未覆盖相同的攻击模型。
实验主要在 Raspberry Pi 隔离原型和主机共享内存配置上完成。论文设想的控制器集成到盘内 silicon，但没有芯片实现、DMA 隔离、固件升级、管理命令审计或真实掉电恢复测试。图 5–8 支撑“原型开销低”，不能直接推出商用设备的部署成本低。
系统性缺陷
空间回收受 timelock 和通电状态限制。论文明确指出，设备断电时倒计时暂停，碎片整理和垃圾回收也无法推进；长期离线或容量接近耗尽时，系统可能无法及时获得 free blocks。元数据日志的月度垃圾回收依赖不可信 VS 正确构造新日志，论文未量化垃圾回收峰值 I/O、尾延迟和崩溃窗口。
检查器形式化证明没有覆盖 Rust 透传、实际 ATA/NVMe 命令全集、控制器固件、密钥生成、BLAKE3 实现和底层介质故障。论文也未讨论坏块、静默数据损坏、加密密钥管理、控制器替换和跨设备备份丢失等运维问题。
局限与后续工作
- 局限 1：物理时钟和隔离硬件仍是系统级信任根。 后续应实现带掉电保持的控制器，并对时钟、命令过滤、DMA 和升级路径做端到端验证。
- 局限 2：恢复与日志回收随写入历史增长。 应测量数月或数 TB 生产 trace 下的日志膨胀、回收峰值和恢复 P99，并设计有安全边界的分层压缩或摘要结构。
- 局限 3：入侵时间由外部取证提供。 可构造多个候选时间的自动恢复流程，并用文件系统一致性、应用校验和或 provenance 评估候选状态。
- 局限 4：多盘只给出协议草图。 后续应在时钟漂移、部分盘失联、重试和跨盘 crash 的条件下验证 recovery barrier 的正确性和性能。
- 局限 5：TD 不防数据窃取或物理破坏。 可与 time-release encryption、远端副本和介质完整性校验结合，评估新增密钥和恢复依赖是否扩大 TCB。