Bo2SS

上周在大前端组里做了一次技术分享，因为现在公司在推行 “办公全英文化”，所以这还是一次全英文的分享。全英文对自己来说是一次挑战，虽然一个半小时全都用了英语，但自我评价还是勇气大于实力吧🐶。

互联网时代，如何建立信任呢❓这建立信任的基础当然是保证信息传输是安全的，这样用户才敢在网上交流、购物、支付... 那么，今天，我们就来一步一步看看互联网时代信息安全的发展吧！

「本文大纲」如下：

「关键字」密码学、对称密钥系统、非对称密钥系统、哈希、数字签名、数字证书、SSL/TLS、SSH、iOS 签名、OpenSSL、WireShark

💡：不用担心，这里不会讲复杂的数学运算。

写在开头#

1. 我们在工程里有很多与信息安全相关的代码，比如 RSA、AES、HMAC... 每次遇到它们，我都会感到迷惑甚至头冷，所以我想了解了解它们到底是干什么的。

2. 之前自己在 iOS 签名的问题上踩过坑，从而有了上一篇文章（iOS | 图解 iOS 签名背后的原理，感兴趣的可以去看看），这次因为是针对大前端的分享，所以算是在上篇文章的基础上扩展。

以上原因，就促成了这篇文章的诞生，希望互联网时代的你们会感兴趣。

本文目标#

回答并理解以下问题：

1. 🥣信息传输一般使用对称加密➕非对称加密，为什么？不能只使用其中一种吗？

2. 🥣信息安全为什么需要数字签名？

3. 🥣为什么签名前需要做哈希操作？

4. 🥣信息安全为什么需要数字证书？

终极目标：当我们遇到密码学相关问题时，不再恐惧和迷惑。

什么是信息安全？#

这是一个比较大的问题，在这里，我想通过信息安全的三要素（简称CIA）来回答。

CIA 的组成如下：

• 机密性（ Confidentiality）：指信息在存储、传输、使用的过程中，不会被泄漏给非授权用户或实体。

• 完整性（Integrity）：指信息在存储、传输、使用的过程中，不会被非授权用户篡改，或防止授权用户对信息进行不恰当的篡改。

• 可用性（ Availability）：指确保授权用户或实体对信息资源的正常使用不会被异常拒绝，允许其可靠而及时地访问信息资源。

  • ➕认证性（Authentication）：也可以理解为不可否认性（Non-Repudiation），指网络通信双方在信息交互过程中，确信参与者本身和所提供的信息真实同一性，即所有参与者不可否认或抵赖本人的真实身份，以及提供信息的原样性和完成的操作与承诺。

  • ➕可控性（Controllability）：指网络系统和信息在传输范围和存放空间内的可控程度。

参考：信息安全的 5 个安全特征——51know

💡这里有 2 点需要进行说明：

1. 可用性里还添加了两个要素：认证性和可控性，个人认为这两者是为可用性服务的，所以归为一类。

2. 本文要聊的和这 3 个要素有关：机密性、完整性和认证性，我们可以把它们仨当成3 个需求，本文的首要任务就是完成它们。另外，上面对这 3 个要素的解释比较有专业性，我再用大白话简单介绍下：

   1. ❗️机密性：A 给 B 发短信，不想让 C看到短信内容。

   2. ❗️完整性：A 给 B 发短信，不想让 C修改短信内容。

   3. ❗️认证性：A 给 B 发短信，B 可以确认发送方的身份是 A，而不是 C。

好，我们带着3 个需求继续往下看。

为什么需要信息安全？#

在聊怎么做之前，我们先想一下需要信息安全的原因，我这里简单总结为 “用户需要，公司满足”。细说的话可以分为 3 点：

1. 需要信息安全这件事，是一个很普遍的认识，尤其在银行、电商等涉及金钱、用户隐私的领域。

2. 从网络使用者的角度分析，如果他们的信息安全无法被保障，他们怎么还敢在网上购物、支付、贷款以及输入账户密码等私人信息呢？

3. 对一家公司来说，它如果无法保障用户的信息安全，那就会失去用户的信任，也就相当于失去了用户，这样的公司还谈什么发展呢？

所以互联网时代，信息安全是极其必要的。下面我们就来看看怎么做吧！

怎么做到信息安全#

❗️铭记我们的 3 个需求：机密性、完整性、认证性。

讲到信息安全，那当然就少不了密码学的登场，因为密码学的三个基本安全目标（机密性、完整性、可用性）就是针对上面的 3 个需求，可不巧了嘛～

首先，我们可以从下面的视频了解一下密码学的发展史：

• 简单了解：The History of Cryptography｜Explained For Beginners——Binance Academy, Youtube

• 详细了解：

  • Secret Codes: A History of Cryptography (Part 1)——The Generalist Papers, Youtube

  • More Secret Codes: A History of Cryptography (Part 2)——The Generalist Papers, Youtube

好了，现在你应该对密码学有一个大致的认识了，下面我们来看看密码学里的三大常见算法。

三大常见的密码学算法#

它们分别是对称密钥算法、非对称密钥算法、哈希算法。

对称加密算法#

如上图黄框内所示，对称加密的过程就是，发送方通过密钥（Secret Key）加密明文，得到密文并发送给接收方，接收方通过相同的密钥解密密文，即可得到明文。

💡对称加密的特点：加 / 解密所用的密钥是同一把（Same Key）。

Q1: 你能想到哪些常见的对称加密算法呢？

DES、3DES、AES、IDEA、SM1、SM4、RC2、RC4。

其中，除了 RC4 是流密码算法（每次只加解密 1 位或 1 字节）外，其他都属于分组密码算法（平均拆分为 N 组后再进行加密，最后按顺序组合）。

这里列出这些算法名的目的，是想让你在遇到这些术语时，可以明确知道它们是做什么的，从而有的放矢，对数学原理感兴趣的话可以自行深入探索。

参考：密码学基础（一）常见密码算法分类——Blog

Q2: 看到上面这张图，你是否会有这样的疑问：密钥该如何发送给接收方？这样接收方在收到密文后，才能进行解密呀。

这是一个好问题，如果在真实世界中，我们可以通过暗中碰头交接密钥，但在互联网世界，黑客可以轻易的劫获你的通信，所以对称加密算法最大的难点就是密钥分发问题。

如何解决呢？这就有了下面的非对称加密算法。

非对称加密算法#

如上图黄框内所示，非对称加密的过程与对称加密大体相似。

💡唯一的区别，也就是非对称加密算法的特点：加 / 解密所用的密钥不一样（Different Key）。

与对称加密里的对称密钥一样，非对称加密里的私钥（Secret Key / Private Key）也是非常隐私、非常重要的，不能随便给别人，而公钥（Public Key）就可以随意分发了。

如果想让和发送方进行加密通信，可以把公钥发给发送方，给发送方用来加密，自己（也就是接收方）收到密文后，用私钥解密即可。

Q1: 你能列举一些常见的非对称加密算法吗？

RSA、ECC、DSA、ECDSA、SM2。

Q2: 既然非对称加密解决了密钥分发问题，那是不是就没对称加密什么事了？

其实不然，非对称加密也有缺点，它的缺点就是加密速度远慢于对称加密（对称加密的本质是位运算，非对称加密的本质是幂运算和模运算）。

所以，这就引出了本文的目标问题 1：信息传输一般使用对称加密➕非对称加密，为什么？不能只使用其中一种吗？

我们会在 “信息传输的加密方式” 这一节再聊，下面再接着介绍最后一种常见的密码学算法 —— 哈希算法。

哈希算法#

从上图可以看出，哈希算法可以将任意数据，转换成一串固定长度的编码，我们一般把这串编码叫做哈希值或者摘要。

💡哈希算法的特点：

1. “唯一” 标识性：相同的输入，输出一定相同；不同的输入，输出大概率不同。（因为大概率，所以唯一加了双引号）

2. 不可逆：不能通过输出推导出输入。

我们可以将哈希值理解为原始数据的 “指纹”。在犯罪现场，虽然我们不可以通过指纹直接推导出对应的人是啥样（不可逆），但是我们可以通过比对现场和犯罪嫌疑人（或者指纹库）的指纹，找到凶手！

💡结合上面两个特点，哈希算法一般有 2 个用途：

1）验证数据是否被修改

我们在下载某些软件时，会看到下载链接附近还附加了一个哈希值（MD5），有什么用呢？

其实这个哈希值就像原始下载包 A 的一个 “指纹”。如果我们下载的包在下载过程中途被人改动了，变成了假包 B，我们计算一下假包 B 的哈希值 B-hash（MD5），和图中原始包 A 的哈希值 A-hash 做对比，如果 B-hash 和 A-hash 不一致，那还说什么，B 包 “有鬼”。

此外，后面的数字签名技术里也会用到哈希函数，我们待会再聊。

2）存储用户隐私

一个平台的数据库里需要存储用户的账户名、密码，这里如果密码是明文存放的，那可就危险了，保不定数据库出现漏洞，被黑客攻破，密码就全部泄漏了。

所以，数据库里存储的是密码的哈希值，在用户输入密码登陆时，只需要比对原始密码和输入密码的哈希值即可。这也就是，为什么我们在某个平台忘记密码后，只能重设密码，因为平台也不知道我们的原始密码呀～

说到这里，先看两个小问答。

Q1: 你能列举一些常见的哈希算法吗？

MD5、SHA-1、SHA-2、SHA-3、HMAC、SM3。

Q2: SM 系列算法是由我国认定和公布的，你知道它的全称是什么吗？

正是因为是由我国认定的，所以 SM 其实来源于拼音，它的全称是商（S）用密（M）码。

回到哈希算法的第二个用途（存储用户隐私），其实存在一些风险，那就是🌈彩虹攻击。

从上图的彩虹表可以看出，对于一些常用的密码，其对应的哈希值（MD5）早就众人皆知了。黑客拿到这些哈希值，也就相当于拿到原始密码了，所以我们还需要一些措施减少彩虹攻击的风险。这里有一个基于彩虹表的网站cmd5，感兴趣可以去看看。

比如哈希加盐、HMAC。前者是在明文的基础上添加一个随机数（盐）后，再计算哈希值；后者则更加安全，在明文的基础上结合密钥（提前共享的对称密钥），再计算哈希值。

参考：

• 浅谈常见的七种加密算法及实现 | 各种加密算法对比—— 掘金

• 你的密码安全吗？（对称加密、哈希函数、哈希加盐）——bilibili

• 一文详解密码学 Hash 算法的安全问题（加盐、HMAC）——CSDN

好了，以上就是三大常见的密码学算法了，下面基于这些基础算法聊聊如何实现我们的 3 个需求，你还记得吗？机密性、完整性、认证性。

信息传输的加密方式#

❗️实现需求 1：机密性。

🥣回答目标问题 1：信息传输一般使用对称加密➕非对称加密，为什么？不能只使用其中一种吗？

先来回答问题 1，从上面的学习我们已经知道两种加密方式各有不足，又能互相弥补。

🥣所以，结合对称加密（速度快）和非对称加密（便于分发密钥）的优点来实现信息安全传输，也就是用非对称加密传输对称密钥，后面的通信则直接用对称密钥加密的方式，这是目前能想到的最佳方式。

PS: 关于密钥交换方式，除了上面基于非对称加密的方式外，其实还有 2 种方式来交换密钥。

1. 专门的密钥交换算法，如 DH (E)、ECDH (E)；

2. 预部署方式，如 PSK、SRP。

总之，记住一点，因为对称加密的性能好，所以大量、频繁的通信数据都是用对称密钥来加密的，上面说的要交换的密钥也都是对称密钥。

❗️有了加密手段，信息传输的机密性也就有了保障，至此，我们完成了第 1 个需求～

那如何保证信息的完整性呢？这就要看数字签名了。

数字签名#

❗️实现需求 2：完整性。

🥣回答目标问题 2：信息安全为什么需要数字签名？

🥣回答目标问题 3：为什么签名前需要做哈希操作？

数字签名一般夹带在要传输的数据中，用来防止数据被篡改，接下来就来说说它是怎么做到的。

首先，它的底层核心就是刚刚提到的哈希算法和非对称加密算法。

生成（加签）#

签名是由通信中的发送方生成的，发送方首先会对要传输的数据进行哈希，得到数据摘要（也就是哈希值），然后用私钥对摘要进行计算，从而生成了这份数据的签名。

验证（验签）#

接收方收到数据和其签名后，分别做如下处理：

• 数据：使用与发送方相同的哈希算法，计算实际数据的摘要 A；

• 签名：利用发送方所用私钥对应的公钥，对签名进行计算，得到原始数据的摘要 B。

比对摘要 A 和摘要 B，如果相等，则说明实际数据没有被篡改，否则数据存在问题（是不是和哈希验证数据完整性有些类似呢，但签名的安全级别显然更高，因为还引入了私钥保驾护航呢）。

整个签名的生成和验证过程合在一起，就是这样了，那么回到目标问题 2、3，你有答案了吗？

🥣2: 信息安全为什么需要数字签名？

很简单，就是为了保证信息的完整性（❗️顺手就完成了需求 2）。

🥣3: 为什么签名前需要做哈希操作？

先思考两个问题：

1. 哈希是做什么的？它将任意数据，转换成一串固定长度的编码。

2. 签名的本质是非对称加密，有什么不足吗？性能低。

所以对一大段数据进行签名，不如对一小段数据签名来的快，恰巧哈希算法也能很大程度上保证数据的唯一性。

但 1）加快签名速度还只是回答的一部分，因为如果签名前不做哈希操作，这里还会有 2）安全上的隐患：

1. 重排序。如果要传输的消息过长，超过了非对称加密算法支持的最大长度，那么系统只能对消息做分段签名，从而得到多个签名；接收方验证的时候，则是对每个签名分别进行验证。但如果是这样的话，分段后消息的顺序就无法保证不被篡改了，因为每个签名还是可以通过验证的（有人可能会想到，多个签名整合在一起后再生成一个签名，但这样可能又会受到非对称加密算法支持的最大长度限制了）。

2. 消息伪造。黑客通过捕获任意签名，倒推出明文消息，以后就可以组装使用了（因为倒推用的的公钥是很容易获取的）。

参考Why hash the message before signing it with RSA?——StackExchange

至此，我们就只剩下 1 个需求❗️和 1 个目标问题🥣了～

现在，我们先思考一个问题：

Q: 接收方如何拿到验签所用的公钥呢？

请接着往下看。

数字证书#

💡实现需求 3：认证性。

🥣回答目标问题 4：信息安全为什么需要数字证书？

在了解数字证书之前，对于 “接收方如何拿到验签所用的公钥呢？” 这个问题，我们可能马上想到的是，发送方在发送数据和签名的同时，再附带上公钥不就万事俱备了吗～如下图：

但是这样会引入一个新的问题Q：接收方如何确认公钥没有被其他人恶意替换呢？也就是公钥的身份不明。

🎉灯灯灯～灯～～，现在该数字证书登场了。

组成内容#

我们可以先看一下数字证书的组成内容，它是由公钥、公钥的身份信息以及它们的签名（另一个签名）组成的。

注意：

1. 加密公钥数据所用的私钥又是另外一个公私钥组合了，它是由权威的认证机构（Certificate Authority，CA）颁发的，我们肯定是没有 CA 私钥的。

2. 如何理解 CA？我们可以联想一下，我们的身份证是由政府颁发的。

公钥包装在数字证书中传递#

现在，我们发送的内容做了一点改变：公钥→证书。

也就是原来发送的数据 + 签名 +公钥，变成了数据 + 签名 +证书。

证书里包含了接收方验证签名 A 所需的公钥，以及公钥的身份信息和签名 B：

1. 身份信息的存在则可以消除公钥身份不明的隐患（❗️也就完成了需求 3：认证性，🥣回答了目标问题 4：信息安全为什么需要数字证书？）；

2. 而签名 B 则又对公钥及其身份信息的完整性做了保证。

但也因为有了签名 B，我们在取公钥时，还需要先对证书里的签名 B 进行验证：

而验证签名 B 所用的公钥也是由 CA 颁发的，它存在于CA 证书里。

（这里我们可以再复习一下证书的组成内容：公钥 + 公钥的身份信息 + 它们的签名。）

♻️这里你又该有疑问了Q：接收方又从哪里获得这个 CA 证书呢？就算有了 CA 证书，我又要如何验证这个 CA 证书的签名呢？似乎进入了无限循环。

其实，CA 证书一般是在安装系统 / 软件时内置的，这样我们总该信任它了吧～

接下来，我们可以再了解一下证书的信任链。

证书信任链#

根据证书在信任链中所处的位置，可以将证书分为三种：

• 根证书 Root Certificate（参考Apple 操作系统中可用的受信任根证书——Apple 官方）

• 中间证书 Intermediate Certificate

• 叶子证书 Leaf Certificate

🌰举例：我的开发者证书 A（Apple Development）由中间证书 B（Apple Worldwide Developer Relations Certification Authority，安装 Xcode 时内置）的 CA 签发，中间证书 B 由根证书 C（Apple Root CA，系统内置）的 CA 签发，而根证书 C 是由自己的 CA 签发的，因为 C 已经在信任链的顶端啦，它自己说了算。

现在，你也可以看看自己的 Mac > Keychain Access > Certificates，加深理解。

这里还有一个有趣的问题Q：证书有可能被篡改吗？

1. 直接修改？首先想一下直接修改证书的内容（公钥及身份信息），这是肯定行不通的。因为黑客没有 CA 的私钥，它不能对证书内容重新签名。

2. 直接掉包？这也是不行的。因为证书里是有发送者的身份信息的，比如说我通过浏览器（接收方）访问一个网站（发送方），网站的证书里是会有域名信息的，浏览器可以直接比对自己请求的域名和证书里的域名信息，就可以知道证书有没有被掉包了～

参考：彻底搞懂 HTTPS 的加密原理—— 知乎

扩展（规范、体系、标准）：密码学基础（二）数字证书、密钥基础知识——Blog

到这里，我们的 3 大需求❗️和 4 大目标问题🥣全部完成了！放松一下～

最后，我们聊一点加餐内容：

• 信息安全的相关技术（SSL/TLS、SSH、iOS 签名）

• 一些实践（OpenSSL、WireShark）。

相关技术 + 一些实践（加餐）#

因篇幅过长，请移步另一篇文章：（加餐）信息安全 | 互联网时代，如何建立信任？。

回到开篇的目标#

如果这次的分享你只能记住一点点🤏，那就试着理解下面问题的答案吧！

1. 信息传输一般使用对称加密 + 非对称加密，为什么？不能只用非对称加密吗？

2. 为什么需要数字签名？

3. 为什么签名前需要做哈希操作？

4. 为什么需要数字证书？

另外，你实现本文的终极目标了吗？期待与你的交流～

终极目标：当我们遇到密码学相关问题时，不再恐惧和迷惑。

——写于暴雨红色预警⛈️、索性请假的一天，深圳