土法炼钢兴趣小组的算法知识备份

【数据库研究前沿】TEE 数据库与 Oblivious 原语：EnclaveDB 与加密计算

2026-05-26 · database · #tee #sgx #sev-snp #tdx #arm-cca #enclavedb #opaque #oblidb #oblivious #confidential-computing

文章导航

分类入口
database
标签入口
#tee#sgx#sev-snp#tdx#arm-cca#enclavedb#opaque#oblidb#oblivious#confidential-computing

目录

这是【数据库研究前沿】系列的第 19 篇。过去几篇讨论的是性能、弹性、硬件——从 CXL 到 Near-Data Processing 再到 新型 NVM。本篇换一个轴：当我们把数据库搬到不信任的云上、甚至不信任的内核和 Hypervisor 上时，查询引擎还能不能保持机密性与完整性？

这不是纯学术问题。银行、医院、政府客户越来越频繁地要求”数据出机房但不出明文”，欧盟 GDPR、中国《数据安全法》、美国 HIPAA 都在把加密计算从”合规加分项”变成”合规前置条件”。可信执行环境（Trusted Execution Environment, TEE）是目前唯一同时满足”通用计算性能”与”远程证明（Remote Attestation）“的可商用方案：Intel SGX、AMD SEV-SNP、Intel TDX、ARM CCA 各自给出一套硬件语义，上层数据库论文——EnclaveDB（S&P 2018）、Opaque（NSDI 2017）、ObliDB（VLDB 2020）——在这套语义上叠加访问模式混淆（Oblivious Primitives）来抗侧信道。

本文上半部分做两件事：第一，把四种主流 TEE 的威胁模型和性能特征拉平对比；第二，梳理 EnclaveDB / Opaque / ObliDB 三篇论文各自解决的问题，以及 Foreshadow、ÆPIC Leak 等侧信道攻击如何反过来塑造了它们的设计。下半部分回到工程：Azure Confidential SQL、AWS Nitro Enclaves 上跑 OLAP 实际能到什么性能，哪些查询形态是可行的，哪些是现阶段的禁区。

版本说明 本文以 Intel SGX SDK 2.24、Intel TDX 1.5、AMD SEV-SNP（Milan / Genoa）、ARM CCA（Armv9-A）、Azure Confidential Computing 2024、AWS Nitro Enclaves 2024 为主要参照。TEE 领域演进很快，具体 CVE 与微码版本请以厂商公告为准。

一、四种 TEE 的威胁模型与抽象

1.1 TEE 到底在防什么

TEE 的核心卖点是一行话：把计算过程（代码 + 数据 + 内存）的机密性与完整性，从操作系统内核和 Hypervisor 手里拿回来，只信任 CPU 与一段很薄的固件。

这句话隐含的威胁模型（Threat Model）比想象中严格：

而攻击者不能做的事，按 TEE 实现不同各有差异，但通常包括：

注意：TEE 不防御代码本身的漏洞——Enclave 里的缓冲区溢出依然可以被利用；TEE 也不直接防御侧信道攻击，这是 1.5 节的重点。

另外一个经常被忽视的点：TEE 的安全性不是绝对的，它是”在给定威胁模型下的可证明最小 TCB”。这意味着每一次 CPU 厂商的硬件漏洞（例如 Intel CSME 2017、AMD CPU ROP 2023）都会重写 TEE 的可信边界。严肃的生产部署应该把 TEE 的承诺定义成一个 Service Level Objective：例如”承诺在 2020 年之后公开已知的攻击面下保持机密性”，而不是”永远机密”。这种谦虚的工程态度，是 TEE 数据库真正走向合规生产的基础。

1.2 Intel SGX：进程内的”飞地”

Intel SGX（Software Guard Extensions）把保护粒度做到了进程内：一个用户态进程可以划出一段Enclave 页面缓存（Enclave Page Cache, EPC），CPU 负责对 EPC 的读写进行硬件级加密与完整性校验。Enclave 与外部通信通过 ECALL / OCALL 在特殊指令切换下进行。

关键限制有两个：

  1. EPC 容量。SGX v1 只有约 128 MB EPC，v2（Ice Lake SP 以后的 Scalable SGX）扩展到单 socket 1 TB 量级。早期论文（EnclaveDB 2018）的很多设计，本质上是在”EPC 是稀缺资源”这一假设下做的。
  2. TCB（Trusted Computing Base）很薄。除了 CPU，只需要信任 Intel 签发的 Architectural Enclave 与 SGX SDK。这是 SGX 区别于后几种 TEE 的最大特征——也是它被学术界长期追捧的原因。

SGX 的 Remote Attestation 走 EPID / DCAP 两条路径：DCAP（Data Center Attestation Primitives）在 2019 年后成为云环境主流，允许云租户自己运行 PCCS（Provisioning Certificate Caching Service），不再强制走 Intel 的 IAS。

1.3 AMD SEV-SNP：整个 VM 作为信任域

AMD 的 SEV（Secure Encrypted Virtualization）路线把保护粒度提到整个虚拟机：VM 的内存由 AMD Secure Processor（PSP）管理的密钥加密，Hypervisor 看到的全是密文。SEV-SNP（Secure Nested Paging，2020）在 SEV-ES 基础上加了 RMP（Reverse Map Table）来防止恶意 Hypervisor 的内存重映射、重放等攻击。

对数据库视角下的关键差异：

1.4 Intel TDX 与 ARM CCA

Intel TDX（Trust Domain Extensions，2023 起在 Sapphire Rapids 上量产）是 Intel 对 SEV-SNP 路线的回应：同样以 VM 粒度，称为 Trust Domain（TD）。架构细节上，TDX 由 CPU 硬件 + 一段叫 TDX Module 的签名固件共同管理 TD 的生命周期，Hypervisor 看不到 TD 的内存。

ARM CCA（Confidential Compute Architecture，Armv9-A 起）引入”Realm”概念，由 Realm Management Monitor（RMM）在 EL3 下调度，Hypervisor 和 Realm 互相隔离。CCA 目前在 AWS Graviton 4 等芯片上开始落地，但生态（数据库侧的库、证明服务）成熟度仍落后 TDX / SEV。

一张简表汇总：

维度 SGX SEV-SNP TDX ARM CCA
保护粒度 进程内 Enclave 整个 VM 整个 TD（VM） Realm（VM 或 App）
TCB 厚度 极薄 较厚（Guest OS 在内） 较厚（Guest OS + TDX Module） 较厚
EPC / 内存容量 v1 受限，v2 TB 级 不受限 不受限 不受限
抗回滚 / Memory Integrity 硬件 MAC RMP 表 硬件 + TDX Module RMM
Remote Attestation EPID / DCAP SNP Attestation TDX Attestation RMM Attestation
已知侧信道 CVE Foreshadow、ÆPIC、SGAxe 等 SEVered、CipherLeaks TDXDown、少量 研究阶段
生态成熟度 高（学术 + Gramine / Occlum） 中（云厂商普遍支持） 中高（Azure / Google） 早期

1.5 侧信道攻击如何改写 TEE 数据库的设计

2018 年的 Foreshadow（L1TF）让 SGX 的 SEAL 密钥一度近乎”全裸”；2022 年的 ÆPIC Leak 利用 APIC 寄存器的未初始化内存泄漏 SGX 内存内容；SEVered、CipherLeaks 针对 SEV；TDXDown（2024）针对 TDX。攻防节奏大约是：厂商打一个微码补丁，学术界再找一个新路径。

这些攻击对数据库的直接影响不是”TEE 不可用”，而是两条设计规则：

二、EnclaveDB、Opaque、ObliDB 三条主线

2.1 EnclaveDB（S&P 2018）：可信执行 + 只证明执行了查询

Priebe 等人在 IEEE S&P 2018 的 EnclaveDB: A Secure Database Using SGX 把 SQL Server 的存储与查询引擎搬进了 SGX Enclave。EnclaveDB 回答的问题是：假设存储是不可信的磁盘 / 云盘，计算在可信 CPU 上进行，怎么在内存开销最小的前提下保证机密性与完整性？

核心做法可以拆成三层：

  1. 加密存储 + 完整性树。数据页在磁盘上用 AES-GCM 加密，每页带 MAC；所有页的 MAC 组成一棵 Merkle B+ 树，根节点放在 Enclave 内存里。任何页的篡改都会在校验 root 时被发现。
  2. 查询代码同样进 Enclave。SQL Server 的存储引擎 + 查询执行器被裁剪后放进 Enclave，不可信 host 只负责 I/O 调度、网络。
  3. 查询证明（Query Attestation）。客户端发出查询，Enclave 返回结果 + 一个基于 Remote Attestation 的签名，证明”这份结果是在 Enclave 里用指定代码计算出来的”。

EnclaveDB 有两个工程侧值得注意的选择：使用预编译的查询计划，避免在 Enclave 内跑优化器；以及用主机内存做缓冲池（加密后）来绕过 SGX v1 的 EPC 容量限制。在作者公布的 TPC-C 实验上，开销相比原生 SQL Server 大约是 40% 的吞吐损失——这在 2018 年已经是相当不错的数字。

EnclaveDB 的一个有意思的技术决策是不把日志（WAL）放进 Enclave。日志只是”操作的序列化记录”，只要操作本身在 Enclave 内执行并产生 MAC，日志本身是否被不可信存储读取并无大碍。这启发了后来一系列”计算 vs 存储”的职责划分：Enclave 做状态转换，存储做持久化。放到 log is database 的视角看，这其实是”日志即数据库”思想和 TEE 的一次漂亮合流。

EnclaveDB 不防御访问模式侧信道，这是它和 Opaque / ObliDB 的分水岭。

2.2 Opaque（NSDI 2017）：Oblivious 原语搬进 Spark SQL

Zheng 等人在 NSDI 2017 的 Opaque: An Oblivious and Encrypted Distributed Analytics Platform 走了更激进的路线：在 Spark SQL 上做 OLAP 分析，不仅加密，还要访问模式无关。

Opaque 提供三档安全级别，给用户按需选择：

关键原语有两条：

在作者报告的 TPC-H 子集上，Oblivious Mode 相比纯加密模式开销 1.6× ~ 46× 不等，取决于查询里排序 / 聚合的比重。这个数字说明了一个残酷的事实：完全的访问模式无关，对 OLAP 是非常贵的。

2.3 ObliDB（VLDB 2020）：把 oblivious 做进 OLTP 索引

Eskandarian 与 Zaharia 在 VLDB 2020 的 ObliDB: Oblivious Query Processing for Secure Databases 把关注点从 OLAP 挪到了 OLTP 风格的点查 / 范围查 / join。它的核心贡献是为不同查询形态设计不同的 oblivious 物理算子：

ObliDB 的”机灵”之处在于为不同基数（Cardinality）的查询自动选择不同强度的 oblivious 算子——它其实把”基于代价的优化器”思想搬到了 oblivious 世界：代价模型里的度量单位从 I/O 变成了”oblivious cost”。

在 ObliDB 的实验里，点查相对明文的开销在 1.2× ~ 2× 量级；小 join 在 3× ~ 10×；大 join 到了 50× 以上。这也是下半部分要强调的结论：点查可行、小 join 勉强、大 join 基本不行。

值得专门点出的是，ObliDB 并不是把 Opaque 做”向下移植”到 OLTP，二者的基本抽象层完全不同：Opaque 是 Spark SQL 的 Rule-based 重写，ObliDB 直接修改了 B+ 树算子；Opaque 假设数据集放得下 shuffle，ObliDB 假设索引可以被 oblivious 访问。所以如果你要真正构建一套混合 OLTP+OLAP 的 TEE 数据库，两篇论文提供的是正交的构件，不是相互替代的方案——这点在读原文时容易被混淆。

2.4 Oblivious 原语速览

上面三篇论文反复用到的 oblivious 原语，可以整理成一张对照表：

原语 明文复杂度 Oblivious 复杂度 典型用途
Linear Scan O(N) O(N) 小表全扫
Sort（Bitonic） O(N log N) O(N log² N) ORDER BY、sort-merge join
Sort（AKS） O(N log N) O(N log N) 理论 常数极大，工程不用
Hash Join O(N+M) O((N+M) log²(N+M)) 等值 join
Range Scan O(log N + k) O(log N + K) K=paddedSize 范围查询
Path ORAM Access O(log N) O(log² N) 有常数 点查、随机访问
Oblivious Shuffle O(N) O(N log² N) Shuffle 阶段

注意：这里的”Oblivious 复杂度”并不总是最坏上界，而是工程实现里稳定达到的阶。学术上还有 Goodrich 的 O(N log N) oblivious sort（2014）、Asharov 等人 OptORAMa（Eurocrypt 2020）的 O(log N) ORAM 等结果，但常数大到难以工程化。

2.5 一份最小的 Oblivious Sort 伪代码

为了让上面的复杂度不停留在抽象层，把 Bitonic Sort 的核心写成伪代码：

def bitonic_compare(a, i, j, direction):
    # 常数时间：无论 a[i] 与 a[j] 的关系如何，都执行一次 swap 判断
    # 关键是不能用"if a[i] > a[j]: swap"这种有数据依赖的分支
    cond = (a[i] > a[j]) == direction
    x = cond * a[j] + (1 - cond) * a[i]
    y = cond * a[i] + (1 - cond) * a[j]
    a[i], a[j] = x, y

def bitonic_merge(a, lo, n, direction):
    if n > 1:
        k = n // 2
        for i in range(lo, lo + k):
            bitonic_compare(a, i, i + k, direction)
        bitonic_merge(a, lo, k, direction)
        bitonic_merge(a, lo + k, k, direction)

def bitonic_sort(a, lo, n, direction):
    if n > 1:
        k = n // 2
        bitonic_sort(a, lo, k, True)
        bitonic_sort(a, lo + k, k, False)
        bitonic_merge(a, lo, n, direction)

它的”oblivious”体现在：比较顺序完全由 n 决定，与数据无关。放在 Enclave 里执行时，只要 bitonic_compare 本身是常数时间（避免条件跳转、避免 cache 不一致），访问模式就不会暴露任何数据信息。工程实现里还要做一步”padding 到最近的 2 的幂”，防止长度本身泄漏信息。

ObliDB 的一个重要优化是：不所有阶段都用 bitonic。当数据量小于某个阈值（例如 EPC 可完整容纳）时，用 oblivious linear scan 其实更快，因为 bitonic 的常数在小数据上占比太大。这种”按规模切换算法”的思路，与传统 CBO 里”hash vs merge join”的切换非常相似。

2.6 侧信道与 Oblivious 的真实关系

一个常被混淆的点：Oblivious 原语本身并不防御所有侧信道，它防的是访问模式（Access Pattern）这一类。对于：

所以一个严肃的 TEE 数据库项目，实际上要叠加：TEE 硬件 + 代码常数时间化 + Oblivious 算子 + 补丁后的微码 + 远程证明 + 密钥分离存储，才能拿到真正意义上的安全保证。单独吹任何一层，都是不够的。

三、工程落地：Azure Confidential SQL 与 AWS Nitro Enclaves

3.1 Azure Confidential SQL / Always Encrypted with Secure Enclaves

微软在 SQL Server 2019 起引入 Always Encrypted with Secure Enclaves，Azure SQL 上对应的是 Azure Confidential SQL。工程上它采用的组合是：

这一点对工程选型非常关键：Always Encrypted 不是”所有 SQL 都能跑”，它是在明确列出支持的运算集合前提下开放给你。实际生产用法通常是：

-- 声明列使用随机加密（Randomized Encryption），只能等值判断
CREATE TABLE Employees (
    EmployeeId INT PRIMARY KEY,
    Name NVARCHAR(200) COLLATE Latin1_General_BIN2
        ENCRYPTED WITH (
            COLUMN_ENCRYPTION_KEY = CEK_Auto1,
            ENCRYPTION_TYPE = Randomized,
            ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256'
        ),
    Salary DECIMAL(18,2)
        ENCRYPTED WITH (
            COLUMN_ENCRYPTION_KEY = CEK_Auto1,
            ENCRYPTION_TYPE = Randomized,
            ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256'
        )
);

然后在 WITH (ENCLAVE_COMPUTATIONS = 'ENABLED') 的查询会话里可以做范围 / LIKE。开销方面，微软公开的基准显示：

3.2 AWS Nitro Enclaves：另一条路线

AWS 没有直接推 SGX，而是用 Nitro Hypervisor 切出独立 vCPU + 独立内存的 Enclave，没有持久化存储、没有网络，只通过 vsock 和父 EC2 通信。和 SGX 比：

所以 AWS 生态上的”TEE 数据库”通常不是把整个 PostgreSQL 塞进 Nitro Enclave，而是：

这条路线的含义是：在 AWS 上做”TEE 数据库”，往往是在应用层拼装，而不是替换数据库内核。对大多数企业用户来说，这反而是个更工程友好的抽象——你不需要修改 PostgreSQL 源码。

一个典型的 Nitro Enclaves 解密代理拓扑是这样的：

   client --- TLS ---> EC2 host
                       |  vsock (attested channel)
                       v
                   Nitro Enclave
                       |  KMS attestation-bound Decrypt
                       v
                    AWS KMS

KMS 通过 kms:RecipientInfo 字段把解密结果用 Enclave 的公钥包一层，只有该 Enclave 能解出来。这样即便 EC2 host 被攻破，它看到的仍然是密文——Enclave 成了”一次性密钥容器”。这种模式在金融行业做”客户信息解密代理”很常见。

3.3 性能开销量级：给工程师的参考数字

合并前面的论文和厂商公开数据，给一张经验性的开销表（以纯明文为 1×）：

场景 仅加密（EnclaveDB / Always Encrypted） Oblivious（Opaque / ObliDB）
点查（主键等值） 1.1× ~ 1.5× 1.5× ~ 3×
范围扫描（10k ~ 1M 行） 1.5× ~ 3× 3× ~ 10×
等值 Join（小表 + 大表） 1.5× ~ 4× 5× ~ 20×
聚合（GROUP BY） 2× ~ 4× 10× ~ 30×
复杂 OLAP（多 join + 排序） 3× ~ 8× 30× ~ 100×

这张表不是严格基准，只用于估算可行性。结论很直白：“仅加密” 档在 OLTP 和中等 OLAP 上都是可接受的；“Oblivious” 档只推荐在确实需要防侧信道的场景下使用。

一个容易被忽略的维度是尾延迟（Tail Latency）。Enclave 的 ECALL / OCALL 切换和 attestation 验证都会带来偶发毫秒级延迟，在 p99 / p999 上会比平均值放大 3 倍左右。做 SLA 承诺时要基于 p99，而不是 p50。另外，SGX / TDX 下页面加密会让大页（Huge Page）场景的 TLB miss 成本显著上升，内存密集型分析任务对此尤其敏感——把 OLAP 扫描的 batch 大小调到和 EPC 子页对齐，经常能拿到 20% 以上的吞吐提升。

再一个工程细节：远程证明证据的生命周期。Intel SGX DCAP 签发的 attestation quote 默认有效期较短（常见 24 小时），过期后需要重新走一轮 PCCS → TCB info → quote 的刷新流程。业务峰值期间不小心让证据过期会导致会话全部掉线。最佳实践是在后台提前 6~8 小时刷新、滚动替换，而不是被动等待过期告警。这种”可观测性先行”的姿态，对 TEE 生产化至关重要。

3.4 一个真实的部署参考架构

把上面所有要点串成一张图，一家中等规模银行的”TEE OLTP + OLAP”架构可能是这样：

  ┌─────────────────────────────────────────┐
  │        客户端（手机 App / 后台服务）          │
  │  - 持有列加密密钥 CEK（从 HSM 下发）           │
  │  - ADO.NET / JDBC 驱动做透明加解密             │
  └───────────────┬─────────────────────────┘
                  │ TLS + Attested Session
                  v
  ┌─────────────────────────────────────────┐
  │  Azure Confidential SQL（TDX VM）         │
  │  ┌───────────────┐  ┌─────────────────┐ │
  │  │ Query Engine  │  │  Secure Enclave │ │
  │  │ (明文索引)    │→→│ (CEK 派生 + 比较) │ │
  │  └───────────────┘  └─────────────────┘ │
  └───────────────┬─────────────────────────┘
                  │ CDC（密文 + MAC）
                  v
  ┌─────────────────────────────────────────┐
  │  Lakehouse（Iceberg on S3）               │
  │  - 列级加密，密钥由 HSM 管理              │
  │  - OLAP 作业在 Nitro Enclave 里解密片段    │
  └─────────────────────────────────────────┘

这个架构的几个刻意选择：

这类架构通常的 RTO 要求是分钟级，而 attestation 验证本身要几百毫秒到几秒——所以attestation 缓存策略（在有效期内复用 attestation 证据）非常关键，这也是 Intel DCAP 引入 PCCS 的主要动机。

3.5 成本视角

最后把”钱”这件事也带上。与同规格普通 VM 相比：

“仅加密”档在多数合规场景下是成本可控的，这是它成为默认方案的真正原因。

3.6 踩坑清单

几点实战里反复出现的教训：

  1. 不要把 attestation 验证逻辑写成 if-else。一定走厂商提供的 SDK（Intel DCAP、AMD snpguest、AWS NSM），攻击面最小。自己拼接验证流程最常见的坑是漏掉了 TCB Level、漏掉了 CRL 检查，或者没有对比 MRENCLAVE / MRSIGNER 的白名单。
  2. 密钥分层。主密钥（MK）放 HSM / KMS；数据加密密钥（DEK）放 Enclave；会话密钥（Session Key）每次 attest 后重新派生。任何一层泄漏，其他层应能独立吊销。
  3. TEE 升级节奏很高。SGX、SEV、TDX 微码补丁几乎每季度一次，生产环境要有滚动升级 + 快速 attestation policy 更新机制，否则某个 CVE 出来后整个集群会拒绝验证。建议在基础设施层维护一张”当前可接受 TCB 等级”的配置表，由安全团队统一更新。
  4. 别在 Enclave 里跑优化器。查询优化器需要统计信息、内存开销大、代码复杂度高，EnclaveDB 采用”预编译执行计划”是有原因的。现代实践里更常见的做法：优化器在 Enclave 外跑、最终 plan 带签名进 Enclave。
  5. 监控要考虑”加密可观测性”。Enclave 内的日志本身是密文，传统 APM / tracing 基本失效，需要设计一套 attested logging 机制——日志在 Enclave 内签名、外部系统只做收集与存档，告警规则基于密文元数据（如时间、调用次数）而非内容。
  6. 侧信道不是 0/1 的问题。除非业务场景明确提出”抗内部管理员”的威胁模型，否则优先选”仅加密” 档；不要因为论文好看就上 oblivious。一个务实的起点：先跑一遍威胁建模（STRIDE / LINDDUN），列出实际需要防御的攻击者，再反推需要哪一档安全级别。
  7. 测试流程要覆盖 attestation 失败路径。生产事故中最常见的不是”机密泄漏”，而是”某台机器 TCB 降级了，整批连接被拒绝”。CI 里要能模拟 attestation 失败、过期、TCB 回退三种路径。

四、开放问题与路线判断

4.1 研究侧的开放问题

TEE 数据库领域目前有几个明显的开放问题：

4.2 路线判断

路线判断上，作者的个人立场：

五、小结

TEE 数据库不是”银弹”，但它把”机密数据 + 不可信云”这个过去只能靠 FHE（见下一篇 FHE 与 PIR）硬扛的问题，压到了一个工程上可接受的开销区间。过去十年的进步是巨大的：SGX 刚出现时，学术界还在争论”EPC 只有 128 MB 的数据库到底有什么用”；而到 2026 年，TDX / SEV-SNP 已经可以把上百 GB 的内存库照搬进机密 VM，而不改一行 SQL 代码。

把本文压成三条可以带走的结论：

  1. 先定威胁模型，再选 TEE 粒度。抗云管理员选 VM 粒度（SEV-SNP / TDX）；抗内核且 TCB 要小选进程粒度（SGX / CCA Realm-App）。威胁模型不写清楚就上 TEE，常常做成性能损失真金白银、威胁实际没覆盖的”形式合规”。
  2. 先上”仅加密”档。EnclaveDB 路线已经足够覆盖大多数合规需求，Oblivious 档留给确实有侧信道威胁的场景。把 oblivious 做成可选项而不是强制项，在工程上可以保留优化空间。
  3. 把 TEE 当成”密钥与小段计算的执行器”，而不是”整个数据库的替代品”。Nitro Enclaves 的路线在工程上更可持续。Azure 的 Always Encrypted 也是”粒度化 TEE 使用”思路的代表。

下一篇 差分隐私数据库 换一条完全不同的隐私计算路径：不再假设”攻击者看不到数据”，而是允许他看到聚合结果，只保证”看不到个体信息”。再下一篇 FHE 与 PIR 则把加密计算的理论上界摆出来。三篇合在一起，才是完整的数据库隐私工程谱系。

参考文献

  1. Priebe C., Vaswani K., Costa M. EnclaveDB: A Secure Database using SGX. IEEE S&P 2018.
  2. Zheng W., Dave A., Beekman J. G., Popa R. A., Gonzalez J. E., Stoica I. Opaque: An Oblivious and Encrypted Distributed Analytics Platform. NSDI 2017.
  3. Eskandarian S., Zaharia M. ObliDB: Oblivious Query Processing for Secure Databases. VLDB 2020.
  4. Van Bulck J., et al. Foreshadow: Extracting the Keys to the Intel SGX Kingdom with Transient Out-of-Order Execution. USENIX Security 2018.
  5. Borrello P., Kogler A., Schwarzl M., Lipp M., Gruss D., Schwarz M. ÆPIC Leak: Architecturally Leaking Uninitialized Data from the Microarchitecture. USENIX Security 2022.
  6. Kaplan D., Powell J., Woller T. AMD Memory Encryption (SEV) White Paper. AMD, 2021.
  7. Intel. Intel Trust Domain Extensions (TDX) Module Architecture Specification, v1.5. Intel, 2023.
  8. ARM. Arm Confidential Compute Architecture (CCA) Specification. Arm Ltd., 2023.
  9. Microsoft. Always Encrypted with Secure Enclaves in SQL Server 2019+. Microsoft Docs（待核实最新版本号）.
  10. Amazon Web Services. AWS Nitro Enclaves User Guide. AWS Documentation.
  11. Goodrich M. T. Zig-zag Sort: A Simple Deterministic Data-Oblivious Sorting Algorithm Running in O(N log N) Time. STOC 2014.
  12. Asharov G., Komargodski I., Lin W.-K., Nayak K., Peserico E., Shi E. OptORAMa: Optimal Oblivious RAM. EUROCRYPT 2020.

上一篇：【数据库研究前沿】新型 NVM 与存储层级重构

下一篇：【数据库研究前沿】差分隐私数据库：PINQ、APEx 到生产级 DP-SQL

同主题继续阅读

把当前热点继续串成多页阅读，而不是停在单篇消费。

2026-07-08 · os

【操作系统百科】机密计算

OS 如何在不信任 hypervisor 的世界里自处？AMD SEV-SNP、Intel TDX、ARM CCA、远程认证（attestation）、COCONUT-SVSM、Guest Firmware、I/O 加密。

By .