0-RTT密钥交换的安全构造

0‐RTT密钥交换的简单安全定义与构造

Britta Hale¹(B)，Tibor Jager²,，Sebastian Lauer³, 和 Jörg Schwenk³
¹挪威科技大学，特隆赫姆，挪威 britta.hale@ntnu.no
²帕德博恩大学，帕德博恩，德国 tibor.jager@upb.de
³霍斯特 Görtz 研究所，鲁尔‐波鸿大学，波鸿，德国 {sebastian.lauer,joerg.schwenk}@rub.de

摘要

零往返时间（0‐RTT）密钥交换协议允许在无需事先进行加密密钥交换协议消息交互的情况下传输加密保护的有效载荷数据。0‐RTT密钥交换的概念最初由谷歌在QUIC Crypto协议中实现，且TLS 1.3中已对0‐RTT模式的引入进行了深入讨论。

在0‐RTT密钥交换中，会生成两个密钥，通常使用Diffie‐Hellman密钥交换来实现。第一个密钥由临时客户端共享和长期服务器共享组合而成。第二个密钥通过临时服务器共享和相同的临时客户端共享计算得出。

在本文中，我们提出了简单的安全模型，这些模型捕捉了已知0‐RTT密钥交换协议背后的核心思想：即使第二个（或第一个）密钥被泄露，第一个（或第二个）密钥也应与随机值不可区分。我们将此性质称为 strong key independence。此外，我们还基于通用假设——即安全的非交互式密钥交换（NIKE）存在，首次构造了在这些模型下可证明安全的0‐RTT密钥交换协议。

关键词 ：基础 · Low-latency密钥交换 · 0-RTT协议 · Authenticated密钥交换 · Non-interactive密钥交换 · QUIC · TLS 1.3

1 引言

在密钥建立之前需要交换的 消息 数量方面，效率是当今互联网协议日益关注的问题。基本上，第一代互联网 密钥交换协议 对效率并不十分重视，因为安全连接被认为是例外而非常态：SSL（2.0 和 3.0 版）和 TLS（1.0、1.1 和 1.2 版）在能够发送第一条加密保护的 有效载荷数据 之前，需要 2 个 往返时间 （RTT）来完成 密钥 建立。随着 加密 使用的增加，1效率变得

1例如，像 Let’s Encrypt (https://letsencrypt.org/) 这样的倡议。

c©施普林格国际出版公司 2017 年 D. Gollmann 等（编）：ACNS 2017， LNCS 10355，第 20–38 页，2017 年。DOI: 10.1007/978‐3‐319‐61204‐1 2

本文档由 funstory.ai 的开源 PDF 翻译库 BabelDOC v0.5.10 (http://yadt.io) 翻译，本仓库正在积极的建设当中，欢迎 star 和关注。

0‐RTT密钥交换的简单安全定义与构造 21

对于TLS等协议而言，这一点变得越来越重要。同样，较旧的IPSec IKE版本 v1需要3个RTT（激进模式+快速模式）到4.5个RTT（主模式+快速模式）。人们很快意识到这存在问题，因此在IKEv2中将RTT数量减少到了2个。

QUIC协议

从根本上说，低延迟密钥交换（又称LLKE、零RTT或0‐ RTT密钥交换）的讨论始于谷歌提出QUIC协议。2 QUIC（参见图1）通过在客户端缓存一个签名的服务器配置文件来实现低延迟，该文件包含一个中等生命周期的迪菲‐赫尔曼（DH）共享密钥 Y₀= gy₀。3

当客户端希望与服务器建立连接并拥有该服务器的有效配置文件时，它会选择一个新的临时DH共享X= gx，并从中计算出一个临时密钥 k₁。使用该密钥 k₁，客户端可以对要发送到服务器的数据进行加密和认证，并附带 X。作为响应，服务器发送一个新的DH共享 Y= gy，并从 gxy计算出一个会话密钥k₂，用于所有后续的数据交换。

2参见https://www.chromium.org/quic。 3如果客户端没有有效的文件，则必须从服务器请求，这会使 RTT 数量增加 1，但之后可用于未来会话的重用。

22 B. Hale et al

TLS 1.3

早期的TLS 1.3草案，例如draft-ietf-tls-tls13-08[25],包含一种0‐RTT密钥交换模式，其中客户端会缓存类似QUIC的 ServerConfiguration消息。当前版本draft-ietf-tls-tls13-18[26]采用了不同的方法，其中客户端与服务器之间的初始密钥建立从不采用0‐RTT方式。

相反，它定义了一种基于先前会话的密钥来建立新会话的方法。尽管在当前 TLS 1.3规范中这也被称为“0‐RTT”，但实际上更像是一种“0‐RTT会话恢复”协议，而不支持0‐RTT密钥建立。最重要的是，当前TLS 1.3草案与“真正”的0‐RTT密钥交换协议之间的主要区别在于，前者要求客户端在会话之间存储密钥信息。而相比之下，0‐RTT密钥建立协议不需要在会话之间存储密钥信息。

Facebook的Zero协议

最近，社交网络Facebook宣布其正在试验一种名为 Zero的0‐RTT密钥交换协议。4 Zero与QUIC非常相似，只是使用了不同的随机数以及对ServerHello消息进行加密。值得注意的是，Zero与QUIC之间的主要区别是为了防止Facebook发现的一种攻击而引入的，该攻击已报告给谷歌，并且目前在QUIC中也已被修复。我们认为，这是一个很好的例子，表明此类协议对简单安全性定义和可证明安全构造的需求。

安全目标

诸如QUIC之类的0‐RTT密钥交换协议采用临时设计，旨在实现三个目标：（1）0‐RTT加密，即密文数据可随第一条握手消息一并发送；（2）完美前向保密(PFS)，即在服务器的（静态或半静态）私钥泄露后，第二条握手消息之后传输的所有密文仍保持安全；（3）密钥独立性，即关于所生成的两个对称密钥之一的“已知”信息不应危及另一个密钥的安全性。

强密钥独立性

直观上，一个0‐RTT密钥交换协议应在 k₁和 k₂之间实现强密钥独立性；如果其中任何一个密钥在任何时候被泄露，另一个密钥仍然应与随机值不可区分。在所有已知的安全模型中，这一直观概念可形式化如下：如果攻击者 A对 k₁发起揭示查询，则他仍被允许对k₂发起测试查询，反之亦然。如果这两个密钥彼此计算上独立（也包括对不同协议消息的计算），则攻击者在正确回答测试查询时仅能具有可忽略的优势。

最终，这引出了以下研究问题：现有的0-RTT密钥交换协议示例是否具有强密钥独立性？我们能否描述一种通用方法来构建可证明实现强密钥独立性的 0-RTT密钥交换协议？

4参见 https://code.facebook.com/posts/608854979307125/building-zero-protocol-for-fast-secure-mobile-connections/。

0‐RTT密钥交换的简单安全定义与构造 23

QUIC 未提供强密钥独立性

如果攻击者 A被允许通过Reveal查询获取 k₁，那么他就能解密 AE(k₁; Y) 并重新加密其自己的值 Y ∗:= gy ∗为 AE(k₁; Y ∗)。此外，他随后可以计算出与客户端预言机相同的 k₂= Xy∗，从而能够区分“真实”密钥和Test查询所选的“随机”密钥。[11]有关 QUIC 中密钥依赖性的更多详细信息，请参见 注意，这一理论上的攻击并不意味着QUIC不安全。它仅表明在QUIC中用于建立 k₂的服务器迪菲‐赫尔曼共享值的真实性，在很大程度上依赖于密钥 k₁的安全性。因此，QUIC并未提供上述意义上的强密钥独立性。

0-RTT密钥交换的前期工作

0‐RTT密钥交换的概念并非在学术界发展而来，而是源于工业界——由分布式应用的具体实际需求所推动。此前所有关于 0‐RTT KE[11,23]的研究均对QUIC协议进行了事后安全性分析，并采用了定制化的模型。目前尚无基础性构造方案，且其与其他密码协议和原语之间的关系仍未得到充分理解。

在ACM CCS 2014上，Fischlin和Günther [11]提出了多阶段密钥交换协议的形式化定义，并用其分析了QUIC的安全性。Lychev等 [23]对QUIC给出了另一种分析，兼顾了效率与安全性。他们描述了一个专用于QUIC的安全模型，将[17]的复杂、整体式安全模型适配到该协议的需求中。赵 [31]研究了身份隐藏的0‐RTT协议，在该协议中，通过在通信方之间进行相互密码学认证的同时隐藏用户身份来保护用户隐私。Günther等 [14]扩展了格林和米尔斯 [13]的“可穿刺加密”方法，表明即使实现具有完全前向保密性的0‐RTT密钥交换也是可能的，方法是在每次解密后演进密钥。然而，他们的构造目前主要具有概念上的意义，因为尚不够高效，无法在实际中大规模部署。

安全模型

在本文中，我们使用卡内蒂‐克劳奇克[7]安全模型的一种变体。这类安全模型特别适用于仅有两次消息交换的协议，其中单轮密钥交换协议是最重要的一类。此类协议的常见示例包括MQV[22], HMQV [18], SMQV [27], KEA [21,24],和NAXOS [20]。不同版本的卡内蒂‐克劳奇克模型的比较可参见 [9,29]。

安全模型的简洁性的重要性

密钥交换协议的安全模型必须考虑能够修改、重放、注入、丢弃等操作通信方之间传输的任何消息的主动攻击者。它们还需要涵盖多个协议会话的并行执行、早期会话密钥的潜在泄露，以及参与方长期密钥的自适应泄露。这使得即使是标准的密钥交换安全模型也极为复杂（与大多数其他标准密码学原语，例如数字签名或公钥加密相比）。

24 B. Hale et al

显然，0‐RTT密钥交换这一新原语需要形式化的安全性定义。构建此类模型有多种方式。一种方法是注重模型的通用性。Fischlin 和 Günther[11]采用了这一路径，通过定义多阶段密钥交换协议——0‐RTT密钥交换的一种推广形式。这种方法的优势在于为研究一类非常广泛且新颖有趣的原语奠定了基础。

然而，其缺点在于这种通用性本身也给模型带来了巨大的复杂性。显然，安全模型越复杂，设计出新的、简单、高效且可证明安全的构造就越困难。此外，在复杂模型中的证明往往容易出错且不够直观，因为核心的技术思想可能被处理模型通用性所需的形式化细节所掩盖。

另一种方法是设计一种专门用于分析特定协议的模型。例如，复杂的整体式ACCE安全性模型在[17]中被提出，以对TLS进行事后安全性分析。5 Lychev 等[23],也采用了类似的方法，通过定义所谓的 Q‐ACCE模型，将该模型应用于QUIC的事后安全分析。这种方法的一个显著缺点是，这种定制化的模型往往只能捕捉现有协议所实现的性质，而未必涵盖我们对“良好”0‐RTT密钥交换协议所期望的所有性质。因此，一般来说，这类定制化模型并不能为新协议的设计提供有用的理论基础。

在本文中，我们采用了一种不同的方法。我们提出了针对0‐RTT密钥交换的新型“精简”安全模型，旨在捕捉所有（强密钥独立性和前向保密性），但又仅限于直观上对“良好”0‐RTT密钥交换协议所期望的性质。我们提出了两个不同的模型：一个考虑实际中常见的仅服务器认证情况（客户端可能在后续通过已建立的通信通道进行认证，这在思想上类似于[19]中仅服务器认证的 ACCE模型）；另一个则考虑传统的客户端与服务器之间的相互密码学认证。

与[11]中非常通用的多阶段安全模型相比，我们的定义在普遍性上的降低是有意为之的。一个仅捕捉但确实涵盖了对“良好”0‐RTT密钥交换协议所期望的所有属性的模型，使我们能够设计出相对简单、基础且通用的0‐RTT密钥交换协议构造，并实现尽可能清晰的安全性分析。

基础通用构造的重要性

继[3],之后，我们使用非交互式密钥交换（NIKE） [8,12]结合数字签名作为主要构建模块。6这产生了具有强密钥独立性的首批 0‐RTT密钥交换协议实例，以及基于通用复杂性假设的首批0‐RTT密钥交换协议构造。此类通用构造具有诸多优势：

5后来提出了一种更加模块化的方法，参见 [4]。 6回想一下，数字签名可由单向函数推出，而单向函数又可由NIKE推出。因此，本质上我们仅假设NIKE作为构建基础。

0‐RTT密钥交换的简单安全定义与构造 25

1. 通用构造有助于更好地理解协议的结构。由于我们使用的原语具有抽象安全属性，因此可以准确地看出实现0‐RTT密钥交换协议所需的抽象安全要求。
2. 它们阐明了不同类型的密码学原语之间的关系和影响。
3. 它们可以通过基于不同复杂性假设的构建模块进行通用实例化。例如，如果需要“后量子”安全性，则可以通过在通用构造中仅使用后量子安全的构建模块直接获得一个具体协议。

通常，通用构造相比特定构造会涉及更多的计算开销。然而，我们注意到，在拥有高效NIKE方案（例如[12], ）的情况下，我们的0‐RTT密钥交换协议可以相对高效地实例化。

贡献

本文的贡献可以总结如下 :

– 简洁的安全模型 。我们提供了简洁的安全模型，这些模型捕捉了我们对“良好”0‐RTT密钥交换协议所期望的全部安全属性，且仅限于这些属性。我们考虑了两种场景：一种是仅服务器认证的“实际”场景，另一种是具有相互认证的经典场景。
– 首个通用构造 。我们在上述两种场景中均给出了直观、相对简单且高效的0‐RTT密钥交换协议的构造方法。
– 首个非DH实例化 。QUIC和 TLS 1.3都基于DH密钥交换。我们的通用构造产生了首个不依赖于迪菲‐赫尔曼的0‐RTT密钥交换协议（例如，通过使用Freire等[12]提出的基于因子分解的NIKE方案来实例化该通用构造）。
– 首个实现强密钥独立性的0-RTT密钥交换 。我们的0‐RTT密钥交换协议是首个达到上述意义上强密钥独立性的协议。
– 建立在广泛认可的一般性假设之上 。该构造基于一般性假设，即安全的 NIKE方案和数字签名方案的存在性。对于所有构建模块，我们仅要求具备标准安全属性。
– 标准模型下的安全性 。安全性分析完全在标准模型下进行，即无需依赖随机预言启发式[1]，也不依赖非标准复杂性假设。
– 高效实例化能力 。尽管我们的构造是通用的，但所得协议仍可相对高效地实例化。

本文的完整版本。由于篇幅限制，我们不得不将若干结果推迟至本文的完整版本[15]。这包括定理1的完整安全证明、在相互认证下的0‐RTT协议（ 0-RTT-M）的定义与安全模型、一个0-RTT-M协议的构造及其安全模型和安全证明。

26 B. Hale et al

2 预备知识

对于我们在第4节中的构造，我们需要签名方案和非交互式密钥交换（NIKE） 协议。在这里，我们总结了这两种原语及其安全性的相关定义。

2.1 数字签名

一个数字签名方案由三个多项式时间算法 SIG= (SIG.Gen,SIG.Sign,SIG.Vfy) 组成。密钥生成算法 (sk,pk) ←$SIG.Gen(1λ) 在输入安全参数 λ 时生成一个公钥验证密钥 pk 和一个秘密签名密钥 sk。签名算法 σ ←$ SIG.Sign(sk, m) 为消息 m 生成一个签名。验证算法 SIG.Vfy(pk, σ, m) 在 σ 是在密钥 pk 下对 m 的有效签名时返回 1，否则返回 0。

考虑挑战者 C与攻击者 A之间进行的以下安全实验。

1. 挑战者生成一个公钥/密钥对 (sk,pk) ←$ SIG.Gen(1λ)，攻击者将 pk 作为输入接收。
2. 攻击者可以向挑战者查询任意消息 mi。挑战者对每个查询使用签名 σi= SIG.Sign(sk, mi) 进行响应。其中 i 是一个索引，取值范围为 1 ≤ i ≤ q， q ∈ N 为某个值。查询可以自适应地进行。
3. 最终，攻击者输出一个消息/签名对 (m, σ)。

定义 1 。我们在此游戏中将攻击者 A的优势定义为

$$
\text{Adv}_{\text{SIG},A}^{\text{sEUF-CMA}}(\lambda) := \Pr[(m, \sigma) \leftarrow A^{C(\lambda)}(pk): \text{SIG.Vfy}(pk, \sigma, m)= 1, (m, \sigma) \neq (m_i, \sigma_i) \forall i].
$$

SIG在自适应选择消息攻击下对存在性伪造是 强安全的 （sEUF‐CMA），如果对于所有概率多项式时间对抗者 A，Adv sEUF- CMA SIG A ,(λ)是关于 λ的 可忽略函数。

备注1 . 可以根据任何具有EUF‐CMA安全性的签名方案和诱变哈希函数 [6,28]，通用地构造出具有sEUF‐CMA安全性的签名方案。

2.2 安全的非交互式密钥交换

定义2 。一个非交互式密钥交换（NIKE）方案由两个确定性算法（NIKE.Gen， NIKE.Key）组成。

NIKE.Gen(1 λ, r)接收一个安全参数 λ 和随机性 r ∈{0, 1} λ，并输出一个密钥对 (pk, sk)。我们用 (pk, sk) ←$ NIKE.Gen(1 λ ) 表示 NIKE.Gen(1 λ, r) 使用均匀随机的 r ←${0, 1} λ 执行。

0‐RTT密钥交换的简单安全定义与构造 27

NIKE.密钥(ski, pkj)是一个确定性的算法，它以密钥 ski和公钥 pkj作为输入，并输出密钥ki,j。

我们说一个NIKE方案是正确的，如果对于所有(pk i, ski) ←$ NIKE.Gen(1λ)和 (pk j, sk j) ←$ NIKE.Gen(1λ)，都有NIKE.Key(sk i, pkj)= NIKE.Key(skj, pk i)成立。

CKS-Light 安全性

CKS-light NIKE协议的安全模型相对简单且紧凑。我们选择此模型是因为其他（更复杂的）NIKE安全模型，如CKS、CKS-heavy和 m-CKS-heavy，在多项式时间内等价于CKS-light。详见[12]以了解更多信息。

NIKE协议的安全性通过一个在攻击者 A和挑战者之间进行的游戏 NIKE来定义。挑战者以安全参数 λ和一个随机比特 b作为输入，并响应 A的所有查询，直到其输出一个比特b′。挑战者对 A的回答如下：
– RegisterHonest(i). A提供一个索引 i。挑战者运行NIKE.Gen(1λ)生成一个密钥对(pki, ski)，并记录元组(honest pki, ski)以供后续使用，然后将 pki返回给 A。该查询最多可被 A调用两次。
– RegisterCorrupt(pki)。通过此查询， A提供一个公钥 pki。挑战者记录元组(Corrupt pki)以供后续使用。
– GetCorruptKey(i, j)。 A提供两个索引 i和 j，其中 pki被注册为被攻陷， pkj被注册为诚实。挑战者运行 k ← NIKE.Key(skj,pki)，并将 k返回给 A。
– Test(i, j)。攻击者提供两个被诚实地注册的索引 i和 j 。现在挑战者使用比特 b：如果 b= 0，则挑战者执行ki,j ← NIKE.Key(pki, skj)，并返回密钥 ki, j；如果 b= 1，则挑战者从密钥空间中随机采样一个元素，记录该元素以供后续使用，并将密钥返回给 A。

游戏NIKE输出1，记为NIKEA^NIKE(λ) = 1，当且仅当 b= b′成立；否则输出0。我们称 A赢得该游戏，如果NIKEA^NIKE(λ) = 1成立。

定义3 。对于任何在上述NIKE游戏中对抗NIKE方案NIKE的攻击者 A，我们将其赢得游戏NIKE的优势定义为

$$
\text{Adv}_{\text{NIKE},A}^{\text{CKS-light}}(\lambda) = \left| 2 \cdot \Pr[\text{NIKE}_A^{\text{NIKE}}(\lambda)= 1] -1 \right|.
$$

设 λ为一个安全参数，NIKE为一个NIKE协议， A为一个攻击者。我们称NIKE是一个CKS-light-secure的NIKE协议，如果对于所有概率多项式时间的攻击者 A，函数Adv CKS-li g ht NIKE A(λ)在 λ中是一个可忽略函数。

28 B. Hale et al

3 0‐RTT密钥交换协议：仅服务器认证下的语法与安全性

在本节提出的模型中，我们给出了具有强密钥独立性和主密钥前向保密的 0‐RTT密钥交换的形式化定义。我们首先讨论仅服务器认证的情况，因为这在实际中更为重要（特别是，仅服务器认证将成为QUIC和TLS 1.3的主要运行模式）。

3.1 语法和正确性

定义4 。一种仅服务器认证的0-RTT密钥交换方案由确定性算法(Genserver，KEclient_init ， KEclient_refresh，KEserver_refresh)组成。

– Genserver(1λ, r) →(pk, sk)：一个密钥生成算法，输入为安全参数 λ和随机性 r ∈{0, 1}λ，输出一个密钥对(pk, sk)。我们用(pk, sk) ←$Genserver(1λ) 表示当Genserver使用均匀随机的 r←${0, 1}λ执行时，输出为密钥对(pk, sk)。
– KEclient_init(pkj, ri) →(ki, j_tmp, mi)：一个算法，输入为公钥 pkj和随机性 ri ∈{0, 1}λ，输出一个临时密钥 ki, j_tmp和一条消息 mi。
– KEserver_refresh(skj, rj, mi) →(kj, i_main, kj, i_tmp, mj)：一个算法，输入为密钥 skj、随机性 rj和一条消息 mi，输出一个密钥 kj, i_main、一个临时密钥 kj, i_tmp和一条消息 mj。
– KEclient_refresh(pkj, ri, mj) → ki, j_main：一个算法，输入为公钥pkj、随机性 ri和一条消息 mj，输出一个密钥 ki, j_main。

我们说一个0-RTT密钥交换方案是正确的，如果对于所有(pkj, sk j) ←$ Genserver(1λ)以及对于所有 ri, rj ←${0, 1}λ均成立

$$
\Pr[k_{i,j}^{\text{tmp}} \neq k_{j,i}^{\text{tmp}} \text{ or } k_{i,j}^{\text{main}} \neq k_{j,i}^{\text{main}}] \leq \text{negl}(\lambda),
$$

其中 (kj , i_tmp , mi) ← KEclient_init(pkj, ri), (k i , j_main, ki , j_tmp , mj) ← KEserver_refresh(sk j, rj, mi), 以及kj, i ← KEclient_refresh(pk j, ri, mj)。

0‐RTT KE方案由一组参与方使用，这些参与方要么是客户端 C，要么是服务器 S（参见图2）。每个服务器Sp拥有一个生成的密钥对(skp,pkp) ←$Gen server (1 λ, j)，其pkp已公开。该协议执行如下：

1. 客户端预言机 Ci 选择 ri ∈{0, 1} λ 并选取目标参与方的公钥 Sj （该参与方必须是服务器，否则此值未定义）。然后计算 (k i , j_tmp , mi) ← KEclient_init(pk j, ri)，并将 mi 发送给 Sj 。此外，Ci 可以使用 k i , j_tmp 对某些数据 Mi 进行加密。

2. 当接收到消息 mi, Sj 时，初始化一个新的预言机 Sj,t。该预言机选择 rj ∈{0, 1}λ 并计算 (kj, i_main, k j, i_tmp, mj) ← KEserver_refresh(skj, rj, mi)。服务器可以使用临时密钥 k j, i_tmp 对收到的数据进行解密。

3. Ci计算 ki , j_main ← KEclient_refresh(pkj, ri, mj)，且可选择性地解密 Dj。0‐RTT KE方案的正确性保证了 ki , j_main= kj, i_main。

3.2 执行环境

我们为针对0‐RTT密钥交换协议的攻击者 A提供以下执行环境。不拥有长期密钥的客户端由预言机C1,…,Cd表示（无特定“身份”）。我们考虑 个服务器，每个服务器拥有一对长期密钥（skj,pkj） 7, j ∈{1,…, }，且每个客户端均可访问所有公钥pk1,…,pk。每个服务器由一组 k个预言机Sj,1,…,Sj,k表示，其中每个预言机代表一个执行协议单个实例的进程。

我们使用以下变量来维护预言机的内部状态。

客户端 。 每个客户端预言机 Ci, i ∈[d] 维护

– 两个变量 ktmp_i 和 kmain_i ，用于存储会话的临时密钥和主密钥，

我们不区分静态（即长寿命）和半静态（即中等寿命）的密钥对。因此，此模型中的长寿命密钥对应于QUIC和TLS 1.3的服务器配置文件密钥。

29 B. Hale et al

– 一个变量 Partneri，其中包含预期通信伙伴的身份，以及
– 包含预言机发送和接收的 消息 的变量 Min_i 和 Mout_i。

客户端预言机的内部状态初始化为 (ktmp_i ,kmain_i ,Partneri,Min_i,Mout_i):=(∅, ∅, ∅, ∅, ∅)。

服务器 。 每个服务器预言机 Sj,t, (j, t) ∈[] ×[k] 维护：

– 两个变量 ktmp_j,t 和 kmain_j,t ，用于存储会话的临时密钥和主密钥，以及
– 变量 Min_j,t 和 Mout_j,t，包含服务器发送和接收的消息。

服务器预言机的内部状态初始化为 (ktmp_j,t,kmain_j,t,Min_j,t,Mout_j,t):=(∅, ∅, ∅, ∅)。

我们说一个预言机已接受临时密钥 当且仅当 ktmp ≠ ∅，且 接受主密钥 当且仅当 k main ≠ ∅。

在安全实验中，攻击者能够通过发出以下查询来与预言机进行交互。

Send(Ci/Sj,t, m) 。 攻击者向请求的预言机发送消息 m 。该预言机根据协议规范处理 m。预言机根据协议规范生成的任何响应都将返回给攻击者。

如果客户端预言机 Ci 将 m 作为第一条消息接收，则该预言机会检查 m 是否包含一个特殊的初始化消息（m=(init j)）。如果成立，则该预言机会向预期的参与方 Sj 发送生成的第一条协议消息,，否则输出 ⊥。

Reveal(Ci/Sj,t,临时/主) 。 此查询会返回给定阶段的密钥（如果已计算），否则返回 ⊥。

Corrupt(j) 。在输入服务器身份 j时，此查询返回长期服务器的私钥。如果Corrupt(j)是 A发出的第 τ个查询，我们说一个参与方是 τ-corrupted。对于未被攻破的参与方，我们定义 τ:= ∞。

Test(Ci/Sj,t,tmp/main) 。此查询用于测试密钥，且仅被询问一次。回答如下：如果所请求密钥的变量不为空，则随机选择 b ←${0, 1}，并且
– 如果 b= 0，则返回请求的密钥，否则
– 如果 b= 1，则根据概率分布生成一个随机密钥 协议生成的密钥被返回。否则返回 ⊥。

安全性 游戏 G0RTT−sa_A 。 在接收到安全参数 λ 后，挑战者 C 模拟协议并跟踪执行环境中的所有变量：他生成所有服务器参与方的长期密钥对，并如实响应攻击者的所有查询。

攻击者接收所有公钥 pk1,…,pk，并可通过发送任意组合的查询Send()、 Corrupt()和

0‐RTT密钥交换的简单安全定义与构造 31

Reveal()。在某个时刻，攻击者向预言机查询Test()并接收一个密钥，该密钥要么是所请求的密钥，要么是一个随机值。攻击者在收到密钥后可以继续发送 Send()、Corrupt()和Reveal()查询，最后输出某个比特 b′。

定义5 （仅服务器认证的0‐RTT密钥交换安全性）。让一个攻击者 A与挑战者在游戏 G0R中进行交互 T T −sa A如上所述。如果 b= b′且满足以下条件，则称挑战者输出1，记为 G0RTT−sa_A (λ)= 1：

– 如果 A 发出 Test(Ci,临时)，则以下所有条件均成立：

• Reveal(Ci,临时)从未被 A 查询过
• Reveal(Sj,t,临时)从未被 A针对任意预言机 Sj,t满足Partneri= j且 M在j, t= Mouti 查询过
• 通信伙伴 Partneri= j，如果存在，则不是 τ-corrupted with τ< ∞

– 如果 A 发出 Test(Ci,主)，则以下所有条件均成立：

• Reveal(Ci,主)从未被 A 查询过
• Reveal(Sj,t,主)从未被 A 查询过，其中 Partneri= j, Minj,t=Mouti 以及 Mini= Moutj,t
• 通信 Partneri= j 未被 τ-corrupted，其中Test(Ci,main) 是由 A 发出的第 τ0 个查询

– 如果 A 发出 Test(Sj,t,临时)，则以下所有条件成立：

• Reveal(Sj,t,临时)从未被 A 查询过
• 存在一个预言机 Ci具有 Mouti= Minj,t
• Reveal(Ci,临时)从未被 A查询至任何预言机 Ci，其中 Mouti =Minj,t
• Reveal(Sj,t′,tmp)未被 A针对任意预言机 Sj,t′查询过，其中 M属于j,t=M属于j,t′
• j 不是 τ‐被破坏的 ，且具有 τ< ∞

– 如果 A 发出 Test(Sj,t,主)，则以下所有条件均成立：

• Reveal(Sj,t,主)从未被 A 查询过
• 存在一个预言机 Ci具有 Mouti= Minj,t
• Reveal(Ci,主)从未被 A查询过，如果 M在i= Moutj,t 否则游戏输出一个随机比特。我们定义 A在游戏G0RTT−sa_A (λ)中的优势为

$$
\text{Adv} {A}^{0RTT-sa}(\lambda) := \left| 2 \cdot \Pr[G {A}^{0RTT-sa}(\lambda)= 1] -1 \right|.
$$

定义6 。我们说一个0-RTT密钥交换协议是test-安全的，如果存在一个可忽略函数negl(λ)，使得对于所有按照安全性游戏 G0RTT−sa_A (λ)进行交互的概率多项式时间（ PPT）攻击者 A，均有

$$
\text{Adv}_{A}^{0RTT-sa}(\lambda) \leq \text{negl}(\lambda).
$$

32 B. Hale et al

备注 2 。我们的安全模型涵盖了主密钥的前向保密，因为即使攻击者能够攻破测试预言机的通信伙伴（但当然只能在测试预言机接受之后，以避免平凡攻击），仍需满足密钥不可区分性。

此外，强密钥独立性通过以下方式建模：允许试图区分临时密钥与随机值的攻击者（即，提出 Test(X, tmp) 查询的攻击者，其中 X ∈{Ci,Sj,t 为某些 i, j, t}）获取 X 的主密钥。类似地，试图通过提出 Test(X,main) 查询来区分主密钥与随机值的攻击者，也被允许获取 X 的临时密钥。这种意义上的安全性保证了对于计算能力受限的攻击者而言，临时密钥和主密钥看起来是相互独立的。

备注3 . 请注意，上述安全模型中Mout_i = Min_j,t等要求实质上采用了贝尔尔和罗加威匹配会话的概念，该概念最初为通用的多消息密钥交换协议所定义，现应用于0‐RTT密钥交换的特殊情况。

3.3 将0‐RTT密钥交换协议与对称加密组合

上述描述的安全模型仅考虑了0‐RTT密钥交换协议，不包含 对有效载荷数据的对称加密（即不包含图2中显示的消息 Di和 Dj）。在此意义上安全的协议保证了在假设场景中密钥的不可区分性，其中密钥并未用于对攻击者可能已知的有效载荷消息进行对称加密。

0‐RTT密钥交换的简单安全定义与构造 33

人们可能会认为这对于0‐RTT密钥交换而言是不够的，因为在该密钥将被用于加密有效载荷数据，而这会使攻击者能够轻易地区分“真实”密钥与“随机”密钥（这对“临时”密钥 $k_{i,j}^{\text{tmp}}$ 以及实际的“主”会话密钥 $k_{i,j}^{\text{main}}$ 均成立）。请注意，此论点不仅适用于上述0‐RTT密钥交换安全模型，而且实际上适用于任何基于密钥不可区分性的（认证）密钥交换安全模型，例如贝尔尔和罗加威的经典模型以及许多类似模型[2,5,7,10,20,27]。在实践中，该密钥通常会在密码协议中使用，例如用于加密消息，因此显然可以区分“真实”密钥与“随机”密钥。一个在[2,5,7,10,20,27]意义下安全的协议与对称加密协议组合后的安全性，可通过标准的两步混合论证得出，其基本过程如下：

1. 在原始安全实验中，攻击者与一个组合协议进行交互，其中密钥交换协议首先被用于派生密钥 $k$，然后该密钥被用于对称加密协议来加密有效载荷数据。
2. 在下一个混合实验中，攻击者与一个组合协议进行交互，其中对称加密不使用密钥交换协议计算出的密钥 $k$，而是使用一个独立的随机密钥。请注意，能够区分此混合实验与原始游戏的攻击者，可用于区分密钥交换协议的“真实”密钥和“随机”密钥。

现在攻击者与一个加密协议进行交互，该协议使用的密钥是独立于密钥交换协议的。这使得可以将组合协议的安全性归约到对称协议的安全性。

一个类似且直接的混合论证适用于0‐RTT密钥交换与对称加密的组合，其工作方式如下：
1. 在原始安全实验中，攻击者与一个组合协议进行交互，其中首先使用0‐RTT密钥交换协议来推导出密钥 $k_{i,j}^{\text{tmp}}$，然后用该密钥加密随第一条协议消息发送的有效载荷数据。随后，再次使用0‐RTT密钥交换协议推导主密钥 $k_{i,j}^{\text{main}}$，进而用于加密所有后续的有效载荷数据。
2. 在第一个混合实验中，攻击者与一个组合协议进行交互，其中仅 $k_{i,j}^{\text{tmp}}$ 被替换为一个独立的随机值。能够区分该混合实验与原始游戏的攻击者可用于区分“真实”的 $k_{i,j}^{\text{tmp}}$ 与一个“随机”的。

现在，攻击者与一个加密协议进行交互，该加密协议使用与0‐RTT密钥交换协议无关的密钥对第一条有效载荷消息进行加密。这使得第一条有效载荷消息的安全性可以归约到对称协议的安全性。
3. 在第二个混合实验中，攻击者与一个组合协议进行交互，其中 $k_{i,j}^{\text{main}}$ 现在也被替换为一个独立的随机值。能够区分该混合实验与前一个混合实验的攻击者，可用于区分“真实”的 $k_{i,j}^{\text{main}}$ 和“随机”的 $k_{i,j}^{\text{main}}$。这使得可以将所有后续有效载荷消息的安全性归约到对称协议的安全性上。

遵循以往基于不可区分性的密钥交换安全模型研究的长期传统 [2,5,7,10,20,27]，因此我们可以考虑一种基于不可区分性的0‐RTT密钥交换安全模型，即使在实际中密钥交换消息会与对称加密协议的消息交织在一起。这有助于建立简单的安全模型，并支持对组合协议的构建模块进行模块化分析。

4 从NIKE构造通用的0‐RTT密钥交换

现在我们准备描述基于NIKE的通用0‐RTT密钥交换协议及其安全性分析。

4.1 通用构造

设NIKE = (NIKE.Gen, NIKE.Key)为符合定义2的NIKE方案，且设SIG = (SIG.Gen, SIG.Sign, SIG.Vfy)为一个签名方案。然后我们按照定义4构造一个0‐RTT KE方案0‐RTT = (Gen_server, KEclient_init, KEclient_refresh, KEserver_refresh)，方式如下（参见图3）。

34 B. Hale et al

– Genserver(1λ, r) 使用 NIKE 密钥生成算法 $(pk^{\text{nike-static}}, sk^{\text{nike-static}}) \leftarrow$ NIKE.Gen(1λ) 计算密钥对，并使用 SIG 算法 $(pk^{\text{sg}}, sk^{\text{sg}}) \leftarrow$ SIG.Gen 生成签名密钥，然后输出
$$
(pk, sk) := ((pk^{\text{nike-static}}, pk^{\text{sg}}), (sk^{\text{nike-static}}, sk^{\text{sg}})).
$$

– KEclient_init(pkj, ri) 采样 $r_i \leftarrow {0,1}^\lambda$，解析 $pk_j = (pk^{\text{nike-static}} j, pk^{\text{sg}}_j)$，运行 $(pk^{\text{nike}}_i, sk^{\text{nike}}_i) \leftarrow$ NIKE.Gen(1λ, ri) 和 $k^{\text{nike}} {i,j} \leftarrow$ NIKE.Key($sk^{\text{nike}} i, pk^{\text{nike-static}}_j$)，并输出
$$
(k {i,j}^{\text{tmp}}, m_i) := (k^{\text{nike}}_{i,j}, pk^{\text{nike}}_i).
$$

– KEserver_refresh(skj, rj, mi) 接收 $m_i = pk^{\text{nike}} i$，解析 $sk_j = (sk^{\text{nike-static}}_j, sk^{\text{sg}}_j)$，并采样 $r_j \leftarrow {0,1}^\lambda$。然后计算 $k^{\text{nike}} {j,i} \leftarrow$ NIKE.Key($sk^{\text{nike-static}} j, pk^{\text{nike}}_i$)，$(pk^{\text{nike}}_j, sk^{\text{nike}}_j) \leftarrow$ NIKE.Gen(1λ, rj)。如果 $m_i = pk^{\text{nike-static}}_j$，则均匀随机采样 $k^{\text{nike}} {\text{main}}$，否则计算 $k^{\text{nike}} {\text{main}} \leftarrow$ NIKE.Key($sk^{\text{nike-static}}_j, pk^{\text{nike}}_i$)，输出
$$
(k {j,i}^{\text{main}}, k_{j,i}^{\text{tmp}}, m_j) := (k^{\text{nike}} {\text{main}}, k^{\text{nike}} {i,j}, (pk^{\text{nike}}_j, \sigma_j)).
$$

– KEclient_refresh(pkj, ri, mj) 解析 $pk_j = (pk^{\text{nike-static}} j, pk^{\text{sg}}_j)$ 和 $m_j = (pk^{\text{nike}}_j, \sigma_j)$。然后验证 $\text{true} \leftarrow$ SIG.Vfy($pk^{\text{sg}}_j, \sigma_j, pk^{\text{nike}}_j$)，计算 $k^{\text{nike}} {\text{main}} \leftarrow$ NIKE.Key($sk^{\text{nike}} i, pk^{\text{nike}}_j$)，输出 $k {i,j}^{\text{main}} := k^{\text{nike}}_{\text{main}}$。

最终，该构造通过应用NIKE.Gen算法和签名SIG.Gen算法来生成服务器配置文件，该文件包含服务器公钥和一个服务器公钥签名密钥，客户端可使用该文件生成第一个协议流程。为了使0‐RTT KE构造能够抽象底层NIKE的安全保证，必须在$pk^{\text{nike}}_i$、$sk^{\text{nike}}_i$形式的适当客户端NIKE算法中提供可用的密钥。因此，$(pk^{\text{nike}}_i, sk^{\text{nike}}_i)$ 值由客户端本地生成，其中$pk^{\text{nike}}_i$作为消息传递给服务器。请注意，此构造自然放弃了客户端认证。图3展示了该构造。

备注4 。有人可能会问，为什么我们要定义KEserver_refresh(skj, rj, mi)，使其在输入为等于其自身静态NIKE密钥的客户端消息时采样一个随机密钥，即当 mi等于 $m_i = pk^{\text{nike-static}}_j$时。我们注意到，这对于所构造的0‐RTT KE方案的安全性可归约至NIKE方案的安全性是必要的，因为在某些情况下，我们无法模拟服务器预言机在接收到等于其0‐RTT KE公钥中包含的“静态”NIKE公钥的消息时所计算出的密钥。请注意，这会导致可忽略的正确性错误。然而，根据定义4验证该协议的正确性是直接的。

定理1 . 设 0-RTT 使用 d 个客户端、 ℓ 个具有长期密钥的服务器以及用于对每个服务器建模的 k 个服务器预言机执行。对于每个攻击者 A，我们可以根据定义1构造攻击者 B_sig，并根据定义3构造攻击者 B_nike，使得
$$
\begin{aligned}
\text{Adv} A^{0RTT-sa}(\lambda) &\leq 2kd\ell \cdot (\text{Adv} {B_{\text{nike}}}^{\text{CKS-light}}(\lambda) + \text{Adv} {B {\text{sig}}}^{\text{sEUF-CMA}}(\lambda)) \
&+ d\ell \cdot (k \cdot \text{Adv} {B {\text{nike}}}^{\text{CKS-light}}(\lambda) + \text{Adv} {B {\text{sig}}}^{\text{sEUF-CMA}}(\lambda)) \
&+ d\ell \cdot (\text{Adv} {B {\text{nike}}}^{\text{CKS-light}}(\lambda) + \text{Adv} {B {\text{sig}}}^{\text{sEUF-CMA}}(\lambda)) + 4 \cdot \text{Adv} {B {\text{nike}}}^{\text{CKS-light}}(\lambda).
\end{aligned}
$$
B_sig 和 B_nike 的运行时间大约等于执行一次安全实验 A 所需的时间。

定理1的证明思路 。为了证明定理1，我们将攻击者分为四种类型：
– 攻击者 A₁ 向客户端预言机和临时密钥发起Test()请求（CT-attacker）
– 攻击者 A₂ 向客户端预言机和主密钥发起Test()请求（CM-attacker）
– 攻击者 A₃ 向服务器预言机和临时密钥发起Test()请求（ST-attacker）
– 攻击者 A₄ 向服务器预言机和主密钥发起Test()请求（SM-attacker）。

让我们给出一些直观解释，说明为什么这种攻击者分类对安全证明是有用的。在0‐RTT密钥交换方案中，每个参与方计算两个不同的密钥 $k^{\text{tmp}}$ 和 $k^{\text{main}}$，其中 $k^{\text{tmp}}$ 依赖于临时密钥客户端和服务器的静态密钥，以及 $k^{\text{main}}$ 取决于双方的临时密钥。在我们的证明中，希望能够将0‐RTT密钥的不可区分性归约到NIKE密钥的不可区分性。

在NIKE安全性实验中，攻击者收到两个挑战公钥${pk^{\text{nike}}_i, pk^{\text{nike}}_j}$。在归约过程中，我们希望根据第3.2节将这些密钥嵌入到0‐RTT安全性实验中，并仍能正确回答所有Reveal()‐和Corrupt()‐查询。对于测试客户端或服务器临时密钥的攻击者，我们可以将NIKE密钥作为$pk^{\text{nike-static}}_j = pk^{\text{nike}}_j$和 $m_i = pk^{\text{nike}}_i$嵌入。然而，对于针对主密钥的攻击者，这种方法不起作用，因为 $k^{\text{main}}$ 依赖于参与方的临时密钥。在这种情况下，我们必须将密钥作为 $m_i = pk^{\text{nike}}_i$ 和 $m_j = pk^{\text{nike}}_j$ 嵌入。然后，0‐RTT实验中攻击者的Test()‐查询可以用NIKE实验中攻击者收到的挑战来回答。