所属：第五篇 LLM 时代的攻防新战场

本章导读

这一章讲的是未来趋势，而不是当下就能上手的技术。它回答四个前瞻性问题：

1. AI 自己生成混淆代码——大语言模型能不能自动写出混淆工具（第 15.4 节）？
2. 同态加密（FHE）——让数据在加密状态下直接被计算、不用解密就能处理的技术，能否用来保护代码本身（第 15.2 节）？
3. 硬件辅助保护——芯片层面的"安全区"（TEE、ARM CCA、Intel TDX），如何让攻击者连代码都摸不到（第 15.3 节）？
4. 量子计算对密码学的冲击——新型计算机理论上能破解现有的一些加密算法，混淆技术该往哪走（第 15.5 节）？

即使现在的工作中用不到这些技术，了解方向也有助于做技术规划：例如决定何时升级到 AES-256、何时关注硬件安全特性。章末的 2026–2030 路线图（第 15.6 节）可以帮助你判断投入时机。

本章知识定位：本章整体属于理论支撑/前瞻展望，不是零基础读者当下要动手操作的技能。FHE 电路编译、TEE/ARM CCA/Intel TDX 的部署、后量子密码迁移，这些都是需要专门团队和硬件支持的工程项目，远超个人学习范畴。阅读本章的目标是建立"技术雷达"——知道有哪些方向在发展、大致什么时候会成熟、该在什么时间点开始关注，而不是学会操作它们。唯一例外是第 15.4.1 节给出的 LLVM Pass 代码示例，如果你已经学过附录 B，可以把它当作一个可以实际编译运行的练习，但这不是本章的重点。

阅读前需要了解的核心概念（零基础版）

代码混淆技术正处于深刻变革的前夜。On-device LLM（Large Language Model，大语言模型）的普及使模型权重成为新的核心资产，全同态加密（Fully Homomorphic Encryption, FHE）从理论走向早期工程实践，硬件可信执行环境不断扩展其保护边界，而 AI 本身也开始成为混淆工具的设计者。本章系统梳理这些新兴方向的技术原理、工程现状和未来演化路径，并展望量子计算时代对混淆理论基础的冲击。

15.1 On-device LLM 权重保护

知识定位：理论支撑。本节讲的是端侧模型（手机、IoT 设备上跑的 LLM）面临哪些威胁、业界有哪些保护思路（TEE 加密、权重混淆、水印）。除非你所在团队正在做端侧模型部署安全方案，否则不需要亲手实现 TEE 密钥管理或权重混淆算法——重点是理解"模型权重也是需要保护的资产"这个概念，以及几种方案各自的优缺点权衡。

15.1.1 端侧部署的威胁模型

随着大模型部署到端侧设备（手机、PC、IoT 网关），模型权重成为新的高价值资产。端侧部署面临的核心威胁包括：

15.1.2 端侧模型格式：GGUF 与 ONNX（Open Neural Network Exchange，开放神经网络交换格式）

理解保护方案之前，需要了解主流的端侧模型存储格式。

GGUF（GPT-Generated Unified Format）

GGUF 是 llama.cpp 生态推出的模型格式，已成为端侧 LLM 部署的事实标准 [12]：

GGUF 的关键特征与安全影响：

• 量化支持：内置 Q2_K 到 Q8_0 等多种量化格式，7B 模型可压缩至 ~4GB（Q4_K_M）。量化本身提供了微弱的权重保护——攻击者得到的是量化后的权重而非原始 FP16/FP32 值，但量化权重仍然足以完成推理。
• mmap 友好：Tensor Data 区域可直接 mmap 到内存，不需要加载/解码步骤。这意味着权重在磁盘上是"明文"存储的——内存中的数据与文件内容完全一致。
• 单文件自包含：一个.gguf文件包含模型架构、分词器和所有权重，便于分发但也便于盗取。
• 无加密/签名机制：GGUF 规范本身不包含任何加密或完整性验证，权重以裸数据形式存储。

ONNX（Open Neural Network Exchange）

ONNX 是微软和 Facebook 推出的跨框架模型交换格式 [13]，在端侧推理中应用广泛：

ONNX 的安全影响：

• 计算图可见：Protobuf 反序列化后可完整恢复模型架构，包括每一层的算子类型、连接关系和参数维度。
• 权重与图可分离：大模型权重通常存储为外部文件（model.onnx.data），便于管理但也便于单独提取。
• 成熟的工具链：onnxruntime、Netron 等工具可以轻松加载、可视化和修改 ONNX 模型，降低了攻击门槛。
• 优化中的信息泄露：ONNX Runtime 的图优化过程（算子融合、常量折叠等）可能改变模型结构，但不会移除权重信息。

15.1.3 权重保护方案

方案一：TEE + 权重加密

2026 年 9 月的学术论文提出的 TEE 方案是当前工程实践中最成熟的路径：

核心要点： - 权重使用 AES-256-GCM 加密存储在普通世界（REE）中 - 解密密钥绑定到设备硬件，由 TEE 的密钥管理模块保管 - 解密和推理过程全部在 TEE 内完成，REE 中的代码只能通过定义良好的 API 获取推理结果 - 远程证明（Remote Attestation）确保 TEE 环境未被篡改

工程挑战： - TEE 内存受限（TrustZone 的 Secure DRAM 通常仅 16–64 MB），大模型需要分块加载/推理 - TEE 中缺乏 GPU 加速，INT4/INT8 量化推理的性能受限 - 跨平台兼容性：不同 SoC 厂商的 TEE 实现差异较大

方案二：权重混淆（Weight Obfuscation）

对权重做可逆的数学变换，使得直接复制权重文件得到的是无法正常推理的"垃圾"：

常见的权重混淆技术：

方案三：权重水印（Weight Watermarking）

权重水印的目标不是阻止提取，而是在权重被窃取后提供所有权证明和追踪能力：

主流水印技术：

1. 后门型水印（Adi et al., 2018）[4]：在训练中注入特定触发样本 (trigger, label) 对。合法拥有者可以通过验证模型对触发输入的响应来证明所有权。 - 优点：对模型精度几乎无影响，鲁棒性强（抗剪枝、微调） - 缺点：水印验证需要访问模型推理接口

2. 参数空间水印：将水印信息编码到特定层的权重统计特征中（如特定权重的符号模式、频域特征）。 - 优点：可在不运行模型的情况下通过直接检查权重来验证 - 缺点：抵抗量化和微调的鲁棒性较弱

3. 指纹型水印（2025-2026 研究热点）：为每个授权用户/设备生成唯一的水印权重副本。被盗模型可追溯到具体的泄露源头。 - 核心挑战：如何在不影响模型性能的前提下嵌入足够多的区分信息 - 最新进展：利用 LoRA 适配器的低秩特性，在 LoRA 权重中嵌入设备指纹，主干权重不变

15.1.4 实践建议

对于端侧 LLM 部署，建议采用分层防护策略：

15.2 同态加密计算中的代码保护

知识定位：理论支撑，且是本章数学密度最高的一节。LWE 问题、Ring-LWE、FHE 的四算法定义等内容，目的是让你理解"为什么 FHE 这么慢""它的安全性建立在什么假设之上"，不要求你能推导或实现这些公式。15.2.3 的性能数据表可以直接作为"FHE 现在到底多慢"的参考结论来记住，这是本节里最值得带走的实用信息。

15.2.1 FHE 数学原理简介

全同态加密（Fully Homomorphic Encryption, FHE）是密码学中的"圣杯"——它允许在加密数据上直接执行计算，计算结果解密后等于在明文上计算的结果 [2]。

形式化定义：

一个 FHE 方案由四个算法组成(KeyGen, Encrypt, Decrypt, Evaluate)：

对于任意函数 f 和明文 m₁, m₂, ..., mₙ: Decrypt(sk, Evaluate(f, Encrypt(pk, m₁), ..., Encrypt(pk, mₙ))) = f(m₁, m₂, ..., mₙ)

LWE（Learning with Errors）问题

当前主流 FHE 方案（TFHE、BGV、CKKS、BFV）的安全性建立在LWE（Learning With Errors，带错误学习问题）的困难性假设之上。

LWE 问题定义（Regev, 2005）[1]：

给定参数 n（维度）、q（模数）和误差分布 χ（通常为离散高斯分布），定义：

• 秘密向量s∈ ℤqⁿ（均匀随机选取）
• 对于每个样本 i：
• 随机选取aᵢ∈ ℤqⁿ
• 计算 bᵢ = ⟨aᵢ,s⟩ + eᵢ (mod q)，其中 eᵢ ← χ

搜索-LWE：给定多个 (aᵢ, bᵢ) 对，恢复秘密向量s。判定-LWE：区分 (aᵢ, bᵢ) 是 LWE 样本还是均匀随机样本。

LWE 加密示例（简化）： 秘密密钥: s = (3, 1, 4) ∈ ℤ₇³ 模数 q = 7 加密 m = 1: 随机向量: a = (2, 6, 0) 误差: e = 1 (从 χ 采样) b = ⟨a, s⟩ + e + ⌊q/2⌋·m (mod q) = (2·3 + 6·1 + 0·4) + 1 + 3·1 (mod 7) = 12 + 1 + 3 (mod 7) = 16 mod 7 = 2 密文: (a, b) = ((2, 6, 0), 2) 解密: b - ⟨a, s⟩ = 2 - 12 mod 7 = -10 mod 7 = 4 4 ≈ ⌊q/2⌋·1 = 3 → m = 1 ✓ (误差 e 足够小，不影响解密正确性)

安全性保证： - 已知最优攻击的复杂度为 2^(Ω(n))（针对合适参数选择） - LWE 问题可以从最坏情况格问题（如 GapSVP、SIVP）归约得到 - 被认为是后量子安全的——量子计算机在此问题上没有已知的超多项式加速

Ring-LWE 与效率提升

为了提高效率，实际 FHE 方案通常使用Ring-LWE变体：

Ring-LWE：在多项式环 Rq = ℤq[x]/(xⁿ+1) 上的 LWE 优势： - 密钥大小从 O(n²) 降至 O(n) - 加密/解密的计算复杂度从 O(n²) 降至 O(n log n)（利用 NTT） - 密文大小显著减小 安全性： - 可从理想格上的最坏情况问题归约 - 参数选择需要更加谨慎（理想格可能有额外的代数结构可利用）

15.2.2 FHE 用于代码保护的原理

理论上，FHE 可以实现终极的代码保护——将程序逻辑编码为 FHE 电路，攻击者只能看到加密后的电路运算，无法恢复原始逻辑：

传统执行: 程序 P + 输入 x ──→ P(x) = y FHE 保护: 加密程序 Enc(P) + 加密输入 Enc(x) ──→ Enc(P(x)) = Enc(y) │ 解密（需密钥） ▼ y = P(x)

两种保护模式：

1. 加密数据 + 明文程序（当前主流应用）： - 保护数据隐私，程序逻辑对服务方可见 - 应用场景：隐私计算、安全多方计算

2. 加密程序 + 明文数据（代码保护目标）： - 保护程序逻辑，数据对执行方可见 - 技术上可行但开销更大——需要将程序本身编码为 FHE 电路的输入

3. 加密程序 + 加密数据（终极目标）： - 双向保护，完全的"黑盒"计算 - 当前完全不具备工程实用性

15.2.3 当前性能数据

以下是截至 2026 年中期主流 FHE 库的性能基准数据 [5, 14, 15, 16]：

Bootstrapping（自举）性能——FHE 能够"全同态"的关键操作：

端到端应用基准：

15.2.4 FHE 代码保护的工程路径

鉴于当前性能限制，FHE 在代码保护领域的实用路径是选择性加密：

预计时间线： -2026–2027：FHE 加速硬件（Intel、DARPA DPRIVE 项目 [20]）逐步成熟，减速倍数可望降至 10²–10³ -2028–2029：FHE 编译器自动化程度提升，开发者无需手动设计电路 -2030+：通用 FHE 代码保护方案可能达到工程可用门槛

15.3 硬件辅助混淆

知识定位：理论支撑/前瞻展望。ARM CCA、Intel TDX 这类硬件机密计算架构的部署和配置是芯片厂商、OS 厂商和云服务商的工作，普通开发者不会自己去"搭一个 Realm"或"配置 TD"。本节的价值在于让你看懂行业新闻和技术选型文档里提到这些名词时知道它们是什么、解决什么问题，便于未来评估"要不要为我的产品接入这类硬件保护"。

15.3.1 现有硬件安全特性

硬件 + 软件协同：将混淆代码中的关键校验放入 TrustZone，软件层面的 bypass 无法影响硬件层面的验证。

15.3.2 ARM CCA（Confidential Compute Architecture，ARM 的机密计算架构）

ARM CCA 是 ARM 在 2021 年宣布、2024-2026 年逐步落地的下一代机密计算架构 [10, 21]，是 TrustZone 的重大演进。Intel TDX 则是 Intel 推出的面向服务器和 PC 平台的机密计算技术 [11]，两者设计理念类似但目标平台不同。下面的综合架构图同时展示了 ARM CCA 的四个世界模型与 Intel TDX 的 Trust Domain 模型，并给出关键维度对比。

CCA 相对 TrustZone 的关键改进：

CCA 对代码混淆的意义：

1. Realm 中的混淆解密：混淆代码的密钥和解密逻辑放入 Realm，Normal World 的 Root Kit 或 Hypervisor 级攻击者都无法访问
2. 多层保护隔离：不同安全级别的代码放入不同 Realm，即使一个 Realm 被攻破，其他 Realm 不受影响
3. 标准化证明：代码完整性可通过远程证明验证，确保混淆代码未被篡改
4. 动态代码保护：Realm 可动态创建，实现运行时按需加载和保护关键代码段

15.3.3 Intel TDX（Trust Domain Extensions，Intel 的可信域扩展）

Intel TDX 是 Intel 推出的机密计算技术 [11]，与 ARM CCA 的设计理念类似，但面向服务器和 PC 平台。上文的综合架构图右侧已给出 TDX 的核心结构示意，此处不再重复 ASCII 图，重点说明其安全特性。

TDX 的核心安全特性：

Intel TDX vs AMD SEV-SNP（Secure Encrypted Virtualization - Secure Nested Paging，AMD 的安全加密虚拟化）vs ARM CCA 对比：

15.3.4 硬件辅助混淆的协同架构

结合各硬件特性的最佳实践架构：

15.4 AI 生成混淆

知识定位：以理论支撑/前瞻展望为主，但掺杂少量可实践内容。工作流全景图（Phase 1–5）、GAN 对抗训练框架、代码多样性引擎都是帮你理解"AI 混淆目前发展到什么阶段"的背景知识，不要求你去搭建一整套 LLM 驱动的 Pass 生成流水线。但 15.4.1 中给出的 MBA 替换 Pass 示例代码，如果你学过附录 B 的 LLVM Pass 开发流程，是可以直接编译运行验证的——这一小段可以当作实践练习，其余内容仍属于了解范畴。

15.4.1 LLM 驱动的混淆 Pass 自动生成

传统的混淆 Pass 开发需要编译器专家手工编写 LLVM/GCC Pass [17]，开发周期长、维护成本高。LLM 的出现使得自动化生成混淆 Pass 成为可能。

完整工作流

flowchart TB subgraph P1["Phase 1: 需求规范化"] A1["自然语言目标<br/>例如：把 x+y 替换为等价 MBA"] A2["LLM 解析 → 结构化规范 JSON"] A1 --> A2 end subgraph P2["Phase 2: Pass 代码生成"] B1["输入：规范 + LLVM Pass 模板 + API 文档 + MBA 模式库"] B2["LLM 生成"] B3["C++ 源码 / CMakeLists / lit 测试 / 设计文档"] B1 --> B2 --> B3 end subgraph P3["Phase 3: 自动化验证"] C1["编译验证<br/>cmake .. && make"] C2["语义等价验证<br/>原始 IR vs 混淆 IR 执行结果 R1 == R2"] C3["Alive2 形式化验证"] C4["混淆强度评估<br/>复杂度 / 反编译可读性"] C1 --> C2 --> C3 --> C4 C1 -.失败.->|错误反馈 LLM| B2 C2 -.失败.->|语义错误反馈 LLM| B2 C3 -.反例.->|反馈 LLM| B2 C4 -.不足.->|增强反馈| B2 end subgraph P4["Phase 4: 对抗性测试"] D1["LLM 反混淆攻击"] D2["符号执行攻击 angr/Triton"] D3["模式匹配攻击 SSPAM/MBA-Blast"] D1 --> D2 --> D3 D2 -.发现弱点.->|增强混淆| B2 end subgraph P5["Phase 5: 产出与集成"] E1["obfuscation-pass/<br/>源码 / 头文件 / CMake / 测试 / 文档"] E2["opt -load-pass-plugin=... -passes=mba-sub"] E1 --> E2 end P1 --> P2 --> P3 --> P4 --> P5

实际代码示例

LLM 生成的 MBA 替换 Pass 核心逻辑（简化）：

// 由 LLM 自动生成的 LLVM MBA Substitution Pass // Phase 2 产出 → Phase 3 验证通过 #include "llvm/IR/IRBuilder.h" #include "llvm/IR/PassManager.h" #include "llvm/Passes/PassBuilder.h" #include <random> using namespace llvm; struct MBASubstitutionPass : public PassInfoMixin<MBASubstitutionPass> { PreservedAnalyses run(Function &F, FunctionAnalysisManager &AM) { std::mt19937 rng(std::random_device{}()); bool changed = false; for (auto &BB : F) { for (auto it = BB.begin(); it != BB.end(); ) { Instruction &I = *it++; if (auto *binop = dyn_cast<BinaryOperator>(&I)) { if (binop->getOpcode() == Instruction::Add) { changed |= substituteAdd(binop, rng); } } } } return changed ? PreservedAnalyses::none() : PreservedAnalyses::all(); } private: bool substituteAdd(BinaryOperator *op, std::mt19937 &rng) { IRBuilder<> builder(op); Value *x = op->getOperand(0); Value *y = op->getOperand(1); Value *result = nullptr; // 随机选择 MBA 等价变换 switch (std::uniform_int_distribution<>(0, 2)(rng)) { case 0: // x + y = (x ^ y) + 2 * (x & y) result = builder.CreateAdd( builder.CreateXor(x, y), builder.CreateShl(builder.CreateAnd(x, y), 1)); break; case 1: // x + y = (x | y) + (x & y) result = builder.CreateAdd( builder.CreateOr(x, y), builder.CreateAnd(x, y)); break; case 2: // x + y = 2*(x | y) - (x ^ y) result = builder.CreateSub( builder.CreateShl(builder.CreateOr(x, y), 1), builder.CreateXor(x, y)); break; } op->replaceAllUsesWith(result); op->eraseFromParent(); return true; } };

15.4.2 对抗训练：混淆生成器 vs 反混淆器

GAN（Generative Adversarial Network，生成对抗网络）式博弈框架将混淆问题建模为两个对抗者的零和博弈：

15.4.3 代码多样性生成

LLM 的创造力使得"同一逻辑、无限实现"成为可能——这是随机化混淆的终极形态：

工程实现要点：

1. 等价性保证：每个变体必须通过模糊测试（fuzz testing）和形式化验证（如 Alive2 [18]）确认与原始实现语义等价。
2. 多样性度量：使用编辑距离、AST 差异、控制流图相似度等指标量化变体之间的差异，确保足够的多样性。
3. 选择策略：结合设备指纹和时间戳作为随机种子，确保同一设备的不同版本使用不同变体，增加攻击者的追踪难度。

15.5 量子计算对混淆的影响

知识定位：理论支撑。量子计算机目前尚不具备破解现有密码体系的实际能力（本节也说明了这一点），这里讲的是"Shor/Grover 算法威胁哪些密码原语"以及"后量子迁移路径"这类风险评估性质的知识，用来理解长期安全规划的逻辑，不是你现阶段需要动手部署的内容。15.5.3 的迁移路径时间表可以作为未来几年需要关注的节点记一下即可。

15.5.1 量子计算的威胁全景

量子计算机的发展对密码学和混淆技术的安全基础产生深远影响：

15.5.2 对混淆技术的具体影响

对对称密码混淆原语的影响

许多混淆方案依赖对称密码原语（如 AES、哈希函数）进行完整性校验或代码加密：

对不可区分混淆（iO）的影响

不可区分混淆（indistinguishability Obfuscation, iO）是混淆理论的"终极目标"：

• 经典世界：2020 年 Jain-Lin-Sahai 证明了基于标准假设（LWE + 一些额外假设）的 iO 构造存在性 [3]。
• 量子世界：
• LWE 假设被认为后量子安全 → iO 的安全性基础部分得到保留。
• 但 iO 构造中使用的某些中间工具（如特定的伪随机函数族）的量子安全性需要重新评估。
• 量子计算机可能提供新的攻击途径——如量子多项式插值可能加速对混淆电路的分析。

对虚拟化混淆的影响

量子计算对当前工程中广泛使用的虚拟化混淆（VM-based obfuscation）的影响相对有限：

虚拟化混淆的安全性来源: 1. 自定义指令集的复杂度 — 量子计算无直接加速 2. handler 之间的耦合关系 — 量子搜索可能加速模式匹配 3. 指令调度的不确定性 — Grover 搜索可加速约 √N 4. 反调试/完整性校验 — 对称密码需升级密钥长度 结论: 虚拟化混淆不依赖量子脆弱的密码假设, 因此受量子计算的直接威胁较小。 但基于密码学构造的混淆层需要升级。

15.5.3 后量子混淆方案

面向量子时代的混淆方案需要满足以下要求：

1. 后量子安全的代码加密：使用基于格的加密方案（如 Kyber/ML-KEM [8]）替代 RSA/ECC 进行密钥交换和代码段加密。
2. 后量子安全的签名验证：使用 CRYSTALS-Dilithium [9] 或 SPHINCS+ 替代 ECDSA 进行代码完整性验证。
3. 后量子安全的白盒密码：研发基于格困难问题的白盒密码方案（当前仍处于早期研究阶段）。
4. 量子安全的不可区分混淆：探索全面基于后量子假设的 iO 构造。

15.6 混淆技术发展路线图（2026–2030 预测）

知识定位：理论支撑/前瞻展望。这是作者对未来五年的预测性汇总，置信度一栏已经明确标注了每条预测的确定程度，本质是"行业趋势参考资料"，用于做技术投入的时间规划，不是需要掌握的操作性知识，也不应被当作确定会发生的事实。

15.6.1 总览

15.6.2 分年预测

2026：LLM 攻防元年

2027：硬件 TEE 普及

2028：AI 原生混淆

2029：后量子迁移

2030：自适应混淆

15.6.3 关键不确定性因素

影响路线图的主要变量: 1. 量子计算进展速度 乐观: 2029 年出现密码学相关量子计算机 → 加速后量子迁移 悲观: 2035 年前不构成实际威胁 → 迁移压力推迟 2. LLM 能力上限 乐观: ASI 级模型可完全自动化逆向 → 混淆价值大幅降低 悲观: LLM 在程序推理上遇到理论瓶颈 → 混淆仍然有效 3. FHE 硬件加速 乐观: 专用芯片将开销降至 10× → 通用 FHE 保护可行 悲观: 物理限制使开销停留在 1000× → 仅限小规模关键计算 4. 监管环境 若各国要求软件可审计 → 混淆技术受到法律限制 若知识产权保护加强 → 混淆技术得到政策支持 5. 开源 vs 闭源生态演化 开源主导 → 混淆需求降低，但模型保护需求上升 闭源主导 → 混淆作为商业核心竞争力持续发展

参考资料

学术论文

[1] Regev, O. (2005). "On lattices, learning with errors, random linear codes, and cryptography."Journal of the ACM, 56(6), 1-40. — LWE 问题的开创性论文。

[2] Gentry, C. (2009). "Fully homomorphic encryption using ideal lattices."STOC '09, 169-178. — 首个 FHE 方案。

[3] Jain, A., Lin, H., & Sahai, A. (2021). "Indistinguishability obfuscation from well-founded assumptions."STOC '21, 60-73. — 基于标准假设的 iO 构造。

[4] Adi, Y., Baum, C., Cissé, M., Pinber, B., & Goldberg, J. (2018). "Turning your weakness into a strength: Watermarking deep reinforcement learning agents."ICML 2018. — 后门型神经网络水印。

[5] Chillotti, I., Gama, N., Georgieva, M., & Izabachène, M. (2020). "TFHE: Fast fully homomorphic encryption over the torus."Journal of Cryptology, 33(1), 34-91. — TFHE 方案。

[6] Shor, P. W. (1997). "Polynomial-time algorithms for prime factorization and discrete logarithms on a quantum computer."SIAM Journal on Computing, 26(5), 1484-1509. — Shor 算法。

[7] Grover, L. K. (1996). "A fast quantum mechanical algorithm for database search."STOC '96, 212-219. — Grover 搜索算法。

技术标准与规范

[8] NIST FIPS 203 (2024).Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM). — 后量子密钥封装标准（Kyber）。

[9] NIST FIPS 204 (2024).Module-Lattice-Based Digital Signature Standard (ML-DSA). — 后量子数字签名标准（Dilithium）。

[10] ARM Architecture Reference Manual (2025).Realm Management Extension (RME) for ARMv9-A. — ARM CCA 架构参考。

[11] Intel Corporation (2023).Intel Trust Domain Extensions (TDX) Module Architecture Specification. — Intel TDX 架构规范。

[12] GGUF Format Specification, llama.cpp project. https://github.com/ggerganov/ggml/blob/master/docs/gguf.md — GGUF 格式规范。

[13] ONNX Specification v1.16 (2024). https://onnx.ai/onnx/repo-docs/IR.html — ONNX IR 规范。

工具与框架

[14] Zama Concrete (2026). https://docs.zama.ai/concrete — FHE 编译器和运行时。

[15] Microsoft SEAL v4.1. https://github.com/microsoft/SEAL — FHE 库。

[16] OpenFHE v1.2. https://github.com/openfheorg/openfhe-development — 开源 FHE 库。

[17] LLVM Project. https://llvm.org/ — 编译器基础设施。

[18] Alive2. https://alive2.llvm.org/ — LLVM IR 变换验证工具。

行业报告

[19] Gartner (2026). "Hype Cycle for Post-Quantum Cryptography." — 后量子密码成熟度分析。

[20] DARPA DPRIVE Program (2024-2027). "Data Protection in Virtual Environments." — FHE 硬件加速研究项目。

[21] Arm (2025). "Confidential Computing on Arm: A Technical Overview of CCA." — ARM CCA 技术白皮书。