文章总结： 文档以电脑配件组合问题引出密码学协议的组合安全挑战，详细阐述通用可组合安全框架的核心思想：通过理想功能定义安全目标，利用模拟器证明安全性，依靠通用组合定理保证模块化组合后的安全性。以Needham-Schroeder协议为例展示组合攻击风险，介绍UC框架的优势、局限性及变体，为复杂密码系统设计提供理论基础。 综合评分： 82 文章分类： 其他,安全建设,应用安全,技术标准

---

【密码学】通用可组合安全(UC)

sec0nd安全

2026年2月21日 16:47 河北

以下文章来源于Coder小Q ，作者Litt1eQ

Coder小Q .

简单记录一下编程过程中遇到的一些坑

【密码学】通用可组合安全(UC)

Bob

Alice，我最近遇到一个很有意思的问题。你知道的，我这台电脑用了好几年了，最近想升级一下。我在网上买了新的显卡、内存条和SSD。

B

AAlice

挺好的，升级配件总是让人兴奋。遇到什么问题了吗？

Bob

问题就来了。我分别测试了每个配件——显卡单独装上去，跑分正常；内存条单独测试，也没问题；SSD也能正常读写。但是当我把这三个配件一起装上的时候，电脑却意外死机了。反复试了好几次都是这样。这太奇怪了，每个部件单独都能工作，为什么组合在一起就出问题？

B

EEve

这个问题在计算机系统设计中很常见。你以为验证了单个组件的功能就够了，但实际上组件之间会相互影响。比如你的新显卡可能功耗很高，和原来的电源配合没问题，但加上新内存和SSD后，总功耗超过了电源的承载能力。或者新显卡和某个内存条在同一条PCIe总线上有地址冲突。单个组件的测试，并不能保证它们组合后的安全性。

AAlice

这正是密码学协议设计中极为棘手的问题。我们把它叫做组合安全性问题（Composable Security）。一个密码协议可能在单独测试时看起来很安全，但当它和其他协议一起运行时，可能就完全不安全了。

Bob

密码协议也会这样？能举个具体例子吗？

B

AAlice

当然。最经典的例子是1978年提出的Needham-Schroeder密钥交换协议。这个协议的目标很简单：让两个人（比如Alice和Bob）通过不安全的网络，建立一个只有他们知道的共享密钥。

协议的工作流程是这样的：

1. Alice生成一个随机数 ，用Bob的公钥加密后发给Bob：
2. Bob收到后解密，生成自己的随机数 ，用Alice的公钥加密后发回：
3. Alice验证  确实是自己发的，然后用Bob的公钥加密  发回：
4. Bob验证后，双方就用  作为共享密钥

Bob

听起来挺合理的。Alice和Bob都验证了对方确实收到了正确的随机数，而且随机数被加密保护，外人看不到。这有什么问题吗？

B

EEve

单独看这个协议，确实很安全，它满足两个核心性质：

1. 密钥一致性：如果Alice和Bob都认为建立了密钥，那这个密钥一定是
2. 密钥保密性：攻击者只能看到加密的消息，无法得知

在1978到1995年间，大家都认为这个协议是安全的。但问题在于——

AAlice

问题在于这个协议被设计成只用一次。如果有人用这个协议建立密钥后，又用这个密钥去加密消息，整个系统就崩溃了。

Bob

为什么？建立密钥不就是为了用来加密吗？

B

AAlice

让我给你演示一个攻击。假设Alice和Bob正在运行Needham-Schroeder协议。在协议的最后阶段，Alice发送了密钥确认消息（即用Bob公钥加密的 ），并且她认为连接已经建立，紧接着用这个密钥  加密了一条消息发给Bob。

Bob

这很常见，为了提高效率，我们经常在握手完成前就发送数据。

B

AAlice

没错。假设这条消息很简单，只有两个词：”buy”（买入）或”sell”（卖出）。加密方式是用一次性密码本（One-Time Pad），即密文 。

EEve

现在我作为攻击者登场了。我控制了网络，截获了Alice发给Bob的两条消息：

1. 密钥确认消息：
2. 密文：

EEve

我把原始的密钥确认消息  丢弃（或拦截下来），不让Bob收到。然后，我利用密文  来伪造一个新的密钥确认消息。

Bob

等等，你不知道 ，怎么伪造？

B

EEve

我不需要知道 。我猜测消息是 “sell”。于是我计算 。如果原始消息真的是 “sell”，那么 。 此时 。看，我算出了正确的密钥。

EEve

然后，我用Bob的公钥加密这个 ，即 ，把它作为“密钥确认消息”发给Bob。

Bob

我收到  后，会解密得到 ，然后检查它是否等于我生成的随机数 。

B

EEve

正是，

• 如果消息是 “sell”，那么 ，你会验证通过，接受连接。
• 如果消息是 “buy”，那么 ，你会验证失败，拒绝连接（报错）。

EEve

所以我只要观察Bob你是“接受连接”还是“报错”，就能确切地知道Alice发的消息是 “buy” 还是 “sell”。我完全破解了消息内容，但我从未直接破解加密算法，也没有破解密钥。

Bob

这种手段确实非常隐蔽。但这不是加密算法的问题，也不是密钥交换协议本身的问题——单独看它们都是安全的。问题出在组合上？

B

AAlice

你说得很对。Needham-Schroeder协议本身满足”密钥保密性”，一次性密码本也满足”完美保密性”。但当你把它们组合在一起使用时，攻击者可以把Bob变成一个解密预言机——通过发起新的密钥交换，诱导Bob用密钥  进行运算，从而间接泄露信息。

Bob

那怎么办？每次分析一个协议，都要把它可能和其他协议组合的所有情况都考虑一遍？那工作量确实太大了。

B

AAlice

这就是密码学在1990年代面临的困境。当时的安全定义都是特定协议、特定场景的：

• 语义安全的加密
• 零知识的证明
• 安全的密钥交换
• 安全的函数求值

每个定义都很精确，但它们的安全性保证只在孤立执行时有效。一旦协议在真实环境中运行——和其他协议并发、共享状态、相互调用——原有的安全保证可能就失效了。

EEve

更糟糕的是，协议设计者根本无法预见未来会出现什么样的应用场景。你今天设计了一个加密协议，声称”在没有其他协议干扰时是安全的”，但用户可能会把它和你完全想不到的其他协议组合使用。这就像Bob买电脑配件——显卡厂商测试时不知道你会配什么内存，内存厂商也不知道你会配什么显卡。

AAlice

所以密码学界在2000年前后开始思考：能不能有一种安全定义，保证协议在任意环境下都安全？ 就像电脑配件有个统一标准（比如PCIe接口、电压规范），只要单个配件符合标准，它们组合起来就不会出问题。

这就是通用可组合安全（Universally Composable Security，简称UC安全）[1]的诞生背景。

Bob

听起来很理想，但怎么做到呢？

B

AAlice

UC安全的核心思想是：不要直接定义什么是”安全”，而是定义协议应该实现什么”理想功能”。

让我用一个比喻来解释。假设你要评价一个银行转账系统是否安全。传统方法是列举一堆性质：

• 攻击者不能伪造转账
• 攻击者不能修改金额
• 攻击者不能重放旧的转账请求
• …

但这个列表可能永远列不完，总有你没想到的攻击。

AAlice

UC安全换了一种思路。我们想象一个理想的转账系统：有一个完全可信的第三方（比如上帝），Alice想转账给Bob时，直接告诉上帝”我要给Bob转100元”，上帝从Alice账户扣100元，给Bob账户加100元。这个系统显然是安全的——因为所有操作都由可信方执行，攻击者根本插不上手。

然后我们说：一个真实的转账协议是”UC安全的”，如果它的效果和这个理想系统一样好。

Bob

但真实世界没有上帝啊。怎么判断”一样好”？

B

AAlice

这就是UC框架的精妙之处。我们用模拟（Simulation）来定义”一样好”。

想象一个环境 （Environment），它代表协议运行的外部世界——可能是用户，可能是其他协议，总之是所有会和我们的协议交互的东西。环境  可以：

1. 给协议发送输入
2. 接收协议的输出
3. 观察协议的运行（比如网络通信）

同时，环境还会面对一个对手 （Adversary），对手可以控制网络、窃听消息、甚至攻破某些参与者。

EEve

让我补充一下对手的能力。在UC模型中，对手非常强大：

• 控制网络：可以延迟、删除、修改、重排所有网络消息
• 主动攻击：可以伪造消息、发起假的协议会话
• 适应性腐败：可以在协议运行过程中动态攻破某些参与方，获取他们的秘密状态

这比现实中的攻击者还要强大。我们给对手这么大的能力，是为了确保安全定义足够保守。

AAlice

现在，我们说一个真实协议  UC-实现了理想功能 ，需要满足：

对于任意对手 ，都存在一个模拟器 ，使得对于任意环境 ：

环境与交互环境与交互

这里的  表示”计算上不可区分”——环境  无法通过观察输入输出和通信，判断自己到底是在和真实协议  交互，还是在和理想功能  交互。

Bob

等等，模拟器  是什么？

B

AAlice

模拟器是一个非常关键的概念。在真实世界中，对手  可以攻击协议 ——窃听、篡改、攻破参与者。在理想世界中，协议被理想功能  替代了， 由可信第三方运行，对手似乎无事可做。

但这还不够公平——我们需要给理想世界的对手  一些能力，让它能模拟出真实对手  在真实世界中能造成的影响。比如：

• 如果  能延迟消息， 也应该能延迟  的输出
• 如果  能攻破某个参与者， 也应该能让  “泄露”相应的信息

EEve

关键在于：模拟器  只能通过  的”后门接口”（backdoor）来影响系统。 在设计时就规定了哪些信息可以泄露给 ，哪些操作可以被  延迟或影响。这些”允许的影响”，就代表了我们认为不可避免的、可接受的安全损失。

Bob

你能举个具体例子吗？比如刚才说的转账系统。

B

AAlice

好的。让我们定义一个认证通信的理想功能 。它的目标是：Alice能可靠地给Bob发送消息，但不保证消息内容的保密性。

最简单的定义可能是：

收到的输入就立即输出给

EEve

但这有些过于理想化了。这个定义意味着：

1. 消息瞬间送达（没有延迟）
2. 对手连消息内容都看不到

在真实世界中，即使用最好的认证协议（比如MAC），对手也能看到密文，也能控制消息何时送达。所以这个理想功能无法被实现。

AAlice

所以我们需要放宽理想功能，给对手一些”后门权限”。改进版的  是这样的：

收到的输入发送给模拟器（泄露消息内容和通信方）等待返回输出给

Bob

所以模拟器能看到消息，还能决定什么时候送达？

B

AAlice

没错。这就是  对”认证但不保密”的形式化定义：

• 功能性保证：Bob最终收到的消息确实是Alice发送的 （认证性）
• 允许的泄露：消息内容 、通信双方身份（对应真实世界中对手能看到密文）
• 允许的影响：对手可以任意延迟消息，但不能修改或丢弃（对应真实世界中对手控制网络）

现在可以证明：用HMAC或签名实现的认证通信协议，能够UC-实现 。

Bob

我明白理想功能的概念了。但这和组合安全性有什么关系？

B

AAlice

这就是UC框架最强大的部分——通用组合定理（Universal Composition Theorem）。

定理的表述非常简洁：

如果协议  UC-实现了理想功能 ，那么在任何使用  的上层协议  中，你可以用  替换 ，安全性不会降低。

形式化地说：如果 （ UC-实现 ），那么对于任何协议 （使用  作为子协议）：

这里  表示把  中所有对  的调用替换成对  的调用。

EEve

让我解释这个定理的威力。假设你要设计一个复杂的电子投票系统，它需要：

1. 认证通信：选民提交选票
2. 密钥交换：选举官员建立安全通道
3. 零知识证明：证明选票格式正确但不泄露内容
4. 安全多方计算：统计票数

传统方法需要分析这4个协议所有可能的组合方式、并发场景、状态共享……这是个组合爆炸的问题。

AAlice

但在UC框架下，你只需要：

1. 定义理想功能：分别定义 , , ,
2. 设计顶层协议：设计投票协议 ，假设它可以调用这些理想功能
3. 分析顶层协议：证明  在有这些理想功能的帮助下，实现了理想的投票功能
4. 替换底层实现：找到UC-实现各个理想功能的真实协议 ，用它们替换理想功能

通用组合定理保证：替换后的系统  仍然UC-实现 。

Bob

这确实很强大。但为什么这个定理成立？直觉上怎么理解？

B

AAlice

关键在于UC定义中的环境 。环境代表了”协议之外的整个世界”——包括所有其他协议、所有可能的并发执行、所有可能的状态共享。

当我们说  UC-实现  时，我们实际上在说：对于任意环境 （包括任意复杂的上层协议）， 在  中的表现和  一样好。

所以当你在上层协议  中用  替换  时，对于  之外的环境来说，看不出区别——因为  和  在任意环境下都不可区分。

EEve

这里有个技术细节值得注意。通用组合定理的证明依赖于虚拟对手（Dummy Adversary）引理：

引理：证明  UC-实现  时，只需要考虑一个特殊的对手 ——它只是简单地在环境  和协议之间转发消息，不做任何额外操作。如果存在模拟器  能模拟 ，那么对于任意其他对手 ，也存在相应的模拟器。

Bob

为什么？直觉上，对手应该很复杂才对，怎么只考虑”转发消息”这么简单的对手就够了？

B

AAlice

因为环境  已经代表了所有可能的攻击策略。一个复杂的对手 ，可以看作是环境  的一部分—— 生成攻击指令，通过虚拟对手  传递给协议。

形式化地：对于任意对手  和环境 ，可以构造一个新环境 ，它在内部运行 ，然后通过虚拟对手  与协议交互。从协议的角度看， 和  是等价的。

EEve

有了虚拟对手引理，通用组合定理的证明就很优雅了。假设：

• UC-实现 ，即存在模拟器  使得对于任意环境 ：
• 我们要证明  UC-实现

构造一个新的模拟器 ：它在内部运行  和 ，当环境发送消息给  的某部分时：

• 如果消息发给上层部分，转发给内部的
• 如果  调用了 ，让  执行，并把  的通信交给  处理

AAlice

关键观察是：对于环境 ，它看到的是：

• 真实世界： 与  和对手  交互
• 理想世界： 与  和模拟器  交互

由于  UC-实现 ，当  调用底层功能时， 无法区分调用的是  还是 。因此整体上  无法区分两个世界。

Bob

我理解了。但你之前说Needham-Schroeder协议的问题，在UC框架下怎么体现？

B

AAlice

这是一个很好的问题。Needham-Schroeder协议虽然满足传统的安全定义，但它不是UC-安全的。

让我们定义密钥交换的理想功能 ：

收到的输入生成随机密钥发送给等待返回输出给和

注意： 不允许  知道密钥  的任何信息，只知道谁在和谁交换密钥。

EEve

现在假设Needham-Schroeder协议UC-实现了 。那么应该存在一个模拟器 ，使得对于任意环境 （包括我之前描述的攻击环境）， 无法区分真实世界和理想世界。

但在真实世界中，攻击者可以：

1. 截获Alice加密后发给Bob的消息
2. 修改为
3. 冒充Alice和Bob进行密钥交换
4. 观察Bob是否接受  的解密

这个攻击能以概率1区分消息是”buy”还是”sell”。

AAlice

但在理想世界中， 生成的密钥  对模拟器  完全未知。 无法预测Bob会如何解密 ，因此无法模拟出Bob的行为。

这意味着：不存在模拟器  能让理想世界和真实世界不可区分。所以Needham-Schroeder不是UC-安全的。

Bob

所以UC安全的定义自动排除了组合攻击？

B

AAlice

确实是这样。UC定义要求协议在任意环境下都安全，而”任意环境”包括了：

• 环境可能用协议生成的密钥去加密消息
• 环境可能并发运行多个协议实例
• 环境可能让不同协议共享状态

所有这些组合场景都被”任意环境 “覆盖了。如果一个协议在某种组合场景下不安全，那一定存在某个环境  能区分真实世界和理想世界，因此它不是UC-安全的。

EEve

这也解释了为什么很多传统的”安全”协议在UC框架下不安全。比如：

• 传统零知识证明：在单独执行时是零知识的，但并发执行时可能泄露知识（这就是为什么需要”并发零知识”）
• 传统承诺方案：在单独使用时有hiding和binding性质，但在某些组合场景下可能被”伪造”（这就是为什么需要”non-malleable承诺”）

Bob

那是不是所有协议都应该追求UC安全？

B

AAlice

理论上是的，但实践中有权衡。UC安全的协议往往效率较低，因为它们要抵抗更强的攻击。而且，UC框架本身也有局限性：

1. 建模复杂性：定义一个准确的理想功能需要非常仔细的设计，容易出错
2. 效率开销：很多UC-安全的构造需要额外的密码学工具（如非交互零知识证明、CCA安全加密）
3. 并非所有性质都能建模：某些安全性质（如”公平性”）在标准UC框架下无法实现

Bob

你刚才说”公平性无法实现”，这是什么意思？

B

AAlice

公平性是指：在双方协议中，要么双方都获得输出，要么双方都不获得。比如在电子合同签署中，Alice和Bob应该同时获得对方的签名，不应该出现Alice拿到了Bob的签名，但Bob没拿到Alice的签名的情况。

Cleve在1986年证明了：在有恶意参与者的情况下，公平的双方计算在标准模型下是不可能的。这个不可能性结果在UC框架下依然成立。

EEve

直觉上很容易理解。在真实世界中，总有”最后一步”——最后一条消息总是由某一方发送的。发送方可以在发送前先看到对方的输出，然后决定是否继续。在理想世界中，可信第三方可以同时给双方输出，但这在真实世界中无法模拟。

AAlice

为了解决这类问题，密码学界发展了很多UC的变体：

• UC with timeout：引入时间概念，允许”如果对手延迟超过某个时间，诚实方可以中止”
• Generalized UC (GUC)：允许协议共享全局状态（如公钥基础设施PKI、随机预言机等）
• UC with super-polynomial simulators：放宽模拟器的效率要求，允许在某些场景下使用超多项式时间的模拟器

Bob

等等，为什么需要专门考虑”共享全局状态”？这不是很自然的吗？

B

AAlice

这又是一个微妙的问题。标准UC框架假设每个协议实例都有独立的状态。但在真实世界中，很多协议会共享某些资源：

• PKI：所有用户共享同一个公钥基础设施
• CRS（Common Reference String）：很多零知识证明协议需要一个公共参考串
• 随机预言机：哈希函数被建模为所有人都能访问的随机预言机

EEve

问题是：如果多个协议实例共享同一个全局状态，它们可能通过这个状态”隐蔽地通信”，产生标准UC框架无法捕捉的攻击。

举个例子：假设有两个协议实例  和 ，它们都使用同一个PKI。恶意的  可以通过精心选择的公钥，向  传递隐蔽信息（比如把秘密编码在公钥的低位比特中）。

AAlice

Generalized UC框架通过引入全局功能（Global Functionality）来解决这个问题。全局功能  可以被任意协议实例访问，而不仅仅是某个特定实例的子协议。

定义变成：协议  在全局功能  存在的情况下UC-实现 ，记作 。

组合定理仍然成立：如果  且 ，那么 。

Bob

我理解了。UC框架提供了一种”即插即用”的安全保证——只要每个组件都UC-实现了其理想功能，组合起来就是安全的，就像标准化的电脑配件一样。

B

AAlice

非常正确。这就是UC框架的核心价值：模块化的安全分析。

在UC框架出现之前，每次设计新协议都要从头分析安全性，考虑各种组合场景。现在，你可以：

1. 定义理想功能：明确协议应该实现什么
2. 单独分析：证明协议UC-实现理想功能
3. 自由组合：放心地把协议作为子模块使用

这极大地降低了密码协议设计的复杂性，也提高了安全性——因为安全保证在任意环境下都成立。

EEve

不过，我要补充一点现实考量。虽然UC框架在理论上很美好，但在实践中仍然面临挑战：

1. 性能开销：传统的高效协议（如标准Schnorr签名）通常不满足UC安全性；UC-安全的替代方案（如基于模拟提取的签名）往往效率较低
2. 建模困难：定义一个”正确”的理想功能需要深厚的密码学功底，稍有不慎就会定义出无法实现或过于宽松的功能
3. 证明复杂性：UC安全性证明通常比传统证明复杂得多，需要构造精巧的模拟器

AAlice

这些都是事实。但UC框架仍然是目前我们拥有的最强大的密码学安全分析工具。特别是在设计大型系统（如区块链、电子投票、安全多方计算）时，UC框架提供的组合保证是不可或缺的。

而且，随着研究的深入，我们正在开发更高效的UC-安全构造。比如：

• EasyUC：一个形式化的UC建模语言，简化了理想功能的定义和证明
• 高效的UC承诺：基于相关性可提取哈希函数，避免了昂贵的零知识证明
• UC with superpolynomial simulators：放宽模拟器的效率要求，允许更高效的协议

Bob

最后一个问题：你说UC框架保证”任意环境”下的安全性，但量子计算机算不算一种”环境”？如果未来量子计算机成熟了，现在的UC-安全协议还安全吗？

B

AAlice

这是一个非常有价值的问题。量子计算机是一个计算模型的变化，而不是”环境”的变化。UC框架建立在一定的计算假设上——比如”分解大整数是困难的”或”离散对数问题是困难的”。

如果这些假设被量子计算机打破（Shor算法可以高效分解和求离散对数），那么基于这些假设的UC-安全协议确实会失效。

EEve

但这不是UC框架的问题，而是底层密码学原语的问题。解决方案是：用后量子密码学（Post-Quantum Cryptography）替换掉那些不抗量子的原语。

只要新的原语仍然UC-实现相同的理想功能，组合定理保证整个系统仍然安全——这正是UC框架模块化的优势。你不需要重新分析整个系统，只需要替换底层的密码学构件。

AAlice

事实上，NIST在2024年正式发布的后量子密码标准（如Kyber、Dilithium），已经有研究者在分析它们的UC安全性。未来我们可能会看到完全基于后量子密码的UC-安全协议栈。

Bob

这确实非常精彩。所以UC框架不仅解决了协议组合的问题，还为未来的密码学演进提供了一个稳定的基础。就像电脑的接口标准——从并口到串口到USB，虽然底层技术在变，但标准化的接口让新旧设备可以平滑过渡。

B

AAlice

这个比喻非常贴切。UC框架的”理想功能”就是密码学的”接口标准”——它定义了功能，而不是实现。这种抽象让我们可以：

• 独立演进：改进底层实现，不影响上层应用
• 安全组合：确信组件组合后仍然安全
• 形式化保证：有严格的数学证明支撑

这就是为什么，20多年后的今天，UC框架仍然是密码学安全分析的黄金标准。

Bob

明白了。从一个简单的电脑配件问题，我们深入到了密码学最核心的挑战——如何在复杂的真实世界中保证安全性。UC框架给出了一个优雅的答案：通过理想功能定义目标，通过模拟证明实现，通过组合定理保证模块化。

B

EEve

而从攻击者的角度，UC框架也给我们上了重要的一课：单点的安全不等于系统的安全。Needham-Schroeder协议单独是安全的，一次性密码本也是完美保密的，但组合起来就出了问题。这提醒我们：安全分析必须考虑系统的整体行为，而不是孤立的组件。

本次对话，就这么愉快的结束了，接下来，Alice，Bob，和Eve又会遇到什么故事呢，且听下回分解。快乐的时光过得特别快，又到了说再见的时候了，咱们下次再见~

参考资料

1. Canetti, R. Universally Composable Security: A New Paradigm for Cryptographic Protocols. Proceedings of the 42nd IEEE Symposium on Foundations of Computer Science (FOCS), 136-145.

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：sec0nd安全 《【密码学】通用可组合安全(UC)》