计算机网络中的安全
网络安全概览
网络安全的目标
网络安全旨在保护网络系统中的硬件、软件、数据以及通信过程免受未经授权的访问、使用、泄露、破坏、修改或拒绝服务等威胁,确保网络的正常运行和信息的保密性、完整性、可用性。
核心安全属性
网络安全通常围绕以下几个核心属性展开:
- 机密性:确保信息仅被授权用户访问和理解。即使数据被截获,未授权者也无法解读其内容。这通常通过加密实现。
- 发送方加密消息。
- 接收方解密消息。
- 认证:验证通信参与方(用户、设备或进程)身份的真实性。确保你正在与之通信的对象确实是它所声称的身份。
- 完整性:确保消息在传输过程中或存储后未被篡改。接收方可以验证消息自发送以来是否保持原样。
- 可用性与访问控制:确保授权用户在需要时能够访问信息和网络服务。访问控制则限制不同用户对资源的访问权限。
网络世界中的角色
在讨论网络安全时,我们常常使用以下经典角色来模拟通信场景:
- Alice 和 Bob:他们是合法的通信双方,希望安全地交换信息。
- Trudy(入侵者, Intruder):他是恶意第三方,试图破坏 Alice 和 Bob 之间的安全通信。Trudy 可能会窃听、篡改、伪造消息等。
现实场景对应
- Alice 和 Bob 可以是:
- 进行在线购物的 Web 浏览器和服务器。
- 进行网上银行操作的客户端和服务器。
- 交换路由表更新的 BGP 路由器。
- 进行安全通信的两个 DNS 服务器。
- Trudy 则代表了网络中可能存在的各种攻击者。
常见的网络攻击手段
攻击者(Trudy)为了破坏上述安全属性,可能会采取多种手段:
- 窃听:截取网络上传输的消息。
- 消息插入/篡改:在通信连接中主动插入伪造消息或修改合法消息。
- 身份伪装:伪装成合法通信方。例如,伪造 IP 包中的源地址。
- 连接劫持:接管一个已经建立的合法连接,将发送方或接收方替换为攻击者。
- 拒绝服务:通过耗尽目标资源(如带宽、处理能力)等方式,阻止合法用户使用服务。
密码学原理
密码学
密码学(Cryptography)是研究信息加密、解密以及信息安全相关问题的学科。它是实现网络安全,特别是机密性、认证和完整性的核心技术。
密码学基本术语
- 明文(Plaintext):未经加密的原始消息,用 表示。
- 密文(Ciphertext):明文经过加密算法处理后得到的消息,用 表示。
- 加密(Encryption):将明文转换为密文的过程。
- 解密(Decryption):将密文还原为明文的过程。
- 密钥(Key):控制加密和解密算法行为的参数。用 表示。
- Alice 的密钥 ,Bob 的密钥 。
- 加密算法:用于执行加密和解密的数学函数或规则。
下图展示了一个通用的加密通信模型:
graph TB
subgraph Alice_Side [发送方 Alice]
direction LR
P_A[明文 m] --> EA{加密算法}
KA[密钥 K_A] --> EA
end
EA --> CT["密文 K_A(m)"]
subgraph Trudy_Side [攻击者 Trudy]
direction TB
CT -->|信道 Channel| Trudy_Intercept(Trudy 可能窃听/篡改)
end
Trudy_Intercept --> CT_Rcv
subgraph Bob_Side [接收方 Bob]
direction LR
CT_Rcv["密文 K_A(m)"] --> DA{解密算法}
KB[密钥 K_B] --> DA
DA --> P_B[明文 m']
end
style P_A fill:#lightgreen
style P_B fill:#lightgreen
style CT fill:#lightcoral
style CT_Rcv fill:#lightcoral
style KA fill:#lightblue
style KB fill:#lightblue
在对称加密中,。在公钥加密中, 和 是相关联但不同的密钥对。
密码分析与攻击类型
密码分析是研究如何破解密码体制的学科。攻击者 Trudy 尝试破解加密方案时,根据其掌握的信息和能力,可以分为几种攻击类型:
- 唯密文攻击:Trudy 只拥有一些密文进行分析。这是最困难的攻击场景。
- 已知明文攻击:Trudy 不仅拥有一些密文,还拥有这些密文对应的明文。例如,在单表替换密码中,如果 Trudy 知道某些高频字母(如 e, t, a)的密文对应,就能推断出部分密钥。
- 选择明文攻击:Trudy 能够选择特定的明文,并获取其加密后的密文。这给予攻击者更大的能力来探测密码系统的弱点。
常用的密码分析方法包括:
- 暴力破解:尝试所有可能的密钥,直到找到正确的密钥。密钥空间越大,暴力破解越困难。
- 统计分析:利用明文语言的统计特性(如字母频率、词组频率)来分析密文,从而推断密钥或明文。
对称密钥密码体制
在对称密钥密码体制中,发送方和接收方使用相同的密钥进行加密和解密。密钥的分发和保密是其核心挑战。
graph LR
subgraph Alice
P1[明文 m] --> Enc{加密算法}
K_S[共享密钥 K_S] --> Enc
end
Enc --> C["密文 K_S(m)"]
C --> Dec{解密算法}
subgraph Bob
K_S2[共享密钥 K_S] --> Dec
Dec --> P2[明文 m]
end
style K_S fill:#lightblue
style K_S2 fill:#lightblue
简单替换密码
替换密码是将明文中的每个字符替换为另一个字符或符号。
- 单表替换密码:使用一个固定的替换表。例如,凯撒密码就是一种简单的单表替换密码。
- 明文字母表:
abcdefghijklmnopqrstuvwxyz
- 密文字母表(示例):
mnbvcxzasdfghjklpoiuytrewq
- 加密示例:
bob. i love you. alice
->nkn. s gktc wky. mgsbc
- 密钥:就是这个从 26 个字母到另外 26 个字母的映射关系。密钥空间为 (非常大),但容易受到统计分析攻击。
- 明文字母表:
更复杂的加密方法
为了抵抗统计分析,可以使用更复杂的加密方法,例如:
- 多表替换密码:使用多个替换表,并根据某种规则(如密钥词)在加密过程中切换替换表。
- 多轮加密:使用 个不同的替换密码 ,并定义一个循环模式来依次使用这些密码。例如,对于模式 ,加密 "dog" 时,'d' 用 加密,'o' 用 加密,'g' 用 加密。
- 密钥:包含这 个替换密码以及循环模式。
数据加密标准(DES)
DES(Data Encryption Standard) 是美国于 1993 年发布的加密标准(NIST 1993)。
- 它是一种对称密钥分组密码,明文输入为 64 位分组,密钥长度为 56 位。
- DES 通常与密码分组链接(Cipher Block Chaining, CBC)等模式结合使用,以增强安全性。
- 安全性:
- DES Challenge 显示,56 位密钥可以通过暴力破解在一天内被破解。
- 目前没有已知的有效分析攻击方法优于暴力破解。
- 增强 DES 安全性:
- 3DES:使用 3 个不同的密钥对数据进行三次 DES 加密(加密-解密-加密),有效密钥长度达到 112 位或 168 位,显著提高了安全性。
高级加密标准(AES)
AES(Advanced Encryption Standard) 是 NIST 于 2001 年 11 月采纳的对称密钥加密标准,用以取代 DES。
- 同样是分组密码,处理 128 位的数据块。
- 支持三种密钥长度:128 位、192 位或 256 位。
- 安全性:AES 被认为是高度安全的。如果用破解 DES 需要 1 秒的计算能力来暴力破解 AES(128位密钥),大约需要 149 万亿年。
公钥密码体制
对称密钥密码体制的一个主要问题是密钥的分发和管理,如何安全地将密钥传递给通信双方?为了解决这个问题,密码学家们提出了公钥密码体制。
公钥密码体制是一种与对称密钥体制截然不同的加密方法,由 Diffie 和 Hellman 于 1976 年提出(RSA 算法于 1978 年提出)。
- 核心思想:每个用户拥有一对密钥:
- 公钥(Public Key, ):可以公开给任何人。
- 私钥(Private Key, ):必须由用户自己秘密保管。
- 特点:
- 发送方和接收方不需要共享秘密密钥。
- 用公钥加密的数据只能用对应的私钥解密。
- 用私钥加密(签名)的数据可以用对应的公钥验证。
graph LR
subgraph Alice_Sends_To_Bob
P_A[明文 m] --> Enc{加密算法}
Bob_PK[Bob 的公钥 K_B^+] --> Enc
end
Enc --> C["密文 K_B^+(m)"]
C --> Dec{解密算法}
subgraph Bob_Receives
Bob_SK[Bob 的私钥 K_B^-] --> Dec
Dec --> P_B[明文 m]
end
style Bob_PK fill:#lightgreen
style Bob_SK fill:#lightcoral
公钥密码体制的出现彻底改变了密码学的面貌,解决了对称加密中密钥分发的难题。
RSA 算法
RSA 是由 Rivest, Shamir, Adelson 三人提出的一种广泛使用的公钥加密算法。
模运算是 RSA 的数学基础。
- 表示 除以 的余数。
- 模运算性质:
- 因此,
RSA 密钥生成:
- 选择两个非常大的素数 和 (例如,每个 1024 位)。
- 计算 。 是公钥和私钥的一部分,其长度决定了 RSA 的安全性。
- 计算欧拉函数 。在 RSA 中,通常用 表示。
- 选择一个整数 (加密指数),使得 ,并且 与 互素(即 )。
- 计算整数 (解密指数),使得 。即 是 关于模 的乘法逆元。这意味着 可以被 整除。
- 公钥是 ,记为 。
- 私钥是 ,记为 。
消息表示
在 RSA 中,消息 首先被表示为一个整数。任何比特模式都可以唯一地映射为一个整数。例如,比特串 10010001
(二进制)可以表示为十进制数 145。加密消息等同于加密这个数字。
假设 Alice 想给 Bob 发送消息 (表示为小于 的整数):
- 加密:Alice 获取 Bob 的公钥 ,计算密文 。
- 解密:Bob 收到密文 后,使用自己的私钥 ,计算明文 。
可以证明 。即:
假设 Bob 选择 。
- 。
- 。
- 选择 。因为 5 和 24 互素,所以 是一个合法的选择。
- 计算 使得 。可以找到 (因为 )。
- Bob 的公钥是 。
- Bob 的私钥是 。
现在假设要加密一个 8 位消息,例如明文 (二进制 00001100
)。
- 加密:。
- 解密:[1]。
RSA 原理证明
我们需要证明 。
已知 ,即 对于某个整数 成立,其中 。
所以 .
根据欧拉定理的推广(也与费马小定理和中国剩余定理相关):
对于任意整数 (无论是否与 互素)和 ,有 成立,其中 。
因此,。
一个有用的数论性质
对于任意整数 (其中 , ),有 成立,前提是 (通常 即可)。
更准确地说,是 .
由于 , 我们可以写成 .
所以 。
RSA 算法具有一个非常有用的对称性质:
这意味着:
- (加密后解密)
- (签名后验证)
这是因为指数运算的交换律 。这个性质是数字签名的基础。
RSA 的安全性依赖于大整数分解的困难性。
- 如果 Trudy 知道 Bob 的公钥 ,她想确定私钥 。
- 要计算 ,Trudy 需要知道 。
- 要计算 ,Trudy 需要知道 和 。
- 这意味着 Trudy 需要对 进行质因数分解,找到 和 。
- 对于足够大的 (例如 2048 位或更多),分解 在计算上是不可行的。
RSA 运算(特别是幂模运算)计算量较大,比对称加密算法(如 DES, AES)慢得多(通常慢 100 倍以上)。
因此,在实际应用中,通常采用混合加密方案:
- 使用公钥密码(如 RSA)来安全地协商和分发一个临时的对称会话密钥 。
- 一旦双方都拥有了 ,就使用对称加密算法(如 AES)和 来加密实际的大量数据。
例如,Alice 要给 Bob 发送大量数据:
- Alice 生成一个随机的对称会话密钥 。
- Alice 用 Bob 的公钥 加密 ,得到 。
- Alice 将 发送给 Bob。
- Bob 用自己的私钥 解密得到 。
- 现在 Alice 和 Bob 共享了对称密钥 ,他们可以用 和 AES 等高效算法进行后续通信。
认证与消息完整性
身份认证
身份认证的目标是让通信一方(如 Bob)能够验证另一方(如 Alice)的身份。下面通过一系列协议演进来说明身份认证的挑战和解决方案。
ap(application protocol) 是一个应用层协议,通常用于实现身份认证。
ap1.0:「我是 Alice」
- Alice 直接向 Bob 发送消息:「我是 Alice」。
- 缺陷:Trudy 可以轻易地伪装成 Alice,也发送「我是 Alice」给 Bob。Bob 无法区分。
ap2.0:「我是 Alice」+ 源 IP 地址
- Alice 发送一个 IP 包,其中包含她的源 IP 地址,并在数据部分声明「我是 Alice」。
- 缺陷:Trudy 可以构造一个 IP 包,将源 IP 地址伪造成 Alice 的 IP 地址(IP 欺骗,IP Spoofing)。
ap3.0:「我是 Alice」+ 秘密口令
- Alice 发送她的 IP 地址、身份声明「我是 Alice」以及一个共享的秘密口令来证明身份。
- 缺陷:
- 如果 Trudy 窃听了网络,她就能获取口令。
- 重放攻击:Trudy 可以记录 Alice 发送的整个包(包括 IP、身份和口令),然后在稍后将其重新发送给 Bob,冒充 Alice。
ap3.0 (改进):「我是 Alice」+ 加密后的秘密口令
- Alice 发送她的 IP 地址、身份声明「我是 Alice」以及用共享密钥加密后的秘密口令。
- 缺陷:虽然 Trudy 无法直接获得明文口令,但重放攻击仍然有效。Trudy 可以记录加密后的口令包,并重放它。
ap4.0: 使用 Nonce 防重放(基于对称密钥)
为了防止重放攻击,引入了 Nonce 的概念。
Nonce
Nonce (Number used once) 是一个仅使用一次的随机数。它用于确保消息的新鲜性,防止旧消息被重放。
- 协议 ap4.0:
- Alice Bob:「我是 Alice」
- Bob Alice: 发送一个随机数 (Nonce)
- Alice Bob: 返回用 Alice 和 Bob 共享的对称密钥 加密的 ,即 。
- 验证:Bob 收到 后,用 解密。如果解密结果与他之前发送的 相同,则 Bob 相信对方是 Alice(因为只有 Alice 知道 并且能正确加密 ),并且 Alice 是「活的」(因为她能正确处理当前的 Nonce)。
- 前提:Alice 和 Bob 预先共享了对称密钥 。
sequenceDiagram
participant Alice
participant Bob
Alice->>Bob:「我是 Alice」
Bob-->>Alice: R (Nonce)
Alice->>Bob: K[A-B](R)
Note right of Bob: Bob 验证 K[A-B](R) <br/> 是否能解密为 R
ap5.0: 使用 Nonce + 公钥密码
如果 Alice 和 Bob 没有共享对称密钥,可以使用公钥密码进行认证。
- 协议 ap5.0:
- Alice Bob:「我是 Alice」
- Bob Alice: 发送一个随机数 (Nonce)
- Alice Bob: 返回用 Alice 的私钥 加密的 ,即 。
- Bob 同时向 Alice 请求其公钥 (或者 Bob 已知 Alice 的公钥)。
- 验证:Bob 收到 和 Alice 的公钥 后,计算 。如果结果等于他之前发送的 ,则 Bob 相信对方是 Alice(因为只有 Alice 拥有私钥 能正确「签名」)。
sequenceDiagram
participant Alice
participant Bob
Alice->>Bob:「我是 Alice」
Bob-->>Alice: R (Nonce)
Alice->>Bob: K[A-](R)(用 Alice 私钥签名 R)
Note right of Bob: Bob 获取 Alice 公钥 K[A+] <br/> 并验证 K[A+](K[A-](R)) == R
ap5.0 的缺陷:中间人攻击
尽管 ap5.0 看起来不错,但它仍然存在一个严重的漏洞:中间人攻击(Man-in-the-Middle Attack, MITM)。
- 场景:Trudy 位于 Alice 和 Bob 之间,可以拦截、修改和转发他们之间的所有消息。
- Alice Trudy(以为是 Bob):「我是 Alice」
- Trudy Bob:「我是 Alice」(冒充 Alice)
- Bob Trudy (以为是 Alice): Nonce
- Trudy Alice(冒充 Bob): Nonce (Trudy 自己的 Nonce,或者转发 )
- Alice Trudy(以为是 Bob): (用 Alice 私钥签名 )
- Trudy(拥有 ,但无法直接用它来回应 Bob 的 )
- 此时 Trudy 需要 Bob 以为她是 Alice。Trudy 可以用自己的私钥 签名 Bob 发来的 ,即 ,然后把这个和自己的公钥 发给 Bob。
- Trudy Bob: (用 Trudy 私钥签名 ),并声称 是 Alice 的公钥。
- Bob 用 验证 ,验证通过。Bob 错误地认为 Trudy 是 Alice。
- 之后,Bob 发送给「Alice(实际是 Trudy)的消息 ,会用 加密。Trudy 用 解密。
- Trudy 再用 Alice 的真实公钥 加密 ,转发给 Alice。
sequenceDiagram
participant Alice
participant Trudy as Trudy(中间人)
participant Bob
Alice->>Trudy:「我是 Alice」
Trudy->>Bob:「我是 Alice」(冒充 Alice)
Bob-->>Trudy: R[B] (Nonce for "Alice")
Trudy-->>Alice: R[T] (Nonce for Alice, from "Bob")
Alice->>Trudy: K[A-](R[T])(Alice 签名 R[T])
Note over Trudy: Trudy 现在需要回应 Bob 的 R[B]
Trudy->>Bob: K[T-](R[B])(Trudy 用自己私钥签名 R[B])
Trudy->>Bob: 这是 Alice 的公钥 K[T+](实际是 Trudy 的公钥)
Note right of Bob: Bob 用 K[T+] 验证签名,通过。<br/>Bob 认为 Trudy 是 Alice。
Bob->>Trudy: K[T+](m)(用 Trudy 公钥加密消息给 "Alice")
Note over Trudy: Trudy 用 K[T-] 解密得到 m。
Trudy->>Alice: K[A+](m)(Trudy 用 Alice 真公钥加密 m,转发给 Alice)
中间人攻击的关键在于 Bob 无法确信他收到的公钥 真的属于 Alice。这引出了对公钥证书的需求。
消息完整性与数字签名
消息摘要(哈希函数)
消息摘要或哈希函数 是一种算法,它接收任意长度的消息 作为输入,并输出一个固定长度的短字符串,称为哈希值或摘要 。这个哈希值可以看作是消息的「数字指纹」。
- 密码学哈希函数的特性:
- 易于计算:对于任意给定的消息 ,计算 相对容易。
- 固定长度输出:无论输入消息多长,输出的哈希值长度总是固定的(如 128 位、160 位、256 位)。
- 抗原像攻击:给定一个哈希值 ,在计算上难以找到任何消息 使得 。
- 抗第二原像攻击:给定一个消息 ,在计算上难以找到另一个不同的消息 使得 。
- 抗碰撞性:在计算上难以找到任意两个不同的消息 和 使得 。
互联网校验和
TCP/IP 协议栈中使用的互联网校验和算法(如用于 IP, TCP, UDP 头部校验)具有哈希函数的一些特性(如固定长度输出,多对一映射),但它不是一个密码学安全的哈希函数。
- 它很容易找到碰撞。例如,给定一个消息和它的校验和,很容易构造出另一个内容不同但校验和完全相同的消息。
常用哈希算法:
- MD5(Message Digest 5):输出 128 位哈希值。由于已发现有效的碰撞攻击方法,MD5 已不安全,不应再用于安全性要求高的场景(如数字签名)。
- SHA-1(Secure Hash Algorithm 1):输出 160 位哈希值。SHA-1 也已被证明存在碰撞攻击,NIST 不推荐使用。是 Git commit 的默认哈希算法。
- SHA-2 系列(SHA-256, SHA-384, SHA-512):目前被认为是安全的,广泛使用。
- SHA-3 系列:最新的标准,提供不同的安全级别。
数字签名
数字签名是一种密码学技术,用于验证数字消息或文档的真实性、完整性以及发送者的身份,并提供不可否认性。它类似于手写签名在物理世界中的作用。
- 原理:发送方(如 Bob)使用自己的私钥 对消息 (或其哈希值)进行「加密」操作,生成签名。
- 特性:
- 可验证:接收方(如 Alice)可以使用发送方的公钥 来验证签名的有效性。
- 不可伪造:只有拥有私钥 的 Bob 才能生成有效的签名。其他人(包括 Alice 和 Trudy)无法伪造。
- 不可否认:Bob 不能否认他曾经签署过该消息,因为只有他的私钥能产生该签名。
简单数字签名(对整个消息签名)
- Bob 要发送消息 给 Alice,并附上数字签名。
- Bob 用自己的私钥 加密整个消息 ,得到 。
- Bob 将 发送给 Alice。
- Alice 收到后,使用 Bob 的公钥 对 进行「解密」操作,得到 。
- Alice 比较 和收到的明文 。如果两者相同,则签名有效。
对整个消息签名的缺点
- 计算开销大:公钥密码运算(如 RSA)通常比对称加密慢很多。对长消息进行签名会导致显著的性能开销。
- 消息冗余:需要发送原始消息和签名后的消息(如果签名是加密整个消息,则密文本身就是签名,但通常签名是附加的)。
数字签名与消息摘要结合(更高效)
为了提高效率,实际中通常对消息的哈希值进行签名,而不是整个消息。
- Bob(发送方/签名方):
- 计算消息 的哈希值 。
- 用自己的私钥 对哈希值 进行加密(签名),得到签名 。
- 将原始消息 和签名 一起发送给 Alice,即 。
- Alice(接收方/验证方):
- 收到 。
- 用 Bob 的公钥 对签名 进行解密,得到 。
- 自己独立计算收到的消息 的哈希值 。
- 比较 和 。如果两者相等,则签名有效,消息完整且确实来自 Bob。
公钥证书与证书颁发机构(CA)
回顾 ap5.0 的中间人攻击,其根本原因在于 Bob 无法确信他从 Trudy 那里获得的公钥 真的属于 Alice。他需要一种可靠的方式来验证公钥与其声称的所有者之间的绑定关系。这就是公钥证书和证书颁发机构(Certification Authority, CA)发挥作用的地方。
- 公钥证书:是一个由受信任的第三方(CA)签发的电子文档,它将一个公钥与一个特定的实体(如个人、网站、组织)的身份信息绑定在一起。
- 证书颁发机构(CA):是一个被广泛信任的组织,负责验证实体的身份并为其签发公钥证书。CA 用自己的私钥对证书内容进行数字签名,以保证证书的真实性和完整性。
证书的创建与使用流程
-
实体注册与身份验证:
- Bob(实体)生成自己的公钥/私钥对 。
- Bob 向 CA 提交其公钥 以及证明其身份的信息。
- CA 验证 Bob 的身份。
-
CA 签发证书:
- 如果身份验证通过,CA 会创建一个包含 Bob 的身份信息、Bob 的公钥 、CA 的名称、证书有效期等信息的文档。
- CA 使用自己的私钥 对该文档进行数字签名。
- 最终形成的签名文档就是 Bob 的公钥证书。
-
Alice 获取并验证 Bob 的证书:
- 当 Alice 想与 Bob 安全通信并需要 Bob 的公钥时,她可以从 Bob 那里或公共目录获取 Bob 的证书。
- Alice 需要拥有 CA 的公钥 (通常预装在操作系统或浏览器中,或者通过信任链获得)。
- Alice 使用 验证证书上 CA 的签名。
- 如果签名有效,Alice 就可以信任证书中的内容,即证书中包含的公钥确实属于 Bob。然后 Alice 可以使用这个公钥与 Bob 通信。
信任链
在实际的公钥基础设施(PKI)中,可能存在多级 CA。一个根 CA 签发中间 CA(Intermediate CA)的证书,中间 CA 再签发最终实体(如网站)的证书。用户设备通常预装了受信任的根 CA 的公钥。验证一个证书时,可能需要沿着证书链一直验证到根 CA。
安全电子邮件
安全电子邮件旨在为电子邮件通信提供机密性、完整性、身份认证和不可否认性。常用的标准有 PGP (Pretty Good Privacy) 和 S/MIME (Secure/Multipurpose Internet Mail Extensions)。
实现机密性
Alice 想给 Bob 发送一封机密的邮件 。
- Alice 生成一个一次性的对称会话密钥 。
- Alice 用 加密邮件内容 ,得到密文 。
- 使用对称加密是因为其效率高
- Alice 用 Bob 的公钥 加密会话密钥 ,得到 。
- 使用公钥加密来安全分发会话密钥
- Alice 将加密后的邮件 和加密后的会话密钥 一起发送给 Bob。
Bob 收到邮件后:
- 用自己的私钥 解密加密后的会话密钥,得到 。
- 用会话密钥 解密邮件内容,得到 。
实现完整性与身份认证(不加密邮件内容)
Alice 想给 Bob 发送邮件 ,并让 Bob 能够验证邮件的完整性和 Alice 的身份。
- Alice 计算邮件 的哈希值 。
- Alice 用自己的私钥 对哈希值 进行数字签名,得到 。
- Alice 将原始邮件 和数字签名 一起发送给 Bob。
Bob 收到邮件后:
- 独立计算收到的邮件 的哈希值 。
- 用 Alice 的公钥 验证数字签名 ,得到解密后的哈希值 。
- 比较 和 。如果两者相等,则邮件完整且确实来自 Alice。
同时实现机密性、完整性与身份认证
Alice 想给 Bob 发送一封既保密又能验证完整性和身份的邮件 。
- 签名:
- Alice 计算邮件 的哈希值 。
- Alice 用自己的私钥 对 进行签名,得到 。
- 组合:
- Alice 将原始邮件 和签名 组合成一个新的数据体 。
- 加密:
- Alice 生成一个一次性的对称会话密钥 。
- Alice 用 加密组合后的数据体 ,得到 。
- Alice 用 Bob 的公钥 加密会话密钥 ,得到 。
- 发送:
- Alice 将 和 一起发送给 Bob。
Bob 收到邮件后:
- 解密会话密钥:用自己的私钥 解密 ,得到 。
- 解密邮件内容:用 解密 ,得到 。分离出原始邮件 和签名 。
- 验证签名:
- 独立计算收到的 的哈希值 。
- 用 Alice 的公钥 验证签名 ,得到 。
- 比较 和 。如果相等,则邮件保密、完整且确实来自 Alice。
这种结合方式提供了强大的电子邮件安全保障。
传输层安全
传输层安全(Transport-Layer Security, TLS)协议是目前广泛部署的一种安全协议,它工作在传输层之上,旨在为应用层通信提供安全保障。我们日常接触到的 HTTPS (HTTP Secure) 就是 HTTP 协议与 TLS 结合的产物,通常使用 TCP 端口 443。几乎所有的现代浏览器和 Web 服务器都支持 TLS。
TLS 能够提供以下核心安全服务:
- 机密性:通过对称加密实现,确保数据在传输过程中不被窃听者理解。
- 完整性:通过加密哈希,通常是消息认证码(Message Authentication Code, MAC),确保数据在传输过程中未被篡改。
- 认证:通过公钥密码学和数字证书,验证通信双方(尤其是服务器)的身份。
历史沿革
TLS 的前身是安全套接字层(Secure Socket Layer, SSL),由网景公司在 20 世纪 90 年代初提出。SSL 经过多个版本演进,最终由互联网工程任务组(IETF)标准化为 TLS。
- 早期的研究和实现集中在安全网络编程和安全套接字。
- SSL 协议已于 2015 年被正式弃用。
- 目前广泛推荐和使用的是 TLS 1.2 和 TLS 1.3 (RFC 8846, [2018])。
构建一个简化的 TLS 协议
为了理解 TLS 的核心机制,我们可以设想构建一个玩具版的 TLS 协议,称之为 t-tls。这个过程会涉及到几个关键阶段:
- 握手:
- 通信双方(例如 Alice 和 Bob)使用各自的数字证书和私钥来相互认证身份。
- 协商或交换一个共享密钥,这个密钥将用于后续通信的加密和完整性保护。
- 密钥派生:
- Alice 和 Bob 使用握手阶段得到的共享密钥,通过一个密钥派生函数(Key Derivation Function, KDF),生成一系列用于不同目的的会话密钥(例如,加密密钥、MAC 密钥)。
- 数据传输:
- 数据以「记录」的形式进行流式传输,而不仅仅是一次性的事务。
- 每个记录都会被加密和保护完整性。
- 连接关闭:
- 使用特殊的消息来安全地关闭连接,防止意外中断或攻击。
t-tls 初始握手
在 t-tls 的握手阶段,假设客户端 Bob 想要与服务器 Alice 建立安全连接:
- Bob 首先与 Alice 建立一个标准的 TCP 连接(三次握手)。
- Alice 向 Bob 发送其公钥证书,Bob 验证该证书的有效性以确认 Alice 的身份。
- Bob 生成一个主密钥(Master Secret, MS),用 Alice 的公钥加密后发送给 Alice。这个加密后的主密钥称为加密主密钥(Encrypted Master Secret, EMS)。
- Alice 用自己的私钥解密 EMS,得到主密钥 MS。
- 双方现在共享了主密钥 MS,后续将用它派生出会话所需的各种密钥。
潜在问题
这种简化的握手方式(加上 TCP 握手)在客户端能够开始发送应用数据之前,大约需要 3-RTT,效率不高。
sequenceDiagram
participant Bob as Bob (客户端)
participant Alice as Alice (服务器)
Bob->>Alice: TCP SYN
Alice->>Bob: TCP SYN-ACK
Bob->>Alice: TCP ACK
Alice->>Bob: t-tls hello, 公钥证书
Bob->>Bob: 验证 Alice 的证书
Bob->>Bob: 生成主密钥(MS)
Bob->>Alice: 加密的主密钥(EMS = KA+(MS))
Alice->>Alice: 使用 KA- 解密 EMS 以获取 MS
Note over Bob, Alice: 双方现在都拥有 MS
Bob->>Alice: 客户端请求(使用派生密钥加密)
Alice->>Bob: 服务器回复(使用派生密钥加密)
t-tls 加密密钥
在密码学实践中,为不同的加密功能使用相同的密钥通常被认为是不安全的。因此,t-tls 需要从主密钥 MS 中派生出多组不同的密钥:
- :客户端发送给服务器的数据的加密密钥。
- :客户端发送给服务器的数据的 MAC 密钥。
- :服务器发送给客户端的数据的加密密钥。
- :服务器发送给客户端的数据的 MAC 密钥。
这些密钥通过密钥派生函数(KDF)从主密钥 MS 生成。KDF 还可以结合一些额外的随机数据(如握手时交换的随机数)来增强密钥的随机性。
t-tls 数据加密
TCP 提供的是字节流抽象,直接在流上进行加密和完整性校验比较困难,尤其是 MAC 的计算。如果 MAC 放在数据流的末尾,那么接收方必须接收完所有数据并关闭连接后才能验证完整性,这不实用。
解决方案:将字节流分割成一系列的记录(records)。
- 每个从客户端到服务器的记录都携带一个使用 计算的 MAC。
- 接收方可以在每个记录到达时独立地对其进行处理和验证。
一个 t-tls 记录在被加密并传递给 TCP 前,其结构可能为(以客户端发送为例):[length | data | MAC]
整个记录(包括 length, data, MAC)会使用对称密钥 进行加密。
t-tls 数据流面临的攻击与对策
即使数据被加密,数据流本身也可能遭受攻击:
- 重排序攻击:中间人截获 TCP 段并打乱其顺序。由于 TCP 头部本身未加密,攻击者可以操纵 TCP 序列号。
- 重放攻击:攻击者重新发送之前截获的合法数据包。
解决方案:
- TLS 序列号:在 TLS 层面维护记录的序列号。这个序列号会包含在 MAC 的计算范围内,即
MAC(data, TLS-seq-#, other_info)
。这样,任何对记录顺序的篡改或重放都会导致 MAC 校验失败。 - 随机数:在 MAC 计算中引入一个不重复的随机数(nonce),确保即使是相同的数据内容,每次传输时生成的 MAC 也不同,有效防止简单的重放攻击。
t-tls 连接关闭
- 截断攻击:攻击者伪造一个 TCP 连接关闭段(FIN),使得通信一方或双方误以为数据传输已提前结束,而实际上还有数据未发送或未接收。
解决方案:引入记录类型。
- 例如,类型 0 表示数据记录,类型 1 表示关闭连接记录。
- MAC 的计算现在需要包含数据、记录类型和序列号:
MAC(data, type, sequence #)
。 - 一个经过加密的 t-tls 记录(包含类型信息)结构可能如下:
Kc( [length | type | data | MAC] )
其中 MAC 是基于type
,data
,sequence #
计算得到的。
TLS 1.3 概览
实际的 TLS 协议(尤其是 TLS 1.3)比我们的 t-tls 要复杂和完善得多。
- 通用 API:TLS 提供了一个应用无关的 API,任何应用层协议都可以使用它来增强安全性。
- HTTP 视角下的 TLS:
- HTTP/1.x over TCP: TLS 运行在 TCP 之上,HTTP 之下。
- HTTP/2 over TCP: 类似,TLS 在 TCP 之上。
- HTTP/3 over QUIC: QUIC 协议本身就集成了 TLS 1.3 的功能,运行在 UDP 之上。
TLS 1.3 密码套件
密码套件是一组预定义的加密算法,用于密钥生成、加密、MAC 和数字签名。
TLS 1.3 (2018) 相较于 TLS 1.2 (2008) 对密码套件的选择做了大幅精简和增强:
- 选择更少:TLS 1.3 仅有 5 个推荐的密码套件(相较于 TLS 1.2 的 37 个),减少了选择困难和配置错误的风险。
- 强制 Diffie-Hellman(DH):密钥交换必须使用 DH 系列算法(如 ECDHE),不再支持基于 RSA 的密钥交换,以实现前向保密。
- 认证加密:采用认证加密和关联数据(Authenticated Encryption with Associated Data, AEAD)算法,如 AES-GCM 或 ChaCha20-Poly1305。这种算法同时提供加密和认证,比分别进行加密和 MAC 更高效、更安全。TLS 1.3 的 5 个套件中有 4 个基于 AES。
- HMAC 用途:主要用于密钥派生(HKDF)和早期握手消息的完整性保护,通常使用 SHA-256 或 SHA-384。
TLS 1.3 握手:1-RTT
TLS 1.3 的一个主要目标是减少握手延迟,实现了 1-RTT 握手(对于新连接)。
%%{init: { 'sequence': {'noteAlign': 'left'} }}%%
sequenceDiagram
participant 客户端
participant 服务器
客户端->>服务器: 1. ClientHello(客户端问候)
Note over 客户端: - 猜测密钥协商方式(例如 ECDHE 参数)<br>- 支持的密码套件<br>- DH 密钥共享
服务器->>客户端: 2. ServerHello(服务器问候), EncryptedExtensions(加密扩展),<br/> Certificate(证书), CertificateVerify(证书验证), Finished(完成)
Note over 服务器: - 选择密钥协商协议和参数<br>- 选择密码套件<br>- 发送服务器签名的证书<br>- 发送其 DH 密钥共享<br>- 计算并发送 Finished(握手消息的 MAC)
客户端->>客户端: 3. 客户端操作
Note over 客户端: - 验证服务器证书<br>- 从共享的 DH 密钥生成会话密钥<br>- 计算并发送 Finished(握手消息的 MAC)<br>- 现在可以发送应用数据(例如 HTTPS GET)
客户端->>服务器: Finished(完成), Application Data(加密的应用数据)
- 客户端 ClientHello:
- 客户端「猜测」服务器可能支持的密钥协商协议(如椭圆曲线 Diffie-Hellman, ECDHE)和参数,并发送其 DH 公钥份额。
- 指明自己支持的密码套件列表。
- 服务器响应:
- 服务器选择一个双方都支持的密钥协商协议和密码套件。
- 发送其 DH 公钥份额、服务器证书(由 CA 签名)、以及一个对握手消息的签名以证明自己拥有证书对应的私钥。
- 发送一个
Finished
消息,这是对目前为止所有握手消息的 MAC,使用协商出的会话密钥计算。
- 客户端操作:
- 客户端验证服务器证书的有效性。
- 使用服务器的 DH 公钥份额和自己的 DH 私钥份额计算出共享的会话密钥。
- 验证服务器发送的
Finished
消息。 - 发送自己的
Finished
消息给服务器。 - 此时,握手完成,客户端可以立即开始发送加密的应用数据(例如 HTTPS GET 请求)。
这种优化的握手流程将建立安全连接所需的时间显著缩短。
网络层安全
IPsec(Internet Protocol Security) 是一套在 IP 层提供安全服务的协议簇。它能够为 IP 数据报提供加密、认证和完整性保护,可以用于保护用户数据流量(如 TCP, UDP 包)和网络控制流量(如 BGP, DNS 消息)。
IPsec 主要工作在两种模式下:
-
传输模式:
- 只对 IP 数据报的载荷部分(即传输层数据,如 TCP 段或 UDP 数据报)进行加密和/或认证。
- 原始 IP 头部保持不变(或仅做少量修改,如协议字段)。
- 通常用于端到端(主机到主机)的通信安全。
-
隧道模式:
- 对整个原始 IP 数据报(包括原始 IP 头部和载荷)进行加密和/或认证。
- 然后将这个处理过的数据报封装在一个新的 IP 数据报中,添加一个新的外部 IP 头部。
- 常用于构建虚拟专用网络(Virtual Private Network, VPN),例如在两个路由器之间建立安全隧道。
IPsec 协议
IPsec 主要包含两个核心协议:
- 认证头(Authentication Header, AH)[RFC 4302]:
- 提供源认证和数据完整性保护。
- 不提供机密性(即不加密数据)。
- 封装安全载荷(Encapsulation Security Protocol, ESP)[RFC 4303]:
- 提供源认证、数据完整性保护,并且提供机密性(加密数据)。
- ESP 比 AH 更常用,因为它提供了更全面的安全服务。ESP 也可以配置为只提供认证和完整性而不加密。
安全关联
在发送 IPsec 保护的数据之前,发送方和接收方之间必须建立一个安全关联(Security Association, SA)。
- SA 是一个单向的逻辑连接,定义了用于保护数据流的各种参数(如加密算法、密钥、序列号计数器等)。
- 如果需要双向安全通信,则需要建立两个 SA(每个方向一个)。
- SA 使得 IPsec 具有了「面向连接」的特性,尽管 IP 本身是无连接的。TCP 端点也维护状态信息,但 SA 是在网络层。
接收实体(如路由器 R1)会为每个活动的 SA 存储状态信息,包括:
- 安全参数索引(Security Parameter Index, SPI):一个 32 位的标识符,用于唯一标识一个 SA。当接收方收到一个 IPsec 包时,它会查看 ESP (或 AH) 头中的 SPI 值,以确定使用哪个 SA 来处理该包。
- 源 SA 接口(例如,IPsec 隧道的本地端点 IP 地址,如
200.168.1.100
)。 - 目的 SA 接口(例如,IPsec 隧道的远端端点 IP 地址,如
193.68.2.23
)。 - 使用的加密算法和密钥。
- 使用的完整性校验算法和密钥(认证密钥)。
IPsec 数据报结构(以 ESP 隧道模式为例)
一个典型的 IPsec ESP 隧道模式数据报结构如下:
- New IP Header: 新的外部 IP 头部,用于在公共网络中路由。
- ESP Header:
- SPI(Security Parameter Index): 告知接收方使用哪个 SA 来处理此包。
- Sequence Number: 一个单调递增的计数器,用于防止重放攻击。
- Original IP Header(Enc): 原始数据包的 IP 头部,被加密。
- Original Payload(Enc): 原始数据包的载荷(如 TCP/UDP 数据),被加密。
- ESP Trailer:
- Padding: 用于块加密算法,确保数据长度是块大小的整数倍,也可能用于隐藏实际载荷长度。
- Pad Length: 指示填充数据的长度。
- Next Header: 指示被加密的载荷是什么协议类型(例如,IP, TCP, UDP)。
- ESP Authentication(ESP Auth): 这是一个消息认证码(MAC),通常覆盖从 ESP 头部到 ESP Trailer 的部分(不包括 ESP Auth 字段本身),使用共享密钥计算,用于验证数据的完整性和来源。
具体哪些部分被认证取决于 ESP 的配置。通常,加密部分和 ESP 头部都会被认证。新的 IP 头部通常不被认证,因为它在网络传输中可能被修改(如 TTL)。
ESP 隧道模式操作流程(在发送方 R1)
当路由器 R1(隧道入口)要发送一个数据包给 R2(隧道出口)时:
- R1 为原始数据报(包含原始 IP 头和载荷)附加 ESP Trailer。
- 使用 SA 中指定的算法和密钥,对
原始数据报 + ESP Trailer
进行加密。 - 在加密数据的前面附加 ESP Header(包含 SPI 和序列号)。
- 使用 SA 中指定的算法和密钥,为
ESP Header + 加密数据
计算认证 MAC(ESP Auth)。 - 将 MAC 附加到数据末尾,形成 IPsec 保护的载荷。
- 创建一个新的 IP 头部,其源 IP 为 R1,目标 IP 为 R2,并将 IPsec 保护的载荷作为其数据部分。
- 将这个新的 IP 数据报发送出去。
IPsec 序列号
- 对于每个新的 SA,发送方将序列号初始化为 0。
- 每次通过该 SA 发送数据报时,发送方递增序列号计数器,并将当前值放入 ESP(或 AH) 头的序列号字段。
- 目标:防止攻击者嗅探并重放数据包。接收重复的、已认证的 IP 包可能会干扰服务。
- 方法:
- 接收方检查传入数据包的序列号以检测重复包。
- 为了效率,接收方通常不记录所有已接收包的序列号,而是使用一个滑动窗口机制来判断序列号是否有效(即在窗口范围内且未被接收过)。
IPsec 安全数据库
IPsec 的实现依赖于两个关键的数据库:
- 安全策略数据库(Security Policy Database, SPD):
- 定义了对 IP 流量的总体安全策略:「做什么」
- 对于给定的数据报,SPD 决定了该数据报是否需要 IPsec 处理、应该使用哪个 SA(或 SA 束)、或者直接丢弃/通过。
- 策略可以基于源/目标 IP 地址、协议号、端口号等。
- 安全关联数据库(Security Association Database, SAD):
- 存储了所有活动 SA 的详细参数:「怎么做」
- 当发送 IPsec 数据报时,发送方(如 R1)根据 SPD 找到合适的 SA,然后从 SAD 中检索该 SA 的参数(如密钥、算法、SPI)来处理数据报。
- 当接收 IPsec 数据报时,接收方(如 R2)从 IPsec 头部(ESP 或 AH)中提取 SPI,用 SPI 作为索引在 SAD 中查找对应的 SA,然后使用该 SA 的参数来解密和验证数据报。
互联网密钥交换
手动配置和管理大量 IPsec SA(尤其是在拥有数百个端点的 VPN 中)是非常不切实际的。例如,一个 SA 的配置可能包括:
- SPI:12345
- 源 IP:200.168.1.100
- 目标 IP:193.68.2.23
- 协议:ESP
- 加密算法:3DES-cbc
- HMAC 算法:MD5
- 加密密钥:0x7aeaca…
- HMAC 密钥:0xc0291f…
为了解决这个问题,IPsec 使用互联网密钥交换(Internet Key Exchange, IKE)协议来动态地协商和建立 SA,包括生成和分发密钥。
IKE 支持两种主要的认证方式:
- 预共享密钥(Pre-Shared Secret, PSK):通信双方预先配置了一个共享的秘密值。IKE 运行时,双方使用此 PSK 进行相互认证,并生成 IPsec SA。
- 公钥基础设施(Public Key Infrastructure, PKI):通信双方使用其公钥/私钥对和数字证书。IKE 运行时,双方交换证书并进行签名验证以相互认证,然后协商 IPsec SA。这与 SSL/TLS 中的握手类似。
IKE 协议通常分两个阶段进行:
- 建立一个双向的 IKE SA(也称为 ISAKMP SA)。这个 IKE SA 用于保护后续的 IKE 消息。
- IKE SA 与 IPsec SA 是不同的。
- 有两种模式:
- 积极模式:使用较少的消息交换,速度快,但身份保护较弱(部分身份信息可能以明文发送)。
- 主模式:使用更多的消息交换,提供更强的身份保护,更灵活。
- 使用已建立的 IKE SA 来安全地协商一对(或多对)IPsec SA(通常一个方向一个)。
IPsec 总结
- IKE 用于交换算法信息、协商密钥、分配 SPI 号码,以建立 SA。
- IPsec 可以使用 AH 协议(提供完整性和源认证)或 ESP 协议(额外提供加密),或者两者结合。
- IPsec 对等体可以是两个终端系统、两个路由器/防火墙,或者一个路由器/防火墙和一个终端系统。
IPsec 服务思考
假设攻击者 Trudy 位于受 IPsec 保护的两个路由器 R1 和 R2 之间,但 Trudy 不知道会话密钥。
- Trudy 能否看到原始数据报的内容?
- 如果使用 ESP 加密,则不能。
- Trudy 能否看到源/目标 IP 地址、传输协议、应用端口?
- 在隧道模式下,原始 IP 头被加密,Trudy 只能看到外部 IP 头;在传输模式下,原始 IP 头可见。
- Trudy 能否在不被检测到的情况下翻转数据位?
- 不能,因为有完整性保护 MAC。
- Trudy 能否冒充 R1 并使用 R1 的 IP 地址?
- 不能,因为有源认证。
- Trudy 能否重放一个数据报?
- 不能,因为有序列号防重放机制。
无线和移动网络中的安全
无线和移动网络由于其开放的传输媒介,面临着独特的安全挑战。
IEEE 802.11 (Wi-Fi) 安全:认证和加密
当一个移动设备(如笔记本电脑、手机)进入一个 Wi-Fi 网络时,它必须:
- 关联接入点:与 AP 建立无线链路通信。
- 向网络认证:证明自己的身份合法,并获得网络访问权限。
这个过程通常涉及以下四个主要步骤:
- 发现安全能力:
- AP 通过信标帧广播其存在以及支持的认证和加密方式。
- 移动设备发送关联请求,指明其希望使用的认证和加密形式。
- 此时,设备和 AP 已经在交换消息,但设备尚未认证,也没有加密密钥。
- 相互认证和共享对称密钥派生:
- 移动设备和认证服务器(Authentication Server, AS)(通常通过 AP 中继)进行相互认证。
- 双方通常已共享一个「共同的秘密」(例如,预设的 Wi-Fi 密码,或在企业环境中通过 EAP 方法获得的凭证)。
- 它们使用这个共享秘密、随机数(nonces,用于防止重放攻击)和加密哈希函数来相互验证身份,并派生出一个对称会话密钥。
- 共享对称会话密钥分发:
- AS 将派生出的共享对称会话密钥(例如,用于 AES 加密)通知给 AP。移动设备已经自己派生了这个密钥。
- 加密通信:
- 移动设备和 AP 之间的所有后续数据帧都使用派生出的会话密钥进行加密和完整性保护。
WPA3 握手简化流程(SAE)
WPA3 使用对等实体同时认证(Simultaneous Authentication of Equals, SAE)协议,它基于「蜻蜓握手」,即使在密码较弱的情况下也能提供较好的安全性。一个高度简化的概念如下(实际过程更复杂,涉及椭圆曲线密码学):
- AS (或 AP 本身在个人模式下) 与 Mobile 共享一个初始秘密(如 Wi-Fi 密码)。
- AS Mobile: AS 生成一个随机数
Nonce_AS
并发送给 Mobile。 - Mobile AS:
- Mobile 收到
Nonce_AS
。 - Mobile 生成自己的随机数
Nonce_M
。 - Mobile 使用初始共享秘密、
Nonce_AS
和Nonce_M
派生出会话密钥K_M-AP
。 - Mobile 发送
Nonce_M
和一个基于初始共享秘密与Nonce_AS
计算的 HMAC 值给 AS。
- Mobile 收到
- AS: AS 验证 HMAC 值,并使用初始共享秘密、
Nonce_AS
和Nonce_M
派生出相同的会话密钥K_M-AP
。
双方现在共享了会话密钥K_M-AP
。
sequenceDiagram
participant 移动设备
participant 接入点
participant 认证服务器
移动设备->>接入点: 关联请求
接入点->>移动设备: 关联响应
Note over 移动设备, 认证服务器: 双方都知道一个初始共享密钥(例如:密码)
认证服务器->>移动设备: (a) Nonce_AS
移动设备->>移动设备: (b) 接收 Nonce_AS,生成 Nonce_M
移动设备->>移动设备: 派生会话密钥 K_M-AP(使用初始密钥、Nonce_AS、Nonce_M)
移动设备->>认证服务器: (b) Nonce_M, HMAC(f(K_AS-M, Nonce_AS))
认证服务器->>认证服务器: (c) 验证 HMAC,派生会话密钥 K_M-AP
Note over 移动设备, 认证服务器: 双方现在都拥有 K_M-AP
可扩展认证协议
可扩展认证协议(Extensible Authentication Protocol, EAP) [RFC 3748] 定义了一个在移动设备和认证服务器(AS)之间的端到端请求/响应协议框架。它支持多种认证方法。
- 在 802.11 网络中,EAP 消息通常封装在 EAP over LAN(EAPOL) 帧中,在移动设备和 AP 之间传输。
- AP 充当 EAP 消息的中继,将它们转发给后端的 AS (通常使用 RADIUS 协议,其承载在 UDP/IP 之上)。
4G LTE 网络中的认证和加密
4G LTE 网络中的认证和加密过程与 Wi-Fi 有相似之处,但也有显著区别:
- 移动设备必须:
- 与基站(Base Station, BS)关联,建立 4G 无线链路。
- 向网络认证自身,并且网络也需要向移动设备认证自身。
- 与 Wi-Fi 的显著差异:
- 移动设备的 SIM 卡提供全球唯一的身份标识(IMSI),并预存有与归属网络共享的密钥。
- 在拜访网络中提供的服务取决于用户在其归属网络中订购的服务。
- 认证的核心实体是归属网络中的归属用户服务器(Home Subscriber Server, HSS)。拜访网络中的移动性管理实体(Mobility Management Entity, MME)参与认证过程,并与 HSS 协同工作,共同扮演类似 Wi-Fi 中 AS 的角色。
- 移动设备和基站(BS)使用派生出的会话密钥 来加密 4G 链路上的通信。
- 拜访网络和归属网络之间存在信任和商业关系。
4G LTE 认证和密钥协商流程(简化)
-
认证请求至归属网络 HSS:
- 移动设备向 BS 发送附着消息,包含其 IMSI 和拜访网络信息。
- 消息经由 BS 中继到拜访网络的 MME,再由 MME 转发给移动设备的归属网络 HSS。
- IMSI 用于识别移动设备的归属网络。
-
HSS 生成认证向量:
- HSS 使用与该移动设备 SIM 卡预共享的密钥 ,派生出一个认证令牌(
auth_token
)和一个期望的认证响应令牌(xres_HSS
)。 auth_token
包含了由 HSS 使用 加密的信息,允许移动设备验证网络的合法性(即确认对方知道共享密钥)。- HSS 将
auth_token
、xres_HSS
以及其他可能的会话密钥发送给拜访网络的 MME。MME 将auth_token
转发给移动设备(通过 BS)。 - MME (代表拜访网络) 会保存
xres_HSS
用于后续验证。
- HSS 使用与该移动设备 SIM 卡预共享的密钥 ,派生出一个认证令牌(
-
移动设备认证网络并响应:
- 移动设备使用其 SIM 卡中的 验证收到的
auth_token
,从而认证了网络。 - 移动设备使用其 计算出一个认证响应令牌(
res_M
),这个计算方式与 HSS 计算xres_HSS
的方式相同。 - 移动设备将
res_M
发送给 MME (通过 BS)。
- 移动设备使用其 SIM 卡中的 验证收到的
-
网络认证移动设备:
- MME 比较收到的
res_M
和之前 HSS 计算并保存的xres_HSS
。 - 如果两者匹配,则移动设备通过认证。这是因为只有合法的移动设备(拥有正确的 )才能计算出正确的
res_M
。 - MME 通知 BS 移动设备已认证,并可能向 BS 分发用于建立安全链路的密钥材料。
- MME 比较收到的
-
密钥派生和加密通信:
- 移动设备和 BS 根据协商的密钥材料派生出用于加密数据和控制帧的会话密钥 。
- 可以使用 AES 等强加密算法进行通信。
从 4G 到 5G 的安全增强
5G 在 4G 的基础上引入了一些安全改进:
- 认证决策权:
- 4G: 拜访网络中的 MME 做出最终认证决策。
- 5G: 归属网络提供认证决策,拜访网络中的实体(AMF)扮演「中间人」角色,但仍可拒绝。
- 密钥共享:
- 4G: 通常使用预共享密钥。
- 5G: 对于物联网(IoT)等场景,密钥可以不预先共享,支持更灵活的密钥协商机制。
- IMSI 隐私:
- 4G: 设备的 IMSI(永久身份标识)可能以明文形式传输给 BS。
- 5G: 使用公钥加密技术来加密 IMSI(在 5G 中称为 SUPI - Subscription Permanent Identifier),增强用户身份隐私保护。
运营安全:防火墙和入侵检测系统
运营安全关注在网络运行过程中采取的措施来保护网络资源。
防火墙
防火墙
防火墙(Firewall)是一种网络安全设备或软件,用于隔离组织内部网络与外部网络(如互联网),并根据预设规则允许或阻止特定数据包通过。它在受信任的内部网络和不受信任的外部网络之间建立一道屏障。
防火墙的主要目的:
- 防止拒绝服务攻击(Denial of Service, DoS):例如,SYN 泛洪攻击,攻击者建立大量伪造的 TCP 连接,耗尽服务器资源。
- 防止对内部数据的非法修改/访问:例如,阻止攻击者篡改公司网页。
- 只允许授权访问内部网络:基于认证的用户/主机进行访问控制。
防火墙主要有三种类型:
-
无状态包过滤器:
- 逐个检查数据包,根据固定的规则集决定转发或丢弃。
- 决策依据通常是 IP/TCP/UDP 头部信息:
- 源/目标 IP 地址
- TCP/UDP 源/目标端口号
- ICMP 消息类型
- TCP 标志位(SYN, ACK, FIN, RST 等)
- 示例规则:
- 阻止 IP 协议号为 17 (UDP) 且源或目标端口为 23 (Telnet) 的所有进出数据报,从而禁止所有 UDP Telnet 连接。
- 阻止入站 TCP 段中 ACK 位为 0 的包(即阻止外部客户端主动发起对内部服务器的 TCP 连接,但允许内部客户端连接外部服务器,因为其响应包 ACK 位为 1)。
- 访问控制列表(Access Control Lists, ACLs):防火墙规则通常以 ACL 的形式组织,规则按顺序匹配,从上到下。这类似于 OpenFlow 的转发规则。
-
有状态包过滤器:
- 无状态过滤器是「一刀切」的工具,可能允许一些「无意义」的包通过(例如,一个目标端口为 80 且设置了 ACK 位的包,即使之前并没有建立 TCP 连接)。
- 有状态过滤器会跟踪每个 TCP 连接的状态(如 SYN, ESTABLISHED, FIN_WAIT)。
- 它会判断传入和传出的数据包是否符合当前连接状态的「逻辑」。
- 对于不活动的连接,有状态防火墙会设置超时,超时后不再允许相关数据包通过。
- ACL 规则会增加一个「检查连接状态表」的条件。
-
应用网关:
- 不仅检查 IP/TCP/UDP 头部,还会检查应用层数据。
- 可以为特定应用(如 HTTP, FTP, Telnet)提供细粒度的访问控制。
- 示例(Telnet 网关):
- 要求所有内部用户通过 Telnet 网关访问外部 Telnet 服务。
- 对于授权用户,网关代表用户建立到目标主机的 Telnet 连接。
- 网关在用户和目标主机之间的两个连接之间中继数据。
- 路由器上的包过滤器会阻止所有不是源自该 Telnet 网关的 Telnet 连接请求。
防火墙和网关的局限性
- IP 欺骗:路由器/防火墙难以判断数据包是否真的来自其声称的源 IP 地址。
- 应用特定性:如果多个应用需要特殊处理,可能需要为每个应用配置单独的应用网关。
- 客户端配置:使用应用网关(如 Web 代理)通常需要在客户端软件(如浏览器)中配置代理服务器的 IP 地址。
- UDP 策略:对于 UDP 这种无连接协议,过滤器通常采用「全允许」或「全禁止」的简单策略。
- 权衡:需要在与外部世界的通信便利性和安全级别之间做出权衡。
- 无法完全防御:即使有防火墙,许多受高度保护的站点仍然会遭受攻击。防火墙是深度防御策略的一部分,而非全部。
入侵检测系统
传统的包过滤防火墙主要基于头部信息,且通常不跨会话进行关联检查。
入侵检测系统
入侵检测系统(Intrusion Detection System, IDS)是一种监控网络或系统活动,以发现恶意行为或策略违反迹象的设备或软件。
IDS 的能力通常超越传统防火墙:
- 深度包检测(Deep Packet Inspection, DPI):查看数据包的内容,例如,检查数据包中的字符特征串是否与已知病毒库或攻击特征库匹配。
- 多包关联分析:分析多个数据包之间的关联,以识别更复杂的攻击模式,例如:
- 端口扫描:检测是否有主机在尝试连接目标系统的大量端口。
- 网络映射:检测是否有工具在探测网络拓扑。
- 拒绝服务攻击:识别异常流量模式。
IDS 可以部署在网络中的不同位置(例如,在防火墙之后监控内部网络,或在 DMZ 区监控面向公众的服务),形成多层检测。
有意思的是,不小心开成 Python 验算,然后按成
17^29
了,结果也是 12,真是巧啊。 ↩︎