可信执行环境在跨组织多模型一致性检查中的保密性与可行性

《Journal of Systems and Software》：Confidentiality and practicality of trusted execution environments for cross-organizational multi-model consistency checking

　　

# 摘要

在跨组织工程项目中，保密性保持的一致性检查至关重要，各方虽需联合处理模型数据，但彼此之间可能存在不信任或不愿披露数据的倾向。当数据在所有者受控环境之外被访问、传输或临时存储时，此类处理会产生保密性风险。可信执行环境（TEE）可通过隔离计算和远程证明降低这些风险，但TEE在此领域的安全性和实用性仍未得到充分理解。本文并未提出新的TEE安全机制或架构，而是基于明确的系统和威胁模型，系统性地识别多模型一致性检查工作流中的漏洞，并将其与已有的TEE保证进行映射。分析表明，TEE可以缓解关键威胁，尤其在运行时处理阶段，但并不能完全解决在设置、交互和结果披露阶段中存在的泄露和信任建立风险。部分剩余漏洞需要补充保障措施，包括基于证明的配置、分布式信任或受控结果披露。一个原型实现评估了TEE保护的一致性检查的实际开销和可扩展性，并证明了其在代表性工作负载下的可行性。所得的领域特定评估阐明了TEE用于保密性多模型一致性检查的安全保证、局限性及实际适用性。

# 引言

现代工程项目越来越多地要求跨组织边界的协作。系统供应商、分包商和领域专家贡献了描述架构、功能、行为和约束的模型。确保这些模型之间的一致性是一项基本的工程活动，因为不一致可能会传播为操作故障或合同纠纷（Feldmann, 2019, Torres et al., 2020）。然而，跨组织边界的一致性检查在已有一致性检查挑战（Bergemann, 2022）中提出了一个新的核心挑战：根据项目和上下文的不同，模型数据可能高度机密，各组织可能彼此之间的信任程度不足以在没有保护措施的情况下交换数据进行一致性检查。这一保密性问题不仅限于组织层面，也可能发生在公司内部的部门、团队甚至个人之间，因此我们在本文余下部分使用"方"这一术语来包含所有这些主体。第5节中的供应商集成示例使这一保密性冲突变得具体化。

当前实践通常依赖双边交换、混淆的模型片段或保密协议，但其中任何一种都无法扩展或可靠地防止泄露（Bergemann, 2023, Starnecker, 2024, Zeiringer and Thalmann, 2022）。实践中反复出现的一种解决方案是简单地拒绝任何自动化模型一致性检查，这可能导致系统不一致，从而增加修正和集成成本。因此，需要一种保密性保持的一致性检查解决方案，该方案能够使用来自不同模型的组合信息执行一致性检查，而不向其他检查方、托管基础设施或外部攻击者泄露机密细节（Bergemann, 2023）。其他领域的相关挑战促使我们考虑隐私增强技术（Cheng et al., 2019, Kairouz et al., 2021, Mohassel and Zhang, 2017），包括安全多方计算（SMPC）、同态加密（HE）和TEE（见第2节）。在这些技术中，TEE可以通过在硬件保护区域内执行现有检查逻辑来容纳，从而将数据与特权主机软件隔离（Geppert et al., 2022, Sabt et al., 2015）。

然而，TEE用于多模型一致性检查的安全性和实用性仍未得到充分理解。多模型一致性检查是一个迭代、有状态且依赖数据的过程：规则在异构的互连模型集合上进行评估，处理数据的信息也可能从执行模式、内存访问模式、中间状态或反馈差异中推断出来。同样，TEE很可能由参与方之一实例化，该方可能在设置、证明或数据配置期间表现出恶意行为。这些特征要求对TEE保护进行领域特定评估。

现有的TEE攻击研究并未确定这些环境能缓解哪些跨组织一致性检查（COCC）漏洞或需要哪些补充保障措施（第3节）。它们对代表性检查工作负载的实际执行时间开销也需要评估。

我们通过三个研究问题来调查这些空白。

**RQ1** 在互相不信任的各方和模型数据保密性要求的假设下，在完整的一致性检查工作流中会出现哪些攻击面？这些攻击面在多大程度上可以通过结构化分析和经验探索来系统性地识别？

**RQ2** 鉴于已识别的攻击面，并假设在共同的TEE中执行一致性检查，RQ1中哪些漏洞可以通过TEE内置保证来缓解，哪些需要额外的安全机制？

**RQ3** 假设一个代表性的一致性检查实现，TEE保护的COCC工作流相对于非安全基线引入了多少实际执行时间开销？

我们通过贡献一个系统的、领域特定的分析来回答这些问题，涵盖工作流、其保密性漏洞、适用的TEE保证、剩余威胁以及所得保护方案的可行性。本文并未引入新的TEE原语或安全架构。

**C1** 一项结构化分析，识别COCC中的数据保密性漏洞并将其映射到COCC阶段和攻击者能力，从而实现TEE适用性的全面评估。

**C2** 一项系统的、领域特定的TEE应用于COCC的漏洞评估，评估C1中识别的漏洞中哪些可以通过TEE缓解，哪些不能，形成一个结构化的缓解和剩余漏洞目录。

**C3** 一个TEE保护的一致性检查工作流原型实现和经验评估，展示其可行性和实际开销。

研究结果指导TEE在COCC中的使用，并指出需要补充保障措施的地方。

支撑本工作的初步想法此前在一篇简短的工作坊论文中已有概述（Zhu et al., 2026），该文引入了评估TEE-based COCC中保密性漏洞的概念。本文通过结构化评估方法、保证与漏洞映射以及基于原型的经验评估扩展了该工作。

第2节背景、第3节相关工作建立背景和研究语境。第4节方法论、第5节运行示例介绍方法论和运行示例。第6节识别COCC漏洞，第7节评估TEE对其的缓解。第8节原型实现、第9节功能评估展示原型和评估，随后是第10节讨论和第11节结论。

# 第2节 背景

本节定义分析中使用的模型一致性和保密计算概念。

# 第3节 相关工作

在第2节基础上，我们回顾一致性检查、保密性保持协作、保密计算和TEE攻击。

# 第4节 方法论

本工作遵循一种结构化的安全分析方法论，结合工作流分解、威胁建模和TEE能力的评估。表1总结了三个层次：机制无关的漏洞分析、映射到TEE保证、以及基于原型的行为评估。

# 第5节 运行示例

为说明跨组织一致性检查期间出现的保密性挑战，以下章节使用一个协作汽车制动场景作为运行示例。这是一个构造的插图，并非工业案例研究。相关工程工作将制动和车辆模型跨越仿真工具进行组合（Berzi et al., 2019），但以下各方、保密政策和检查情况均为示意性的。

假设一个电机供应商修订了……

# 第6节 COCC中的数据保密性漏洞

本节识别和分类COCC生命周期中的保密性漏洞，构成我们分析的第一层（表1）。系统模型（第6.1节）、工作流（第6.2节）和威胁模型（第6.3节）为漏洞分类体系（第6.4节）提供基础。

# 第7节 基于TEE的解决方案的缓解措施和剩余漏洞

本节将TEE保证映射到第6节中识别的漏洞，并检查剩余风险，构成我们分析的第二层（表1）。

在第2.2节TEE背景的基础上，我们首先规定与COCC相关的保证。

# 第8节 原型实现

原型测试现有的多模型一致性检查器能否在TEE中无修改运行，并通过标准安全通信与远程工具交互。它支持第9节中的可行性评估，而非优化飞地特定的执行。

# 第9节 功能评估

本评估测量原型的可行性和端到端延迟开销（第8节），而非提供生产规模的工业基准。它实现了表1中的经验评估层。

我们关注每次检查的延迟而非设置时间。在假设的部署中，检查器持续运行或隔夜重启，将飞地创建和安全通道建立的成本摊薄到多次检查中。因此每次检查的延迟更能反映日常……

# 第10节 讨论

本节讨论研究结果的范围和影响，并回答第1.1节中的研究问题。

# 第11节 结论

本文调查了TEE在跨组织工程中用于保密性保持的多模型一致性检查。我们未贡献新的安全机制或架构，而是一个系统的、领域特定的COCC漏洞分析、将其映射到已有的TEE保证、识别剩余威胁以及对实际可行性的经验评估。

结果表明，虽然TEE在运行时执行期间提供了强大保护，但它们并不能……

## CRediT作者贡献声明

Sebastian Bergemann：写作 – 审阅与编辑，写作 – 原稿，可视化，验证，软件，方法论，调查，形式化分析，数据整理，构思。Derui Zhu：写作 – 审阅与编辑，写作 – 原稿，可视化，方法论，调查，形式化分析，构思。Andreas Bayha：写作 – 审阅与编辑，监督，调查，资金获取。Mohammad Sadeghi：写作 – 审阅与编辑，调查。

## 关于生成式AI和AI辅助技术在论文准备过程中的声明

在准备本工作过程中，作者使用了OpenAI ChatGPT（5.2和6）来缩短和润色论文文本。在使用该工具后，作者对内容进行了审阅和编辑，并对发表文章的内容承担全部责任。

## 利益冲突声明

作者声明没有已知的竞争性财务利益或个人关系可能影响本文所述工作。

## 致谢

本工作由德国研究基金会（DFG）资助 – SFB 1608 – 501798263。本工作由德国联邦经济和能源部（BMWE）通过ZIM项目DigiSemNet（KK5137406RG4）支持。

---

**作者信息：** Sebastian Bergemann | Derui Zhu | Andreas Bayha | Mohammad Sadeghi | Colin Atkinson | Alexander Pretschner，fortiss，巴伐利亚自由州软件密集型系统研究与转移研究所，德国