第八章 计算机网络安全

在第1.6节中，我们描述了一些非常普遍和破坏性的互联网攻击，包括恶意软件攻击、拒绝服务、嗅探、源伪装和消息修改和删除。虽然我们已经了解了大量关于计算机网络的知识，但我们仍然没有研究如何保护网络免受这些攻击。我们将利用新获得的计算机网络和互联网协议的专业知识，深入研究安全通信，特别是如何保护计算机网络免受那些可恶的坏人的攻击。

让我们介绍一下Alice和Bob，这两个人想要安全地交流。由于这是一个网络文本，我们应该注意到Alice和Bob可能是两个想要安全地交换路由表的路由器，一个想要建立安全传输连接的客户端和服务器，或者两个想要交换安全电子邮件的电子邮件应用程序——我们将在本章后面讨论这些案例。Alice和Bob是安全社区中的知名设备，这可能是因为它们的名称比一个名为A的通用实体更有趣，后者希望与一个名为B的通用实体进行安全通信。爱情、战时通信和商业交易是人们对安全通信的常见需求;比起后两个，我们更喜欢第一个，我们很乐意使用Alice和Bob作为我们的发送方和接收方，并在第一个场景中想象他们。

我们说过，Alice和Bob想要进行通信，并且希望这样做是安全的，但是这到底意味着什么呢?正如我们将看到的，安全(像爱情一样)是一件非常光荣的事情;也就是说，安全性有很多方面。当然，Alice和Bob希望他们的通信内容不被窃听。他们可能还想确保当他们通信时，他们确实是在互相通信，如果他们的通信被窃听者篡改了，希望这种篡改会被检测出来。在本章的第一部分中，我们将介绍基本的加密技术，这些技术允许对通信进行加密，验证与之通信的一方，并确保消息的完整性。

在本章的第二部分，我们将研究如何使用基本的密码学原则来创建安全的网络协议。同样采用自顶向下的方法，我们将研究每个(前四层)层中的安全协议，从应用层开始。我们将研究如何确保电子邮件的安全，如何确保TCP连接的安全，如何在网络层提供全面的安全，以及如何确保无线局域网的安全。在本章的第三部分，我们将考虑运营安全，这是关于保护组织网络免遭攻击。特别是，我们将仔细研究防火墙和入侵检测系统如何增强组织网络的安全性。

8.1 什么是网络安全

让我们回到希望安全地交流的恋人Alice和Bob，开始对网络安全的研究吧。这究竟意味着什么?当然，Alice希望只有Bob能够理解她发送的消息，即使他们在一个不安全的媒介上通信，入侵者Trudy可能会截获从Alice发送给Bob的任何信息。Bob还想确定他从Alice那里收到的消息确实是由Alice发送的，而Alice想确定与她通信的人确实是Bob。Alice和Bob还希望确保消息的内容在传输过程中没有被更改。他们还希望首先确保他们能够进行通信(即，没有人拒绝他们访问通信所需的资源)。考虑到这些因素，我们可以确定 安全通信 的以下理想属性。

• 保密性 只有发送方和预期的接收方才能够理解发送的消息的内容。由于窃听者可能会截获消息，这就必然要求对消息进行某种 加密 ，以使拦截的消息不能被拦截者理解。这方面的机密性可能是术语安全通信最常见的含义。我们将在第8.2节中研究用于加密和解密数据的密码技术。
• 消息完整 Alice和Bob想要确保他们的通信内容在传输过程中不会被恶意或意外地改变。我们在可靠传输和数据链路协议中遇到的校验和技术的扩展可以用来提供这样的消息完整性。我们将在8.3节中研究消息完整性。
• 端点验证 发送方和接收方都应该能够确认参与通信的另一方的身份——确认对方确实是他们所声称的人或物。面对面的交流通过视觉识别很容易地解决了这个问题。当通信实体在媒介上交换消息时无法看到对方，身份验证就没那么简单了。当用户希望访问收件箱时，邮件服务器如何验证该用户是否是他或她声称的那个人?我们将在8.4节中研究端点验证。
• 运行安全 今天几乎所有的组织(公司、大学等)都有连接到公共Internet的网络。因此，这些网络可能会受到威胁。攻击者可以向网络中的主机植入蠕虫，获取公司机密，映射内部网络配置，并发起DoS攻击。在第8.9节中，我们将看到防火墙和入侵检测系统等操作设备用于反击针对组织网络的攻击。防火墙位于组织网络和公共网络之间，控制网络数据包的来往。入侵检测系统执行深度数据包检测，向网络管理员发出可疑活动警报。

在确定了网络安全的含义之后，接下来让我们考虑入侵者可能访问哪些信息，以及入侵者可以采取哪些行动。图8.1演示了这个场景。发送方Alice想把数据发送给接收方Bob。为了安全地交换数据，同时满足机密性、端点身份验证和消息完整性的要求，Alice和Bob将交换控制消息和数据消息(就像TCP发送方和接收方交换控制段和数据段一样)。

图 8.1 发送方、接收方和入侵者(Alice、Bob和Trudy)

所有或部分消息通常将被加密。如第1.6节所讨论的，入侵者可能会执行：

• 窃听 ——嗅探并记录信道上的控制和数据消息。
• 修改、插入 或 删除 消息或消息内容

正如我们将看到的，除非采取适当的反制措施，否则这些功能允许入侵者进行各种各样的安全攻击:嗅探通信(可能窃取密码和数据)、冒充另一个实体、劫持正在进行的会话、通过超载系统资源拒绝向合法的网络用户提供服务，等等。CERT协调中心[CERT 2020]维护了报告的攻击摘要。

既然已经确定了在互联网上确实存在着真正的威胁，那么我们需要安全通信的朋友Alice和Bob在互联网上对应的是什么呢?当然，Bob和Alice可能是两个终端系统的人类用户，例如，真正想要交换安全电子邮件的真实的Alice和真实的Bob。他们也可能是电子商务交易的参与者。例如，真实的Bob可能希望将他的信用卡号安全地转移到Web服务器，以便在线购买商品。类似地，真实的Alice可能希望与她的银行进行在线交互。需要安全通信的各方本身也可能是网络基础设施的一部分。回想一下，域名系统(DNS，见第2.4节)或交换路由信息的路由守护进程(见第5章)需要双方之间的安全通信。对于网络管理应用程序也是如此，这是我们在第五章中讨论的主题。一个入侵者可以主动干扰DNS查找(如2.4节所讨论的)，路由计算(5.3节和5.4节)，或网络管理功能(5.5节和5.7节)，从而在Internet上造成严重破坏。

现在已经建立了框架、几个最重要的定义以及对网络安全的需求，接下来让我们深入研究密码学。而使用密码学提供保密性是不言而喻的，我们将很快看到这也是提供端点验证和消息完整的中心——使密码学成为网络安全的基石。

8.2 密码学原理

尽管密码学的历史很长，至少可以追溯到尤里乌斯·凯撒时代，但现代加密技术，包括许多在互联网上使用的加密技术，都是基于过去30年取得的进步。Kahn的书《密码破译者》[Kahn 1967]和Singh的书《密码书:从古埃及到量子密码学的保密科学》(Singh 1999)，让我们来看看密码学的悠久历史。对密码学本身的完整讨论需要一本完整的书[Bishop 2003;Kaufman 2002;Schneier 2015]，所以我们只涉及到加密的基本方面，特别是在互联网上进行的加密。我们还注意到，虽然本节的重点是使用密码学来实现机密性，但我们很快就会看到密码学技术不可避免地融入身份验证、消息完整性、不否认(nonrepudiation)等方面。

图 8.2 密码组件

加密技术允许发送方伪装数据，使入侵者无法从截获的数据中获得任何信息。当然，接收方必须能够从伪装的数据中恢复原始数据。图8.2说明了一些重要的术语。

假设现在Alice想要向Bob发送一条消息。Alice的原话(如:“Bob, I love you. Alice”)被称为 明文 。Alice使用加密算法加密她的明文消息，这样加密的消息，即 密文 ，对任何入侵者来说都是无法理解的。有趣的是，在许多现代密码系统中，包括那些在互联网上使用的密码系统，加密技术本身是公开的——标准化的，并且对每个人都可用(例如，[RFC 1321;RFC 3447;RFC 2420;NIST 2001])，甚至是潜在的入侵者!显然，如果每个人都知道编码数据的方法，那么一定有一些秘密信息可以防止入侵者解密传输的数据。这就是密钥的作用。

在图8.2中，Alice提供了一个 密钥 ，K_A(一串数字或字符)，作为加密算法的输入。加密算法以密钥和明文消息m作为输入，生成密文作为输出。K_A(m)表示明文消息m的密文形式(使用密钥K_A加密)。使用密钥K_A的实际加密算法将从环境中看出。类似地，Bob将为 解密算法 提供一个密钥K_B，该算法将密文和Bob的密钥作为输入，并生成原始的明文作为输出。也就是说，如果Bob收到一条加密的消息K_A(m)，他通过计算K_B(K_A(m)) = m来解密。在 对称密钥系统 中，Alice和Bob的密钥是相同的，是秘密的。在 公钥系统 中，使用一对密钥。其中有一把密钥是Bob和Alice都知道的(事实上，全世界都知道)。另一个密钥只有Bob或Alice知道(但不是两个都知道)。在下面的两个小节中，我们将更详细地讨论对称密钥和公钥系统。

8.2.1 对称密钥密码学

所有的加密算法都涉及用一件东西替换另一件东西，例如，取一段明文，然后计算并替换适当的密文来创建加密的消息。在研究现代基于密钥的密码系统之前，让我们先来研究一个非常古老、非常简单的对称密钥算法，它被称为 凯撒密码 (密码是一种加密数据的方法)。

对于英文文本，凯撒密码的工作原理是:取明文信息中的每个字母，然后以每个字母之后的第k个字母替换之(允许环绕;也就是说，字母z后面跟着字母a)。例如，如果k = 3，那么明文中的字母a变成密文中的d;明文中的b变成密文中的e，依此类推。这里，k的值作为密钥。举个例子，明文消息“bob, i love you. Alice”变成了“ere, l oryh brx. dolfh”密文。虽然密文看起来确实像胡言乱语，但如果知道使用的是凯撒密码，破解密码就不会花太多时间，因为只有25个可能的密钥。

凯撒密码的一种改进是单字母密码，它也用字母表中的另一个字母替换字母表中的一个字母。然而，不是按照常规模式进行替换(例如，用偏移量k替换所有字母)，任何字母都可以替换其他任何字母，只要每个字母都有一个唯一的替代字母，反之亦然。图8.3中的替换规则显示了一种对明文进行编码的可能规则。

图 8.3 一个单字母(monoalphabetic)密码

明文消息“bob, i love you. Alice” 变成了 “nkn, s gktc wky. mgsbc.”因此，同凯撒密码一样，这看起来像胡言乱语。单字母密码似乎也比凯撒密码更好，因为有26！(近似于10²⁶)个可能的字母组合，而不是25种可能的字母组合。尝试所有10²⁶种可能的配对的暴力方法需要做太多的工作，从而不能成为破解加密算法和解码消息的可行方法。然而，通过对明文语言的统计分析，例如，知道e和t是典型英语文本中出现频率最高的字母(占出现频率的13%和9%)，并且知道两个和三个字母出现的特定字母经常同时出现(例如，in、it、the、ion、ing等等)，就相对容易破解这个密码。如果入侵者对消息的可能内容有所了解，那么破译代码就更容易了。例如，如果入侵者Trudy是Bob的妻子，并且怀疑Bob与Alice有婚外情，那么她可能会怀疑Bob和Alice的名字出现在文本中。如果Trudy确定这两个名字出现在密文中，并且有上面示例密文消息的副本，那么她可以立即确定26个字母组合中的7个，暴力方法检查的可能性减少到19！个。事实上，如果Trudy怀疑Bob有外遇，她很可能会在消息中找到一些其他的措辞。

当考虑到Trudy破解Bob和Alice的加密方案有多容易时，我们可以根据入侵者拥有的信息区分三种不同的场景。

• 纯密文攻击 在某些情况下，入侵者可能只能访问被截获的密文，而对明文消息的内容没有特定的信息。我们已经看到了统计分析如何帮助对加密方案进行 纯密文攻击(ciphertext-only attack) 。
• 已知明文攻击 我们在上面看到，如果Trudy以某种方式确定bob和alice出现在密文消息中，那么她就可以确定字母a, l, i, c, e, b和o的(明文，密文)配对。Trudy也可能足够幸运地记录了所有的密文传输，然后找到了bob草草写在一张纸上的一个传输的解密版本。当入侵者知道一些(明文、密文)对时，我们将其称为对加密方案的 已知明文攻击（known-plaintext attack） 。
• 选择明文攻击 在 选择明文攻击（chosen-plaintext attack） 中，入侵者可以选择明文消息并获得相应的密文形式。对于我们目前看到的简单加密算法，如果Trudy能获得Alice发送的信息，“The quick brown fox jumps over the lazy dog,”，她就能完全破解加密方案。我们将很快看到，对于更复杂的加密技术，选择明文攻击并不一定意味着加密技术可以被攻破。

500年前，人们发明了改进单字母加密的技术，即 多字母加密(polyalphabetic encryption) 技术。多字母加密背后的思想是使用多个单字母密码，用特定的单字母密码对明文消息中特定位置的一个字母进行编码。因此，在明文消息中出现在不同位置的同一个字母,可能编码不同。多字母加密方案的示例如图8.4所示。它有两个凯撒密码(k = 5和k = 19)。我们可以选择在重复模式C₁, C₂, C₂, C₁, C₂中，使用这两个凯撒密码，C₁和C₂。也就是说，明文的第一个字母用C₁编码，第二个和第三个字母用C₂编码，第四个字母用C₁编码，第五个字母用C₂编码。然后重复该模式，第6个字母使用C₁编码，第7个字母使用C₂编码，以此类推。明文消息“bob, i love you.”因此加密后为“ghu, n etox dhz.”。注意，明文消息中的第一个b使用C₁加密，而第二个b使用C₂加密。在本例中，加密和解密密钥是对两个凯撒密钥(k = 5, k = 19)和模式C₁, C₂, C₂, C₁, C₂的理解。

图 8.4 使用两个凯撒密码的多字母密码

区块密码

现在让我们看看现代的对称密钥加密是如何实现的。我们将重点关注区块密码（block cipher），它用于许多安全的Internet协议，包括PGP(用于安全电子邮件)、TLS(用于保护TCP连接)和IPsec(用于保护网络层传输)。

在区块密码中，要加密的消息以k位为单位的区块进行处理。例如，如果k = 64，则消息被分解成64位的区块，每个区块独立加密。为了对一个区块进行编码，密码使用一对一的映射将k位的明文区块映射到k位的密文区块。让我们来看一个例子。假设k = 3，那么区块密码将3位输入(明文)映射为3位输出(密文)。表8.1给出了一种可能的映射。注意，这是一个一对一映射;也就是说，每个输入都有不同的输出。这种区块密码将消息分解为3位的区块，并根据上述映射对每个区块进行加密。您应该验证消息010110001111是否被加密为101000111001。

输入	输出	输入	输出
000	110	100	011
001	111	101	010
010	101	110	000
011	100	111	001

表 8.1 一种特定的3位区块密码

继续这个3位区块示例，请注意，表8.1中的映射只是许多可能映射中的一个映射。有多少可能的映射?要回答这个问题，请注意映射不过是所有可能输入的排列。有2³(= 8)种可能的输入(见输入列)。这八个输入可以排列成8!= 40320种不同的方式。因为每个排列指定一个映射，所以有40,320种可能的映射。我们可以将每个映射视为一个密钥——如果Alice和Bob都知道这个映射(密钥)，他们就可以对它们之间发送的消息进行加密和解密。

对这个密码的暴力攻击是试图通过使用所有映射来解密密文。只有40,320个映射(当k = 3时)，这可以在桌面PC上快速完成。为了阻止暴力攻击，区块密码通常使用更大的区块，由k = 64位或更大的区块组成。注意，一般k位区块密码可能的映射数是2^k!，这对于适度的k值(比如k = 64)来说也是天文数字。

尽管如前所述，k值适中的全表(full-table)区块密码可以产生健壮的对称密钥加密方案，但不幸的是，它们很难实现。对于k = 64和一个给定的映射，Alice和Bob需要维护一个包含2⁶⁴个输入值的表，这是一个不可行的任务。此外，如果Alice和Bob要更改密钥，他们必须各自重新生成表。因此，提供所有输入和输出之间的预定映射(如上例所示)的全表区块密码是不可能的。

相反，区块密码通常使用模拟随机排列表（randomly permuted tables）的函数。图8.5展示了k = 64位的这种函数的一个例子(改编自[Kaufman 2002])。该函数首先将一个64位的区块分解为8个块，每个块由8位组成。每个8位块由一个8位到8位的表处理，这个表具有可管理的大小。例如，第一个块由T₁表示的表处理。接下来，8个输出块被重新组装成一个64位区块。然后对区块中64位的位置进行置乱(排列)以产生64位输出。这个输出反馈给64位输入，从那里开始另一个循环。经过n次循环后，该函数将提供一个64位的密文区块。循环的目的是使每个输入位影响大部分(如果不是全部)最终输出位。(如果只使用一轮，一个给定的输入位只会影响64个输出位中的8个。)这个区块密码算法的密钥是八个排列表(假设置乱函数是公开的)。

图 8.5 区块密码的一个例子

今天有许多流行的区块密码，包括DES(代表数据加密标准)，3DES和AES(代表高级加密标准)。这些标准都使用函数，而不是预先确定的表，如图8.5所示(虽然每个密码都更复杂，更具体)。每一种算法都使用一串位作为密钥。例如，DES使用64位区块和56位密钥。AES使用128位的区块，可以对128、192和256位的密钥进行操作。算法的密钥决定了算法内部特定的迷你表映射和排列。对每个密码的暴力攻击是遍历所有密钥，对每个密钥应用解密算法。注意，当密钥长度为n时，有2ⁿ个可能的密钥。NIST [NIST 2001]估计，一台能够在一秒钟内破解56位DES(即在一秒钟内尝试所有2⁵⁶个密钥)的机器要想破解128位AES密钥，大约需要149万亿年。

密码区块链

在计算机网络应用中，我们通常需要对长消息或长数据流进行加密。如果我们像描述的那样简单地将消息分割成k位的区块，并独立地对每个区块进行加密，就会出现一个微妙但重要的问题。要明白这点，请注意两个或多个明文区块可以是相同的。例如，两个或多个区块中的明文可以是“HTTP/1.1”。对于这些相同的区块，密码当然会产生相同的密文。攻击者可能会在看到相同的密文区块时猜测出明文，甚至可能通过识别相同的密文区块并使用有关底层协议结构的知识来解密整个消息[Kaufman 2002]。

为了解决这个问题，我们可以在密文中加入一些随机性，使相同的明文区块产生不同的密文区块。为了解释这个思想，让m(i)表示第i个明文区块，c(i)表示第i个密文区块，a ⊕ b表示两个位字符串a和b的异或(XOR)。0 ⊕ 0 = 1 ⊕ 1 = 0和0 ⊕ 1 = 1 ⊕ 0 = 1，两个位字符串的异或运算是逐位进行的。例如，10101010 ⊕ 11110000 = 01011010。将区块密码加密算法使用的密钥S表示为K_S。基本思想如下:发送方为第i个区块创建一个k位的随机数字r(i)，并计算出c(i) = K_S (m(i) ⊕ r(i))。注意，为每个区块选择一个新的k位随机数。然后发送方发送c(1)， r(1)， c(2)， r(2)， c(3)， r(3)，依此类推。由于接收方接收到c(i)和r(i)，它可以通过计算m(i) = K_S(c(i) ⊕ r(i ))来恢复每一个明文区块。需要注意的是，尽管r(i)是明文发送的，因此Trudy可以嗅出，但她无法获得明文m(i)，因为她不知道密钥K_S。还需要注意的是，如果两个明文区块m(i)和m(j)相同，对应的密文区块c(i)和c(j)将不相同(只要随机数r(i)和r(j)不同，这种情况发生的概率非常大)。

以表8.1中的3位区块密码为例。假设明文为010010010。如果Alice直接加密，不包含随机性，得到的密文就会变成101101101。如果Trudy嗅出了这个密文，因为三个密码区块都是相同的，她可以正确地推测出三个明文区块都是相同的。现在假设Alice生成随机区块r(1) = 001, r(2) = 111和r(3) = 100，并使用上述技术生成密文c(1) = 100, c(2) = 010和c(3) = 000。注意，尽管明文区块相同，但这三个密文区块是不同的。然后Alice发送c(1)， r(1)， c(2)， r(2)， c(3)， r(3)。您应该验证Bob可以使用共享密钥K_S获得原始的明文。

精明的读者会注意到，引入随机性虽然解决了一个问题，但又产生了另一个问题:也就是说，Alice必须传输比以前多一倍的位。事实上，对于每一个密码位，她现在还必须发送一个随机位，使所需带宽增加一倍。为了鱼与熊掌兼得，区块密码通常使用一种称为 密码区块链(CBC，Cipher Block Chaining) 的技术。基本思想是在第一个消息中只发送一个随机值，然后让发送方和接收方使用计算得到的编码区块来代替随后的随机数。具体来说，CBC是这样操作的：

1. 在加密消息(或数据流)之前，发送方生成一个随机的k位字符串，称为 初始化向量(IV，Initialization Vector) 。用c(0)表示这个初始化向量。发送方以明文的形式向接收方发送IV。
2. 对于第一个区块，发送方计算m(1) ⊕ c(0)，即计算第一个明文区块与IV的异或，然后通过区块-密码算法运行该结果，得到对应的密文区块;即c(1) = K_S(m(1) ⊕ c(0))。发送方发送加密区块c(1)给接收方。
3. 对于第i个区块，发送方从c(i) = K_S(m(i) ⊕ c (i - 1))生成第i个密文区块。

现在让我们研究一下这种方法的一些后果。首先，接收方仍然能够恢复原始消息。事实上，当接收方收到c(i)时，它会用K_S解密得到m(i) = c(i) ⊕ c(i - 1);因为接收方已经知道c(i - 1)，所以它从m(i) = K_S(c(i) ⊕ c(i - 1))中获取明文区块。其次，即使两个明文区块是相同的，对应的密文(几乎总是)将是不同的。第三，尽管发送方在明文中发送了IV，但入侵者仍然无法解密密文块，因为入侵者不知道密钥S。最后，发送方只发送一个附加区块(overhead block，即IV)，因此可以忽略对长消息(包含数百个区块)的带宽使用。

作为一个例子，现在让我们确定表8.1中3位区块密码的密文，明文为010010010,IV = c(0) = 001。发送方首先使用IV计算c(1) = K_S(m(1) ⊕ c(0)) = 100。然后发送方计算c(2) = K_S(m(2) ⊕ c(1)) = K_S(010 ⊕ 100) = 000, c(3) = K_S(m(3) ⊕ c(2)) = K_S(010 ⊕ 000) = 101。读者应该验证接收方，知道IV和K_S可以恢复原始明文。

在设计安全的网络协议时，CBC有一个重要的后果:我们需要在协议中提供一种机制来将IV从发送方分发到接收方。我们将在本章后面的几个协议中看到这是如何做到的。

8.2.2公钥加密

2000多年来(从凯撒密码时代一直到20世纪70年代)，加密通信要求通信双方共享一个共同的秘密——用于加密和解密的对称密钥。这种方法的一个困难是，双方必须以某种方式同意共享密钥;但这样做本身就需要安全的通信。也许双方可以先见面并亲自商定密钥(例如，凯撒的两个百夫长可能会在罗马浴场见面)，然后用加密技术进行交流。然而，在一个网络化的世界中，通信各方可能永远不会见面，也可能永远不会交谈，除非通过网络。

双方是否可能在没有事先知道的共享密钥的情况下使用加密通信?1976年，Diffie和Hellman [Diffie 1976]演示了一种算法(现在被称为Diffie-Hellman密钥交换)来实现这一点——一种完全不同的、非常优雅的安全通信方法，导致了今天的公钥密码系统的发展。我们很快就会看到，公钥加密系统还有一些很棒的特性，这些特性不仅对加密有用，而且对身份验证和数字签名也很有用。有趣的是，在20世纪70年代早期，英国通信电子安全集团的研究人员在一系列秘密报告中独立开发出了类似于[divie 1976]和[RSA 1978]的想法。

通常情况下，伟大的想法可以在许多地方独立出现;幸运的是，公共密钥的进步不仅发生在私下，而且也发生在公众的视野中。

公钥密码学的使用在概念上非常简单。假设Alice想和Bob通信。如图8.6所示，Bob和Alice不共享一个密钥(在对称密钥系统的情况下)，而是Bob (Alice消息的接收方)有两个密钥——一个对世界上的每个人都可用的 公钥 (包括入侵者Trudy)和一个只有Bob知道的 私钥 。我们将使用 $K\_{B}^{+}$ 和 $K_{B}^{-}$ 表示法分别表示Bob的公钥和私钥。为了与Bob通信，Alice首先获取Bob的公钥。然后，Alice使用Bob的公钥和一个已知的(例如，标准化的)加密算法将她的消息m加密给Bob;即Alice计算$K_B^+$(m)。Bob收到Alice的加密消息，并使用他的私钥和已知的(例如，标准化的)解密算法来解密Alice的加密消息。也就是说，Bob计算$K_B^-(K_B^+(m))$。下面我们将看到选择公钥和私钥的加密/解密算法和技术使得:$K_B^-(K_B^+(m))$ = m;即，应用Bob的公钥，$K_B^+$，到消息，m（为了得到$K_B^+$(m)）,然后应用Bob的私钥， $K_B^-$，到m的加密版本（即，计算$K_B^-(K_B^+(m))$恢复m）。这是一个非凡的结果!通过这种方式，Alice可以使用Bob的公开可用密钥向Bob发送一条秘密消息，而双方都不需要分发任何密钥!我们很快就会看到，我们可以交换公钥和私钥加密，并得到同样非凡的结果，即$K_B^-(K_B^+(m))$ = $K_B^+(K_B^-(m))$ = m。

图 8.6 公钥密码学

虽然公钥密码学很吸引人，但有一个问题会立即浮现在脑海中。因为Bob的加密密钥是公开的，任何人都可以向Bob发送加密信息，包括Alice或假装是Alice的人。在使用单个共享密钥的情况下，发送方知道该密钥的事实隐式地将发送方标识给接收方。但是，在公钥加密的情况下，这种情况不再存在，因为任何人都可以使用Bob的公开可用密钥向Bob发送加密的消息。将发送方绑定到消息需要数字签名，这是我们将在8.3节中学习的主题。

RSA

虽然有很多算法可以解决这些问题，但RSA算法(以其创始人Ron Rivest、Adi Shamir和Leonard Adleman的名字命名)几乎已经成为公钥密码学的代名词。让我们首先看看RSA如何工作，然后检查它为什么工作。

RSA广泛使用modulo-n算法进行算术运算。让我们简单回顾一下模算法。回想一下，x对n取余就是x除以n的余数;例如，19 mod 5 = 4。在模算术中，人们执行加法、乘法和求幂等常见运算。可使用如下三个模运算公式进行加法和乘法运算：

$$[(a\ mod\ n) + (b\ mod\ n)]\ mod\ n = (a + b)\ mod\ n$$

$$[(a \mod n) - (b \mod n)] \mod n = (a - b) \mod n$$

$$[(a\ mod\ n) · (b\ mod\ n)]\ mod\ n = (a · b)\ mod\ n$$

根据第三个公式得出:(a mod n$)^d$ mod n = $a^d$ mod n，这是一个我们很快就会发现非常有用的等式。

现在假设Alice想向Bob发送一条经过RSA加密的消息，如图8.6所示。在我们对RSA的讨论中，让我们始终记住消息只不过是一个位模式，而每个位模式可以用一个整数(以及位模式的长度)唯一地表示。例如，假设一条消息是位模式是1001;此消息可以用十进制整数9表示。因此，当使用RSA加密消息时，它相当于加密表示消息的唯一整数。

RSA有两个相互关联的组成部分:

• 公钥和私钥的选择
• 加密和解密算法

为了生成公钥和私钥，Bob执行以下步骤:

1. 选择两个大的质数，p和q, p和q应该有多大?值越大，就越难破解RSA，但编码和解码所需的时间也就越长。RSA实验室建议p和q的乘积是1024位的数量级。关于如何找到大质数的讨论，见[Caldwell 2020]。

2. 计算n = pq 和 z = (p - 1)(q - 1).

3. 选一个数e，小于n，且与z没有公因数(除1外)(在这种情况下，e和z被认为是相对质数)。使用字母e是因为这个值将用于加密。

4. 找到一个数字d，使ed - 1能被z整除(即没有余数)。使用字母d是因为这个值将用于解密。换句话说，给定e，我们选择d使：

   $$ed\ mod\ z = 1$$

5. Bob向全世界提供的公钥$K_B^+$是一对数字(n, e);他的私钥$K_B^-$是一对数字(n, d)。

Alice的加密和Bob的解密步骤如下:

• 假设Alice想给Bob发送一个位模式表示为m (m < n)的整数，Alice对$m^e$进行幂运算，然后计算$m^e$除以n时的整数余数，也就是说Alice的明文消息m的加密值c为:

  ​ $$c = m^e\ mod\ n$$

对应于这个密文c的位模式被发送给Bob。

• 为了解密收到的密文消息，c, Bob计算:

  ​ $$m=c^d\ mode\ n$$

作为RSA的一个简单例子，假设Bob选择p = 5, q = 7。(诚然，这些值太小，不安全。)则n = 35 z = 24。Bob选择e = 5，因为5和24没有公因数。最后，Bob选择d = 29，因为5 · 29 - 1(即ed - 1)能被24整除。Bob公开了n = 35和e = 5这两个值，并对d = 29保密。观察这两个公共值，假设Alice现在想把l o v e发送给Bob。将每个字母解释为1到26之间的数字(a为1,z为26)，Alice和Bob分别执行表8.2和8.3所示的加密和解密。注意，在本例中，我们将四个字母中的每一个视为一个不同的消息。一个更实际的示例是将四个字母转换为它们的8位ASCII表示，然后对产生的32位模式的相应整数进行加密。(这样一个现实的例子产生的数字太长了，无法在教科书中打印!)

明文字母	m:数字表示	$m^e$	密文 c = $m^e$ mode n
l	12	248832	17
o	15	759375	15
v	22	5153632	22
e	5	3125	10

表 8.2 Alice的RSA加密，e = 5，n = 35

考虑到表8.2和8.3中的玩具示例已经产生了一些非常大的数字，并且考虑到我们前面看到的p和q应该每个都有几百位长，关于RSA的几个实际问题就会浮现在脑海中。如何选择大的质数?那么如何选择e和d呢?如何对大数求幂呢?对这些重要问题的讨论超出了本书的范围;详情请参阅[Kaufman 2002]及其参考文献。

密文c	$c^d$	m = $c^d$ mod n	明文字母
17	4819685721067509150915091411825223071697	12	l
15	127834039403948858939111232757568359375	15	o
22	851643319086537701956194499721106030592	22	v
10	1000000000000000000000000000000	5	e

表 8.3 Bob的RSA解密，d = 29,n = 35

会话密钥

我们在这里注意到RSA要求的取幂是一个相当耗时的过程。因此，在实践中RSA经常与对称密钥密码学结合使用。例如，如果Alice想向Bob发送大量加密数据，她可以这样做。首先，Alice选择一个用于编码数据本身的密钥;这个密钥被称为 会话密钥(session key) ，由$K_S$表示。Alice必须通知Bob会话密钥，因为这是共享的对称密钥，他们将使用一个对称密钥加密(例如，DES或AES)。Alice使用Bob的公钥对会话密钥进行加密，即计算c = $(K_S)^e$ mod n。Bob接收RSA加密的会话密钥c，并对其进行解密以获得会话密钥$K_S$。Bob现在知道了Alice将用于加密数据传输的会话密钥。

为什么RSA能工作?

RSA加密/解密显得相当神奇。为什么要先使用加密算法，再使用解密算法，恢复原始消息?为了理解RSA的工作原理，再次表示n = pq，其中p和q是RSA算法中使用的大素数。

回想一下，在RSA加密下，对消息(由唯一的一个整数表示)m取e次幂，然后使用modulo-n算法，即：

$$c = m^e\ mod\ n$$

解密是通过将该值取d次幂来执行的，同样使用modulo-n算法。一个加密步骤和一个解密步骤的结果是$(m^e\ mod\ n)^d$ mod n。现在让我们看看这个量。如前所述，取模算法的一个重要性质是$(a\ mod\ n)^d$ mod n = $a^d$ mod n，对于任意值a, n和d。因此，在这个性质中使用a = $m^e$，我们有

$$(m^e\ mod\ n)^d\ mod\ n = m^{ed}\ mod\ n$$

因此，它仍然表明$m^{ed}\ mod\ n$ = m。尽管我们试图消除RSA工作的一些魔力，为了建立这一点，我们将需要使用一个来自数论的相当神奇的结果。特别地，我们需要这样的结果:如果p和q是素数，n = pq, z = (p - 1)(q - 1)，那么$x^y$ mod n等于$x^{(y\ mod\ z)}$ mod n [Kaufman 2002]。将这个结果应用到x = m和y = ed，我们有

$m^{ed}\ mod\ n$=$m^{(ed\ mod\ z)}$ mod n

但记住，我们让e和d满足ed对z取余= 1。这给了我们

$m^{ed}\ mod\ n$ = $m^1$ mod n = m

这正是我们想要的结果!首先取e次幂(即加密)，然后取d次幂(即解密)，我们就得到了原始值m。更奇妙的是，如果我们先取d次幂，然后再取e次幂——也就是说，我们颠倒加密和解密的顺序，首先执行解密操作，然后应用加密操作——我们还得到了原始值m。这个美妙的结果是由模运算立即得到的：

$$(m^d\ mod\ n)^e\ mod\ n = m^{de}\ mod\ n=m^{ed}\ mod\ n=(m^e\ mod\ n)^d\ mod\ n$$

RSA的安全性依赖于这样的事实,没有已知的算法快速分解一个数字,在这种情况下,公共值n,分解成质数p和q。如果一个人知道p和q,那么考虑到公共值e,可以很容易地计算出密钥,d。另一方面,尚不清楚是否存在快速分解一个数字的算法,在这个意义上,RSA的安全性是没有保证的。随着量子计算的最新进展，以及量子计算机的快速分解算法的发布，有人担心RSA可能不会永远安全[MIT TR 2019]。但这些算法的实际实现似乎还需要很长时间。

8.3 消息完整性和数字签名

在前一节中，我们看到了如何使用加密为两个通信实体提供机密性。在本节中，我们将转向同样重要的密码学主题，即提供消息完整性(也称为消息身份验证)。除了消息完整性之外，我们还将在本节中讨论两个相关的主题:数字签名和端点身份验证。

我们再次使用Alice和Bob来定义消息完整性问题。假设Bob收到一条消息(可能是加密的，也可能是明文的)，并且他认为这条消息是由Alice发送的。要验证此消息，Bob需要进行验证：

1. 消息确实来自Alice。
2. 消息在发送给Bob的途中没有被篡改。

在第8.4至8.7节中，我们将看到消息完整性问题是几乎所有安全网络协议的关键问题。

举例来说，假设计算机网络使用链路状态路由算法(如OSPF)来确定网络中每对路由器之间的路由(参见第5章)。在链路状态路由算法中，每个路由器都需要向网络中所有其他路由器广播一条链路状态消息。路由器的链路状态消息包含了与它直接相连的邻居的列表以及这些邻居的直接开销。一旦一台路由器收到来自其他所有路由器的链路状态消息，它就可以创建一个完整的网络映射，运行它的最小开销路由算法，并配置它的转发表。对于路由算法来说，一种相对容易的攻击是Trudy分发带有错误链路状态信息的虚假链路状态消息。因此，需要消息完整性——当路由器B收到来自路由器A的链路状态消息时，路由器B应该验证路由器A是否真的创建了该消息，并且确认在传输过程中没有人篡改该消息。

在本节中，我们将描述许多安全网络协议使用的一种流行的消息完整性技术。但在此之前，我们需要介绍密码学中的另一个重要主题——密码散列函数。

密码散列函数

如图8.7所示，散列函数接受一个输入，m，并计算一个叫散列（hash）的固定大小的字符串H(m)。Internet校验和(第3章)和CRC(第6章)满足这个定义。 密码散列函数(cryptographic hash function) 需要具有以下附加属性：

• 在计算上找不到任意两个不同的消息x和y使H(x) = H(y)。

图 8.7 散列函数

非正式地说，该属性意味着入侵者在计算上无法用一条消息替换受散列函数保护的另一条消息。也就是说，如果(m, H(m))是消息和发送者创建的消息的散列值，那么入侵者无法伪造另一条消息y的内容，使该消息y与原始消息具有相同的散列值。

让我们说服自己，一个简单的校验和，如Internet校验和，执行一个糟糕的加密散列函数。而不是执行1补和（1s complement）运算(正如Internet上的校验和)，让我们计算校验和，将每个字符视为一个字节，并一次使用4字节块将字节相加。假设Bob欠Alice $100.99，并向Alice发送IOU组成消息字符串“IOU100.99BOB”。这些字符的ASCII表示(十六进制表示法)是49,4f,55,31,30,30,2E,39,39,42,4F,42。

图8.8(上)显示了这条消息的4字节校验和是B2 C1 D2 AC。图8.8的下半部分显示了一个稍微不同的消息(对Bob来说是一个更昂贵的消息)。消息"IOU100.99BOB"和"IOU900.19BOB"具有相同的校验和。因此，这个简单的校验和算法违反了上面的要求。给定原始数据，很容易找到具有相同校验和的另一组数据。显然，出于安全考虑，我们需要一个比校验和更强大的哈希函数。

图 8.8 初始消息和欺诈消息有相同的校验和!

Ron Rivest [RFC 1321]的MD5散列算法在今天被广泛使用。它在一个四步过程中计算一个128位散列，这个四步过程包括填充步骤(添加一个1后跟足够多的0，以便消息的长度满足某些条件)、附加步骤(在填充之前附加消息长度的64位表示)、累加器的初始化步骤和循环步骤，在循环步骤中，消息的16字区块在四轮中被处理(破坏)。关于MD5的描述(包括C源代码实现)参见[RFC 1321]。

今天使用的第二个主要散列算法是安全散列算法(SHA-1) [FIPS 1995]。该算法的原理与MD5的前身MD4 [RFC 1320]的设计原理类似。SHA-1是美国联邦标准，当联邦应用程序需要加密散列算法时，就需要使用它。它产生160位的消息摘要。输出长度越长，SHA-1安全性越高。

8.3.2 消息验证码

现在让我们回到消息完整性的问题。现在我们已经理解了散列函数，让我们先来尝试一下如何执行消息完整性：

1. Alice创建消息m并计算散列H(m)(例如，使用SHA-1)。
2. 然后Alice将H(m)追加到消息m，创建一条扩展消息(m, H(m))，将扩展消息发送给Bob。
3. Bob收到一条扩展消息(m, h)并计算出H (m)。如果H(m) = h, Bob得出结论，一切正常。

这种方法显然有缺陷。Trudy可以创建一条假消息 m′ ，她说自己是Alice，计算H(′)，然后发送给Bob (′, H(′))。当Bob收到消息时，在步骤3中检查所有内容，因此Bob不会怀疑有任何可疑的事情。

为了实现消息完整性，除了使用加密散列函数外，Alice和Bob还需要一个共享密钥(shared secret)，s。这个共享密钥就是一串位，称为 验证密钥（authentication key） 。使用此共享密钥，可以如下执行消息完整性：

1. Alice创建消息m，将s和m连接起来创建m + s，并计算散列值H(m + s)(例如，使用SHA-1)。H(m + s)称为 消息验证码MAC (message authentication code)。
2. 然后Alice将MAC添加到消息m，创建一个扩展消息(m, H(m + s))，并将该扩展消息发送给Bob。
3. Bob收到一个扩展消息(m, h)，并且知道s，计算MAC H (m + s)，如果H (m + s) = h, Bob认为一切正常。

这个过程的摘要如图8.9所示。读者应该注意，这里的MAC(代表消息验证码)与链路层协议中使用的MAC(代表媒介访问控制)不同。

图 8.9 消息验证码(MAC)

MAC的一个优点是它不需要加密算法。事实上，在许多应用中，包括前面描述的链路状态路由算法,通信实体只关心消息的完整性，而不关心消息的机密性。使用MAC，实体可以验证它们发送给彼此的消息，而不必将复杂的加密算法集成到完整性过程中。

正如您所预料的那样，多年来针对MAC提出了许多不同的标准。目前最流行的标准是 HMAC ，它既可以和MD5一起使用，也可以和SHA-1一起使用。HMAC实际上通过散列函数运行数据和验证密钥两次[Kaufman 2002;RFC 2104)。

这仍然是一个重要的问题。我们如何将共享验证密钥分发给通信实体?例如，在链路状态路由算法中，我们可能需要以某种方式将验证密钥分发给自治系统中的每个路由器。(注意，路由器可以使用相同的验证密钥。)网络管理员实际上可以通过访问每个路由器来实现这一点。或者，如果网络管理员很懒，而且每个路由器都有自己的公钥，那么网络管理员可以将验证密钥分发给任意一台路由器，用路由器的公钥对验证密钥进行加密，然后再通过网络将加密后的密钥发送给路由器。

8.3.3 数字签名

想想你上周在一张纸上签名的次数。你签支票、信用卡收据、法律文件和信件。你的签署证明你(而不是其他人)已承认及/或同意该文件的内容。在数字世界中，通常要指出文件的所有者或创造者，或表示对文件内容的同意。 数字签名 是一种在数字世界中实现这些目标的加密技术。

就像手写签名一样，数字签名应该以一种可验证和不可伪造的方式进行。也就是说，必须有可能证明某个人签署的文件确实是由那个人签署的(签名必须是可验证的)，并且只有那个人签署了该文件(签名不能伪造)。

现在让我们考虑如何设计数字签名方案。注意，当Bob签署消息时，Bob必须在消息中添加对他来说是唯一的东西。Bob可以考虑为签名附加一个MAC，其中MAC是通过将他的密钥(对他来说是唯一的)附加到消息中，然后获取散列来创建的。但是Alice要验证签名，她还必须有一个密钥的副本，在这种情况下，密钥对Bob来说不是唯一的。因此，MAC无法完成这里的工作。

回想一下，使用公钥加密，Bob同时拥有一个公钥和一个私钥，这两个密钥对Bob来说都是唯一的。因此，公钥密码学是提供数字签名的一个很好的候选者。现在让我们来研究一下它是如何做到的。

假设Bob想要对文档m进行数字签名。我们可以将该文档视为Bob将要签名和发送的文件或消息。如图8.10所示，要签名此文档，Bob只需使用他的私钥，$K_B^-$,来计算$K_B^-(m)$。乍一看，Bob使用他的私钥(如我们在第8.2节中看到的，该私钥用于解密用他的公钥加密的消息)来签署文档似乎有些奇怪。但是请记住，加密和解密只不过是数学运算(在RSA中对e或d取幂)。请参阅第8.2节，并回忆Bob的目标不是混淆或模糊文档的内容，而是以一种可验证和不可伪造的方式签署文档。Bob对文档的数字签名是$K_B^-(m)$。

图 8.10 为文档创建数字签名

数字签名$K_B^-(m)$是否满足我们可验证和不可伪造的要求?假设Alice有m和$K_B^-(m)$。她想在法庭上证明Bob确实签署了该文件，并且是唯一可能签署该文件的人。Alice使用Bob的公钥$K_B^+$，并将其应用于与文档m相关联的数字签名$K_B^-(m)$。也就是说，她计算$K_B^+(K_B^-(m))$，生成了m，它与原始文档完全匹配!然后Alice认为只有Bob可以签署这个文件，原因如下:

• 对消息进行签名的人必须在计算签名$K_B^-(m)$时使用私钥$K_B^-$，这样$K_B^+(K_B^-(m))$ = m。
• 唯一可能知道私钥$K_B^-$的人是Bob。回想一下我们在8.2节中对RSA的讨论，知道公钥$K_B^+$对得知私钥$K_B^-$没有任何帮助。因此，唯一知道$K_B^-$的人是首先生成密钥对($K_B^+$, $K_B^-$)的人，Bob。(注意，这假设Bob没有给任何人$K_B^-$，也没有任何人从Bob那里窃取$K_B^-$。)

还需要注意的是，如果将原始文档m修改为另一种形式,′，那么Bob为m创建的签名对′来说将无效,因为$K_B^+(K_B^-(m))$不等于′。因此，我们看到数字签名还提供了消息的完整性，允许接收方验证消息及其来源是否未被更改。

通过加密签名数据的一个问题是，加密和解密的计算成本很高。考虑到加密和解密的开销，通过完全加密/解密对数据进行签名可能是多余的。一种更有效的方法是在数字签名中引入散列函数。回顾8.3.2节，散列算法获取任意长度的消息m，并计算该消息的固定长度“指纹”，用H(m)表示。Bob使用散列函数对消息的散列值进行签名，而不是消息本身，也就是说，Bob计算$K_B^-(H(m))$。由于H(m)通常比原始消息m小得多，创建数字签名所需的计算工作量大大减少。

在Bob向Alice发送消息的环境中，图8.11提供了创建数字签名的操作过程的摘要。Bob将他的原始长消息推入一个散列函数，然后他用他的私钥对生成的散列进行数字签名。原始消息(明文)和数字签名消息摘要(因此称为数字签名)随后被发送给Alice。图8.12提供了签名操作过程的摘要。Alice将发送者的公钥应用到消息中以获得一个散列结果。Alice还将散列函数应用于明文消息以获得第二个散列结果。如果两个散列匹配，那么Alice可以确定消息的完整性和作者。

图 8.11 发送数字签名消息

图 8.12 验证已签名的消息

在继续之前，让我们简单地比较一下数字签名和MAC，因为它们有相似之处，但也有重要的细微差别。数字签名和MAC都以消息(或文档)开始。为了在消息中创建MAC，我们将验证密钥附加到消息中，然后获取结果的散列值。注意，创建MAC时既不涉及公钥加密，也不涉及对称密钥加密。要创建数字签名，我们首先获取消息的散列，然后用我们的私钥对消息进行加密。因此，数字签名是一种较"重"的技术，因为它需要底层的公钥基础设施(PKI)和证书颁发机构，如下所述。我们将在第8.4节中看到PGP——一个流行的安全电子邮件系统——使用数字签名来实现消息的完整性。我们已经看到OSPF使用MAC来实现消息的完整性。在第8.5和8.6节中，我们将看到MAC也用于流行的传输层和网络层安全协议。

公钥认证

数字签名的一个重要应用是 公钥认证(public key certification) ，即证明一个公钥属于某个特定的实体。公钥认证在许多流行的安全网络协议中使用，包括IPsec和TLS。

为了深入了解这个问题，让我们考虑一个经典的“披萨恶作剧”的互联网商务版本。Alice从事披萨外卖业务，接受网上订单。披萨爱好者Bob向Alice发送了一条纯文本消息，其中包括他的家庭地址和他想要的披萨类型。在此消息中，Bob还包含一个数字签名(即原始明文消息散列的签名)，以向Alice证明他是消息的真正来源。为了验证签名，Alice获取Bob的公共密钥(可能来自公共密钥服务器或电子邮件消息)并检查数字签名。通过这种方式，她确保下订单的是Bob，而不是某个恶作剧的青少年。

这一切听起来都很好，直到聪明的Trudy出现。如图8.13所示，Trudy沉迷于一个恶作剧。她给Alice发了一条短信，说自己是Bob，并给了Bob的家庭住址，然后叫了一份披萨。在这条消息中，她还包括她(Trudy)的公钥，尽管Alice自然地假定它是Bob的公钥。Trudy还附加了一个数字签名，这是用她自己(Trudy)的私钥创建的。在收到消息后，Alice将Trudy的公钥(认为它是Bob的)应用到数字签名中，并得出明文消息确实是Bob创建的。当送货员带着腊肠和凤尾鱼的披萨到家时，Bob会非常惊讶!

图 8.13 Trudy用公钥密码伪装成Bob

从这个示例中我们可以看出，要使公钥加密有用，您需要能够验证您拥有希望与之通信的实体(人、路由器、浏览器等)的实际公钥。例如，当Alice想要使用公钥加密与Bob通信时，她需要验证应该是Bob的公钥是否确实是Bob的。

将公钥绑定到特定实体通常由 认证机构(CA，Certification Authority ) 完成，其工作是验证身份和颁发证书。CA具有如下角色：

1. CA验证实体(人、路由器等)是否与它所说的一致。对于如何进行认证并没有强制性的程序。在处理CA时，必须相信CA已经执行了适当严格的身份验证。例如，如果Trudy能够走进伪CA并简单地宣布我是Alice并接受与Alice身份相关的证书，那么人们就不应该太相信伪CA认证的公钥。另一方面，人们可能(或不可能!)更愿意信任联邦或州计划的一部分的CA。您可以信任与公钥关联的身份，但只能信任CA及其身份验证技术的程度。我们编织了一张多么复杂的信任之网啊！
2. 一旦CA验证了实体的身份，CA就创建一个 证书 ，该证书将实体的公钥绑定到该身份。该证书包含公钥和关于公钥所有者的全局唯一标识信息(例如，人名或IP地址)。证书由CA进行数字签名。图8.14显示了这些步骤。

图 8.14 Bob的公钥由CA认证

现在让我们看看如何用证书来对付像Trudy这样的披萨订餐恶作剧者和其他不受欢迎的人。当Bob下订单时，他还发送CA签名的证书。Alice使用CA的公钥检查Bob的证书的有效性，并提取Bob的公钥。

国际电信联盟(ITU)和IETF都为CA制定了标准。ITU X.509 [ITU 2005a]指定了一种验证服务以及证书的特定语法。[RFC 1422]描述了用于安全Internet电子邮件的基于CA的密钥管理。它与X.509兼容，但通过为密钥管理体系结构建立过程和约定而超越了X.509。表8.4描述了证书中的一些重要字段。

字段名	描述
Version	X.509规范的版本号
Serial number	CA颁发的证书的唯一标识符
Signature	指定CA签署此证书时使用的算法
Issuer name	颁发此证书的CA的标识，以区分名称的格式 (DN) [RFC 4514]
Validity period	证书有效期的开始及结束日期
Subject name	其公钥与此证书相关联的实体的身份(DN格式)
Subject public key	实体的公钥以及与此密钥一起使用的公钥算法(和算法参数)的指示

表8.4 X.509和RFC 1422公钥中的选定字段

8.4 端点身份验证

端点身份验证(End-point authentication) 是一个实体通过计算机网络向另一个实体证明其身份的过程，例如，用户向电子邮件服务器证明其身份。作为人类，我们可以通过多种方式验证对方的身份:见面时认出对方的脸，打电话时认出对方的声音，海关官员根据护照上的照片对我们进行验证。

在本节中，我们将考虑当双方通过网络通信时，一方如何对另一方进行身份验证。我们这里主要讨论在通信实际发生时对活动的一方进行身份验证。一个具体的例子是用户向电子邮件服务器验证自己的身份。这与证明过去某个时候收到的消息确实来自声明的发送者(如第8.3节所述)的问题略有不同。

在网络上执行身份验证时，通信双方不能依赖生物特征信息，例如视觉外观或声纹。实际上，我们将在后面的案例研究中看到，通常是路由器和客户端/服务器进程等网络元素必须相互验证。在这里，身份验证必须完全基于作为 身份验证协议（authentication protocol） 一部分交换的消息和数据。通常，身份验证协议会在通信双方运行其他协议(例如，可靠的数据传输协议、路由信息交换协议或电子邮件协议)之前运行。验证协议首先确定双方的身份，使对方满意;只有在身份验证之后，双方才能着手进行手头的工作。

就像我们在第3章中开发可靠数据传输(rdt)协议的情况一样,我们将在这里开发各种版本的认证协议,我们将称之为 ap (身份验证协议),并在我们继续进行的每个版本中找出漏洞。(如果你喜欢这个设计的逐步发展，你可能也会喜欢[Bryant 1988]，它讲述了一个开放网络认证系统的设计者之间的虚构故事，以及他们发现的许多微妙问题)。

假设Alice需要向Bob验证自己。

也许我们能想到的最简单的身份验证协议就是Alice简单地向Bob发送一条消息，说她是Alice。该协议如图8.15所示。这里的缺陷是显而易见的——Bob没有办法知道发送信息“我是Alice”的人确实是Alice。例如，Trudy(入侵者)也可以发送这样的信息。

图8.15 ap1.0协议和失败场景

身份验证协议 ap2.0

如果Alice有一个众所周知的网络地址(例如IP地址)，Bob可以通过验证携带验证消息的IP数据报上的源地址是否与Alice的已知地址匹配来验证Alice。在这种情况下，Alice将被验证。这可能会阻止一个非常天真的网络入侵者冒充Alice，但它不会阻止坚定的学生研究这种案例，或其他案例。

从我们对网络层和数据链路层的研究中知道，创建一个IP数据报并不困难(例如,如果一个人进入操作系统代码,可以建立一个自己的操作系统内核,就像Linux和其他几个免费操作系统一样),把我们想要的IP源地址(例如,Alice的著名的IP地址)的IP数据报,并将数据报通过链路层协议送到第一跳路由器。从那时起，错误的源地址数据报将被忠实地转发给Bob。这种方法(如图8.16所示)是一种IP欺骗。如果配置Trudy的第一跳路由器只转发包含Trudy的IP源地址的数据报[RFC 2827]，就可以避免IP欺骗。然而，这种能力并不是普遍部署或强制的。因此，如果Bob认为Trudy的网络管理员(可能就是Trudy自己)已经将Trudy的第一跳路由器配置为只转发适当地址的数据报，那就太愚蠢了。

图8.16 ap2.0协议和失败场景

身份验证协议 ap3.0

一种经典的身份验证方法是使用秘密密码。密码是身份验证者和被验证者之间的共享秘密。Gmail、Facebook、telnet、FTP和许多其他服务使用密码身份验证。在ap3.0协议中，Alice将她的秘密密码发送给Bob，如图8.17所示。

图8.17 ap3.0协议和失败场景

由于密码的使用如此广泛，我们可能会怀疑协议ap3.0是相当安全的。如果是这样，我们就错了!这里的安全漏洞很明显。如果Trudy窃听到Alice的通讯，她就能知道Alice的密码。为了避免您认为这是不可能的，请考虑这样一个事实:当您Telnet到另一台机器并登录时，登录密码将不加密地发送到Telnet服务器。连接到Telnet客户端或服务器局域网的人可能会嗅探(读取和存储)在局域网中传输的所有数据包，从而窃取登录密码。事实上，这是一种众所周知的窃取密码的方法(例如，参见[Jimenez 1997])。这样的威胁显然是非常真实的，所以ap3.0显然不行。

身份验证协议 ap3.1

我们修复ap3.0的下一个想法自然是加密密码。通过加密密码，我们可以防止Trudy知道Alice的密码。如果我们假设Alice和Bob共享一个对称密钥$K_{A-B}$，那么Alice可以对密码进行加密，并将她的身份信息“我是Alice”和她的加密密码发送给Bob。然后Bob解密密码，假设密码是正确的，对Alice进行身份验证。Bob可以放心地对Alice进行身份验证，因为Alice不仅知道密码，而且还知道加密密码所需的共享密钥值。我们称该协议为ap3.1。

虽然ap3.1确实阻止了Trudy获知Alice的密码，但在这里使用加密并不能解决身份验证问题。Bob受到 回放攻击（playback attack） :Trudy只需要窃听Alice的通信，记录加密后的密码，然后将加密后的密码回放给Bob，假装她是Alice。在ap3.1中使用加密密码并没有使情况与图8.17中的协议ap3.0有明显的不同。

身份验证协议 ap4.0

图8.17中的失败场景是由于Bob无法区分Alice的原始身份验证和后来回放的Alice的原始身份验证。也就是说，Bob不知道Alice是否在活动(也就是说，当前确实在连接的另一端)，也不知道他接收到的消息是否是Alice之前验证的记录的回放。非常(非常)细心的读者应该还记得，解决相同问题所需的三次TCP握手协议——如果接收到的SYN(Synchronize Sequence Numbers)段是以前连接的SYN段的旧副本(重传)，TCP连接的服务器端不希望接受该连接。TCP服务器端如何解决确定客户端是否真正处于活动状态的问题?它选择了一个很长时间没有使用过的初始序列号，将该序列号发送给客户端，然后等待客户端以包含该序列号的ACK段响应。对于身份验证，我们可以采用相同的思路。

nonce 是一个协议在一生中只使用一次的数字。也就是说，一旦协议使用了nonce，它将永远不会再使用这个号码。我们的ap4.0协议使用如下的nonce：

1. Alice把"我是Alice"的消息发给Bob。
2. Bob选择一个nonce,R，并把它发送给Alice。
3. Alice使用Alice和Bob的对称密钥,$K_{A-B}$,对nonce进行加密，并将加密后的nonce ,$K_{A-B}(R)$ ,发送回Bob。与ap3.1协议一样，事实是Alice知道$K_{A-B}$，并使用它来加密一个值，让Bob知道他收到的消息是由Alice生成的。nonce用于确保Alice是活动的。
4. Bob解密接收到的消息。如果解密的nonce等于他发送给Alice的nonce，那么Alice就被验证了。

协议ap4.0如图8.18所示。通过使用一生中只使用一次的值,R，然后检查返回值$K_{A-B}(R)$， Bob可以确定Alice是她所说的那个人(因为她知道加密R所需的密钥值)，并且是活跃的(因为她已经加密了Bob刚刚创建的nonce， R)。

图8.18 ap4.0协议和成功场景

nonce和对称密钥加密的使用构成了ap4.0的基础。一个自然的问题是，我们是否可以使用nonce和公钥加密(而不是对称密钥加密)来解决身份验证问题。本章最后的问题对这一问题进行了探讨。

8.5 安全电子邮件

在前几节中，我们研究了网络安全中的基本问题，包括对称密钥和公钥加密、端点身份验证、密钥分发、消息完整性和数字签名。我们现在要研究这些工具是如何被用来提供互联网安全的。

有趣的是，可以在Internet协议栈的前四层中的任何一层提供安全服务。当为特定的应用层协议提供安全性时，使用该协议的应用程序将享有一种或多种安全服务，如保密性、身份验证或完整性。当为传输层协议提供安全性时，使用该协议的所有应用程序都享有该传输协议的安全服务。当在网络层以主机对主机的方式提供安全性时，所有传输层段(以及所有应用层数据)都享受网络层的安全服务。当以链路为基础提供安全性时，则所有在链路上传输的帧中的数据都得到链路的安全性服务。

在8.5到8.8节中，我们将研究如何在应用层、传输层、网络层和链路层中使用安全工具。为了与本书的总体结构保持一致，我们从协议栈的顶部开始，讨论应用层的安全性。我们的方法是使用特定的应用程序(电子邮件)作为应用层安全性的案例研究。然后我们向下移动协议栈。我们将讨论提供传输层安全性的TLS协议、提供网络层安全性的IPsec协议、IEEE 802.11无线局域网协议的安全性。

您可能想知道为什么在Internet的多个层中提供安全功能。难道仅仅在网络层提供安全功能并完成它还不够吗?这个问题有两个答案。首先，虽然网络层的安全性可以通过对数据报中的所有数据(即所有传输层段)加密和对所有源IP地址进行身份验证来提供“全面覆盖”，但它不能提供用户级的安全性。例如，商业站点不能依赖IP层安全性来对在商业站点购买商品的客户进行身份验证。因此，需要在更高的层上实现安全功能，同时也需要在较低的层上实现全面覆盖。其次，通常更容易在协议栈的较高层部署新的Internet服务，包括安全服务。在等待安全被广泛部署到网络层(这可能还需要许多年的时间)的同时，许多应用程序开发人员只是将安全功能引入到他们喜欢的应用程序中。一个典型的例子是Pretty Good Privacy (PGP)，它提供安全的电子邮件(在本节后面讨论)。PGP只需要客户端和服务器应用程序代码，是最早在互联网上广泛使用的安全技术之一。

8.5.1 安全电子邮件

现在，我们使用第8.2至8.3节的加密原理来创建一个安全的电子邮件系统。我们以递增的方式创建这种高级设计，在每个步骤引入新的安全服务。在设计一个安全的电子邮件系统时，让我们记住8.1节中介绍的生动的例子——Alice和Bob之间的爱情。假设Alice想要向Bob发送一封电子邮件，而Trudy想要入侵。

在为Alice和Bob设计一个安全的电子邮件系统之前，我们应该考虑哪些安全特性是他们最需要的。首先也是最重要的是保密性。如第8.1节所讨论的，Alice和Bob都不希望Trudy读取Alice的电子邮件消息。Alice和Bob最希望在安全电子邮件系统中看到的第二个功能是发送方身份验证。特别是当Bob收到“I don’t love you anymore. I never want to see you again.Formerly yours, Alice”的信息时。他自然会想确认消息是Alice而不是Trudy发来的。这对情侣喜欢的另一个功能是消息完整性，也就是说，确保Alice发送的消息在发送到Bob的途中没有被修改。最后，电子邮件系统应该提供接收方身份验证;也就是说，Alice想要确保她确实是把信寄给了Bob，而不是冒充Bob的其他人(例如，Trudy)。

所以，让我们从最重要的问题开始，保密性。提供保密性的最直接方法是让Alice使用对称密钥技术(如DES或AES)加密消息，让Bob在接收消息时解密消息。正如在8.2节中讨论的，如果对称密钥足够长，并且只有Alice和Bob有密钥，那么其他人(包括Trudy)读取消息是极其困难的。尽管这种方法很简单，但它具有我们在8.2节中讨论的基本困难——分发一个对称密钥，这样只有Alice和Bob有它的副本。所以我们自然会考虑另一种方法——公钥加密(例如，使用RSA)。在公钥方式中，Bob使他的公钥公开可用(例如，在公钥服务器中或在他的个人Web页面上)，Alice用Bob的公钥加密她的消息，然后她将加密的消息发送到Bob的电子邮件地址。当Bob收到消息时，他只需要用他的私钥解密即可。假设Alice明确地知道公钥是Bob的公钥，这种方法是提供所需保密性的绝佳方法。然而，一个问题是公钥加密的效率相对较低，特别是对于长消息。

为了克服效率问题，我们使用会话密钥(在第8.2.2节中讨论)。具体来说，Alice(1)随机选择一个对称会话密钥$K_S$，(2)用对称会话密钥加密她的消息m，(3)用Bob的公钥$K_B^+$加密对称会话密钥，(4)将加密的消息和加密的对称会话密钥连接起来形成一个"包"，(5)将包发送到Bob的电子邮件地址。步骤如图8.19所示。(在这个图和后面的图中，圈出的"+"表示连接，圈出的"-"表示取消连接。)当Bob收到包时，他(1)使用他的私钥$K_B^-$来获得对称密钥$K_S$，(2)使用对称会话密钥$K_S$来解密消息m。

​ 图8.19 Alice使用了一个对称会话密钥$K_S$，向Bob发送了一封秘密电子邮件

在设计了一个提供机密性的安全电子邮件系统之后，现在让我们设计另一个同时提供发送方身份验证和消息完整性的系统。现在，我们假设Alice和Bob不再关心机密性(他们想与每个人分享他们的感受!)，而只关心发送方身份验证和消息完整性。为了完成这个任务，我们使用数字签名和消息摘要，如8.3节所述。具体来说，Alice(1)对她的消息m应用散列函数H(例如，MD5)来获得消息摘要，(2)用她的私钥$K_A^-$对散列函数的结果进行签名，以创建一个数字签名，(3)将原始(未加密)消息与签名连接起来创建一个包，(4)将包发送到Bob的电子邮件地址。当Bob收到包时，他(1)应用Alice的公钥$K_A^+$到消息摘要,(2)将该操作的结果与他自己的消息散列值H进行比较。步骤如图8.20所示。如8.3节所讨论的，如果两个结果相同，Bob就可以非常确信消息来自Alice并且没有被修改。

图8.20 使用散列函数和数字签名来提供发送方身份验证和消息完整性

现在，让我们考虑设计一个提供保密性、发送方身份验证和消息完整性的电子邮件系统。这可以通过结合图8.19和8.20中的过程来完成。Alice首先创建一个初始包，如图8.20所示，包含她的原始消息和数字签名的消息的散列。然后，她将这个初始包视为消息本身，并通过图8.19中的发送方步骤发送这个新消息，创建一个发送给Bob的新包。Alice应用的步骤如图8.21所示。当Bob收到包时他首先应用图8.19和图8.20中那种方式。很明显，这种设计实现了提供保密性、发送方身份验证和消息完整性的目标。注意，在这个方案中，Alice使用了两次公钥加密:一次使用她自己的私钥，一次使用Bob的公钥。类似地，Bob也使用了两次公钥加密——一次他的私钥，一次Alice的公钥。

图8.21 Alice使用对称密钥加密、公钥加密、散列函数和数字签名来提供保密性、发送方身份验证和消息完整性

图8.21中概述的安全电子邮件设计可能在大多数情况下为大多数电子邮件用户提供了令人满意的安全性。然而，仍有一个重要问题有待解决。图8.21中的设计要求Alice获得Bob的公钥，Bob也需要获得Alice的公钥。这些公钥的分发是一个非常重要的问题。例如，Trudy可能伪装成Bob，并给Alice她自己的公钥，同时说这是Bob的公钥，使她能够接收给Bob的消息。正如我们在第8.3节中了解到的，安全分发公钥的一种流行方法是使用CA认证公钥。

8.5.2 PGP

Phil Zimmermann在1991年写的 PGP(Pretty Good Privacy) [PGP 2020]是电子邮件加密方案的一个很好的例子。PGP设计在本质上与图8.21所示的设计相同。根据版本的不同，PGP软件使用MD5或SHA来计算消息摘要;用于对称密钥加密的CAST、triple-DES或IDEA;公钥加密为RSA。

安装PGP后，软件会为用户创建一个公钥对。公钥可以在用户的网站上公开，也可以放在公钥服务器上。私钥通过使用密码来保护。每次用户访问私钥时都需要输入密码。PGP用户可以选择对消息进行数字签名、加密，或者同时进行数字签名和加密。图8.22显示了一条PGP签名消息。此消息出现在MIME头之后。消息中经过编码的数据为$K_A^- (H(m))$，即经过数字签名的消息摘要。正如我们上面讨论的，为了让Bob验证消息的完整性，他需要访问Alice的公钥。

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bob: Can I see you tonight? Passionately yours, Alice -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv yhHJRHhGJGhgg/12EpJ+lo8gE4vB3mqJhFEvZP9t6n7G6m5Gw2 -----END PGP SIGNATURE-----

图8.22 PGP签名消息

-----BEGIN PGP MESSAGE----- Version: PGP for Personal Privacy 5.0 u2R4d+/jKmn8Bc5+hgDsqAewsDfrGdszX68liKm5F6Gc4sDfcXyt RfdS10juHgbcfDssWe7/K=lKhnMikLo0+1/BvcX4t==Ujk9PbcD4 Thdf2awQfgHbnmKlok8iy6gThlp -----END PGP MESSAGE

图8.23 一个加密的PGP消息

图8.23显示了一条加密PGP消息。此消息也出现在MIME头之后。当然，明文消息不包含在秘密电子邮件消息中。当发送方(如Alice)既想要保密性又想要完整性时，PGP在图8.22的消息中包含了图8.23所示的消息。

PGP还提供了一种公钥认证机制，但这种机制与传统的CA有很大的不同，PGP公钥是通过一个*信任网（web of trust）*进行认证的。Alice自己可以证明任何密钥/用户名对，如果她认为这对确实该在一起的话。此外，PGP允许Alice说她信任另一个用户来保证更多密钥的真实性。部分PGP用户通过召开密钥签名派对进行密钥签名。用户通过物理方式聚集、交换公钥，并使用私钥签名验证对方的密钥。

8.6 安全的TCP连接：TLS

在上一节中，我们了解了加密技术如何为特定的应用程序(即电子邮件)提供机密性、数据完整性和端点身份验证。在本节中，我们将深入协议栈中的一层，并研究密码学如何通过安全服务增强TCP，包括保密性、数据完整性和端点身份验证。TCP的这个增强版本通常被称为 传输层安全(TLS，Transport Layer Security) ，它已经被IETF标准化[RFC 4346]。该协议的一个较早且类似的版本是SSL Version 3。

SSL协议最初是由网景公司设计的，但是保护TCP的基本思想早于网景(例如，见Woo [Woo 1994])。自诞生以来，SSL和它的继承者TLS得到了广泛的部署。所有流行的Web浏览器和Web服务器都支持TLS, Gmail和基本上所有的Internet商务网站(包括Amazon、eBay和淘宝)都使用TLS。每年在TLS上花费数千亿美元。事实上，如果您曾经使用信用卡在互联网上购买过任何东西，那么您的浏览器和服务器之间的通信几乎肯定使用了TLS。(当URL以https:而不是http开头时，您可以识别您的浏览器正在使用TLS。)

为了理解TLS的需求，让我们来了解一个典型的Internet商务场景。Bob正在网上冲浪，来到了卖香水的Alice Incorporated网站。Alice Incorporated站点显示了一个表单，Bob需要在该表单中输入所需香水的类型和数量、他的地址和他的支付卡号码。Bob输入这个信息，点击Submit，并期望收到(通过普通邮政邮件)购买的香水,他还希望接下来在支付卡中收到订单的费用情况。这听起来不错，但是如果不采取安全措施，Bob可能会遇到一些意外。

• 如果不使用保密性(加密)，入侵者就可以拦截Bob的命令，获取他的支付卡信息。然后，入侵者可以以Bob的钱进行购买。
• 如果不使用数据完整性，入侵者可以修改Bob的订单，让他购买比预期多十倍的香水。
• 最后，如果没使用服务器身份验证，服务器可以显示Alice Incorporated著名的标志，而实际上是Trudy维护的网站，她伪装成Alice Incorporated，当接受到Bob的订单后，Trudy可以拿着Bob的钱跑路。或者Trudy可以通过收集Bob的名字，地址和信用卡号来进行身份窃取。

TLS通过增强TCP的保密性、数据完整性、服务器身份验证和客户端身份验证来解决这些问题。

TLS通常用于为通过HTTP发生的事务提供安全性。但是，由于TLS可以保护TCP，因此任何运行在TCP上的应用程序都可以使用它。TLS提供了一个带有套接字的简单API，它类似于TCP的API。当应用程序希望使用TLS时，该应用程序包含SSL类/库。如图8.24所示，尽管TLS技术上驻留在应用层，但从开发人员的角度来看，它是一种传输层协议，提供了TCP的服务，并增强了安全服务。

图8.24 尽管TLS技术上位于应用层，但从开发人员的角度来看，它是一个传输层协议

8.6.1 宏图

我们首先描述TLS的一个简化版本，它将使我们对TLS的why和how有一个全面的了解。我们将把这个简化版本的TLS称为"almost-TLS"。在描述了almost-TLS之后，在下一小节中，我们将描述真正的TLS，并填充细节。almost-TLS(和TLS)有三个阶段:握手、密钥派生和数据传输。现在，我们描述客户端(Bob)和服务器(Alice)之间的通信会话的这三个阶段，其中Alice有一个私/公钥对，以及一个将其身份绑定到她的公钥的证书。

握手

在握手阶段，Bob需要(a)与Alice建立TCP连接，(b)验证Alice是否真的是Alice， (c)向Alice发送一个主密钥，Alice和Bob使用这个主密钥生成TLS会话所需的所有对称密钥。这三个步骤如图8.25所示。注意，一旦建立了TCP连接，Bob就会向Alice发送一个hello消息。然后，Alice返回她的证书，其中包含她的公钥。如第8.3节所讨论的，因为证书已经由CA认证，所以Bob肯定知道证书中的公钥属于Alice。然后Bob生成一个主密钥(MS，Master Secret)(仅用于此TLS会话)，使用Alice的公钥对MS进行加密，生成EMS(Encrypted Master Secret)，并发送给Alice。Alice用她的私钥解密EMS以获得MS。在这个阶段之后，Bob和Alice(其他人都不知道)知道这个TLS会话的主密钥。

图8.25 almost-TLS握手，almost-TLS从TCP连接开始

密钥派生

原则上，MS(现在由Bob和Alice共享)可以用作所有后续加密和数据完整性检查的对称会话密钥。然而，对于Alice和Bob来说，使用不同的加密密钥以及使用不同的密钥进行加密和完整性检查通常被认为是更安全的。因此，Alice和Bob都使用MS生成4个密钥：

• $E_B$ = 从Bob发送到Alice的数据的会话加密密钥
• $M_B$ = 从Bob发送到Alice的数据的会话HMAC密钥，其中HMAC [RFC 2104]是我们在8.3.2节中遇到的标准散列消息验证码(MAC)
• $E_A$ = 从Alice发送到Bob的数据的会话加密密钥
• $M_A$ = 从Alice发送到Bob的数据的会话HMAC密钥

Alice和Bob各自从MS生成4个密钥。这可以通过简单地将MS分割成4个密钥来完成。(但实际上TLS要复杂一些，我们将会看到)在密钥派生阶段的最后，Alice和Bob都拥有所有四个密钥。两个加密密钥将用于加密数据;两个HMAC密钥将被用来验证数据的完整性。

数据传输

既然Alice和Bob共享了相同的四个会话密钥($E_B$、$M_B$、$E_A$和$M_A$)，它们就可以开始通过TCP连接向彼此发送安全的数据了。由于TCP是一种字节流协议，自然的方法是让TLS动态地加密应用程序数据，然后将加密的数据动态地传递给TCP。但是如果我们要这样做，我们应该把HMAC放在哪里进行完整性检查呢?我们当然不希望等到TCP会话结束时才验证在整个会话中Bob发送的所有数据的完整性!为了解决这个问题，TLS将数据流分成记录，为每条记录附加一个HMAC以进行完整性检查，然后对记录+HMAC进行加密。为了创建HMAC, Bob将记录数据和密钥$M_B$输入到散列函数中，如8.3节所述。为了加密记录+HMAC包, Bob使用他的会话加密密钥$E_B$。然后将这个加密的包传递给TCP，以便在Internet上传输。

尽管这种方法有很长的路要走，但在为整个消息流提供数据完整性方面，它仍然不能做到万无一失。特别地，假设Trudy是一个woman-in-the-middle，并且能够在Alice和Bob之间发送的TCP段流中插入、删除和替换段。例如Trudy可以捕获Bob发送的两个段，将这两个段的顺序颠倒，调整TCP序列号(未加密)，然后将这两个顺序颠倒的段发送给Alice。假设每个TCP段精确地封装了一条记录，现在让我们看看Alice是如何处理这些段的。

1. 在Alice中运行的TCP会认为一切正常，并将这两条记录传递给TLS子层。
2. Alice中的TLS将对这两条记录进行解密。
3. Alice中的TLS将使用每条记录中的HMAC来验证这两条记录的数据完整性。
4. 然后TLS将两个记录的解密字节流传递给应用层;但是由于记录是颠倒的，Alice接收到的完整字节流的顺序不正确。

当Trudy删除段或重放段时，鼓励您演练类似的场景。

这个问题的解决方案，正如您可能猜到的，是使用序列号。TLS的操作如下。Bob维护一个序列号计数器，该计数器从0开始，并对他发送的每个TLS记录递增。实际上Bob并没有在记录中包含序列号，但是在计算HMAC时，他会在HMAC计算中包含序列号。因此，HMAC现在是数据的散列值加上HMAC密钥$M_B$加上当前序列号。Alice跟踪Bob的序列号，通过在HMAC计算中包含适当的序列号来验证记录的数据完整性。这种TLS序列号的使用阻止了Trudy进行woman-in-the-middle攻击，例如重新排序或重放段。(为什么?)

TLS记录

TLS记录(以及almost-TLS记录)如图8.26所示。记录由类型字段、版本字段、长度字段、数据字段和HMAC字段组成。注意，前三个字段没有加密。type字段指示该记录是握手消息还是包含应用程序数据的消息。它还用于关闭TLS连接，如下所述。接收方TLS使用长度字段从传入的TCP字节流中提取TLS记录。版本字段不言自明。

图8.26 TLS记录格式

8.6.2 更大的宏图

前面的小节涵盖了almost-TLS协议;它让我们对TLS的why和how有了一个基本的了解。既然我们已经对TLS协议有了基本的了解，那么我们就可以更深入地研究一下实际TLS协议的精要。在阅读TLS协议的描述的同时，建议您完成Wireshark TLS实验室，该实验室可以在教科书的网站上找到。

TLS握手

SSL并不强制Alice和Bob使用特定的对称密钥算法或特定的公钥算法。相反，TLS允许Alice和Bob在TLS会话开始时(在握手阶段)就加密算法达成一致。此外，在握手阶段，Alice和Bob互相发送nonces，用于创建会话密钥($E_B$、$M_B$、$E_A$和$M_A$)。实际的TLS握手步骤如下：

1. 客户端发送一个它支持的加密算法列表，以及一个客户端nonce。
2. 从列表中，服务器选择对称算法(例如AES)和公钥算法(例如RSA，具有特定密钥长度)和HMAC算法(MD5或SHA-1)以及HMAC密钥。它向客户端返回它的选择，以及一个证书和一个服务器nonce。
3. 客户端验证证书，提取服务器的公钥，生成一个Pre-Master Secret (PMS)，用服务器的公钥对PMS进行加密，然后将加密后的PMS发送给服务器。
4. 使用相同的密钥派生函数(由TLS标准指定)，客户端和服务器分别从PMS和nonce计算主密钥(MS)。然后MS被分割，生成两个加密和两个HMAC密钥。此外，当选择的对称密码使用CBC(如3DES或AES)时，则两个初始化向量(IV)——连接的两边各一个——也从MS获取。因此，客户端和服务器之间发送的所有消息都是加密和验证的(使用HMAC)。
5. 客户端发送所有握手消息的HMAC。
6. 服务器发送所有握手消息的HMAC。

最后两个步骤可以防止握手被篡改。要了解这一点，请注意在步骤1中，客户端通常提供一个算法列表——有的强，有的弱。这个算法列表以明文形式发送，因为加密算法和密钥还没有达成一致。Trudy作为woman-in-the-middle，可以从列表中删除较强的算法，迫使客户端选择较弱的算法。为了防止这种篡改攻击，在步骤5中，客户端发送其连接的发送和接收的所有握手消息的HMAC。服务器可以将这个HMAC与它接收和发送的握手消息的HMAC进行比较。如果不一致，服务器可以终止连接。类似地，服务器发送它看到的握手消息的HMAC，允许客户端检查不一致。

您可能想知道为什么步骤1和步骤2中有nonce。难道序列号不足以防止段重放攻击吗?答案是肯定的，它们不能单独防止"连接重放攻击"。考虑下面的连接重放攻击。假设Trudy嗅探了Alice和Bob之间的所有消息。第二天，Trudy伪装成Bob并向Alice发送了Bob在前一天发送给Alice的相同的消息序列。如果Alice不使用nonce，她将以她前一天发送的完全相同的消息序列来回复。Alice不会怀疑任何骗人的勾当，因为她收到的每一条信息都将通过完整性检查。如果Alice是一个电子商务服务器，她会认为Bob正在下第二个订单(完全相同的事情)。另一方面，通过在协议中包含一个nonce, Alice将为每个TCP会话发送不同的nonce，导致这两天的加密密钥不同。因此，当Alice从Trudy接收到回放的TLS记录时，这些记录将无法通过完整性检查，虚假的电子商务交易将不会成功。总之，在TLS中，nonce用于防御连接重放攻击，序列号用于防御在正在进行的会话中重放单个数据包。

连接关闭

在某些时候，Bob或Alice都希望结束TLS会话。一种方法是让Bob通过简单地终止底层TCP连接来结束TLS会话——也就是说，Bob向Alice发送一个TCP FIN段。但是，这样一个幼稚的设计为*截断攻击(truncation attack)*设置了台阶，Trudy再次进入正在进行的TLS会话中，并以TCP FIN提前结束会话。如果Trudy这样做，Alice会认为她收到了Bob的所有数据，而实际上她只收到了它的一部分。这个问题的解决方案是在类型字段中指出记录是否用于终止TLS会话。(虽然TLS类型是明文发送的，但它在接收方使用记录的HMAC进行身份验证。)通过包含这样一个字段，如果Alice在接收关闭TLS记录之前收到一个TCP FIN，她就会知道发生了一些有趣的事情。

至此，我们完成了对TLS的介绍。我们已经看到它使用了第8.2和8.3节中讨论的许多密码学原理。想在更深层次上探索TLS的读者可以阅读Rescorla关于SSL/ TLS的高可读性的书籍[Rescorla 2001]。

8.7 网络层安全:IPsec和VPN

IP安全协议，通常称为 IPsec ，提供网络层的安全性。IPsec保护任何两个网络层实体(包括主机和路由器)之间的IP数据报。正如我们将很快描述的那样，许多机构(公司、政府分支机构、非营利组织等)使用IPsec创建运行在公共Internet上的 虚拟私有网络(VPN,virtual private networks) 。

在讨论IPsec的细节之前，让我们先回过头来探讨一下在网络层提供保密性意味着什么。对于一对网络实体之间的网络层机密性(例如，两个路由器之间、两个主机之间或路由器和主机之间)，发送实体对它发送给接收实体的所有数据报的有效载荷进行加密。加密的有效载荷可以是TCP段、UDP段、ICMP消息等等。如果有这样的网络层服务，那么所有数据都将从一个实体发送到另一个实体——包括电子邮件、Web页面、TCP握手消息和管理消息(如ICMP和SNMP)——对任何可能嗅探网络的第三方都是隐藏的。因此，网络层安全被称为提供“全面覆盖”。

除了保密性之外，网络层安全协议还可能提供其他安全服务。例如，它可以提供源身份验证，以便接收实体可以验证受保护数据报的源。网络层安全协议可以提供数据完整性，因此接收实体可以检查数据报在传输过程中可能发生的任何篡改。网络层安全服务还可以提供重放攻击预防，这意味着Bob可以检测到攻击者可能插入的任何重复数据报。我们很快就会看到IPsec确实为所有这些安全服务提供了机制，即保密性、源身份验证、数据完整性和重放攻击预防。

8.7.1 IPsec和VPN

一个跨多个地理区域的机构通常希望拥有自己的IP网络，这样它的主机和服务器就可以以安全和保密的方式相互发送数据。为了实现这一目标，机构可以实际部署一个独立的物理网络——包括路由器、链路和DNS基础设施——它完全独立于公共互联网。这种专用于某一特定机构的不连贯的网络被称为 私有网络 。毫无疑问，私有网络可能非常昂贵，因为机构需要购买、安装和维护自己的物理网络基础设施。

如今，许多机构不再部署和维护私有网络，而是在现有的公共互联网上创建VPN。通过VPN，机构的办公室间流量通过公共互联网发送，而不是通过物理上独立的网络。但是为了提供保密性，办公室间的通信在进入公共Internet之前是经过加密的。一个简单的VPN示例如图8.27所示。这里的机构包括一个总部、一个分支机构和出差的销售人员，他们通常从他们的酒店房间访问互联网。(图中只有一个销售人员)在这个VPN中，每当总部中的两台主机相互发送IP数据报时，或者每当分支机构中的两台主机想要通信时，它们都使用传统的IPv4(即不使用IPsec服务)。但是，该机构的两个主机通过公共互联网的路径进行通信时，通信内容在进入互联网之前会被加密。

图8.27 VPN

为了了解VPN是如何工作的，让我们在图8.27的环境中浏览一个简单的示例。当总部的一台主机向酒店的销售人员发送IP数据报时，总部的网关路由器将普通的IPv4数据报转换为IPsec数据报，然后将IPsec数据报转发到Internet。这个IPsec数据报实际上有一个传统的IPv4头，这样公共互联网中的路由器就可以像处理普通IPv4数据报一样处理该数据报——对他们来说，数据报是一个非常普通的数据报。但是，如图8.27所示，IPsec数据报的负载中包含一个IPsec头，用于IPsec处理;此外，IPsec数据报的有效负载是加密的。当IPsec数据报到达销售人员的笔记本电脑时，笔记本电脑中的操作系统将对负载进行解密(并提供其他安全服务，如验证数据完整性)，并将未加密的负载传递给上层协议(如TCP或UDP)。

我们刚刚对一个机构如何使用IPsec来创建VPN进行了高层次的概述。为了透过树木看森林，我们忽略了许多重要的细节。现在让我们仔细看看。

8.7.2 AH协议和ESP协议

IPsec是一种相当复杂的怪兽——它在十几个RFC中都有定义。两个重要的RFC是RFC 4301，它描述了整个IP安全架构，以及RFC 6071，它提供了IPsec协议套件（suite）的概述。和往常一样，我们在这本教科书中的目标不是简单地缺乏创意地改写枯燥和神秘的RFC，而是采取一种更具有操作性和教学意义的方法来描述协议。

在IPsec协议套件中，有两个主要协议: AH (Authentication Header) 协议和 ESP (encapsulating Security Payload) 协议。当源IPsec实体(通常是主机或路由器)向目标实体(也可以是主机或路由器)发送安全数据报时，它使用AH协议或ESP协议。AH协议提供源认证和数据完整性，但不提供保密性。ESP协议提供源认证、数据完整性和保密性。由于对VPN和其他IPsec应用来说，保密性往往是至关重要的，因此ESP协议比AH协议的应用要广泛得多。为了消除IPsec的神秘感并避免它的复杂性，我们今后将专门关注ESP协议。希望了解AH协议的读者可以探索RFC和其他在线资源。

8.7.3 安全关联

IPsec数据报是在一对网络实体之间发送的，例如两台主机之间、两台路由器之间或主机和路由器之间。IPsec数据报从源实体发送到目标实体之前，源实体和目标实体之间需要建立网络层逻辑连接。此逻辑连接称为 安全关联(SA，security association) 。SA是一个单工逻辑连接;也就是说，从源到目标是单向的。如果两个实体都希望相互发送安全的数据报，那么需要建立两个SA(即两个逻辑连接)，每个方向建立一个SA。

例如，再次思量图8.27中的机构VPN。这个机构由一个总部、一个分公司，还有n个旅行推销员组成。为了便于举例，假设总部和分支机构之间存在双向IPsec流量，总部和业务人员之间存在双向IPsec流量。在这个VPN中，SA有多少?请注意，总部网关路由器和分支机构网关路由器之间有两个SA(每个方向一个)。对于每个销售人员的笔记本电脑，在总部网关路由器和笔记本电脑之间有2个SA(每个方向一个)。所以总共有(2 + 2n)个SA。但是，请记住，并不是所有由网关路由器或笔记本电脑发送到Internet的流量都是IPsec安全的。例如，总部的一台主机可能希望访问公共Internet上的Web服务器(如Amazon或谷歌)。因此，网关路由器(和笔记本电脑)将向互联网发送普通IPv4数据报和安全的IPsec数据报。

现在让我们看看SA内部。为了使讨论更加具体和具体，让我们以图8.28中路由器R1到路由器R2之间的SA为例进行讨论。(如图8.27所示，可以将Router R1想象为总部网关路由器，Router R2想象为分支机构网关路由器。)路由器R1将维护这个SA的状态信息，包括：

• SA的32位标识符，称为 安全参数索引(SPI，Security Parameter Index)
• SA的源接口(在本例中为200.168.1.100)和目标接口(在本例中为193.68.2.23)
• 要使用的加密类型(例如，3DES和CBC)
• 加密密钥
• 完整性检查的类型(例如HMAC 和 MD5)
• 身份验证密钥

每当路由器R1需要构造一个IPsec数据报以便在这个SA上转发时，它都会访问这个状态信息，以确定它应该如何对数据报进行身份验证和加密。类似地，路由器R2将为该安全关联维护相同的状态信息，并将使用这些信息对从该安全关联到达的任何IPsec数据报进行身份验证和解密。

图8.28 从R1到R2的安全关联

一个IPsec实体(路由器或主机)经常维护大量SA的状态信息。例如，在图8.27中有n个销售员的VPN实例中，总部网关路由器为(2 + 2n)安全关联维护状态信息。IPsec实体将其所有SA的状态信息存储在其 安全关联数据库(SAD，Security Association Database) 中，这是实体OS内核中的一种数据结构。

8.7.4 IPsec数据报

在描述了SA之后，我们现在可以描述实际的IPsec数据报了。IPsec有两种不同的数据包形式，一种是叫做 隧道模式（tunnel mode） ，另一种叫做 传输模式(transport mode) 。隧道模式比传输模式部署得更广泛，更适合于VPN。为了进一步揭开IPsec的神秘面纱并避免其复杂性，我们从此只关注隧道模式。一旦你掌握了隧道模式，你应该能够很容易自发理解传输模式。

IPsec数据报的数据包格式如图8.29所示。您可能认为数据包格式是枯燥无味的，但是我们很快就会看到IPsec数据报实际上看起来和尝起来就像一种流行的Tex-Mex美食!让我们在图8.28的环境中检查IPsec字段。假设路由器R1收到来自总部网络172.16.1.17的普通IPv4数据报，目标地址是分支网络172.16.2.48。路由器R1使用以下方法将原始IPv4数据报转换为IPsec数据报：

• 在原始IPv4数据报(包括原始头字段)的后面追加一个“ESP 尾”字段
• 使用SA指定的算法和密钥对结果进行加密
• 在加密的量的前面附加一个称为“ESP header”的字段;做成的包叫做“enchilada”
• 使用SA中指定的算法和密钥在整个enchilada上创建一个认证MAC
• 将MAC附加到enchilada后面形成有效负载
• 最后，创建一个全新的IP头，包含所有经典的IPv4头字段(通常为20字节长)，并将其附加在负载之前

图8.29 IPsec数据报格式

注意，产生的IPsec数据报是一个真正的IPv4数据报，传统的IPv4头字段后面跟着一个负载。但是在这种情况下，有效负载包含一个ESP头、原始IP数据报、一个ESP 尾和一个ESP验证字段(对原始数据报和ESP 尾进行加密)。原IP数据报的源IP地址为172.16.1.17，目标IP地址为172.16.2.48。因为IPsec数据报包含原始IP数据报，所以这些地址作为IPsec数据包有效负载的一部分被包含(并进行加密)。但是，在新的IP头(即IPsec数据报最左边的头)中的源IP地址和目标IP地址怎么办呢?如您所料，此处设置为隧道两端的源路由器接口200.168.1.100和目标路由器接口193.68.2.23。另外，这个新的IPv4头字段中的协议号没有设置为TCP、UDP或SMTP的协议号，而是设置为50，表示这是一个使用ESP协议的IPsec数据报。

R1将IPsec数据报发送到公网后，要经过很多路由器才能到达R2。这些路由器中的每一个都将像处理普通数据报一样处理IPsec数据报——他们完全不知道数据报携带的是IPsec加密的数据。对于这些公网路由器，由于外层头中的目标IP地址是R2，因此数据报的最终目的地是R2。

在浏览了如何构造IPsec数据报的示例之后，现在让我们仔细看看enchilada中的成分。从图8.29中可以看出，ESP尾由三个字段组成:padding; pad length;和next header。回想一下，区块密码要求将消息加密为区块长度的整数倍。使用padding(由无意义的字节组成)，以便在添加到原始数据报时(以及pad length和next header字段)，产生的消息是区块的整数倍。padding -length字段指示接收实体插入了多少padding(因此需要删除)。next header标识有效负载数据字段中包含的数据类型(例如，UDP)。负载数据(通常是原始的IP数据报)和ESP 尾被连接起来，然后进行加密。

附加在这个加密单元前面的是ESP头，它以明文发送，由两个字段组成:SPI和序列号字段。SPI向接收实体表示该数据报所属的SA;然后，接收实体可以用SPI对其SAD进行索引，以确定适当的身份验证/解密算法和密钥。序列号字段用于防止重放攻击。

发送实体还附加一个认证MAC。如前所述，发送实体在整个enchilada(包括ESP头、原始IP数据报和ESP尾)上计算一个MAC——数据报和尾被加密)。回想一下，为了计算MAC，发送端向enchilada添加一个秘密的MAC密钥，然后计算结果的固定长度散列值。

当R2收到IPsec数据报时，发现数据报的目标地址是R2本身。因此，R2处理数据报。因为协议字段(最左边的IP报头)是50,R2认为它应该对数据报应用IPsec ESP处理。首先，仔细观察enchilada，R2使用SPI来确定数据报属于哪个SA。其次，计算出enchilada的MAC值，验证该MAC值与ESP MAC字段的值是否一致。如果是，它就知道enchilada来自R1，没有被篡改过。第三，它检查序列号字段，以验证数据报是新鲜的(而不是重放的数据报)。第四，使用与SA相关联的解密算法和密钥对被加密的单元进行解密。第五，它删除填充并提取原始的IP数据报。最后，第六，将原始数据报转发到分支机构网络，向最终目的地发送。哇，多么复杂的食谱啊?没人说过准备和拆开enchilada是件容易的事！

实际上还有另一个重要的微妙之处需要解决。问题的核心是:当R1收到来自总部网络主机的一个(不安全的)数据报，该数据报的目标地址是总部以外的某个IP地址时，R1如何知道是否应该转换为IPsec数据报?如果要由IPsec处理，R1如何知道哪个SA(在它的SAD中的许多SA中)应该被用来构造IPsec数据报?问题解决如下。除了SAD之外，IPsec实体还维护另一个称为 安全策略数据库(SPD，Security Policy Database) 的数据结构。SPD表示哪些类型的数据报(根据源IP地址、目标IP地址和协议类型)需要被IPsec处理;需要IPsec处理的，使用哪个SA。在某种意义上，SPD中的信息指示如何处理到达的数据报;SAD中的信息指示了如何去做。

IPsec服务总结

那么，IPsec具体提供什么服务呢?让我们从攻击者的角度来研究这些服务，例如Trudy，她是一个woman-in-the-middle，位于图8.28中R1和R2之间的路径上。假设在本讨论中Trudy不知道SA使用的身份验证和加密密钥。Trudy能做什么，不能做什么?首先，Trudy看不到原始数据报。事实上，不仅原始数据报中的数据对Trudy是隐藏的，协议号、源IP地址和目标IP地址也都是隐藏的。对于SA发送的数据报，Trudy只知道该数据报来自200.168.1.100，发送到193.68.2.23。她不知道它携带的是TCP、UDP还是ICMP数据;她不知道它是否携带HTTP、SMTP或其他类型的应用程序数据。因此，这种保密性比SSL要远得多。第二，假设Trudy试图通过翻转某些位来篡改SA中的数据报。当这个被篡改的数据报到达R2，它将通不过完整性检查(使用MAC)，再次挫败Trudy的恶毒企图。第三，假设Trudy试图伪装成R1，创建一个源为200.168.1.100，目标为193.68.2.23的IPsec数据报。Trudy的攻击将是徒劳的，因为这个数据报将再次通过R2的完整性检查。最后，由于IPsec包含序列号，Trudy将无法创建成功的重放攻击。总之，如本节开头所述，IPsec提供——在通过网络层处理数据包的任何一对设备之间——保密性、源认证、数据完整性和重放攻击防范。

8.7.5 IKE: IPsec中的密钥管理

当VPN的端点数量较少时(例如图8.28中只有两台路由器)，网络管理员可以手动将SA信息(加密/认证算法和密钥，以及SPI)输入到端点的SAD中。对于可能包含数百甚至数千个IPsec路由器和主机的大型VPN来说，这种手动操作显然是不切实际的。大型的地理分布式部署需要一种自动机制来创建SA。IPsec通过在RFC 5996中指定的Internet密钥交换(IKE，Internet Key Exchange)协议来实现这一点。

IKE与SSL中的握手有一些相似之处(参见章节8.6)。每个IPsec实体都有一个证书，证书中包含该实体的公钥。与SSL一样，IKE协议让两个实体交换证书、协商身份验证和加密算法，并安全地交换密钥材料，以便在IPsec SA中创建会话密钥。与SSL不同，IKE使用两个阶段来执行这些任务。

让我们以图8.28中的两台路由器R1和R2为例来研究这两个阶段。第一阶段包括R1和R2之间的两次消息对交换：

• 在第一次交换消息时，双方使用Diffie-Hellman(参见作业问题)在路由器之间建立一个双向 IKE SA 。为了让我们所有人都感到困惑，这个双向IKE SA与8.6.3节和8.6.4节中讨论的IPsec SA完全不同。IKE SA在两台路由器之间提供一条经过验证和加密的信道。在第一次消息对交换期间，为IKE SA建立加密和身份验证的密钥。还建立了一个主密钥，将在阶段2中用于计算IPSec SA密钥。注意，在第一步中，没有使用RSA公钥和私钥。具体来说，R1和R2都不会通过使用其私钥签名消息来显示其身份。
• 在第二次交换消息中，双方通过签名向对方透露自己的身份。但是，身份不会透露给无源的嗅探器（passive sniffer），因为消息是通过安全的IKE SA信道发送的。在此阶段，双方还将协商IPsec SA使用的IPsec加密和认证算法。

在IKE阶段2中，双方在每个方向上创建一个安全关联。在阶段2结束时，两个安全关联的加密和身份验证会话密钥在双方建立。然后双方可以使用SA发送安全的数据报，如8.7.3节和8.7.4节所述。IKE中有两个阶段的主要动机是计算开销——由于第二阶段不涉及任何公钥加密，IKE可以在两个IPsec实体之间生成大量的SA，而计算开销相对较低。

8.8 安全无线局域网和4G/5G蜂窝网络

在无线网络中，安全性是一个特别重要的问题，攻击者可以通过简单地将接收设备放置在发送者的传输范围内的任何地方来嗅闻帧。这在802.11无线局域网以及4G/5G蜂窝网络中都是如此。在这两种设置中，我们将看到我们在本章前面研究的基本安全技术的广泛使用，包括使用nonce进行身份验证，使用加密散列实现消息完整性，衍生用于加密用户会话数据的共享对称密钥，以及广泛使用AES加密标准。随着研究人员和黑客发现现有安全协议中的弱点和缺陷，我们也将看到，正如有线互联网设置中的情况一样，无线安全协议经历了不断的演变。

在本节中，我们简要介绍802.11(WiFi)和4G/5G设定下的无线安全。有关更深入的讨论，请参阅高可读性的802.11安全书籍[Edney 2003;Wright 2015]，【Sauter 2014】3G/4G/5G安全的优秀覆盖，以及近期调查【Zou 2016;Kohlios 2018]。

8.8.1 802.11无线局域网中的认证和密钥协商

让我们通过确定两个(或许多[Zou 2016])我们希望802.11网络处理的关键安全问题来开始我们对802.11安全的讨论：

• 相互身份验证 在允许移动设备完全连接到接入点并将数据报发送到远程主机之前，网络通常希望首先对设备进行身份验证——验证连接到网络的移动设备的身份，并检查该设备的接入权限。类似地，移动设备将希望验证它所连接的网络——确保它要加入的网络是它真正想要连接的网络。这种双向身份验证称为 相互身份验证 。
• 加密 由于802.11帧将在无线信道上交换，可能会被潜在的不干正事者（ne’er do-well）嗅出和操纵，因此对携带移动设备和接入点(AP)之间交换的用户级数据的链路级帧进行加密将是很重要的。在实践中使用对称密钥加密，因为加密和解密必须高速执行。移动设备和AP将需要导出要使用的对称加密和解密密钥。

图8.30说明了移动设备希望连接到802.11网络的场景。我们在7.3节的802.11网络的早期研究中看到了两个常见的网络组件——我们还看到了一个新的架构组件， 身份验证服务器(AS，authentication server) ，它将负责对移动设备进行身份验证。身份验证服务器可能位于AP中，但更常见的情况是，它被实现为提供身份验证服务的单独服务器，如图8.30所示。在认证过程中，AP作为一个直通（pass-through）设备，在移动设备和验证服务器之间中继认证和密钥派生消息。这种验证服务器通常会为其网络内的所有AP提供验证服务。

图8.30 WPA中的相互身份验证和加密密钥派生

在图8.30中，我们可以确定相互身份验证和加密密钥派生和使用过程的四个不同阶段：

1. 发现 在发现阶段，AP将它的存在以及可以提供给移动设备的身份验证和加密形式通告给移动设备。然后移动设备请求所需的特定形式的身份验证和加密。虽然设备和AP已经在交换消息，但设备还没有通过身份验证，也没有在无线链路上进行帧传输的加密密钥，因此在设备通过AP进行安全通信之前，还需要几个步骤。
2. 相互身份验证和共享对称密钥派生 这是确保802.11信道安全的最关键步骤。我们会看到，假设(在802.11和4G/5G网络的实践中都是如此)，在开始相互身份验证之前，身份验证服务器和移动设备已经拥有一个 共享的秘密（shared common secret） ，这将大大促进这一步骤的进行。在此步骤中，设备和身份验证服务器将使用这个共享密钥以及nonce(防止中继攻击)和加密散列(确保消息完整性)来进行身份验证。它们还将获得移动设备和AP使用的共享会话密钥，以加密在802.11无线链路上传输的帧。
3. 共享对称会话密钥分发 由于对称加密密钥是在移动设备和身份验证服务器上派生的，因此身份验证服务器需要一个协议来将共享的对称会话密钥通知AP。虽然这是相当直接的，但它仍然是必要的步骤。
4. 移动设备和通过AP的远程主机间的加密通信 正如我们在前面的7.3.2节中看到的那样，在移动设备和AP之间发送的链路层帧使用步骤2和步骤3创建和分发的共享会话密钥进行加密。我们在前面的8.2.1节中介绍了AES对称密钥加密，它通常在实践中用于加密/解密802.11帧数据。

相互身份验证和共享对称会话密钥派生

相互身份验证和共享对称会话密钥派生是802.11安全的核心组成部分。由于在这里发现了各种早期版本的802.11安全性的安全缺陷，让我们先解决这些挑战。

802.11安全性的问题已经引起了技术圈和媒体的广泛关注。虽然有大量的讨论，但几乎没有争论——普遍认为，被统称为有线等效隐私(WEP，Wired Equivalent Privacy)的原始802.11安全规范包含许多严重的安全缺陷[Fluhrer 2001;Stubblefield 2002]。一旦这些缺陷被发现，公共领域软件这些漏洞很快就会被利用，使得WEP保护的802.11无线局域网的用户与完全没有使用安全功能的用户一样容易受到安全攻击。有兴趣了解WEP的读者可以查阅参考资料，以及本教科书中涉及WEP的早期版本。像往常一样，这本书的退役材料可以在配套网站上找到。

WiFi保护接入(WPA1，WiFi Protected Access)是由WiFi联盟[WiFi 2020]于2003年为克服WEP的安全缺陷而开发的。WPA1的最初版本在WEP的基础上进行了改进，引入了消息完整性检查，并避免了允许用户在观察加密消息流一段时间后推断加密密钥的攻击。WPA1很快让位于WPA2，后者强制使用AES对称密钥加密。

WPA的核心是一个四次握手协议，它执行相互身份验证和共享对称会话密钥派生。握手协议的简化形式如图8.31所示。注意，移动设备(M)和身份验证服务器(AS)开始都知道一个共享密钥$K_{AS-M}$(例如，密码)。他们的任务之一是获得一个共享的对称会话密钥$K_{M-AP}$，它将被用于加密/解密稍后在移动设备(M)和AP之间传输的帧。

图8.31 WPA2四次握手

图8.31所示的四次握手的前两个步骤a和b完成了相互身份验证和共享对称会话密钥派生。步骤c和d用于派生用于组通信的第二个密钥;[Kohlios 2018;Zou 2016]了解详情。

​ a. 在第一步中，AS生成一个nonce，即$Nonce_{AS}$，发送给移动设备。回顾8.4节，nonce用于避免回放攻击和证明被验证的另一方的“活跃性”。

​ b. 移动设备，M，从AS接收nonce,$Nonce_{AS}$，并生成自己的nonce,$Nonce_M$。然后移动设备使用$Nonce_{AS}$、$Nonce_M$、初始共享密钥$K_{AS-M}$、它的MAC地址和AS的MAC地址生成对称的共享会话密钥$K_{M-AP}$。然后它发送它的nonce,$Nonce_M$和一个对$Nonce_{AS}$和$K_{AS-M}$进行编码的HMAC签名的值(参见图8.9)。

AS从M接收到这条消息。通过查看它刚刚发送的HMAC签名版本的nonce，NonceAS，验证服务器知道移动设备是活的;因为移动设备能够使用共享密钥$K_{AS-M}$进行加密，AS也知道移动设备确实是它声称的那个人(也就是说，一个设备知道共享的初始密钥)。AS就这样认证了移动设备!现在，AS还可以使用接收到的$Nonce_M$、$Nonce_{AS}$、初始共享密钥$K_{AS-M}$、它的MAC地址和移动设备的MAC地址，执行与移动设备完全相同的计算来派生共享对称会话密钥，$K_{M-AP}$。此时，移动设备和AS都计算出了相同的共享对称密钥$K_{M-AP}$，该密钥将用于对移动设备和AP之间传输的帧进行加密/解密。在图8.30的步骤3中，AS将该密钥值通知AP。

WPA3于2018年6月发布，是WPA2的更新版本。该更新解决了对四向握手协议的攻击，该攻击可能会导致之前使用的nonce的重用[Vanhoef 2017]，但仍然允许使用四向握手作为遗留协议，并包括更长的密钥长度，以及其他变化[WiFi 2019]。

802.11安全消息协议

图8.32显示了用于实现上述802.11安全框架的协议。可扩展身份验证协议(EAP，Extensible Authentication Protocol) [RFC 3748]定义了端到端消息格式，用于移动设备和AS之间的简单请求/响应交互模式，并在WPA2下进行认证。如图8.32所示，EAP消息采用EAPoL (EAP over LAN)封装，通过802.11无线链路发送。然后这些EAP消息在接入点被解封装，然后使用RADIUS协议进行重新封装，通过UDP/IP传输到AS。虽然RADIUS服务器和协议[RFC 2865]不是必需的，但它们是事实上的标准组件。最近标准化的DIAMETER协议[RFC 3588]预计将在未来最终取代RADIUS协议。

图8.32 EAP是一种端到端协议。在移动设备和接入点之间的无线链路上使用EAPoL封装EAP消息，在接入点和AS之间使用RADIUS over UDP/IP封装EAP消息

8.8.2 4G/5G蜂窝网络身份验证与密钥协议

在本节中，我们将介绍4G/5G网络中的相互身份验证和密钥生成机制。我们将在这里遇到的许多方法都与我们刚才在802.11网络中研究的方法类似，但有一个显著的例外，即在4G/5G网络中，移动设备可能连接到其家庭网络(即它们订阅的蜂窝运营商网络)，或可能在访问网络上漫游。在后一种情况下，访问网络和家庭网络需要在对移动设备进行身份验证和生成加密密钥时进行交互。在继续之前，您可能想通过重读第7.4和7.7.1节来重新熟悉4G/5G网络架构。

在4G/5G设置中，相互身份验证和生成密钥的目的与802.11设置相同。为了加密正在无线信道上传输的帧的内容，移动设备和基站将需要派生一个共享的对称加密密钥。另外，移动设备连接的网络将需要验证设备的身份，并检查其接入权限。同样，移动设备也需要验证它所连接到的网络。虽然网络对移动设备进行身份验证的需求可能是显而易见的，但反向身份验证的需求可能不是那么明确。然而，有记录的案例表明，不干正事者操作捣蛋蜂窝基站诱使毫无防备的移动设备连接到捣蛋网络，使设备暴露在一系列攻击之下[Li 2017]。因此，在802.11无线局域网的情况下，移动设备在连接到蜂窝网络时应该非常谨慎！

图8.33说明了移动设备连接到4G蜂窝网络的场景。在图8.33的顶部，我们看到了前面在7.4节中遇到的许多4G组件——移动设备(M)、基站(BS)、移动设备想连接到的网络中的移动管理实体(MME)、移动设备家庭网络中的家庭用户服务(HSS)。图8.30和8.33的对比显示了802.11和4G安全设置的异同。我们再次看到移动设备和基站;在网络连接期间派生的用户会话密钥，即$K_{BS-M}$，将用于加密/解密通过其无线链路传输的帧。4G MME和HSS将共同发挥与802.11设置中的身份验证服务器类似的作用。注意，HSS和移动设备还共享一个共同的密钥$K_{HSS-M}$，在身份验证开始之前，两个实体都知道这个密钥。该密钥存储在移动设备的SIM卡和家庭网络的HSS数据库中。

图8.33 4G LTE蜂窝网络中的相互身份验证和密钥协议

4G身份验证和密钥协商(AKA，Authentication and Key Agreement)协议包括以下步骤：

​ a. 对HSS的身份验证请求 当移动设备第一次通过基站请求连接到网络时，它发送一条包含其国际移动用户标识(IMSI)的连接消息，该消息被中继到移动管理实体(MME)。然后MME将发送IMSI和访问网络的信息(如图8.33中的VN info所示)到设备家庭网络中的家庭用户服务(HSS)。在7.4节中，我们描述了MME如何能够通过互联蜂窝网络的全IP全球网络与HSS通信。

​ b. 来自HSS的身份验证响应 HSS使用预先共享的密钥$K_{HSS-M}$执行加密操作，以派生身份验证令牌auth_token和预期的身份验证响应令牌$xres_{HSS}$。auth_token包含由HSS使用$K_{HSS-M}$加密的信息，该信息将允许移动设备知晓计算auth_token的人知道密钥。例如，假设HSS计算了$K_{HSS-M}$(IMSI)，即使用$K_{HSS-M}$对设备的IMSI进行加密，并将该值作为auth_token发送。当移动设备接收到加密的值并使用其密钥解密该值时，即计算$K_{HSS-M}(K_{HSS-M}(IMSI))$= IMSI，它知道生成auth_token的HSS知道自己的密钥。这样，移动设备就可以验证HSS了。预期的身份验证响应令牌,$xres_{HSS}$,包含一个移动设备需要能够计算的值(使用$K_{HSS-M}$)，并返回给MME以证明它(移动设备)知道这个密钥，从而对移动设备进行MME身份验证。

请注意，MME在这里只扮演一个中间人的角色，接收身份验证响应消息，保留$xres_{HSS}$供以后使用，提取身份验证令牌并将其转发给移动设备。特别是它不需要知道，也不会得知,密钥$K_{HSS-M}$。

c. 来自移动设备的身份验证响应 移动设备接收到auth_token后，计算出$K_{HSS-M}(K_{HSS-M}(IMSI))$= IMSI，对HSS进行身份验证。然后，移动设备使用它的密钥计算一个值$res_M$——以进行与HSS计算$xres_{HSS}$完全相同的加密计算，并将这个值发送给MME。

d. 移动设备身份验证 MMS将移动计算值$res_M$与HSS计算值$xres_{HSS}$进行比较。如果它们匹配，则对移动设备进行身份验证，因为移动设备已经向MME证明它和HSS都知道公共密钥。MMS通知基站和移动设备完成相互认证，并发送基站密钥，用于步骤e。

e. 数据平面和控制平面的密钥派生 移动设备和基站将各自确定用于加密/解密其在无线信道上的帧传输的密钥。数据平面和控制平面的帧传输将派生单独的密钥。我们在802.11网络中看到的AES加密算法也用于4G/5G网络。

我们上面的讨论集中在4G网络中的身份验证和密钥协议。尽管4G的大部分安全技术被带入了5G，但也有一些重要的变化：

• 首先，请注意，在我们上面的讨论中，访问网络中的MME做出身份验证决策。5G网络安全正在发生的一个重大变化是，允许家庭网络提供身份验证服务，访问网络扮演更小的中间人角色。虽然访问网络仍然可能拒绝来自移动设备的身份验证，但在这种新的5G场景中，接受身份验证请求取决于家庭网络。
• 5G网络将支持上述身份验证和密钥协议(AKA)协议，以及用于身份验证和密钥协议的两个新的附加协议。其中一个被称为AKA´，与4G AKA协议密切相关。它还使用预先共享的密钥 $K_{HSS-M}$ 。但是，由于它在802.11身份验证的环境中使用了我们之前在图8.33中遇到的EAP协议，5G AKA´和4G AKA的消息流不同。第二个新的5G协议是为物联网环境设计的，不需要预先共享密钥。
• 5G的另一个变化是，使用公钥加密技术，对设备的永久身份(IMSI)进行加密，使其永远不会以明文形式传输。

在本节中，我们只简要介绍了4G /5G网络中的相互身份验证和密钥协议。正如我们所看到的，它们广泛地使用了本章前面所研究的安全技术。关于4G/5G安全的更多细节可以在[3GPP SAE 2019;Cable Labs 2019;Cichonski 2017]。

8.9 操作安全:防火墙和入侵检测系统

通过这一章，我们已经看到互联网不是一个非常安全的地方——坏人在外面，制造各种破坏。考虑到因特网的敌对性质，现在让我们来考虑一个组织的网络和管理网络的网络管理员。从网络管理员的角度来看，世界分成了两个阵营——好人(属于组织的网络，他们应该能够以相对不受限制的方式访问组织网络内的资源)和坏人(所有其他人，他们对网络资源的访问必须仔细审查)。在许多机构中，从中世纪城堡到现代公司办公大楼，都有一个单一的出入口，好人和坏人进出机构都要接受安全检查。在城堡里，吊桥一端的门是这样做的;在公司大楼里，这是在保安台完成的。在计算机网络中，当进入/离开网络的流量被安全检查、记录、删除或转发时，这是由称为防火墙、入侵检测系统(IDS)和入侵防御系统(IPS)的操作设备完成的。

8.9.1 防火墙

防火墙是一种硬件和软件的组合，它将组织内部网络与Internet隔离开来，允许一些数据包通过，阻止其他数据包通过。防火墙允许网络管理员通过管理进出这些资源的流量来控制外部世界和受管理网络内资源之间的访问。防火墙有三个目标：

• 所有从外部到内部的流量(反之亦然)都要通过防火墙。 图8.34显示了一个防火墙，它正好位于受管理网络和Internet其他部分之间的边界上。虽然大型组织可能使用多层防火墙或分布式防火墙[Skoudis 2006]，但将防火墙定位在网络的单个接入点(如图8.34所示)，可以更容易地管理和执行安全接入策略。

图8.34 在被管理网络和外部世界之间放置防火墙

• 只有本地安全策略定义的授权流量才允许通过 由于所有进入和离开机构网络的流量都要经过防火墙，因此防火墙可以限制接入到授权流量。
• 防火墙本身不会被渗透 防火墙本身是一个连接到网络的设备。如果没有正确地设计或安装，它可能会被破坏，在这种情况下，它只提供了一种错误的安全感觉(这比根本没有防火墙还要糟糕!)

思科和Check Point是当今两家领先的防火墙供应商。您还可以使用iptables (Linux中通常附带的公共域软件)从Linux机器轻松创建防火墙(数据包过滤器)。此外，如第4章和第5章所讨论的，防火墙现在经常在路由器中实现，并使用SDN远程控制。

防火墙可以分为三类: 传统数据包过滤器 、 有状态过滤器 和 应用程序网关 。我们将在下面的小节中依次讨论这些问题。

传统数据包过滤器

如图8.34所示，一个组织通常有一个网关路由器将其内部网络连接到其ISP(从而连接到更大的公共Internet)。所有进出内部网络的流量都要经过这个路由器，并且就是在这个路由器上进行 数据包过滤 的。数据包过滤器单独检查每个数据报，根据特定于管理员的规则确定是否允许通过或删除数据报。过滤决策通常是基于：

• IP源地址或目标地址
• IP数据报字段中的协议类型:TCP、UDP、ICMP、OSPF等
• TCP或UDP协议的源端口和目标端口
• TCP标志位:SYN、ACK等
• ICMP消息类型
• 数据报离开和进入网络的不同规则
• 不同路由器接口的不同规则

网络管理员根据组织的策略配置防火墙。该策略可以考虑用户的生产力和带宽使用，以及组织的安全问题。表8.5列出了一个组织可能有的一些策略，以及如何使用数据包过滤器来解决这些策略。例如，如果组织不想要除其公共Web服务器的TCP连接外的任何传入TCP连接，那么它可以阻止除目标端口为80和与Web服务器对应的目标IP地址的TCP SYN段以外的所有传入TCP SYN段。如果组织不希望其用户通过互联网无线电（radio）应用程序占用接入带宽，它可以阻止所有不重要的UDP通信(因为互联网无线电经常通过UDP发送)。如果组织不希望外部人员对其内部网络进行映射(tracerout)，则可以阻止所有ICMP TTL过期消息离开组织网络。

动作	源地址	目标地址	协议	源端口	目标端口	标志位
允许	222.22/16	除222.22/16外	TCP	>1023	80	任何
允许	除222.22/16外	222.22/16	TCP	80	>1023	ACK
允许	222.22/16	除222.22/16外	UDP	>1023	80	---
允许	除222.22/16外	222.22/16	UDP	53	>1023	---
拒绝	全部	全部	全部	全部	全部	全部

表8.6 路由器接口的接入控制列表

过滤策略可以基于地址和端口号的组合。例如，一个过滤路由器可以转发所有Telnet数据报(端口号为23的数据报)，除了那些前往或来自特定IP地址列表的数据报。此策略允许与允许列表中的主机建立Telnet连接。不幸的是，基于外部地址的策略无法防止源地址被伪造的数据报。

过滤还可以基于是否设置了TCP ACK位。如果组织想让内部客户端连接到外部服务器，但又想阻止外部客户端连接到内部服务器，那么这个技巧非常有用。回想一下第3.5节，每个TCP连接中的第一个段的ACK位设置为0，而连接中的所有其他段的ACK位设置为1。因此，如果一个组织希望阻止外部客户端发起到内部服务器的连接，它只需过滤所有传入的段，并将ACK位设置为0。该策略杀死所有来自外部的TCP连接，但允许来自内部的连接。

防火墙规则在带有接入控制列表的路由器中实现，每个路由器接口都有自己的列表。一个222.22/16组织的接入控制列表示例如表8.6所示。该接入控制列表用于连接路由器和组织外部IPS的接口。规则应用于从上到下通过接口的每个数据报。前两条规则一起允许内部用户浏览Web:第一条规则允许任何目标端口为80的TCP数据包离开组织的网络;第二个规则允许任何源端口80和ACK位设置的TCP数据包进入组织的网络。注意，如果外部源试图与内部主机建立TCP连接，那么连接将被阻塞，即使源或目标端口是80。后两个规则一起允许DNS数据包进入和离开组织的网络。总之，这个相当严格的接入控制列表阻止了除从组织内部发起的Web流量和DNS流量之外的所有流量。[CERT Filtering 2012]提供了一个推荐的端口/协议数据包过滤列表，以避免现有网络应用中的许多众所周知的安全漏洞。

记得比较清楚的读者可能还记得，我们在第4章4.4.3节研究广义转发时遇到过类似于表8.6的接入控制列表。实际上，我们在那里提供了一个示例，说明如何使用广义转发规则来构建数据包过滤防火墙。

有状态过滤器

在传统的数据包过滤器中，过滤决策是单独对每个数据包进行的。有状态过滤器实际上跟踪TCP连接，并使用这些知识来做出过滤决定。

为了理解有状态过滤器，让我们重新检查表8.6中的接入控制列表。尽管限制相当严格，但表8.6中的接入控制列表仍然允许任何从外部到达的ACK = 1和源端口80的数据包通过过滤器。攻击者可能会使用这些数据包试图用畸形的数据包使内部系统崩溃，进行拒绝服务攻击，或映射内部网络。天真的解决方案是阻止TCP ACK数据包，但这样的方法会阻止组织内部用户浏览Web。

有状态过滤器通过跟踪连接表中所有正在进行的TCP连接来解决这个问题。这是可能的，因为防火墙可以通过观察三次握手(SYN、SYNACK和ACK)来观察新连接的开始;当它看到该连接的FIN数据包时，就可以观察到该连接的结束。防火墙还可以(保守地)假定，当它在60秒内没有看到连接上的任何活动时，连接已经结束。防火墙连接表示例如表8.7所示。这个连接表表明目前有三个正在进行的TCP连接，所有这些连接都是从组织内部发起的。此外，有状态过滤器在其接入控制列表中包括一个新列，“检查连接”，如表8.8所示。注意，表8.8与表8.6中的接入控制列表相同，只是现在它指出应该检查连接中的两个规则。

源地址	目标地址	源端口	目标端口
222.22.1.7	37.96.87.123	12699	80
222.22.93.2	199.1.205.23	37654	80
222.22.65.143	203.77.240.43	48712	80

表8.7 有状态过滤器的连接表

动作	源地址	目标地址	协议	源端口	目标端口	标志位	检查连接
允许	222.22/16	除222.22/16外	TCP	>1023	80	任何
允许	除222.22/16外	222.22/16	TCP	80	>1023	ACK	x
允许	222.22/16	除222.22/16外	UDP	>1023	80	---
允许	除222.22/16外	222.22/16	UDP	53	>1023	---	x
拒绝	全部	全部	全部	全部	全部	全部

表8.8 有状态过滤器的接入控制列表

让我们通过一些示例来了解连接表和扩展接入控制列表是如何协同工作的。假设攻击者试图通过发送带有TCP源端口80并设置了ACK标志的数据报向组织的网络发送一个畸形数据包。进一步假设该数据包的源端口号为12543，源IP地址为150.23.23.155。当该数据包到达防火墙后，防火墙会以表8.7中的接入控制列表进行检查，说明必须先检查连接表，才能允许该数据包进入组织网络。防火墙会正确地检查连接表，发现这个数据包不是正在进行的TCP连接的一部分，并拒绝这个数据包。作为第二个例子，假设一个内部用户想浏览一个外部网站。由于该用户首先发送一个TCP SYN段，因此该用户的TCP连接被记录在连接表中。当Web服务器发送回数据包(必须设置ACK位)时，防火墙检查表，并看到一个相应的连接正在进行中。防火墙因此会让这些数据包通过，从而不会干扰内部用户的Web浏览活动。

应用程序网关

在上面的例子中，我们已经看到数据包级过滤允许组织根据IP和TCP/UDP头的内容(包括IP地址、端口号和确认位)执行粗粒度（coarse-grain）过滤。但是，如果组织希望向一组受限的内部用户(而不是IP地址)提供Telnet服务，该怎么办?如果组织希望这些有特权的用户在被允许创建到外部世界的Telnet会话之前先对自己进行身份验证，该怎么办?这样的任务超出了传统和有状态过滤器的能力。事实上，关于内部用户身份的信息是应用层数据，不包含在IP/TCP/UDP头中。

要想要更精细的安全性，防火墙必须将数据包过滤器与应用程序网关结合起来。应用程序网关可以超越IP/TCP/UDP头，并根据应用数据制定策略决策。 应用程序网关（application gateway） 是应用程序独有的服务器，所有应用程序数据(入站和出站)都必须通过该服务器。多个应用程序网关可以在同一台主机上运行，但每个网关都是具有自己进程的独立服务器。

为了深入了解应用程序网关，让我们设计一个防火墙，它只允许有限的一组内部用户Telnet外部，并阻止所有外部客户端Telnet内部。通过将数据包过滤器(路由器)和Telnet应用网关组合实现，如图8.35所示。路由器过滤器配置为阻断除来自应用程序网关IP地址的Telnet连接外的所有Telnet连接。这样的过滤器配置将强制所有出站Telnet连接通过应用程序网关。现在考虑一个想要Telnet到外部世界的内部用户。用户必须先与应用程序网关建立Telnet会话。在网关中运行的应用程序，它侦听传入的Telnet会话，提示用户输入用户ID和密码。当用户提供此信息时，应用程序网关检查用户是否具有Telnet到外部世界的权限。如果不是，则由网关终止内部用户到网关的Telnet连接。如果用户有权限，则网关(1)提示用户输入用户想要连接的外部主机的主机名，(2)在网关和外部主机之间建立Telnet会话，(3)将来自用户的所有数据转发给外部主机，并将来自外部主机的所有数据转发给用户。这样，Telnet应用网关不仅可以完成用户授权，还可以作为Telnet服务器和Telnet客户端，在用户和远程Telnet服务器之间传递信息。注意，过滤器将允许步骤2，因为网关启动了到外部世界的Telnet连接。

图8.35 由应用程序网关和过滤器组成的防火墙

内部网络通常有多个应用程序网关，例如Telnet、HTTP、FTP和电子邮件的网关。事实上，一个组织的邮件服务器(见第2.3节)和Web缓存都是应用程序网关。

应用程序网关并非没有缺点。首先，每个应用程序需要不同的应用程序网关。其次，由于所有数据都将通过网关传输，因此要付出性能上的开销。当多个用户或应用程序使用相同的网关机器时，这就成了一个问题。最后，客户端软件必须知道当用户发出请求时如何联系网关，并且必须知道如何告诉应用程序网关要连接到什么外部服务器。

案列之——匿名和隐私

假设您想访问一个有争议的网站(例如，一个政治活动家网站)，并且您(1)不想将您的IP地址透露给该网站，(2)不想让您本地的ISP(可能是您的家庭或办公室ISP)知道您正在访问该网站，(3)不想让您本地的ISP看到您正在与该网站交换的数据。如果您使用没有任何加密的直接连接到Web站点的传统方法，那么这三项都会失败。即使您使用SSL，您也会在前两个方面失败:在您发送的每个数据报中，您的源IP地址都会呈现给Web站点;而且你发送的每个数据包的目标地址很容易被你的本地ISP嗅探到。

为了获得隐私和匿名性，您可以同时使用可信代理服务器和SSL，如图8.36所示。使用这种方法，您首先建立到可信代理的SSL连接。然后发送到这个SSL连接，对所需站点的页面的HTTP请求。当代理接收到SSL加密的HTTP请求时，它对请求进行解密，并将明文HTTP请求转发给Web站点。然后网站响应代理，代理又通过SSL将响应转发给您。因为网站只看到代理的IP地址，而没有看到您的客户端的地址，因此您确实获得了对网站的匿名访问。因为你和代理之间的所有通信都是加密的，你本地的ISP无法通过登录你访问的网站或记录你交换的数据来侵犯你的隐私。今天的许多公司(如proxify.com)提供这样的代理服务。

图8.36 用代理提供匿名和隐私

当然，在这种解决方案中，您的代理知道一切:它知道您的IP地址和您正在浏览的网站的IP地址;它可以看到你和网站之间交换的所有流量。因此，这样的解决方案只与代理的可信性一样好。TOR匿名和隐私服务采取的一种更可靠的方法是，通过一系列非共谋(non- colluding)代理服务器[TOR 2020]路由您的流量。特别地，TOR允许独立的个人向其代理池贡献代理。当用户使用TOR连接到服务器时，TOR(从它的代理池中)随机选择一个由三个代理组成的链，并在链上路由客户端和服务器之间的所有流量。通过这种方式，假设代理不相互勾结，那么就没有人知道您的IP地址和目标Web站点之间发生了通信。此外，虽然在最后一个代理和服务器之间发送明文，但最后一个代理不知道发送和接收明文的IP地址是什么。

8.9.2 入侵检测系统

我们刚刚看到一个数据包过滤器(传统的和有状态的)在决定让哪些数据包通过防火墙时检查IP、TCP、UDP和ICMP头字段。然而，要检测大量攻击类型，我们需要执行 深度数据包检查（deep packet inspection） ，也就是说，超越头字段，进入数据包携带的实际应用程序数据。正如我们在8.9.1节中看到的，应用程序网关经常进行深度数据包检查。但是应用程序网关只对特定的应用程序执行此操作。

显然，还有另一种设备——它不仅检查通过它的所有数据包的头(像数据包过滤器)，而且还执行深度数据包检查(不像数据包过滤器)。当设备发现一个可疑的数据包或一系列可疑的数据包时，可以阻止这些数据包进入组织网络。或者，因为这些活动只被认为是可疑的，设备可以让数据包通过，但向网络管理员发送警报，然后网络管理员可以仔细查看流量并采取适当的行动。当检测到潜在的恶意流量时产生警报的设备称为 入侵检测系统(IDS，intrusion detection system) 。对可疑流量进行过滤的设备称为 入侵防御系统（IPS ，intrusion prevention system) 。在本节中，我们将同时研究这两个系统——IDS 和 IPS——这些系统最有趣的技术方面是它们如何检测可疑的通信(而不是它们是否发送警报或丢弃数据包)。此后，我们将统称IDS系统和IPS系统为IDS系统。

IDS可以用来检测各种各样的攻击，包括网络映射(例如，从nmap发出)、端口扫描、TCP堆栈扫描、DoS带宽泛洪攻击、蠕虫和病毒、操作系统漏洞攻击和应用程序漏洞攻击。(关于网络攻击的调查请参见第1.6节。)今天，成千上万的组织使用IDS系统。这些部署的系统中有许多是思科、Check Point和其他安全设备供应商的专利产品。但是，部署的许多IDS系统都是公共域系统，例如非常流行的Snort IDS系统(稍后将对此进行讨论)。

一个组织可以在其组织网络中部署一个或多个IDS传感器（sensors）。图8.37显示了一个具有三个IDS传感器的组织。当部署多个传感器时，它们通常会协同工作，向中央IDS处理器发送有关可疑流量活动的信息，由中央IDS处理器收集并集成这些信息，并在适当的时候向网络管理员发送警报。在图8.37中，该组织将其网络划分为两个区域:高安全区域，由数据包过滤器和应用程序网关保护，由IDS传感器监控;还有一个低安全区域——称为 非军事区(DMZ，demilitarized zone) ——它只受数据包过滤器的保护，但也由IDS传感器监控。注意，DMZ包括需要与外部世界通信的组织服务器，例如其公共Web服务器和权威DNS服务器。

图8.37 部署过滤器、应用程序网关和IDS传感器的组织

在这个阶段，您可能想知道，为什么要使用多个IDS传感器?为什么不直接在图8.37中的数据包过滤器后面放置一个IDS传感器(甚至与数据包过滤器集成)?我们很快就会看到，一个IDS不仅需要做深入的数据包检查，而且还必须将每个通过的数据包与数万个签名进行比较;这可能是一个相当大的处理量，特别是当组织从Internet接收千兆/秒的流量时。通过将IDS传感器放置在更下游的位置，每个传感器只能看到组织流量的一小部分，并且可以更容易地跟上。尽管如此，高性能的IDS和IPS系统今天已经可以使用了，而且许多组织实际上只需在其接入路由器附近安装一个传感器就可以过关。

IDS系统大致分为 基于特征的系统（signature-based systems） 和 基于异常的系统（anomaly-based systems） 。基于特征的IDS维护着一个广泛的攻击特征数据库。每个特征都是一组与入侵活动相关的规则。特征可以是关于单个数据包的特征列表(例如，源和目标端口号、协议类型和数据包有效负载中的特定位串)，也可以与一系列数据包相关。这些特征通常是由研究已知攻击的熟练网络安全工程师创建的。组织网络管理员可以自定义特征，也可以将自己的特征添加到数据库中。

在操作上，基于特征的IDS会嗅探经过它的每个数据包，并将嗅探到的每个数据包与其数据库中的特征进行比较。当数据包(或一系列数据包)匹配特征库中的某个特征时，IDS就会发出告警。警报可以通过电子邮件消息发送给网络管理员，也可以发送给网络管理系统，或者只是被记录下来供将来检查。

尽管广泛部署了基于特征的IDS系统，但它有许多限制。最重要的是，它们需要之前对攻击的了解来生成准确的特征。换句话说，基于特征的IDS对尚未记录的新攻击是完全盲目的。另一个缺点是，即使匹配了特征，也有可能不是攻击的结果，从而产生误报。最后，由于每个数据包都必须与大量的特征集合进行比较，IDS可能会因为处理而不堪重负，实际上无法检测出许多恶意数据包。

基于异常的IDS在观察正常流量时，会创建一个流量通道（traffic profile）。然后它寻找统计上不正常的数据包流，例如，ICMP数据包的不正常百分比或端口扫描和ping扫描的突然指数增长。基于异常的IDS系统的伟大之处在于，它们不依赖于之前关于现有攻击的知识，也就是说，它们可以潜在地检测到新的、未记录的攻击。另一方面，区分正常流量和统计上的异常流量是一个极具挑战性的问题。到目前为止，大多数IDS部署主要是基于特征的，尽管有些部署包含一些基于异常的功能。

Snort

Snort是一个公共领域的开源IDS，有数十万个现有部署[Snort 2012;Koziol 2003]。它可以在Linux、UNIX和Windows平台上运行。它使用通用的嗅探接口libpcap, Wireshark和许多其他数据包嗅探器也使用该接口。它可以轻松处理100Mbps的流量;对于具有G比特/秒通信速率的安装，可能需要多个Snort传感器。

为了深入了解Snort，让我们看一个Snort特征的示例:

​ alert icmp $EXTERNAL_NET any -> $HOME_NET any ​ (msg:”ICMP PING NMAP”; dsize: 0; itype: 8;)

该特征被任何从外部($EXTERNAL_NET)进入组织网络($HOME_NET)的ICMP数据包匹配，类型为8 (ICMP ping)，且负载为空(dsize = 0)。由于nmap(参见第1.6节)生成具有这些特定特征的ping数据包，该特征被设计用于检测nmap ping扫描。当数据包匹配此特征时，Snort生成一个警报，其中包括ICMP PING NMAP消息。

也许Snort最令人印象深刻的地方在于维护其特征数据库的庞大用户社区和安全专家。通常在新的攻击发生后的几个小时内，Snort社区编写并发布一个攻击特征，然后由分布在世界各地的数十万Snort部署人员下载。此外，使用Snort特征语法，网络管理员可以修改现有特征或创建全新的特征，从而根据自己组织的需要定制特征。

8.10 总结

在这一章中，我们研究了我们的秘密恋人Bob和Alice可以用来安全地交流的各种机制。我们已经看到Bob和Alice对机密性(所以只有它们才能理解传输信息的内容)、端点身份验证(这样他们就能确定他们正在彼此交谈)和消息完整性(这样他们就能确定他们的消息在传输过程中没有被更改)感兴趣。当然，对保密通信的需求并不仅限于秘密恋人。实际上，我们在第8.5节到8.8节中看到，可以在网络体系结构的各个层中使用安全性，以防止有大量攻击手段的坏人。

本章的第一部分介绍了安全通信的各种基本原则。在第8.2节中，我们介绍了用于加密和解密数据的加密技术，包括对称密钥加密和公钥加密。本文将DES和RSA作为当今网络中使用的这两类主要加密技术的具体案例进行研究。

在8.3节中，我们研究了两种提供消息完整性的方法:消息认证码(MAC,message authentication codes)和数字签名。这两种方法有许多相似之处。这两种技术都使用加密哈希函数，并且都使我们能够验证消息的来源以及消息本身的完整性。一个重要的区别是MAC不依赖于加密，而数字签名需要公共密钥基础设施。正如我们在8.5到8.8节中看到的那样，这两种技术在实践中被广泛使用。此外，数字签名用于创建数字证书，这对于验证公钥的有效性非常重要。在8.4节中，我们研究了端点认证并介绍了防止重放攻击的随机数(nonces)。

在第8.5节到8.8节中，我们研究了几种在实践中广泛使用的安全网络协议。我们看到对称密钥加密是PGP、SSL、IPsec和无线安全的核心。我们看到公钥加密对于PGP和TLS都是至关重要的。我们看到PGP使用数字签名来保证消息的完整性，而TLS和IPsec使用MAC。我们还探索了无线网络的安全性，包括WiFi网络和4G/5G蜂窝网络。现在，您已经了解了密码学的基本原理，并研究了这些原理的实际使用方法，您就可以设计自己的安全网络协议了。

有了8.2到8.8节介绍的技术，Bob和Alice就可以安全地通信了。但机密性只是网络安全图景的一小部分。正如我们在8.9节中学到的，网络安全的重点越来越多地集中在保护网络基础设施免受坏人的潜在攻击上。在本章的后面部分，我们讨论了检查进入和离开组织网络的数据包的防火墙和IDS系统。