【网络安全】理解报文加密、数字签名能解决的实际问题-Toy模板网

这篇具有很好参考价值的文章主要介绍了【网络安全】理解报文加密、数字签名能解决的实际问题。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

前言

工作中重新接触了【公钥、私钥、签名】的概念。抽空重新看了《计算机网络》和国外的小黑书，把这块基础知识再收敛一下。基于小黑书的叙事结构，把网络安全解决的实际问题拆解成：

防止报文泄露
防止报文被篡改
实体鉴别
端点鉴别
防止重放攻击

1. 防止报文泄露 —— 加密体系的出现

网络丢包是常见的事情，丢包意味着报文可能被截获。怎样能够减少丢包造成的损失呢？两个思路

物理隔绝 —— 内网通信
保护信息 —— 报文加密

如果两家公司在公网上通信，涉密信息的报文一定要经过加密。加密又有两种形式，（这个网上资料很多，不再赘述）

对称加密
非对称加密

NOTE: 非对称加密算法复杂，消耗的资源多，所以实际应用是【非对称加密 + 对称加密】，旨在确保通信安全的前提下兼顾效率。

1.1 理解非对称加密体系的实施难点

以 RSA 非对称算法为例，比DES慢 2~4个数量级
多对多的网络模式下，密钥的管理和交换比对称加密复杂

1.2 加密体系的实际应用

A与B用RSA（非对称加密）交换会话密钥（对称密钥）
A和B在一段时间内，都使用会话密钥进行通信。

【网络安全】理解报文加密、数字签名能解决的实际问题,计算机网络,基础,后端,web安全,安全

2. 防止报文被篡改 —— 数字签名的出现

上文提到，报文加密可以减少丢包的损失。简单来说就是截获网络报文的人看不懂双方在讲什么。只加密就完了吗？我们把攻击者想象得太简单了，有一些攻击者，会做这些事

从发送方中把报文（密文）篡改了，再丢给接收方。接收方从密文中还原的明文也就成了乱码。
从发送方中获取明文和密钥，修改明文，加密后再发给接收方。接收方就被误导了。

有没有办法证明报文本身没被篡改呢？大体思路是这样的：

报文中确保有发送者的签名
签名一定要与内容进行绑定，内容变了，签名失效。（完成这种机制的就是数字签名）

值得注意的是，“签名” 一词在中文里面表达一种不变量，比如小明本人签字，内容一定是“小明”。而在计算机世界中，这个 “签名” 是被计算出来的，根据内容实时变化的。

2.1 数字签名的原理

数字签名以非对称加密为基础。
“公钥加密，私钥解密” 这个是大多数人的共识，但是这里存在容易混淆概念的地方。
因为中文的“解密”一定出现在“加密”之前。实际上把 “加密” 和 “解密” 都换成 “运算”，更合理些。
因为运算是可以满足交换律的，数字签名就是使用的运算的交换律
【网络安全】理解报文加密、数字签名能解决的实际问题,计算机网络,基础,后端,web安全,安全

A 生成密文后，用自己的私钥（全宇宙只有自己持有），对密文进行X运算，生成数字签名。把密文和数字签名一起发送给 B
B 收到密文后，先用 A 的公钥对数字签名进行D运算。由于X运算和D运算满足交换律，所以对数字签名进行D运算会解析出密文。如果这个密文和A给的密文不一致，则报文被篡改。
以上的 D运算 实际上就是验签
由于A的私钥是全宇宙唯一的，所以A的签名不可伪造，也不可抵赖（A说自己没发过这个报文，但是世界不会承认他没发过）

2.2 数字签名的实施难点

非对称加密比较消耗资源，特别是对大报文进行运算。

2.2 数字签名的实际应用 —— 引入摘要算法

既然大报文消耗性能，能不能把报文弄小? 思路其实就是摘要算法，常见的 md5、sha-1 就是摘要算法（也叫散列算法）。
【网络安全】理解报文加密、数字签名能解决的实际问题,计算机网络,基础,后端,web安全,安全

程序中的应用

// 把签名拼接到密文后面，接收者再解析出签名，验签即可
密文.签名

3. 实体鉴别 —— CA证书

上文提到，现实的通信基础，是对称和非对称加密结合。那么自然就引出了两个议题

如何交换密钥
如何证明 “A的公钥属于A”

这块内容是密钥管理的内容，内容多的可以单独开个专题来讲了。对于通信双方，只需要知道CA证书的存在即可，他是作为密钥管理的第三方，CA = Certification Authority (认证中心)。具体的管理方式：

A 在认证中心上注册了自己的公钥，获得了CA证书。
B 要与 A 通信前先用 A 给的 CA 证书去认证中心确认公钥来自于 A

后记

值得一提的是，理解了上述概念，再看看jwt的报文组成，就显得合理多了。

另外，理解报文加密、数字签名就写到这里。

下面的两个话题主要是防止中间人攻击。

端点鉴别
- 类似于回答 “证明你是你的问题”，比如现实生活中的活体认证（扫脸）。
  EG:
  - 一个ip数据包的源地址为 102.189.67.134，已知报文可以伪造，怎么证明该ip数据包就是 102.189.67.134 发出的
  - 结论：类似这种 ip欺骗（如 DDOS 攻击）的攻击手段，在网络层执行。应用层已经没有痕迹了，只能用 加密口令 加大攻击难度

防止重放攻击
- 可以联想一下业务的幂等控制，通常以”加锁“的方式实现。但是通信领域需要高效的解决方案，加锁太重了，取而代之的是采用 ”不重数集“。
  EG:
  - 102.189.67.134 发起交易请求的报文被攻击者复制了一份（注意，是复制而不是截获，因为问题主干是 “重放”），攻击者把源ip地址改为 102.189.67.134 (伪造成原来的发送方)，再发送出去，接收方怎么识别这种攻击呢？
  - 结论：类似于TCP的滑动窗口，两边约定一个不重数集合，消费过的数据不会被重复消费。