数字签名（digital signature）技术介绍

本文主要介绍数字签名（digital signature）技术的相关知识。

1 概述

1.1 What

数字签名（又称公钥数字签名、电子签章），是一种类似写在纸上的、普通的物理签名，只不过数字签名使用公钥加密领域的技术实现，数字签名属于鉴别数字信息的方法。一套数字签名通常定义两种互补的运算：一个运算用于签名，另一个运算用于验证签名（验签）。

数字签名，就是只有信息的发送者才能产生的、别人无法伪造的一段数字串，这段数字串是对信息发送者所发送信息真实性的一个有效证明。

数字签名是非对称密钥加密技术与数字摘要技术的应用。

数字签名文件的完整性是很容易验证的（不需要骑缝章、骑缝签名，也不需要笔迹专家），而且数字签名具有不可抵赖性（不需要笔迹专家来验证）。

简单地说，所谓数字签名，就是附加在数据单元上的一些数据，或者是对数据单元所做的密码变换，通过使用这些数据或变换，数据单元的接收者能够确认数据单元的来源、数据单元的完整性，并且（这些数据或变换）保护数据、防止被人（例如接收者）进行伪造。

数字签名是对电子形式的消息进行签名的一种方法，一个签名消息能在通信网络中传输。

尽管基于公钥密码体制和私钥密码体制都可以获得数字签名，不过目前主要是基于公钥密码体制的数字签名。

2.2 应用场景

数字签名技术的应用场景较多，在此介绍几种常见的应用场景。

2.2.1 应用场景1

通过使用数字签名技术，将摘要信息（数字摘要是将任意长度的消息变成固定长度的短消息，这里描述的是对原文使用 HASH 函数生成的一个摘要信息）使用发送者的私钥加密，与原文一起发送给接收者。接收者通过发送者的公钥解开被加密的摘要信息，同时使用 HASH 函数对收到的原文生成一个摘要信息，然后对比这两份摘要信息：如果对比结果相同，则说明收到的信息是完整的，即信息在传输过程中没有被修改；否则，则说明信息被修改过。所以说数字签名能够验证信息的完整性。

数字签名是个加密的过程，数字签名验证（验签）是个解密的过程。

2.3 作用

数字签名的作用是：保证信息传输的完整性、进行信息发送者的身份认证、防止交易中的抵赖发生。

2 示例

2.1 示例1

继承另一篇非对称加密算法文章：为了确保通信中的一方得到的公钥 K2 确实是通信另一方发布的公钥 K2（而不是中间人 mim 伪造的公钥 K2），数字签名技术应运而生。

下面通过示例演示，介绍数字签名的相关知识。

2.1.1 使用数字签名生成CRT

生成 CRT 的过程如下：

1. 小红把自己的公钥 K2 和 ID（身份证号码，或者域名）合成为身份证申请（certificate signing request，CSR），如下：

小红的CSR = 小红公钥K2 + 小红域名

2. 小红把自己的 CSR 发给一个德高望重的人（称为 CA，即 certificate authority），比如小亮；

3. 小亮用自己的私钥 K1 加密小红的 CSR，得到的密文被称为数字签名（digital signature，下面简称 signature），如下：

小亮的signature = E(小红的CSR, 小亮的私钥K1)

4. 小亮把 signature 和小红的 CSR 的明文合在一起，称作经过 CA 签署的身份证（CA signed certificate，CRT），发给小红，成为了小红的CRT，如下：

小红的CRT = 小红的CSR + 小亮的signature

说明：单纯的 CSR 都是明文的，因为 CSR 只是公钥和 ID 的组合。

2.1.2 根据数字签名进行认证

在上面生成了小红的 CRT 后，如果小明要与小红聊天，过程如下：

1. 小明想要与小红聊天（建立 HTTPS 连接）时，小红出示了自己的 CRT，该 CRT 是经过小亮（CA）签署的； 

2. 小明拿到了小红的 CRT 后，看到了这个 CRT 是经过小亮签署的，因为小亮很权威，小明是相信小亮的（小明预先在自己的机器上安装了小亮的身份证 CRT。这里小亮的身份证 CRT 是小亮对外公布的，其实是一个自签名的 CRT）；

3. 小明从小亮的身份证 CRT 中获取小亮的 CSR，再从小亮的 CST 中提取小亮的公钥 K2。如下：

小亮的公钥K2 = 小亮的CRT中的CSR（明文）中的公钥K2

4. 小明用提取的小亮的公钥 K2，解密小红 CRT 中小亮的 signature，得到了小红的 CSR'。如下：

小红的CSR' = D(CRT中小亮的signature, 小亮的公钥K2)

5. 如果第 4 步中得到的这个小红的 CSR' 和小红 CRT 中的 CSR（明文）一致，则说明“这个小红的 CRT 是经过小亮确认过并且签名的，所以这个小红的 CRT 是可信的”。如下：

if 小红的CSR' == 小红的CRT中的小红的CSR（明文），则小红的CRT可信

6. 所以，既然小红的 CRT 是可信的，小明就可以获取小红 CRT 中的 CSR 中的小红的公钥 K2，进行后续通信了。

2.1.3 Who is CA

从上述过程中可以看出，任何人或机构都可以作为 CA，只要他愿意公开自己的公钥 K2（通过自签名、提供自己的 CRT 的方式），那么他就可以用自己的私钥去加密别人的 CSR（生成 signature），签署生成别人的 CRT。

如果 CA 不可靠，那就没有办法了，很多操作系统（Windows、Mac OS X）和浏览器（Chrome、Firefox、IE）会内置一些可靠的 CA 的身份证，我们可以从这些可靠的 CA 的身份证中获取该 CA 的公钥 K2，如果后面遇到了该 CA 签署的别人的身份证，那么就可以通过该 CA 的公钥 K2 验证那个人的身份证是否可信了。

2.1.4 信任链

在上文中，CA 小亮如果担心没人相信自己是个权威的 CA，那么可以找一个大家都相信的 CA（比如老王），然后让老王对小亮的 CRT 进行签名，如下：

小亮的CSR = 小亮的公钥K2 + 小亮的域名
老王的signature = E(小亮的CSR, 老王的私钥K1)
小亮的CRT = 小亮的CSR（明文） + 老王的signature

经过上述步骤后，如果浏览器或者操作系统中安装了老王的公钥 K2（可以从老王的自签名 CRT 中获取），则可以验证“小亮的身份证 CRT 是老王确认并且签名过的”。

此时，小亮在签署小红的 CRT 时，可以在小红的 CRT 后面附上小亮的 CRT，这样小红的 CRT 就有“两页”了。

当小明和小红通信时，过程如下：

1. 小红出示自己的 CRT，该 CRT 是经过小亮认证的，而小亮的 CRT 又是经过老王认证的；

2. 小明虽然不信任小亮，但是因为信任老王，所以小明先用老王的公钥 K2 来验证小红 CRT 中附带的小亮的 CRT；

3. 经过验证，小明信任了小亮；

4. 然后，小明再用小亮的公钥 K2 来验证小红的 CRT；

5. 最终，小明信任了小红。

要是怕小明连自己也不信任，老王可以再找一个小明信任的人来签名自己的身份证。这个过程可以不断递推，从而形成一条信任链（trust of chain）。

2.1.5 根CA和自签名

前面介绍了信任链，不过信任链总会有个顶端，即最后一个签名者（CA），这个最后的签名者被称为根 CA（root CA）。

根 CA 对应的 CRT 称为根身份证，根身份证是由根 CA 自己签名的。

实际上，我们每个人都可以自己签名认证自己的身份证，得到自签名的身份证（self-signed certificate）。生成自签名身份证的过程如下：

1. 生成一对秘钥：公钥 K2 和私钥 K1；

2. 创建自己的 CSR；

3. 用自己的秘钥 K1 加密 CSR，得到 signature；

4. 最后，把自己的 CSR（明文）和 signature 一起发布，生成自己的 CRT。

任何人，只要相信我们的自签名 CRT，就可以用我们的 CRT 中的 CSR 中的公钥 K2 加密传送给我们的信息，然后我们就可以通过私钥 K1 来解密。

在 2.1.4 节的示例中，如果老王是根 CA，那么身份证信任链如下：

【小红的 CRT】

小红的CSR = 小红公钥K2 + 小红域名
小亮的signature = E(小红的CSR, 小亮的私钥K1)
小红的CRT = 小红的CSR（明文） + 小亮的signature

【小亮的 CRT】

小亮的CSR = 小亮的公钥K2 + 小亮域名
老王的signature = E(小亮的CSR, 老王的私钥K1)
小亮的CRT = 小亮的CSR（明文） + 老王的signature

【老王的 CRT】

老王的CSR = 老王的公钥K2 + 老王的域名
老王的signature = E(老王的CSR, 老王自己的私钥K1)   --- 根CA，自签名
老王的CRT = 老王的CSR（明文） + 老王的signature