什么是数字签名

签名的本质是用于验证数据的合法性，确保被签名的数据来自特定的来源，并且未经篡改。换成通俗的话说，即证明你自己的身份，确保你是你。
它基于非对称加密和哈希算法，研究签名之前需要对这两种算法有一定的了解。

非对称加密算法

它在加密和解密时使用的是不同的密钥，具有这样的特征：

• 有一对密钥 a 和 b ，满足 a ≠ b
• 用密钥a加密的数据只能用b进行解密，a自身无法解密，反之亦然
• 只知道其中一个密钥，无法推导出另一个
• 把其中一个可以公开的叫做公钥，另一个不能公开的叫做私钥。本质上，私钥与公钥没有任何不同。

pubkey_crypto.png

基于非对称加密公钥与私钥的特点，也常常有如下说法：

1. 基于私钥加密，被叫做签名。因为私钥只有数据发送方持有，别人无法冒充。类似于现实生活中手写签名，只有自己才有的笔迹。
2. 基于公钥解密，被叫做验签。即验证私钥加密的签名。类似于现实生活中的笔迹大师验证，这个签名确实是你的笔迹。
3. 基于公钥加密，被叫做加密。因为私钥只有数据发送方持有，别人即使获取密文，也无法解出明文。
4. 基于私钥解密，被叫做解密。用于解密密文，获取真实信息。

哈希算法

也叫散列或者摘要算法，对一段任意长度的数据，通过一定的映射和计算，得到一个固定长度的值，这个值就被称为这段数据的哈希值(hash)。给定一个哈希算法，它一定具有以下特征：

• 相同的数据计算出的哈希值绝对相同
• 由于哈希值是固定长度， 也就意味着哈希值的数量是有限的。而任意数据都可以计算出一个哈希值，计算哈希的过程，相当于无限集到有限集的映射。因此哈希值相同，对应的原始数据不一定相同，如果不同，则称这两段数据存在哈希碰撞，实际应用中认为这是小概率事件(数学意义上的”不可能事件”)，优秀的哈希算法都是碰撞率极低的。
• 哈希算法是单向算法，无法通过哈希值，计算出原始数据，这一点非常重要！

常见的哈希算法有: md5, sha1, sha256等，其中sha1长度为160bits，而sha256长度为256bits，二者相比，sha256的取值范围更大，因此碰撞和破解的概率更低，也就相对更安全。

签名算法

有了上面这两种算法作为基础，就可以组建一个签名和验证签名的体系了，如下图所示:

sign_verify.png

假如A要给B发送一段数据d，先对其签名：

• 计算d的哈希值h，并使用自己的私钥a 对 h 进行加密，得到的密文c就是签名

得到签名后，将数据d和签名c通过某种方式发送给B，此时B收到了数据d'以及签名c'，需要验证这段数据是否被篡改，以及是否是A发送的

• 计算d'的哈希值h'，使用A的公钥b将签名c'解密，得到h''。通过对比h'和h''是否一致，就可以知道数据或签名是否被篡改。并且，如果哈希值是匹配的，能够说明这段数据一定是由A签名并发出的

常见的签名算法：

• sha1WithRSAEncryption：先对数据计算sha1摘要，再对摘要进行RSA加密
• sha256WithRSAEncryption：先对数据计算sha256摘要，再对摘要进行RSA加密
• md5WithRSAEncryption：先对数据计算MD5摘要，再对摘要进行RSA加密

这里有小伙伴会问，为什么需要将明文数据先哈希一遍，然后再私钥加密，直接将明文数据加密不行吗？当然可以，直接加密明文，当然也可以验证数据的准确性。但是需要考虑性能，非对称加解密计算量大、耗性能，明文的数据量大，如果全部都加解密，耗时严重。所以先通过哈希算法，将数据量大的明文哈希为固定长度的短哈希值，降低非对称加密的计算量。

证书

上面这个例子中，任何需要接受A的消息的人都需要事先保存A的公钥。这样的方案存在一个很大的问题：如果B要接受来自很多不同来源的数据，不可能事先将所有来源的公钥都提前保存下来，并且这样无法适应来源变动(增加、删除、变更)等带来的变化。因此，一般会把公钥当做签名的一部分，随着数据一起分发，接收方不需要事先保存任何数据来源的公钥。

sign_verify1.png

但是这样会引入一个新的问题：如何知道数据中所携带的公钥就是否是发送者自己的公钥？想了解的同学还可以搜索中间人攻击。

为了解决这个问题，可以把公钥和所有者的信息保存在一个文件里，并让一个可信的第三者使用其私钥对这个文件进行签名，得到一个签了名的公钥文件，这个文件就叫做证书。

cert_struct.png

数据签名中的证书本身也是一段数据(公钥+所有者信息)以及其签名组成的。

CA

证书中的签名是简单签名，一般只有加密哈希值和签发者名称，不会再将签发者的证书包含在签名中，否则就陷入无限递归的死循环了。

此时我们还需要使用签发者的公钥验证这个证书的合法性。虽然需要多验证一步，但是这样一来，本地不再需要保存每个数据来源的公钥，只需要保存这个签发者的证书(公钥)即可，每个数据来源的证书都由这个可信的签发者进行签发，这个可信的签发者就被称为证书颁发机构(Certification Authority)，简称 CA。

向 CA 请求签发，获取证书流程如下图：

ca_request.png

接收者使用证书验证公钥流程如下图：

ca_verify.png

实际上，CA的证书可能也是由其他更高一级的CA进行签发的，这种情况会产生3级甚至3级以上的证书链，系统中只需要保存最高级CA的证书，中间CA的证书和信息提供者的证书依次进行递归校验即可。

总结

经过签名的数据，结构如下图：

data_all.png

发散

1. charles抓包的原理？如何防止charles抓包？

   1. 安装charles的CA证书并信任
   2. 证书固定

2. https中的ssl握手，是如何利用非对称加密算法的？

   1. 客户端发送“client hello”消息，该消息包含了客户端所支持的 TLS 版本和密码组合以供服务器进行选择，还有一个"client random"随机字符串。
   2. 服务器发送"server hello"消息对客户端进行回应，该消息包含了服务器选择的密码组合、"server random"随机字符串和数字证书（公钥）。
   3. 客户端收到消息后，先通过上述流程验证证书，确保对方的合法身份。确认无误后，客户端再次生成一个随机字符串并用服务器的公钥进行加密，得到"premaster secret (预主密钥)"。这个字符串是经过加密过的，只有对应的私钥才能解密。客户端使用client random + server random + premaster secret 生成秘钥KEY，用于后续的对称加密。
   4. 服务器使用私钥解密"premaster secret"。使用client random + server random + premaster secret 生成相同的秘钥KEY，用于后续的对称加密。

3. iOS开发中的常常用到的证书，导给其他开发者的时候，为什么仅仅传递CER证书文件不行，需要传递p12文件？

   1. CER证书仅仅包含公钥信息，不包含私钥信息。
   2. P12文件是一种使用PKCS＃12加密的数字证书，也被称为PKCS#12文件，它使用了公钥密码学标准（PKCS）中的第12个规范。P12文件它通常用于存储和传输加密的私钥、公钥和证书。