第8章：网络安全

1 什么是网络安全？

• 机密性：只有发送方和预定的接收方能否理解传输的报文内容

  • 发送方加密报文

  • 接收方解密报文

• 认证：发送方和接收方需要确认对方的身份

• 报文完整性：发送方、接收方需要确认报文在传输的过程中或者事后有没有被改变

• 访问控制和服务的可用性：服务可以接入以及对用户而言是可用的

2 加密原理

• 对称密钥密码学：发送方和接收方的密钥相同

  • 问题：密钥怎么传输？

• 公开密钥密码学：发送方使用接收方的公钥进行加密，接收方使用自己的私钥进行解密

数字签名

数字签名是手写签名在数字世界的类比，用于解决网络通信中的身份验证、完整性和抗抵赖问题。它具备三个关键特性：

1. 可验证性：接收方（如Alice）能证明发送方（Bob）是文件的签署者。

2. 不可伪造性：只有Bob能生成其签名，他人（包括Alice）无法伪造。

3. 不可抵赖性：Bob事后无法否认自己签署过该文件（可作为法庭证据）。

• 工作原理（基于公钥密码学）

数字签名通过非对称加密实现，涉及一对密钥：

• 私钥 (K⁻)：由签名者（Bob）秘密保管，用于生成签名。

• 公钥 (K⁺)：对外公开，任何人都可用它来验证签名。

核心过程：

1. 签名生成：Bob对消息 m用其私钥进行计算，得到数字签名 KB−​(m)。

2. 签名与消息发送：Bob将原始消息 m和签名 KB−​(m)一起发送给Alice。

3. 签名验证：Alice收到后，用Bob公开的公钥对签名进行计算，验证等式 KB+​(KB−​(m))=m是否成立。

• 具体流程如下：

1. 签署：Bob撰写消息（如“Dear Alice...”），并用自己的私钥通过加密算法处理消息，生成“签名”。

2. 传输：Bob将“原始消息”和“签名”一并发送出去。

3. 验证：Alice收到后，使用Bob的公钥对“签名”进行解密运算。如果解密结果与收到的“原始消息”完全一致，则证明：

   • ✅ 签署者身份真实：签名一定来自Bob的私钥持有者。

   • ✅ 消息未被篡改：Bob签署的就是这份消息 m，而非其他消息 m‘。

3 报文完整性

广泛使用的散列函数算法标准：

• MD5 (消息摘要算法5)：

  • 输出一个**128位（16字节）**的固定长度摘要。

  • 核心特性：具有单向性，即给定一个摘要值x，在计算上几乎不可能构造出另一个能生成相同摘要的原始报文m。这旨在防止伪造。

• SHA-1 (安全散列算法1)：

  • 美国国家标准技术研究院发布的标准。

  • 输出一个更长的160位摘要，理论上比128位的MD5更安全。

重要提示（基于当前知识）：提到的MD5和SHA-1算法，因其已被发现存在致命的碰撞漏洞（即可构造出两个不同内容但摘要相同的报文），现已不再被视为安全的加密散列函数，不应在需要安全性的场景（如数字签名、密码存储）中使用。现代应用已转向SHA-256、SHA-3等更安全的算法。此图更多是作为理解散列函数概念的技术史实例。

• 目的：为解决对长报文直接进行非对称加密（如RSA）效率低下的问题，目标是生成一个固定长度、易于计算的“数字指纹”。

• 工作原理：对任意长度的输入报文 m，通过一个特定的散列函数 H进行计算，得到固定长度的输出 H(m)，即“报文摘要”或“哈希值”。

• 三大关键特性：

  1. 多对一：无数个不同的输入可能映射到同一个有限的输出集合中（即可能发生“碰撞”，但安全的散列函数要求极难找到碰撞）。

  2. 结果固定长度：无论输入多大，输出长度固定（如MD5的128位，SHA-1的160位）。

  3. 单向性（计算不可行性）：这是最关键的安全特性。给定摘要值 x，想要反向计算或找到一个原始报文 m使得 H(m) = x在计算上是不可行的。

散列函数的这些特性，使其成为数字签名和众多安全协议的基石。在数字签名中，通常不是直接对原始长消息签名，而是对消息的散列值进行签名，这既保证了效率，又依托了散列函数的完整性和单向性。

4 密钥分发和证书

1. 对称密钥体系的挑战：如果Alice和Bob想用AES这类对称加密私下聊天，他们首先需要一个只有他们俩知道的共享密钥。但如何在不安全的网络上，安全地交换这个最初的密钥呢？直接发送密钥会被窃听。

2. 公钥体系的挑战：公钥加密（如RSA）不需要交换密钥，Bob可以公开他的公钥。但当Alice拿到一个声称是Bob的公钥时，她如何能确信这真是Bob的公钥，而不是黑客Trudy伪造的呢？

这两种挑战的解决方案，都依赖于一个双方都认可的可信赖的第三方（Trusted Third Party, TTP）。

4.1.1 解决方案一：密钥分发中心

解决场景：对称密钥体系下的初始密钥安全分发问题。

核心思想：引入一个双方都绝对信任的中介服务器——KDC。用户不与每个通信对象分别建立共享密钥，而是只与KDC共享一个长期密钥。KDC负责为每次会话临时生成一个会话密钥，并安全地分发给通信双方。

工作原理（如图2、3所示）：

1. 预先准备：Alice和Bob各自在KDC注册，并分别与KDC共享一个只有他们俩知道的长期主密钥（K_A-KDC, K_B-KDC）。

2. 密钥请求：当Alice想和Bob通话时，她向KDC申请一个与Bob通信的临时密钥。

3. 密钥生成与分发：

   • KDC生成一个临时的会话密钥R1。

   • KDC用Alice的主密钥 K_A-KDC加密一个消息发给Alice，内容是：“这是给Bob用的会话密钥R1”。

   • KDC用Bob的主密钥 K_B-KDC加密一个消息发给Bob，内容是：“Alice想用R1和你通信”。

4. 安全通信建立：Alice和Bob各自用自己的主密钥解密KDC发来的消息，就都得到了同一个会话密钥R1。之后，他们就可以用R1进行安全的对称加密通信了。

优点：只需与KDC共享一个密钥，就能与所有注册用户安全通信。会话密钥临时生成，安全性高。

局限性：KDC成为整个系统的单点故障和性能瓶颈，且必须绝对可信。它知道所有用户的会话密钥。

4.1.2 解决方案二：认证机构

解决场景：公钥体系中公钥真实性的验证问题。

核心思想：引入一个权威的第三方——CA。CA不参与每次通信，也不分发密钥，它的工作是为用户的公钥做“数字公证”，证明“这个公钥确实属于这个人”。

工作流程

4.1.2.1 第一阶段：绑—— 证书颁发（图4）

1. 身份验证：实体（如Bob）向CA提交自己的公钥和能证明自己身份的材料。

2. 数字签名：CA核实身份后，用自己的私钥对“Bob的身份信息+Bob的公钥”这个数据包进行数字签名，生成一个数字证书。这个证书就像是CA颁发的一本“数字护照”。

4.1.2.2 第二阶段：验—— 证书验证（图5）

1. 获取证书：Alice需要Bob的公钥时，可以从Bob的网站、邮件签名等处获得Bob的数字证书。

2. 验证真伪：Alice用她信任的CA的公钥（这个公钥通常预装在操作系统或浏览器中）去解密证书上的CA签名。

3. 建立信任：如果解密成功且内容匹配，就证明这个证书确实是CA颁发的，里面的公钥**K_B+**就真的是Bob的公钥。Alice就可以放心地用这个公钥给Bob发送加密信息，或验证Bob的数字签名了。

优点：CA不参与具体通信，只做“发证”和“验章”的工作。去中心化程度更高，避免了单点性能瓶颈。私钥始终由用户自己保管，CA不知道用户的私钥。

4.1.3 总结与对比

特性	密钥分发中心	认证机构
解决问题	对称加密中，会话密钥的安全初始分发。	公钥加密中，公钥真实性的可信证明。
核心角色	密钥的生成者和分发者。	公钥与身份的绑定者和证明者。
信任基础	通信双方都必须预先信任KDC。	通信双方都必须预先信任同一个CA。
与用户密钥关系	KDC知道所有用户的主密钥。	CA不知道用户的私钥，只为用户的公钥背书。
典型应用	Kerberos认证系统。	HTTPS (SSL/TLS)、代码签名、电子邮件加密 (S/MIME)。

一句话概括：

• KDC像一个高度机密的电话接线总机，负责为每次通话临时接一条安全的线路（会话密钥）。

• CA像一个公安局的户籍科，不关心你们聊什么，只负责开具“这个公钥身份证号就是张三本人”的证明（数字证书）。

5 SSL

• 根证书：这是整个信任体系的“信任锚”。它不由其他机构签发，而是自签名的。您的操作系统或浏览器在出厂时就预装了一批全球公认的、备受信任的**根证书颁发机构（Root CA）**的证书及其公钥。

• 信任链的传递：

  1. 因为您信任了“根CA”，所以您就信任了用它私钥签发的所有证书。

  2. 根CA不会直接为千万个网站签发证书，它通常会签发证书给中间CA。

  3. 中间CA再用自己的私钥为具体的网站（如 www.example.com）签发终端实体证书。

• 验证过程：当您访问一个HTTPS网站时，浏览器会收到一个证书链（网站证书 → 中间CA证书 → 根CA证书）。浏览器用预装的根CA公钥去验证中间CA证书，再用中间CA的公钥去验证网站证书。只要链条中所有签名都有效，您就可以确信网站的公钥是真实的。

简言之：您预先信任少数几个根CA，通过层层数字签名，这种信任被安全地传递给了全球数百万个网站。

5.1.1 SSL/TLS（信任的应用）

**SSL（现普遍称为TLS）**中付诸实践，为您的网络通信（如网页浏览）提供安全保障。

• 协议定位：SSL/TLS工作在应用层和传输层（TCP）之间，为上层应用（如HTTP）提供安全的传输通道。使用HTTP over SSL/TLS，就是您熟悉的 HTTPS。

• 核心安全服务：

  1. 服务器认证（必须）：这正是通过证书链来实现的。客户端（浏览器）验证服务器证书的真实性，确保您连接的是真正的银行网站，而非钓鱼网站。

  2. 数据加密：验证服务器身份后，双方会协商出一个临时的会话密钥，用于加密所有通信数据，防止窃听。

  3. 客户端认证（可选）：在某些对安全要求极高的场景（如企业网银），服务器也可以要求客户端出示证书，实现双向身份验证。

实现原理

1. 建立连接时：您的浏览器（客户端）会通过 SSL/TLS握手协议，要求网站（服务器）出示它的数字证书。

2. 验证身份时：浏览器运用 **“信任树”**的原理，去验证收到的证书链。确认网站身份真实、可靠。

3. 开始通信时：身份确认后，SSL/TLS协议利用该证书中的公钥，安全地协商出临时的会话密钥，开始加密传输所有数据。

结论：“信任树”**是理论基础和安全前提，它解决了“公钥属于谁”的身份问题。 SSL/TLS是工程实现和应用协议，它利用已验证的公钥，解决了“如何安全对话”的通信问题。二者结合，共同构成了守护您网络购物、在线转账等所有安全交互的基石。