基于流的信道安全性研究

数据即流：基于流的信道安全性

MarcFischlin1(B)，FelixG¨unther1,，GiorgiaAzzurraMarson1,和KennethG.帕特森2
1达姆施塔特工业大学密码复杂性研究中心，德国达姆施塔特 marc.fischlin@cryptoplexity.de,guenther@cs.tu‐darmstadt.de, giorgia.marson@cased.de¨
2伦敦大学皇家霍洛威学院信息安全组，英国 伦敦kenny.paterson@rhul.ac.uk

1引言

如今，密码学应用最广泛的功能仍然是安全通信——在两方之间提供用于数据传输 的“安全信道”。安全信道协议种类繁多，功能各异，运行于不同的网络层并提供 不同的安全性服务。典型的例子包括全球移动通信系统、通用移动通信系统和长期 演进技术[1]移动通信系统，有线等效加密、Wi‐Fi保护访问和Wi‐Fi保护访问 2[19]（用于保护无线局域网通信），IP安全协议[22]，传输层安全协议[15]和数据 报传输层安全[31]（分别在传输控制协议[30]和用户数据报协议[29],之上运行）， 谷歌的QUIC协议[33],以及安全外壳协议[36]（一种“应用层”安全协议）。

文献中的AEAD与安全通道。带关联数据的认证加密（AEAD）[32]已成为构建 安全信道的合适密码学工具。AEAD为数据提供了机密性和完整性保障。然而， 仅靠AEAD本身不足以构建安全信道。例如，在大多数实际情况下，安全信道 不仅应提供消息的简单加密，还应保证能够检测（并可能恢复）消息的乱序投 递和重放攻击。此外，安全信道需要处理错误，这些错误可能来自密码学或非 密码学处理过程——当遇到错误时是否终止安全信道会话，以及如何（甚至是 否）向对方通告错误。另一个区别是，某些安全信道设计（如IPsec以及在一定 程度上TLS）具有额外功能，可用于防御流量分析。安全信道可以接收任意长 度的消息，并在加密前对其进行分片，解密后再次重组；或者，它可以向应用 程序提供一个与底层网络基础设施相匹配的最大消息长度。最后但最重要的是， 本文关注的情境下，安全信道可能是为了保护数据流而设计的，而不是密码学 抽象中常见的离散消息序列。

因此，AEAD原语能够合理提供的功能与安全信道的需求之间存在显著差 距。当然，我们并非最先认识到这一差距的人。例如，Bellare等人[5] 将对 称加密的机密性和完整性标准安全概念扩展到有状态环境，从而能够处理安全 信道中离散消息顺序的安全性问题，其主要动机是应用于SSH的分析。随后， Black等人[23] 进一步扩展了这些安全概念，以包含更丰富的特性，适用于 处理允许（或拒绝）重放、消息丢失和重排序的信道。有关安全信道形式化的 其他文献包括[3,12,13,20,24–27,34]。

基于流的通道。上述所有先前工作的特点是，它们都将安全信道视为提供一种 原子性消息接口，即该信道仅设计用于发送和接收离散消息序列。然而，这仅 涵盖了现实中实际使用的一部分安全信道设计。特别是，TLS、SSH和 QUIC都为其使用的应用程序提供了流式接口：应用程序通过应用程序编程接 口（API）提交消息（或明文）流的片段（或分段），并同样从API接收消息 流的片段。发送端可在封装以进行发送之前任意地对消息流进行缓冲和/或分段。 此外，在某些情况下，即使在网络正常运行的情况下，也无法保证所发送的密 文片段流（我们此后将其称为密文，并将其视为不透明的比特字符串）将以相 同的分段模式到达接收器，即使最终重建的消息流是完全相同的。在对抗条件 下，此类情况可能更加复杂。

这些保证显然不成立：例如，TLS在TCP之上运行，而主动的中间人攻击者可 以随意篡改TCP段，任意添加、删除和重排TLS数据。因此，实际的安全信 道需要能够安全地处理任意分片的密文。最后，使情况更加复杂的是，回到原 点，应用程序（如HTTP[17]）通常试图使用面向流的安全信道（如TLS）来 实现安全的原子消息传输。

这一讨论指出了密码学文献中对安全信道的原子化描述与安全信道实际运 行情况之间的不匹配。正如人们所预料的，这种不匹配可能对安全性产生负面 影响。最明显的例子是阿尔布雷希特等人[2]提出的针对SSH的明文恢复攻击。 该攻击特别利用了攻击者能够通过TCP向接收器发送任意序列的SSH数据包分 段，并观察接收器响应行为的能力。尽管[5]的分析已证明SSH安全信道满足 适当的原子状态安全概念，此类攻击仍然可能发生。在[14]中还提出了针对某 些IPsec配置的相关攻击（并利用了IPsec处理IP分段的需求）。在HTTP与 TLS特定背景下，揭示应用程序期望与安全信道实际提供功能之间脱节的攻击 可在[7,35]中找到。所有这些攻击都表明了以往对安全信道建模和分析方法的不 完整性。

博尔德列娃等人[9]将经典的原子化安全信道概念扩展至涵盖类似SSH的 基于流的安全信道，从而拓展了[28]中针对SSH的特定研究。然而，尽管他们 的工作允许密文以分段方式传递给接收器，但仍假设发送方的加密过程是原子 化的，即消息与密文之间存在一一对应关系。这在SSH用于交互式会话时可能 成立，但在SSH的隧道模式下并不成立，对于其他安全通道协议而言也从不成 立。例如，尽管TLS规范[15]未包含正式API定义，但显然其设计意图是为数 据流提供一个安全信道（实际中应用程序员被提供的是类似传输控制协议的套 接字接口），并且如上所述，发送方在准备待发送的密文时可以任意地对消息 流进行缓冲和分段。

我们的贡献。在本文中，我们为基于流的信道建立了形式化的功能规范、安全 概念，并提出了一个构造方法（使用AEAD作为构建模块）。我们的模型遵循基于 游戏的传统，并扩展了[5,9]的模型，以处理我们所考虑信道的流式特性。 尽管我们的方法论和建模与[9],非常相似，实际上也是在其基础上构建的， 但关键区别在于我们对基于流的信道的发送（或加密）函数的处理方式：在[9], 中，发送函数仍然是原子的（而解密则不是），而在我们的基于流的信道设定 中，发送和接收函数均支持数据流，并且在发送端和接收端可能存在任意的缓 冲和分段。这要求对[9]的机密性定义进行仔细修改。此外，我们还开发了 适用于流式环境的适当完整性概念，而[9]未考虑此方面。这一点很重要，因为 应用程序期望安全通道提供的（非正式）安全属性包括机密性以及完整性，而 在[9]所提出的最强大的“选择片段攻击”环境中，安全性并未提供任何完整 性保证。

将完整性引入基于流的通道还使我们能够证明一个类似于对称加密方案经 典结果的组合结果，该经典结果指出，密文的不可区分性（IND‐CPA安全性） 与密文完整性（INT‐CTXT安全性）相结合可保证IND‐CCA安全性。这为证 明给定的基于流的信道构造提供了适当的机密性（选择密文片段攻击下的不可 区分性，即IND‐CCFA安全性）和完整性（明文流的完整性，INT‐PST安全 性）提供了一条便捷途径。

组合定理带来了一个有趣的、需要克服的技术挑战：正如在[10]中针对经 典（原子）场景所认识到的那样，加密方案的现实模型可能涉及多个错误消息， 这意味着[6]的原始组合证明无法成立。在[10],中，这一问题通过假设方案仅 有一种可能的错误消息在方案运行过程中有非可忽略的概率被生成而得以解决。 在这里，我们采取了不同的方法，引入了错误可预测性的概念，该概念保证存 在一种高效算法，能够预测在解密密文流时应输出哪些错误。

我们通过提供一种通用构造来证明所提出安全概念的可行性，该构造利用 AEAD作为组件，构建出满足最强机密性和完整性概念的基于流的信道。所得 到的基于流的信道closelymimicsTLS记录协议。因此，我们的安全性结果为 这一重要的实际协议设计提供了验证，同时充分考虑了其流式行为。在本文的 完整版本中，我们还提出了一种基于支持分段的对称加密的通用构造，用于构 建基于流的信道，如[9]所述。

在完整版本中，我们回到讨论的出发点，分析应用程序如何通过将特定的 消息结束符编码到发送的消息流中以标识原子消息的边界，从而利用基于流的 信道安全地传输原子消息。然而，要确立这种简单而自然方法的安全性，需要 引入一个与完整性和机密性正交的额外技术属性。我们的分析为针对运行在传 输层安全协议之上的超文本传输协议的截断[35]和“Cookie‐cutter”[7]攻 击提供了新的形式化视角，揭示了这些攻击是如何因误解基于流的通道所能为 期望原子消息通道的应用程序提供的安全保证而产生的。

进一步相关工作.巴尔加万等人[8]在对TLS记录协议的详细分析中，提出了针 对基于流的通道的安全性概念。他们的方法涉及将通道安全性属性表示为编程 语言中的类型，然后形式化证明这些类型定义 在对抗环境中得到满足（其中攻击者被建模为与通道的发送和接收函数代码交 互的另一个程序）。

与我们的工作看似相似的另一研究方向涉及分块自适应安全性以及在线对 称加密方案，如[4,11,18,21]中所提出的。在这些研究中，方案以实时方式运行， 每次处理一个固定大小的明文或密文块；同时攻击者可以访问分块加密（以及 可能的解密）预言机。然而，在这些论文中，消息和密文最终被视为离散实体， 而不是像我们这样将其视为消息流和密文片段的流。

论文结构。在第2节介绍一些基本的符号说明和术语之后，我们将在第3节提出 基于流的信道的形式化定义。第4节包含我们针对基于流的信道的机密性和完 整性的安全概念，以及我们的组合定理。最后，在第5节中，我们通过提供一 种基于流的信道的通用构造来展示这些概念的可行性。我们在第6节总结了本工 作引发的开放问题。

2预备知识

符号说明。设 Σ为一个字母表且 s ∈Σ ∗。我们用 |s| 表示 s的长度，用 s[i]表示其 第 i个字符，用 s[i,…, j]表示子串 s[i]|| … ||s[j]，其中 ||表示字符串连接。设 s, t ∈Σ ∗。我们说 s是 t的前缀，并记作 s ≺ t，当且仅当存在 r ∈Σ ∗使得 s||r= t； 此时我们记为r= t% s。我们用[s, t]=[t, s]表示 s和 t的最长公共前缀。注意 s ≺ t 当且仅当[s, t]= s。利用上述符号，我们经常考虑s%[s, t]，即从 s中去掉 s和 t的 最长公共前缀后的后缀。设 s=(s1,..., s) ∈(Σ ∗)为某个整数 对应的字符串 向量；如果 s为空，即 = 0，我们将其记为 s=()。对于每个 0 ≤ i ≤ j ≤ ， 我们记 s[i]= si和 s[i,…, j]=(si,..., sj)；我们用简写 ||s表示连接 s1|| … ||s,， 并按约定定义 ||()= ε。我们说两个向量 s=(s1,..., s)和 t=(t1,..., t′)相等， 并记作 s= t，当且仅当 = ′且对所有 1 ≤ i ≤ 有 s[i]= t[i]。略微重载符号， 我们将两个向量 s和 t的合并记为 s||t=(s1,..., s, t1,…, t′)。

通道术语。我们对通道的语法有意独立于目标安全属性，因为这些属性可 能因具体应用而异。为了体现通道的通用功能，并保持比例如认证加密更高的 抽象层次，我们定义了发送（Send）和接收（Recv），而非加密和解密算法。

3基于流的通道

我们捕捉提供可靠传输流的通道协议的功能，例如传输控制协议（TCP）[30]以及， 第二步，我们定义基于流的安全信道协议（如传输层安全（TLS）记录协议 [15]或安全外壳（SSH）二进制包协议[37]）所期望具备的机密性和完整性属 性。1为此，我们首先需要定义基于流的信道的语法，这种信道与以往将原子消 息作为整体发送的信道模型不同，它发送的是消息（或明文）流的片段。为了 贴近现实世界中的实现，我们将消息空间和密文空间都限制为比特字符串的集 合，其中“消息”和“密文”并非作为原子单元，而是分别作为消息流和密文 流的片段（即子串）来理解。

此外，我们并未规定发送方的特定输入/输出行为，而是允许发送算法 Send根据其自身策略处理输入数据，例如实现某种形式的缓冲。我们通过采用 网络套接字编程中已有的“刷新流”概念，强制将消息流中的特定数据块发送 出去，并向Send算法提供一个额外的f lush标志 f ∈{0, 1}，当该标志被设置 为 f= 1时，可确保迄今为止输入的所有消息片段立即被发送出去。提前说明， 在我们的安全性模型中，这一设计保守地也允许攻击者控制分段。如果刷新标 志被设为零，Send可根据其实现方式和资源情况，内部决定继续接收更多的消 息片段，或发送出一个密文片段。在下文的定义中，我们要求每个被Send处理 的消息片段 mi都产生一个密文片段 ci。由于密文片段可以是空的（ci= ε）， 这隐式地允许Send通过输出空密文片段来等待更多数据。图1展示了基于流的 信道中发送和接收算法的行为。

We继续定义基于流的信道的语法和正确性。

定义1（基于流的通道语法）

一个具有关联的发送状态空间和接收状态空间 SS以及 错误空间 E的基于流的信道Ch=(初始化,发送,接收)由三个高效的概率算法组成：

–初始化。在输入安全参数 1λ时，该算法分别为发送方和接收器输出初始状态 stS,0 ∈ SS和stR,0 ∈ SR。我们记作(stS,0,stR,0) ←$ Init(1λ)。

1我们的模型本质上假设，在良性场景下，密文片段是可靠且有序地传输的（即以类似传 输控制协议的方式）。尽管我们认识到，也可以在诸如用户数据报协议（UDP）之类的 不可靠协议之上设计高效且安全的传输协议[29]例如谷歌的快速UDP互联网连接（ QUIC）协议中所做的那样[33],我们认为这些方法与我们的工作正交或无关。在这些情 况下，可靠的有序流传输可以通过以下方式实现： non-cryptographically一种是在将 UDP数据报交给基于流的信道之前，按照我们的定义对其进行类似传输控制协议的预处 理；另一种是对以独立方式加密和认证（例如使用AEAD方案）的UDP数据报进行后处 理。

–发送。在输入状态stS、 ∈ SS、一个消息片段 m ∈{0, 1}∗和一个刷新标志 f ∈{0, 1}时，该算法输出一个更新后的状态st′S ∈Ss 和一个密文片段 c ∈{0, 1}∗。我们记作(st′S ∈Ss, c) ←$ Send(stS, m, f)。

–接收。在输入状态 stR, ∈ SR 和一个密文片段 c ∈{0, 1}∗时，该算法输出一个更新后的状态st′ R ∈ SR 和一个消息片段m ∈{0, 1}∗ ∪E。我们记作(st′R, m) ←$Recv(stR,c)。

给定一个状态对(stS,0,stR,0)，一个整数 ≥ 0，以及消息片段元组 m=(m1,.. ., m) ∈({0, 1}∗) 和刷新标志元组 f=(f1,..., f) ∈{0, 1},，令(stS, c) ←$ Send(stS,0, m, f)表示以下顺序执行过程的简写：(stS,1, c1) ←$ Send(stS,0, m1, f1) ...,(stS,, c) ←$ Send(stS,−1, m, f)，其中 c=(c1,..., c)且stS,= stS,。 对于 = 0，我们定义 c 为空向量，且stS,=stS,为初始状态。我们对接收器 的算法使用类似的符号说明。

直观上，基于流的信道的正确性保证了：对于输入到发送（Send）函数的每一 条消息片段，如果相应的密文流被接收（Recv）函数处理，则无论接收端如何（重 新）分段该密文流，返回的消息流都是初始消息流的一个前缀。此外，当接收器 （Recv）消费了一个由调用发送（Send）且刷新标志（flushflag）设置为1所产 生的密文片段时，其输出流应包含至此为止所有输入到发送（Send）的消息片段。 接下来我们形式化这一直观描述。

定义2（基于流的信道的正确性）

设Ch=(Init,Send,Recv)为一个基于流 的通道。我们称Ch满足正确性，如果对于所有状态对(stS,0,stR,0) ←$Init(1λ)， 所有 , ′ ≥ 0，算法Init、Send和Recv的所有随机性选择，所有消息片段向 量 m ∈({0, 1}∗),，所有刷新标志向量 f ∈{0, 1},，所有发送输出序列(stS, , c) ←$Send(stS,0, m, f)，所有密文片段向量 c′ ∈({0, 1}∗)′,，以及所有接收 输出序列(st′R,′, m′) ←$ Recv(stR,0, c′)，均有

||c= ||c′=⇒ ||m[1,…, i] ≺ ||m′ ≺ ||m,

其中 i= max({0} ∪{j: fj= 1})是最大的索引，使得刷新标志 fi= 1 （即，如果所有刷新标志都设置为零，则 i= 0 且 m[1,…, i]= ε）。

备注1. 正确性意味着，如果我们向接收算法Recv提供发送算法Send输出的密文流的 一个前缀，即 ||c′ ≺ ||c,，那么接收方输出相应消息流的前缀 ||m′ ≺ ||m,，因为

||c′ ≺ ||c ⇒ ∃ c′′ ∈{0, 1}∗: ||c′ || c′′= ||c(corr.) =⇒ ||m′ || m′′ ≺ ||m ⇒ ||m′ ≺ ||m

对于所有接收输出序列(st′R,′+1, m′′)，有 ←$ Recv(st′R,′, c′′)。

备注2. 将我们的正确性定义与博尔德列娃等人的定义进行比较是有启发意义的。 [9]在那里，正确性要求：如果对一个离散消息序列 m进行加密，并将生成的 密文流 ||c进行解密（可能是以分段方式进行），则得到的消息序列（当消息 分隔符 ¶被移除后）必须与原始序列 m完全相同。在单个消息的特殊情况下， 这意味着在[9],的设置中，加密必须‘始终刷新’，进而导致加密必然是一个 原子操作。相比之下，在我们的设置中，Send算法配备了一个刷新标志，当该 标志设置为零时，整个消息片段可能会被缓冲以供后续发送。因此，这是博尔 德列娃等人的设置与流式设置之间的一个本质区别。另一个区别是，[9]中的正 确性条件比我们的更强，因为它包含了一定程度的鲁棒性。更具体地说，在[9] 的正确性定义中，提交解密的密文片段序列 c′可能超出加密产生的序列（换句 话说， ||c只需是 ||c′的一个前缀，解密仍能正确工作到 ||c为止）。

4基于流的通道的安全性

接下来，我们介绍适用于基于流的设置的机密性和完整性概念，并分析它们的 组合。我们将以渐近安全性的方式提供相应的概念；在具体设置中的类似概念 则容易推导得出。2

2通过将攻击者的优势定义为关于其运行时间、预言机查询次数以及预言机查询输入流 大小上限的具体函数，可以简单地定义一个具体的安全性概念。

4.1机密性

正如Boldyreva等人[9],所提出的密文分片设置中一样，其保密性概念又受到 Bellare等人IND −sfCCA概念的启发[5],，我们的安全概念必须应对基于流的 信道支持对消息或密文流的任意片段进行处理这一事实。虽然Boldyreva等人 [9]仅考虑了分段解密（但采用原子加密），因此将注意力集中在类似CCA的设 置上，而我们此处基于流的信道中的分段消息处理也影响了类似CPA的设置中 的对抗能力。因此，我们分别定义了针对选择明文片段攻击（IND − CPFA）以 及选择密文片段攻击（IND −CCFA）的安全概念。

将攻击者的选定明文能力适配到基于流的设置中相对直接（结合标准的左 或右预言机）。然而，为控制接收到的密文流分段的攻击者推导出一个合理的 安全概念则更为复杂。通常，类似选择密文攻击的预言机旨在尽可能多地解密 输入内容，同时避免导致平凡攻击。我们采用Bellare等人[5] 的方法，通过 考虑接收预言机 ORecv 处于同步状态，并且只要 A 提供由左或右发送预言机 OLoR 按正确顺序输出的原始密文流（部分），就不向攻击者 A 返回响应，以 此来建模有状态（解密）安全概念。当 A 偏离原始密文流时， ORecv 预言机 被视为失步，从该点开始，Recv算法的输出将提供给攻击者。

为了得到一个合理的定义，我们面临这样一个问题：究竟在哪个时间点exactly 应认为 ORecv处于失步状态？博尔德列娃等人决定沿用贝尔尔等人的原始定义，并 保守地将同步丢失定义在密文边界上（即每当密文的任何部分被修改时，其概念就 会揭示出由Send输出的完整密文的解密结果）。然而，在我们的基于流的设置中， 这种选择并不合适，因为在该设置中Send的输出不一定是原子单位。

以TLS为例来说明这一点，假设对一个长度为214+ 1字节的输入消息调用 发送算法（Send算法），且刷新标志f设置为1——这模拟了许多不保留发送缓 冲区的TLS实现的行为。由于单个TLS记录的有效载荷最多不得超过 214字节， 发送算法被迫输出一个包含（至少）两个TLS记录的密文片段c。此时，若攻击 者将该密文片段转发给博尔德列娃等人提出的IND −sfCFA定义中的解密预言 机both，并在转发时修改第二个记录而保持第一个记录不变，则解密预言机会 返回这两个记录的解密结果，从而直接泄露部分挑战消息字符串内容。

考虑到此示例，并且由于在我们的情况下Send的输出通常是无任何附加结 构的比特流，因此很自然地认为：当 ORecv的密文流输入的第一个比特偏离 Send的真实输出时， ORecv即进入失步状态。

更详细地说，我们通过实验IND − CPFA（选择明文片段攻击下的不可区 分性）和IND −CCFA（选择密文片段攻击下的不可区分性）来定义基于流的保 密性概念Expt IND−atk ,b Ch A（其中atk是CPFA或CCFA的占位符），如图2所 示。在实验ExptIND−atk ,b Ch A 中，攻击者的目标是猜测比特 b。在该实验中， OLoR预言机向攻击者提供对（左或右）消息片段输入执行发送的响应。预言 机首先检查输入的消息片段 m0 和 m1 是否具有相同的比特长度（即 |m0| = |m1|）。如果是，则在 mb上调用发送，将其响应 c 添加到内部密文 流变量 CS，并向 A 提供 c。

实验中的 ORecv预言机处理密文片段输入（从而更新接收状态stR,），但只 要片段仍保持同步，就人为抑制Recv的输出。如果同步已经丢失（即sync= 0）， 则 ORecv直接将Recv的输出传递给 A。否则，它会检查截至目前所见的密文片 段与当前片段 c的拼接结果 CR是否仍然是由 OLoR输出的密文流 CS的一个 前缀：如果是，则在 c上调用Recv，但抑制其输出；否则，认为此时已处于 失步状态 ORecv，并存在两种定义选项可供选择，二者均遵循“向攻击者提供 尽可能多信息但不导致平凡攻击”的范式：第一种选项是将对接收器的调用分 为两部分，一部分针对接收到的密文 c与由 OLoR输出的密文流 CS之间仍匹配 的最长公共前缀 ˜c，另一部分针对之后发生分叉的剩余密文部分；第二种选项—— 也是我们此处采用且证明比第一种更合适的选项（我们在完整版本中对此进行 讨论）——是对完整的密文 c运行接收器，然后抑制接收器在运行于 ˜c时本应 获得的消息流的部分内容。

更正式地说，我们在消息流层面上的抑制策略首先在当前状态stR,和 ˜c的 一个副本上模拟一次Recv调用，并记录其输出 m˜。其次，对攻击者提供的完 整密文片段 c，在原始状态stR,上正常调用Recv，从而输出一条消息 m。 最后，抑制 m和 m˜ 的公共前缀（即 m中任何可能的挑战消息流比特），并 将 m的剩余部分传递给 A。

定义3（IND − CPFA和IND − CCFA安全性）

设Ch=(Init,Send,Recv)是一 个基于流的信道，且对于攻击者 A 和比特 b，实验ExptIND−atk,b Ch A(1λ)如图 2所示定义，其中atk为CPFA或CCFA的占位符。在该实验中，攻击者 A可访问 一个（有状态的）左或右发送预言机 OLoR，并且在IND −CCFA安全性的情况下， 还可访问一个（有状态的）接收预言机 ORecv。我们称Ch在选择明文片段（或密文 片段）攻击下提供不可区分性（IND −CPFA或IND − CCFA），如果对于所有概 率多项式时间攻击者 A，以下优势函数在安全参数中是可忽略的：

AdvIND−atk,b Ch,A (λ):= ∣ ∣ Pr[ExptIND−atk,1 Ch,A (1λ)= 1] − Pr[ExptIND−atk,0 Ch,A (1λ)= 1] ∣ .

为了完整性，我们在完整版本中讨论了另一种直观且吸引人的定义接收预 警机的方法，即在我们的设置中对密文进行分割，然而这种方法导致的保密性 概念仅涵盖较小类别的通道。

4.2完整性

在本节中，我们对基于流的信道的完整性概念进行形式化。需要强调的是，尽 管针对原子消息（以及原子密文）的完整性属性已得到充分研究，但此前尚无 工作考虑非原子设置下的完整性。特别是，博尔德列娃等人[9] 仅讨论了存在 密文分片情况下的保密性。我们将基于流的信道的完整性概念定义为标准（有 状态）明文完整性（INT − sfPTXT）和密文完整性（INT −sfCTXT）属性的 细化，并将这些新属性分别称为明文流完整性和密文流完整性（INT − PST， 分别地，INT −CST）。

与原子消息的设定类似，INT − PST可确保对接收预言机的任何对抗性查 询都不会导致接收算法Recv输出的消息流偏离输入到发送算法Send的消息 流。形式化更强的INT −CST属性则需要更加谨慎。直观上，基于密文完整性， 我们期望在处理任何“失步”的密文时，算法Recv应返回错误信息。然而， 在考虑基于流的接口时，可能会出现Recv处理了一个失步的密文，但该密文 尚未包含“足够信息”以被识别为无效的情况；此时，接收算法将缓冲（部分） 该密文片段

安全性实验)

4.2 完整性（续）

并等待更多密文片段，直到获得足够长的密文字符串以进行处理，并判定为有效或无效。在这种情况下，对INT −sfCTXT定义的简单修改将允许攻击者通过使接收缓冲区包含（部分）失步的密文而轻易发起攻击。我们提出的密文流完整性概念仔细区分了上述情况，通过让接收预言机继续等待后续密文片段，仅当接收输出来自密文流失步部分的非空消息片段时，才判定攻击者成功。

图3展示了基于流的信道的integrity(INT − atk)安全性实验。PST攻击者被提供访问中间的 ORecv预言机（INT − PST），而CST攻击者则被授予访问右侧预言机的权限（INT −CST）。

我们通过Expt INT−atk Ch A中所示的安全性实验来形式化明文和密文流的完整性，该实验如图3所示。该实验为攻击者提供预言机 OSend和 ORecv，前者允许 A在任意选择的消息片段下访问算法Send，后者提供与算法 A Recv交互的接口。我们强调，虽然发送预言机 OSend在两个实验INT − PST和INT −CST中是共用的，但接收预言机 ORecv在这两种情况下遵循不同的流程，我们将在下文进一步解释。

在执行INT − PST实验时， OSend在字符串 M S中维护所有已发送消息片段的流，类似地， ORecv在 M R中维护所有接收到的消息片段（和/或错误符号）的流。如果对手导致 MS和 MR产生偏差，且它们的差异中包含的非错误符号数量超过限定值，则该对手赢得游戏。形式上，我们要求接收器输出的字符串 MR不是发送方字符串 MS的前缀，但这种前缀无关性不仅仅是因为来自 E的错误符号所致。

在INT − CST实验中，预言机 OSend和 ORecv维护字符串 CS和 CR，以记录已发送的密文流和已接收的密文片段流。此外，ORecv通过检查已发送和已接收的ciphertext流来判断攻击者是否获胜，这本质上比检查底层已发送/已接收消息片段序列中的偏差更为复杂。事实上，在基于流的信道中，Recv算法可能需要缓冲多个密文，才能恢复出底层的消息流或检测到错误的发生；这种行为在我们的实验中得到了体现。当处理同步的密文时， ORecv只需将每个新的片段追加到 CR中。一旦收到一个不同步的密文，预言机就会比较Recv算法在处理以下两种情况时的输出：(i) 当前输入的密文 c，以及(ii) 其最长的同步前缀 ˜c。如果在情况(i)下 ORecv的输出多于情况(ii)，且两者输出之差为一个非空的有效消息，则攻击者获胜。如果攻击者能够使Recv在处理后续的不同步密文时输出一个非空的有效消息，也同样获胜。

定义4 (INT −PST 和 INT − CST 安全性)

设 Ch=(Init, Send, Recv) 为一个基于流的信道，且针对攻击者 A 的实验 ExptINT−atk Ch A(1λ) 如图3所示定义，其中 atk 为 PST 或 CST 的占位符。在该实验中，攻击者 A 可访问一个发送预言机 OSend 和一个接收预言机 ORecv。我们称 Ch 提供明文流（相应地，密文流）的完整性（即 INT −PST 或相应地 INT −CST），如果对于所有概率多项式时间攻击者 A，以下优势函数在安全参数下是可忽略的：

AdvINT−atk Ch,A (λ):= Pr[Expt INT−atk Ch,A (1λ)= 1].

备注3. 我们对完整性的定义并不排除这样一类信道的安全性：在这些信道中，攻击者向接收预言机传递部分密文可能导致消息比特被输出。这是因为在流式环境中，我们关注的是攻击者是否能够迫使接收器接受对应于已失步的密文流部分的消息片段，而不强调密文边界的重要性。因此，这与通常的“原子”环境有明显区别。特别是，使用流式信道传输原子消息的应用程序必须格外注意，确保不会将从流式信道中部分检索到的消息片段当作完整（原子）消息进行处理，因为此类误解释可能引发——并且过去已经引发过——攻击[7,35]。

我们进一步指出，基于流的完整性所提供的保证弱于原子消息完整性，这似乎是基于流的通道性质所导致的内在结果。特别是，加强这些给定的完整性定义导致了在流式环境中明显不合适的概念。一方面，要求信道在处理第一个偏离所发送密文流的比特后立即输出错误，对于大多数构造来说是无法实现的目标，因为通常无法判断接收到的初始比特是否真实。另一方面，要求信道在未接收到由发送产生的完整密文输出之前不输出任何消息比特，这不当强加了一种原子结构给信道，即基本上等同于[9]的结构，而正如前文所述，这对于像TLS这样可能输出包含多个独立部分密文的信道而言过于严格。

4.3 各概念间的关系与通用组合定理

由于篇幅限制，我们仅在完整版本中全面讨论流式环境中所引入的安全概念之间的关系。简而言之，我们证明了对于机密性和完整性而言，较强的安全概念均蕴含较弱的概念，即如预期一样，IND − CCFA ⇒ IND − CPFA 以及 INT −CST ⇒ INT −PST。此外，我们将来自[6]的组合结果——（有状态的） IND − CPA 与 INT − CTXT 一起可推出（有状态的）IND −CCA——扩展到了我们的流式环境。有趣的是，在本案例中，类似的前置条件 IND −CPFA 和 INT −CST 单独存在并不足以建立组合结果：我们还需要信道具备 error predictable（ERR −PRE）的性质。该概念因篇幅限制仅在完整版本中定义，其形式化描述了当接收算法失败时，能够有效预测所产生的错误消息的能力。

错误可预测性在两个方面有助于我们组合定理的安全性证明。首先，它使我们能够处理存在多个解密错误[10]的问题。该问题同样出现在原子设置中，并已在该场景中通过仅考虑单个错误信息[6]或限制不同错误消息出现的可能性[10]来解决。我们的错误可预测性概念提供了一种更通用的方法，且同样适用于原子设置。其次，在证明中，错误可预测性直接支持向完整性属性INT − CST的归约。在基于流的场景中，我们必须能够判断接收器是否仍在缓冲密文片段，或者是否已经可以生成错误消息。错误可预测性恰好为我们提供了这一点。

我们强调，并将在第5节中展开说明，错误可预测性可通过自然构造来满足。基于流的通道的组合结果总结于下面的定理中。我们在完整版本中为此结果提供了形式化证明。

定理1 (完整性 −密文流 ∧不可区分性 − CPFA ∧错误空间 −错误可预测性 ⇒不可区分性 −选择密文片段攻击)

设 Ch=(初始化,发送,接收)是一个（正确的）基于流的信道，其关联的错误空间为 E。如果Ch提供了密文流的完整性、错误可预测性以及选择明文片段攻击下的不可区分性，则它也提供了选择密文片段攻击下的不可区分性。形式上，对于每个高效不可区分性 −选择密文片段攻击 攻击者 A，存在高效的完整性 −密文流 攻击者 B、错误空间 −错误可预测性 攻击者 C 以及不可区分性 − CPFA攻击者 D，使得

AdvIND−CCFA Ch,A ≤ 2 · AdvINT−CST Ch,B + 2 · AdvERR−PRE Ch,C + AdvIND−CPFA Ch,D .

5 基于流的通道的构造

在本节中，我们通过提供一种基于流的信道通用构造来证明我们的安全概念的可行性，该构造直接基于成熟的带关联数据的认证加密原语，并在机密性和完整性方面提供了强大的安全性。尽管该构造更倾向于说明性而非确定性，但我们指出，我们的构造与TLS记录协议非常接近。

我们基于罗加威[32]提出的带关联数据的认证加密（AEAD）方案AEAD = (Enc, Dec)，其密钥空间为 K，并引入特殊错误符号 ⊥，定义了基于流的信道ChAEAD=(Init, Send, Recv)的通用构造。加密算法Enc: K × {0, 1}∗×{0, 1}∗ →{0, 1}∗在输入密钥、关联数据字符串和消息后，输出密文。解密算法Dec: K×{0, 1}∗×{0, 1}∗ →({0, 1}∗ ∪{⊥})在输入密钥、关联数据字符串和密文后，输出消息或特殊错误符号。我们假设该AEAD方案支持对长度最多为il比特的变长消息进行加密，并且此类消息的密文输出长度至多为 2ol−1 比特。这使得我们能够使用固定长度的ol比特字符串来编码密文的长度。

我们的信道构造 ChAEAD 如图4所示，具有发送状态空间 SS= K× N×{0, 1}∗、接收状态空间 SR= K× N×{0, 1}∗×{0, 1}以及错误空间 E={⊥}。该信道的工作方式如下。

– 初始化算法首先为AEAD方案均匀随机地选取一个密钥 K。然后，它将发送状态和接收状态分别初始化为包含密钥 K、序列号（初始值为0）以及初始为空的消息片段缓冲区和密文片段缓冲区的元组；接收状态还包含一个初始值为 0的失败标志。

– 发送算法持续缓冲输入的消息字符串，直到收集到至少il比特为止。如果已收集足够的比特，则发送算法使用AEAD方案对长度为il比特的消息块 m′进行加密，输入消息为 m′，关联数据为当前序列号seqno。生成的密文随后会 prepend 其长度的二进制编码（固定数量的ol比特）并将结果追加到要输出的密文字符串 c中。注意，长度编码未被认证。如果调用Send算法时刷新标志f设置为1，则在最后一步中，它还会以相同方式加密缓冲区中剩余的任何消息，以清空消息缓冲区（该消息的长度可能小于il）。

– 一旦在之前的某次调用中AEAD解密算法首次产生错误，接收算法（Recv算法）将输出一个错误（不再进行任何状态修改）；否则，它会将接收到的密文片段追加到其缓冲区中。当收到足够的比特数以解析ol比特的长度字段时，便执行解析。接着，检查缓冲区是否包含指定长度的完整AEAD密文，若是，则从缓冲区中移除该密文，对其进行解密（同时递增关联数据中使用的序列号），并将解密结果追加到待输出的消息中。此过程重复执行，直到缓冲区中没有完整的可解析密文为止。然而，如果AEAD解密算法输出错误，则在将该错误符号追加到输出消息后，接收算法（Recv算法）将失败标志fail置为1，并停止解析后续输入。

ChAEAD的正确性由AEAD方案的正确性保证。

安全性分析

我们通用的基于流的信道构造ChAEAD如图4所示，在底层认证加密方案IND − CPFA提供了选择明文片段攻击下的不可区分性（INT − CST）、密文流的完整性（ERR −PRE）以及错误可预测性（AEAD满足罗加威定义的在选择明文攻击下的不可区分性（IND − CPA）和认证性（AUTH）的前提下成立[32]。根据定理1，我们还可以推导出该构造也提供了选择密文片段攻击下的不可区分性（IND −CCFA）。本文完整版本中提供了详细的安全性分析。

构造基于流的信道ChAEAD=(Init,Send,Recv)的通用构造)

5.1 关于TLS记录协议的说明

如前所述，传输层安全（TLS）记录协议实现了一种基于流的信道，对该信道的完整分析超出了本工作的范围。但我们仍需指出，我们基于带关联数据的认证加密构建的基于流的信道，实际上与使用AEAD方案的TLS记录协议非常接近，该方案在TLS 1.2[15,版本中第6.2.3节3]以及TLS 1.3[16,版本的当前草案第 6.2节2]中有规定：记录协议还包含一个经过认证但不在网络上传输的序列号，以及一个在TLS 1.2中既发送又认证的长度字段（该字段被发送但不被认证）。在TLS 1.3中）。然而，TLS记录协议还包含一个2字节版本号和一个1字节内容类型；这些都在关联数据中被发送和认证。此外，所使用的AEAD方案被认为是基于nonce的，尽管确切的nonce生成由所使用的特定密码套件指定。

特别是内容类型字段，它允许TLS在单个连接流内为不同用途多路复用数据流，正如TLS对握手协议、告警协议、ChangeCipherSpec协议和应用协议所做的那样。虽然我们的模型尚未涵盖将多个消息流多路复用到一个密文流中，但可以扩展以支持该功能。这会带来额外的复杂性，也是未来工作的方向之一。

6 结论

在这项工作中，我们研究了用于将数据流从一方（安全地）传输到另一方的信道的安全性，缩小了现实世界中的传输层安全协议（如TLS或SSH）与我们对其理论理解之间的差距。为此，我们形式化了此类基于流的信道的语法，探讨了强安全性概念，并通过提供一种自然且安全的构造方法证明了其可行性，该方法 closely mimics TLS记录协议的操作。

我们的方法为近期攻击提供了形式化的分析视角，特别是涉及基于TLS的 HTTP的使用，证实了应用的期望与安全流通道所提供的保证之间存在脱节。这表明有必要对这类协议的应用程序接口（API）及其安全性保证进行详细规范。

我们的工作也提出了新的研究问题。显然，探索基于流的信道与原子消息信道之间的精确关系是一条值得推进的研究路径，其中一项具体任务是建立我们工作中的安全概念与[9]中的安全概念之间的详细关联。考虑到现有技术，一个尚未解决的问题是：尽管长度隐藏加密这一广为接受的概念本质上与原子消息相关，是否仍可将其融入基于流的设置中。此外，似乎值得将我们的基于流的模型扩展至涵盖允许在单个信道内多路复用多个数据流的信道协议设计（如 TLS 和 QUIC）。