PVLDB 2026 · Dynamic ABAC · Intel SGX · Persistent KV Store

SACK：在不可信云上高效执行动态属性权限

它把属性与策略放进可信 enclave，把大规模数据留在普通存储中，并用按策略密钥、KV separation 和完整性结构兼顾安全、更新效率与性能。

正式来源：PVLDB 19(6), 2026系统：SGX + RocksDB middleware安全：Confidentiality / Integrity / Freshness / ABAC原文 PDF 已保存

先说结论：把昂贵的属性加密只用来保护“小密钥”，数据本体用快速对称加密

SACK 面向不可信云上的持久化 KV 存储。它把用户属性、访问策略和密钥放进 Intel SGX enclave，数据本体仍放在普通 KV store / 磁盘上；通过按策略分组的密钥、KV separation 和完整性元数据，实现动态 ABAC、机密性、完整性和新鲜性。

问题

直接用 ABE 加密每条数据太慢

属性越多，公钥运算、密文膨胀、改权限后的重加密成本越高。

方法

SGX 内执行策略，外部存数据

ABE 只保护每个策略对应的 DEK；真正 KV value 用快速对称密钥加密。

系统创新

权限管理与数据管理解耦

更新用户属性或策略时主要改密钥和元数据，不必扫描并重加密整个 KV store。

一句话理解：与其给仓库里每个箱子都装一套昂贵的属性密码锁，不如把少量“箱子钥匙”放进可信保险柜；保险柜按用户属性决定给不给钥匙。

ABAC 是什么，为什么 ABE 不够实用

ABAC 策略树例子 — 论文图 1：用户拥有 identity、security level、operation 等属性；只有属性满足策略树，才能访问 KV pair。

ABE 随属性数增长的开销 — 论文图 2：直接把每条 KV 用 ABE 加密时，读写延迟和存储开销随属性数快速增长。

计算慢

ABE 使用公钥密码学。论文基线中单属性也会把写、读延迟放大 21.9 倍和 39.2 倍，属性越多越严重。

存储膨胀

策略树会嵌入密文。16 个属性时，存储规模约变成无 ABE 的 4.5 倍。

动态更新贵

用户属性或策略变化时，传统做法可能重新发钥匙并重加密受影响的数据，代价随数据规模增长。

SACK 的核心架构

SACK 架构 — 论文图 3：黄色区域是 SGX enclave；虚线外是不可信内存和磁盘。可信区只保留权限和关键元数据，庞大数据仍放外部。

Enclave 内：决定谁能拿到哪把钥匙

User-attribute table：用户 → 属性，并缓存可用 PID / DEK
Policy-metadata table：策略 → PID、DEK 校验信息、VLog 根
Prefix tree / Bloom filters：帮助定位元数据和减少磁盘访问

Enclave 外：保存可扩展的数据结构

KV store：保存加密 key 与 KV-meta 索引
VLog：保存加密 value，同策略数据放在一起
ILog：按明文 key 前缀组织 KV-meta，用于扫描和新鲜性校验

为什么不把整个数据库塞进 SGX：可信内存容量和持久化都不适合承载大规模 KV 数据，而且 enclave 与外界切换也很贵。SACK 的重点就是尽量缩小可信计算基。

访问控制具体怎么做

用户建立可信会话

通过 remote attestation 确认 enclave 未被篡改，再建立安全通道并认证用户。

按属性匹配策略

Enclave 在 user-attribute table 中取属性，计算满足哪些策略。

解出策略密钥

ABE 只用于解密小型 DEK。后续会话将 PID / DEK 缓存在用户条目中。

读写加密 KV

value 用对应策略的 DEK 对称加解密；HMAC、Merkle tree 和序列号验证完整性与新鲜性。

动态权限更新的两个场景

用户权限变化

管理员修改用户属性。Enclave 清掉失效的 PID / DEK 缓存，再按新属性加载可用密钥；已有 KV 数据不动。

数据策略变化

修改、迁移或合并策略时，重新用 ABE 包装 DEK，并更新 policy metadata / VLog 归属；不用逐条重加密 value。

KV separation：为什么要把 key / metadata 和 value 拆开

KV-meta 和 VLog — 论文图 6：KV store 只放 KV-meta；真正的加密 value 放 VLog。KV-meta 记录 VLog 位置、序列号、HMAC 等。

Key

用 master key 做确定性加密，让同一 key 仍可查询。代价是会泄露“两个请求是否针对相同 key”这类访问模式。

Value

用每个策略独立的 DEK + 随机 IV 加密，相同明文得到不同密文；同策略数据写入对应 VLog。

KV-meta

保存 VLog ID、offset、sequence、KV-HMAC、metadata-HMAC，让系统能定位数据并检查篡改。

两个容易忽略的系统问题

新鲜性

只有 HMAC 不够，因为攻击者可以回放“旧但签名合法”的版本。SACK 用 ILog、序列号、prefix tree 和 Bloom filter 协同识别最新版。

崩溃一致性

KV store、VLog、ILog 和 enclave 状态分开保存，宕机可能各自进度不同。SACK 设计写入顺序、sealing 与恢复流程来重新对齐。

实验结果：快在哪里，代价又在哪里

实验设置：三套系统是无安全保护的 RocksDB、已有 SGX 安全 KV 系统 TWEEZER，以及 SACK。默认先装载 6400 万条 1KiB KV（24B key + 1000B value），再发出 500 万次请求；访问服从 Zipf 0.99，并报告 5 次运行均值和 95% 置信区间。默认每条数据只绑定一个属性和一个策略，策略规模另在 Exp#7 单独测试。

YCSB 工作负载	请求构成	它主要考什么
A	50% 读 / 50% 写	读写混合
B	95% 读 / 5% 写	读密集
C	100% 读	纯读上限
D	95% 读 / 5% 写，偏向最新数据	热点与新鲜数据
E	95% scan / 5% 写	范围扫描
F	50% 读 / 50% read-modify-write	更新路径

Exp#1：六种 YCSB 负载下的吞吐

YCSB 吞吐量 — 论文图 9：除 scan-heavy 的 Workload E 外，SACK 相对 TWEEZER 的吞吐提升为 1.9–5.4 倍。

读写扫描更新延迟 — 论文图 10：读、写平均延迟优于 TWEEZER，但扫描和更新有额外代价；纵轴相对无保护 RocksDB 归一化。

SACK 在 A/B/C/D/F 上比 TWEEZER 高 1.9–5.4 倍，其中纯读 C 达 5.4 倍；原因是 KV separation、减少 enclave paging，以及读比例越高越能发挥缓存收益。例外是扫描负载 E：跨多个 VLog 取值使吞吐比 TWEEZER 低 51.6%，批量读取优化只能把它从 0.10 提到 0.15 KOPS。综合六种负载，SACK 相对 RocksDB 的平均吞吐下降约 6.7 倍，TWEEZER 则下降约 12.5 倍。

Exp#2：绝对延迟，不只看百分比

系统	平均延迟（μs）				P99 延迟（μs）
系统	写	读	Scan	Update	写	读	Scan	Update
RocksDB	34.2	48.4	431.1	15.3	1120.6	335.8	2234.6	37.2
TWEEZER	194.8	698.6	4259.0	178.5	1233.0	2257.3	21624.1	477.6
SACK	150.3	136.3	10874.5	185.6	195.3	458.8	17726.2	300.3

比较	结果	怎么理解
SACK vs 直接 ABE	写延迟 -79.9%，读延迟 -92.8%	公钥加密只包小密钥，数据改用对称加密
SACK vs TWEEZER	写 -22.8%，读 -80.5%	KV separation 缩小索引与 enclave paging
SACK vs TWEEZER	scan +155.3%，update +4.0%	扫描需跨多个 VLog 取值，GC 也增加更新成本
SACK vs RocksDB	平均延迟高 2.8–25.2 倍	这是机密性、完整性、新鲜性和 ABAC 的安全税
存储	比 RocksDB 多 39.3%	KV-meta、ILog、VLog Merkle tree 都占空间

别被平均值骗了：SACK 的平均 scan 比 TWEEZER 慢 155.3%，但 scan 的 P99 反而低约 18%；四类操作的 P99 相比 TWEEZER 平均降低 54.7%。系统更稳定，但扫描的正常路径仍很慢。与“每条数据直接 ABE”相比，SACK 的平均写、读延迟分别降低 79.9% 和 92.8%。

Exp#3：时间到底花在哪一步

写 1MiB 数据的步骤	耗时（ms）
生成 KV-meta	19.66
加密 KV	23.08
构建 Merkle tree	3.48
更新 Bloom filters	32.15
刷 VLogs	0.72
更新 ILogs	70.81
更新 KV store	3.99

读 1MiB 数据的步骤	耗时（ms）
查询 Bloom filters	4.78
从 KV store 取 KV-meta	33.22
从 ILogs 取 KV-meta	477.42
从 VLog 读取 value	38.16
权限检查与解密	16.46
完整性与新鲜性验证	42.56

其他路径	步骤	耗时（ms/MiB）	含义
Scan	查询 ILogs	34.59	连续 metadata 可批量处理
Scan	从 VLogs 读 value	55.35	value 分散在多个日志，是扫描瓶颈
Scan	权限检查与解密	10.06	可批处理，比单条读便宜
Scan	完整性验证	15.66	仍需验证每批结果
GC	ILog GC	6.43	相对便宜
GC	VLog GC	45.16	需验数据并更新有效 KV-meta

瓶颈定位：写入最贵的是更新 ILog，占总写时间约 46%；随机读最贵的是查询 ILogs；scan 最贵的是从分散 VLog 取 value。也就是说，密码运算并非唯一瓶颈，数据布局与日志维护更关键。

Exp#4：崩溃恢复是否可用

恢复步骤	耗时（s）	占总恢复时间
Unseal enclave	6.68	1.3%
恢复 ILogs	194.72	38.6%
恢复 VLogs：取 KV pairs	15.73	合计 60.1%
恢复 VLogs：解密	31.32
恢复 VLogs：校验	45.42
恢复 VLogs：更新 BFs	40.94
恢复 VLogs：更新 ILogs	101.73
恢复 VLogs：更新 KV store	10.32
总计	504.69 ± 38.64	约 8.4 分钟

这里是 6400 万条数据、写入约一半后强制杀进程的恢复实验。恢复不是瞬时的，主要成本是重算 HMAC、重建 KV-meta 和日志索引；因此它证明“能恢复”，不等于满足低 RTO 的在线数据库要求。

Exp#5 / #6：Enclave、CPU 和存储资源

SACK 与 TWEEZER 的 SGX paging — 论文图 11：SACK 将 TWEEZER 在写、读、scan、update 上的 EPC paging 分别降低 74.0%、89.2%、95.0%、77.9%。SACK 的持久元数据约占 51.6MiB EPC，因此明显少于把 LSM 元数据放进 enclave 的 TWEEZER。

CPU 与存储占用 — 论文图 12：代价转移到了 CPU 和磁盘。SACK 的 CPU 使用率比 RocksDB 高 95.3%–193.1%，存储从 61.9GiB 增至 86.2GiB（+39.3%）。

资源	RocksDB	TWEEZER	SACK	SACK 的主要来源
写 CPU	17.0%	26.1%	33.2%	加密、HMAC、日志维护
读 CPU	16.6%	16.5%	42.2%	权限检查、解密与完整性验证
Scan CPU	14.4%	26.2%	42.2%	批量解密和跨 VLog 读取
Update CPU	19.0%	26.6%	46.4%	日志与 GC
存储	61.9GiB	63.0GiB	86.2GiB	VLogs 68.2GiB、KV store 8.95GiB、ILogs 8.84GiB

Exp#7：策略和属性变多后会怎样

策略规模和更新开销 — 论文图 13：策略数从 1 增至 2^16 时，首次初始化从 8ms 上升到 326.4s；日常读延迟增长温和，但策略重包密钥仍可达数分钟。

场景	小规模	大规模	怎么理解
首次初始化	1 策略：8ms	2^16 策略：326.4s	需用 ABE 解出每个相关策略的 DEK
成功读取	136.3μs	152.9μs	密钥已缓存，增长仅 12.2%
失败读取	95.1μs	111.1μs	不需取值和解密，所以更快
写入	150.3μs	321.8μs	策略越多，VLog buffer 争用越明显
更新用户属性	1 属性：10.2μs	16 属性：16.9μs	只改 enclave 内表很快
Rekey	1 属性：112.7s	4 属性：203.1s；16 属性：212.7s	大量受影响策略需重新包 DEK

“动态更新很轻”要分两层看：修改一个用户的内存属性只需微秒级，但随后重新为该用户初始化可用 DEK 可能很慢；更新大量策略时 rekey 也达到 112.7–212.7 秒。它的优势是成本不再随 KV 数据总量线性增长。

Exp#8：Bloom Filter 的空间换时间

Bloom Filter 大小对读写延迟的影响 — 论文图 14：增大 per-ILog insert BF（IBF）会让写入略慢，却把读取从 487.5μs 降到 135.6μs；update BF（UBF）也有类似但更温和的写入成本。

配置变化	写延迟	读延迟	结论
IBF：0 → 2KiB	130.9 → 154.9μs	487.5 → 135.6μs（-72.2%）	少量写成本换来大幅减少 ILog 误查
UBF：0 → 16MiB	130.9 → 150.3μs	稳定在约 136.3μs	主要影响更新记录，不明显改变正常读
UBF 容量	16MiB 支持约 1090 万次更新；32MiB 支持约 2170 万次更新（1% 假阳性率）		应按两次 VLog GC 之间的更新量配置

八组实验合起来的结论：SACK 确实把“直接 ABE”以及 TWEEZER 的主要性能问题压低了，尤其适合点查；代价是扫描慢、CPU/存储增加、恢复和大规模策略初始化以分钟计。对数仓场景，这意味着它更适合作为敏感 KV 缓存/元数据层，而不是直接承担分析型全表扫描。

创新点

权限与数据解耦

ABAC 在 enclave 内做，数据管理在通用 KV store 上做；无需改 RocksDB 的内部索引实现。

ABE 只保护 DEK

保留 ABE 表达复杂属性策略的能力，同时把高频数据读写切换到对称密码学。

面向持久化的完整设计

不仅做授权，还一起处理 freshness、GC、扫描、崩溃恢复、policy renewal，这比概念性 ABAC 原型完整得多。

安全边界与论文没有解决的事

明确提供

未授权用户和云管理员看不到明文
数据、策略和属性被篡改可检测
尽量保证只处理最新版本
用户属性和数据策略可以更新

明确不提供

不隐藏访问模式
不处理拒绝服务攻击
不覆盖 SGX 自身漏洞
一个 KV pair 暂不支持多个并行策略

它和数仓 / 智能问数项目有什么关系

SACK 不是“自然语言权限判断器”，也不是完整数仓权限系统。它更适合回答一个下层问题：如果你的问数系统把语义缓存、向量索引、元数据、会话状态或敏感中间结果放在共享 KV store 中，如何在不信任云管理员的前提下执行动态细粒度权限。

上层问数权限

身份、RBAC/ABAC、指标与表列行权限、用途限制。

→

SQL / 结果执行门

SQL AST、RLS/CLS、脱敏、审计、预算与速率限制。

→

SACK 类安全存储

保护缓存、索引、元数据和中间结果的持久化 KV 层。

→

不可信基础设施

云磁盘、共享 KV store、运维管理员与潜在存储篡改。

真正值得借鉴的设计原则：权限策略不应和每条数据紧耦合；用“小而可信的策略/密钥平面”管理“大而不可信的数据平面”，可以让权限更新成本与数据规模解耦。

审稿人视角

系统强依赖 Intel SGX 和论文的威胁假设，实际云平台可用性、硬件代际、侧信道防护都需重新评估。
扫描性能明显偏弱，而数仓和分析系统恰恰大量依赖 range scan、批量读取和聚合。
2^16 策略下初始化达到 326.4 秒，说明“策略规模大但首次连接仍快”并未解决。
访问模式泄露没有处理；对高敏场景，知道同一个 key 被频繁访问本身就可能泄露业务信号。
论文基于单机 RocksDB 中间件原型，距离分布式湖仓、弹性扩缩容和跨节点事务还有很大距离。

综合评价：SACK 是一篇扎实的安全存储系统论文，最适合作为“问数平台底层敏感 KV 数据怎么保护”的参考，而不是直接拿来替代数仓的行列级权限和上层问数治理。