从加密到信任：不可信网络中安全通信的建立逻辑

互联网能够把数据从一台主机传输到另一台主机，却不会天然保证这些数据是秘密的、完整的，也不会自动证明通信对象的真实身份。一个数据报即使按照协议顺利到达目的地，也可能已经被攻击者窃听、修改、复制或替换。攻击者还可能冒充通信双方，重放过去截获的合法报文，或者在公钥交换过程中替换密钥。

因此，网络安全所要解决的核心问题并不只是如何加密一段数据，而是：

如何在存在主动攻击者的不可信网络中，建立一条可验证、可持续的可信通信关系？

围绕这一目标，现代网络安全逐步形成了相互衔接的机制：对称加密负责高效保护数据内容，公钥密码缓解密钥分发问题，散列函数和数字签名验证消息来源与完整性，随机数防止旧报文被重复利用，数字证书和证书颁发机构则建立公钥与真实身份之间的可信绑定。

  flowchart LR
    A[不可信网络] --> B[机密性]
    A --> C[完整性]
    A --> D[身份认证]
    A --> E[运行安全]

    B --> F[对称加密]
    C --> G[散列与数字签名]
    D --> H[挑战—响应]
    D --> I[数字证书]
    I --> J[CA信任体系]
  

这套体系的关键不在于某一种算法能够独立解决所有安全问题，而在于不同机制分别承担不同职责，并通过协议组合形成完整的安全链条。

1. 安全通信需要同时满足多种性质

网络安全通常包含机密性、消息完整性、端点鉴别和运行安全性四个层面。这些性质彼此相关，却不能相互替代。

1.1 机密性：攻击者即使截获，也不能理解

机密性要求只有获得授权的通信实体能够理解报文内容。发送方使用密钥和加密算法把明文转换为密文，接收方再使用正确的密钥恢复原文：

[
c=E_K(m)
]

[
m=D_K(c)
]

其中，(m) 表示明文，(c) 表示密文，(K) 表示密钥。

加密并不阻止攻击者看到网络中传输的比特。它真正保证的是：攻击者即使截获密文，也难以恢复其中的有效信息。

1.2 完整性：接收方必须知道数据是否被修改

消息完整性关注的不是攻击者能否阅读报文，而是攻击者能否在不被发现的情况下修改报文。

例如，攻击者不一定需要理解一条转账指令的全部内容，只要能够把金额字段从 100 修改为 900，就可能造成实际损失。即使报文经过加密，如果所使用的方案没有提供完整性保护，攻击者仍可能修改密文并影响解密结果。

因此：

加密主要解决“别人能否看懂”，完整性机制解决“别人是否改动”。

1.3 端点鉴别：身份声明不等于身份证明

网络中的通信实体无法直接观察对方本人，只能接收到 IP 数据报、协议字段、口令、公钥或数字签名。

发送一句“I am Alice”只能表达发送者声称自己是 Alice，却不能证明该声明真实。可靠的身份认证必须依赖攻击者难以伪造的密码学证据，例如共享秘密、私钥签名或者可信证书。

1.4 运行安全性：算法安全不等于系统安全

即使密码算法本身足够安全，系统仍可能由于密钥泄露、权限配置错误、服务器漏洞或证书管理失误而被攻破。

因此，真实系统还需要防火墙、入侵检测、访问控制、补丁管理、密钥保护和安全运维。AES 算法再强，如果密钥被公开保存，加密也会失去意义。

❗ 本节核心结论： 安全通信不是单一目标。机密性、完整性和身份认证分别解决不同问题，不能因为数据已经加密，就默认它没有被篡改或发送者身份已经得到证明。

2. 对称加密：高效，但依赖共享秘密

对称密钥加密要求通信双方拥有同一个共享秘密，或者拥有可以高效相互推导的加密与解密密钥。发送方使用该秘密完成加密，接收方使用相应秘密完成解密。

对称加密的主要优势是计算效率高，适合处理大量数据。现代文件加密、磁盘加密和网络会话中的主体数据通常都依赖对称密码。

2.1 从简单替换密码到现代分组密码

简单替换密码把每个明文字母固定映射为另一个字母。它能够直观说明密钥控制明文与密文之间的映射关系，但无法抵御现代攻击。

自然语言具有稳定的统计特征，例如不同字母出现频率不同，某些字母组合和单词反复出现。攻击者可以利用这些规律进行频率分析，从而逐渐推测出替换表。

现代对称密码不再依赖简单字符替换，而是通过多轮复杂变换，使明文、密钥和密文之间形成难以分析的关系。

2.2 DES、3DES 与 AES 的演进

DES 是早期广泛使用的对称分组密码，采用 56 位有效密钥和 64 位分组。其主要问题是密钥空间过小。56 位密钥只有 (2^{56}) 种可能，在计算能力不断提升后，攻击者已经能够通过专用设备穷举密钥。

3DES 通过多次执行 DES 延长密钥长度。典型结构为“加密—解密—加密”：

[
C=E_{K_3}(D_{K_2}(E_{K_1}(M)))
]

中间执行一次解密并不意味着取消前一次加密。加密和解密在这里都是由密钥控制的可逆变换。EDE 结构还可以在三个密钥相同时兼容原有 DES 系统。

3DES 提高了安全性，但需要执行多次 DES 运算，效率较低。AES 随后成为现代主流标准。AES 使用 128 位分组，支持 128、192 和 256 位密钥。

AES-128 的密钥空间为：

[
2^{128}
]

与 DES 的 (2^{56}) 相比，密钥空间不是简单扩大两倍，而是扩大了：

[
2^{72}
]

倍。

2.3 对称加密的根本矛盾

对称加密本身并不难使用。只要 Alice 和 Bob 已经拥有同一个安全密钥，就可以高效传输大量数据。

真正困难的是：

Alice 和 Bob 在通信开始之前，如何安全获得同一个秘密密钥？

如果 Alice 直接通过不安全网络发送密钥，攻击者也可以截获它。这就是密钥分发问题。它可以通过线下预置、密钥分发中心、公钥密码或密钥交换协议解决。

❗ 本节核心结论： 对称加密适合保护大量实际数据，但它预设通信双方已经拥有共享秘密。其性能优势和密钥分发困难共同推动了公钥密码的发展。

3. 公钥密码：把“可以公开”与“必须保密”分离

非对称密码为每个用户建立一对数学相关但功能不同的密钥：

• 公钥可以公开；
• 私钥只能由密钥拥有者保存。

假设 Bob 拥有公钥 (K_B^+) 和私钥 (K_B^-)。Alice 想向 Bob 发送秘密消息时，可以使用 Bob 的公钥进行加密：

[
c=K_B^+(m)
]

Bob 使用自己的私钥解密：

[
m=K_B^-(c)
]

在课程中的抽象模型下，可以表示为：

[
K_B^-(K_B^+(m))=m
]

由于只有 Bob 掌握对应私钥，因此其他获得 Bob 公钥的人虽然可以生成发给 Bob 的密文，却不能直接恢复明文。

3.1 公钥为什么能够公开

公钥的职责不是作为共享秘密，而是让其他实体能够与密钥拥有者建立密码学关系。获得 Bob 公钥的人可以：

• 加密只有 Bob 能解密的消息；
• 验证由 Bob 私钥生成的数字签名。

公钥密码的安全性要求攻击者不能在现实可接受的时间内仅根据公钥推出私钥。

3.2 RSA 的两种使用方向

在课程模型中，RSA 具有两种可逆关系：

[
K_B^-(K_B^+(m))=m
]

[
K_B^+(K_B^-(m))=m
]

两种方向对应不同目的：

这里最容易产生的误解是把“使用私钥”理解为另一种加密。现代数字签名具有独立的算法结构和填充规则，不能简单等同于把原始消息用私钥进行普通 RSA 加密。但在课程的概念模型中，可以通过“私钥生成签名、公钥完成验证”理解其密钥使用方向。

3.3 为什么不能用 RSA 加密所有数据

公钥密码运算通常比对称密码昂贵。若对大型文件、视频或全部网络流量直接执行 RSA 运算，会产生显著计算开销。

实际系统通常采用混合加密：

  sequenceDiagram
    participant A as Alice
    participant B as Bob

    A->>A: 生成会话密钥 Ks
    A->>B: 使用Bob公钥保护Ks
    B->>B: 使用Bob私钥获得Ks
    A->>B: 使用Ks和AES传输数据
    B->>A: 使用Ks和AES返回数据
  

公钥密码负责认证或建立共享会话密钥，对称密码负责加密会话中的大量数据。这种分工同时利用了公钥密码便于建立秘密的优势和对称密码高效的优势。

❗ 本节核心结论： 公钥密码不是对称加密的全面替代品。它主要解决认证和密钥建立问题，而实际数据传输仍通常交给高效的对称密码完成。

4. 数字签名：证明消息来源与内容完整性

加密回答的是“谁能够阅读消息”，数字签名回答的是“谁生成了消息，以及消息是否发生变化”。

假设 Bob 向 Alice 发送消息 (m)。数字签名机制需要让 Alice 能够验证：

• 签名者掌握 Bob 的私钥；
• 消息在签名后没有被修改。

4.1 为什么签名消息摘要

直接对长消息执行公钥密码运算效率较低。因此，实际签名一般先使用散列函数计算消息摘要：

[
h=H(m)
]

散列函数接收任意长度的输入，输出固定长度的结果。摘要可以被理解为消息的密码学指纹。

理想的密码学散列函数应满足：

• 给定消息，能够快速计算摘要；
• 给定摘要，难以恢复原消息；
• 难以找到与指定消息摘要相同的另一条消息；
• 难以主动构造两条摘要相同的不同消息。

由于输入空间远大于固定长度的输出空间，碰撞在数学上一定存在，即可能出现：

[
m_1\neq m_2
]

但：

[
H(m_1)=H(m_2)
]

密码学安全所要求的不是碰撞绝对不存在，而是攻击者无法在可接受成本内找到有实际价值的碰撞。

4.2 校验和不能代替密码学散列

Internet 校验和也能把较长数据映射为固定长度结果，但其目标是检测传输中的随机错误，而不是抵抗恶意攻击。

攻击者可以有意修改多个字段，使变化在校验和计算中相互抵消。因此，校验和可以发现部分意外错误，却不能可靠防止精心构造的篡改。

MD5 和 SHA-1 分别生成 128 位和 160 位摘要，在密码学发展史中具有重要地位。但由于已发现实际碰撞攻击，它们不再适合用于要求抗碰撞性的现代数字签名系统。

4.3 签名与验证流程

Bob 首先计算消息摘要：

[
h=H(m)
]

随后使用私钥生成签名：

[
s=\operatorname{Sign}_{K_B^-}(h)
]

Bob 将消息和签名一起发送给 Alice：

[
(m,s)
]

Alice 收到后重新计算消息摘要：

[
h_1=H(m)
]

同时使用 Bob 的公钥验证签名，获得或验证签名所对应的摘要 (h_2)。若：

[
h_1=h_2
]

则说明收到的消息与 Bob 签名时的消息一致，并且签名由掌握相应私钥的实体生成。

  flowchart LR
    M[消息 m] --> H1[计算 H(m)]
    H1 --> S[使用私钥生成签名]
    M --> T[发送消息和签名]
    S --> T
    T --> R1[接收方重新计算摘要]
    T --> R2[使用公钥验证签名]
    R1 --> C{摘要是否一致}
    R2 --> C
    C -->|是| V[签名有效]
    C -->|否| F[消息或签名不可信]
  

数字签名并不自动隐藏原文。任何能够获得消息的人都可能读取其内容，但只有拥有可信公钥的人才能验证签名。

❗ 本节核心结论： 数字签名通过“消息摘要＋私钥签名＋公钥验证”证明消息来源和完整性，但不负责隐藏消息内容，其可信程度还取决于验证者是否持有正确且可信的公钥。

5. 身份认证协议的演进：从声明身份到证明在线

身份认证协议的设计不能只观察正常情况下是否能够完成认证，还必须站在攻击者视角分析报文能否被伪造、复制或重新使用。

从 ap1.0 到 ap5.0 的演进展示了安全协议设计的基本方法：每增加一种机制，都是为了修复上一版本暴露出的特定漏洞。

5.1 ap1.0：只声明身份

Alice 向 Bob 发送：

1

I am Alice.

该方案完全依赖发送者的自我声明。任何攻击者都可以发送同样的字符串，因此它没有提供任何可验证的身份证据。

5.2 ap2.0：使用源 IP 地址

下一步可以尝试检查报文的源 IP 地址。但 IP 数据报中的源地址可以被伪造。攻击者能够构造一个源地址看起来属于 Alice 的数据报。

IP 地址只能说明报文声称从哪里发出，不能构成密码学意义上的身份证明。

5.3 ap3.0：发送密码

要求 Alice 同时发送身份和密码，可以阻止不知道密码的攻击者直接登录。然而，如果密码或认证报文以可复制形式通过网络发送，监听者可以记录整段合法通信，之后原样再次提交。

这种攻击称为重放攻击。攻击者甚至不需要理解密码内容，只需要复制以前被系统接受的报文。

重放攻击揭示了身份认证中的一个重要区别：

一条报文曾经合法，不代表它在当前会话中仍然合法。

5.4 ap4.0：使用 nonce 实现挑战—响应

为防止旧报文被重复使用，Bob 可以为每次认证生成一个新的 nonce。nonce 是仅使用一次的随机数或不可重复值。

认证过程如下：

1. Alice 声明身份。
2. Bob 生成新的随机数 (R) 并发送给 Alice。
3. Alice 使用与 Bob 共享的秘密对 (R) 进行密码学处理。
4. Bob 验证返回结果是否与本次挑战匹配。

若 Alice 和 Bob 共享密钥 (K_{A-B})，Alice 可以返回：

[
K_{A-B}(R)
]

攻击者过去记录的响应对应旧随机数：

[
K_{A-B}(R_{\text{old}})
]

而本次认证要求的是：

[
K_{A-B}(R_{\text{new}})
]

只要新的 nonce 不重复，旧响应就无法通过验证。Bob 因此不仅确认对方掌握共享秘密，还确认对方正在针对当前挑战实时响应。

nonce 本身通常不需要保密。需要保密的是生成合法响应所依赖的密钥。

5.5 ap5.0：使用公钥完成挑战—响应

共享密钥方案仍然面临密钥分发问题。为避免事先共享对称密钥，可以让 Alice 使用私钥响应 Bob 的随机挑战。

Bob 发送 nonce (R)，Alice 使用自己的私钥生成响应，Bob 再使用 Alice 的公钥完成验证。若验证成功，Bob 可以确认对方掌握与该公钥配对的私钥。

但这一方案立即产生新的问题：

Bob 如何确定手中的公钥确实属于 Alice？

如果 Bob 只是通过当前网络连接询问 Alice 的公钥，攻击者就可以把自己的公钥发送给 Bob，并声称它属于 Alice。此时密码学运算可能全部正确，身份绑定却是错误的。

❗ 本节核心结论： 身份认证不仅要证明对方掌握某个秘密，还要证明响应属于当前会话。nonce 解决报文新鲜性问题，公钥挑战—响应缓解共享密钥分发问题，但仍不能自行证明公钥归属。

6. 中间人攻击：算法正确，通信仍可能失守

中间人攻击发生时，攻击者 Trudy 位于 Alice 和 Bob 之间，并分别与双方建立通信：

1

Alice ←→ Trudy ←→ Bob

Alice 以为自己正在与 Bob 通信，Bob 也以为自己正在与 Alice 通信。实际上，双方都只与 Trudy 建立了经过替换的密码学关系。

假设 Bob 请求 Alice 的公钥，Trudy 可以把自己的公钥发送给 Bob，并声称这是 Alice 的公钥。Bob 随后使用该公钥加密消息。Trudy 使用自己的私钥解密，读取或修改内容，再用 Alice 的真实公钥重新加密并转发。

整个过程中：

• Bob 使用的加密算法是正确的；
• Alice 使用的解密算法也是正确的；
• 双方可能正常收到格式正确的数据；
• 真正错误的是公钥与身份之间的绑定。

这说明：

公钥可以公开，不代表从网络中获得的任意公钥都可信。

公钥密码解决的是“拿到正确公钥以后如何安全通信”，却不能单独解决“如何确认拿到的是正确公钥”。

7. 数字证书与 CA：建立公钥和身份之间的绑定

为解决公钥归属问题，网络安全体系引入证书颁发机构 CA。CA 的核心职责是验证实体身份，并对实体身份与公钥之间的绑定关系进行数字签名。

实体可以是个人、组织、服务器、网站、软件发布者或其他网络设备。

7.1 数字证书的生成

Bob 向 CA 提交：

• 身份或组织信息；
• 域名信息；
• Bob 的公钥；
• 用于证明身份或域名控制权的材料。

CA 完成验证后，生成包含以下信息的证书：

• 证书主体；
• 域名；
• 主体公钥；
• 有效期；
• 签发者；
• 允许用途；
• 使用的密码算法。

CA 随后使用自己的私钥对证书内容或其摘要签名。证书所表达的并不是“这个网站绝对安全”，而是：

CA 根据其验证程序，确认该公钥与证书中声明的身份或域名存在绑定关系。

7.2 浏览器如何验证证书

浏览器收到网站证书后，不能只检查签名是否在数学上正确，还需要完成多项验证：

1. 验证签发 CA 的数字签名。
2. 验证证书链能否连接到受信任的根 CA。
3. 检查证书中的域名是否与当前访问域名一致。
4. 检查证书是否处于有效期内。
5. 检查证书用途是否允许服务器身份认证。
6. 检查证书是否已被吊销或受到其他限制。

即使一张证书由可信 CA 正确签名，如果它绑定的是另一个域名，也不能用于当前网站。

7.3 证书链与根信任

网站证书通常不是直接由根 CA 签发，而是由中间 CA 签发。验证过程形成一条证书链：

1
2
3
4
5
6
7

网站证书
    ↓ 中间CA签名
中间CA证书
    ↓ 根CA签名
根CA证书
    ↓ 操作系统或浏览器预先信任
信任起点

根 CA 证书通常预装在操作系统或浏览器的信任库中。它不是因为能够被更高层证书验证才可信，而是作为系统预先配置的信任锚。

  flowchart TD
    W[网站证书] --> I[验证中间CA签名]
    I --> R[验证到根CA]
    R --> D[检查访问域名]
    D --> T[检查有效期]
    T --> U[检查证书用途]
    U --> A[接受网站公钥]
  

7.4 CA 体系的边界

CA 并不能彻底消除风险。它只是把原来的问题：

我是否相信网站自己提供的公钥？

转化为：

我是否相信 CA 正确完成身份验证，并妥善保护了自己的私钥？

历史上的错误签发和 CA 入侵事件说明，一张证书的密码学签名可以完全正确，其签发过程却可能已经失守。若 CA 错误地向攻击者签发目标域名证书，浏览器可能在密码学层面顺利验证这张欺诈证书。

证书也不能证明网站业务合法、网页内容真实或者服务器不存在漏洞。它主要证明的是域名、公钥和签发体系之间的关系。

❗ 本节核心结论： 数字证书不是网站安全保证书，而是经过 CA 签名的公钥身份证明。其可靠性既依赖密码学算法，也依赖 CA 的验证流程、私钥保护和浏览器信任配置。

8. 现代安全通信是一条连续的信任链

对称加密、公钥密码、数字签名、nonce 和数字证书并不是彼此独立的知识点，而是依次修复安全通信中的不同缺口。

  flowchart TD
    A[需要保护大量数据] --> B[使用对称加密]
    B --> C[出现密钥分发问题]
    C --> D[引入公钥密码]
    D --> E[需要确认通信对象身份]
    E --> F[数字签名与挑战—响应]
    F --> G[需要防止重放]
    G --> H[引入nonce]
    D --> I[需要确认公钥归属]
    I --> J[数字证书与CA]
    J --> K[建立可信会话]
  

各机制之间的职责可以归纳为：

以典型安全连接为例，通信过程通常包含以下逻辑：

1. 客户端获得服务器证书。
2. 客户端验证证书链、域名、有效期和用途。
3. 客户端接受证书中的服务器公钥。
4. 双方通过公钥机制或密钥交换建立会话密钥。
5. 后续大量数据使用对称密码加密。
6. 完整性认证机制防止数据被悄悄修改。
7. nonce、序列号或其他新鲜性信息防止旧报文被重复利用。

现代协议的安全性因此不是来自某一个“足够强”的算法，而是来自整个流程中每个环节都完成了自己的职责。

结论

网络安全的根本任务，是在不可信的传输环境中建立可信关系。加密只能让攻击者难以理解数据，不能自动证明数据没有被修改；数字签名能够证明来源和完整性，却不负责隐藏原文；nonce 能够证明响应属于当前会话，却不能解决公钥归属；公钥可以公开，但必须通过数字证书和 CA 信任体系确认它属于谁。

对称密码、公钥密码、散列函数、数字签名、挑战—响应和证书体系共同构成了一条连续的信任链：

对称密码负责高效保护数据，公钥密码负责建立秘密，数字签名负责证明来源与完整性，nonce 负责保证报文新鲜性，数字证书负责绑定身份与公钥。

理解网络安全的关键，不是孤立背诵每种算法的定义，而是明确每一种机制解决了什么问题、仍然留下什么缺口，以及下一种机制为什么必须出现。只有当机密性、完整性、身份认证、公钥可信性和系统运行安全同时成立时，通信双方才真正获得了一条可信的安全连接。