大话数字签名

序言

最近业界出台了一系列规定，要求部分业务需要进行数字签名，以便达到行业的合规要求。借此机会建设下公司的PKI（Public Key Infrastructure）, 其核心是通过CA进行数字签名。通过此篇文章梳理下数字签名内容。

签名有两个作用：

• 不可伪造：别人不能冒充我签署某个文件；
• 不可抵赖：我不能抵赖我签署过这个文件；

生活中见到的很多都是手写签名，由于每个人的手写签名都是独一无二的，所以应用比较广泛，比如合同，借条等。

数字签名如果也要达到上述目的，也必须满足不可伪造和不可抵赖两个特性。用到的技术就是数字签名算法和消息摘要。

数字签名算法主要有三种：

• RSA：基于大整数分解问题；
• DSA：基于离散对数问题；
• ECDSA：基于椭圆曲线上的离散对数问题，DSA的一个变种；

此文不会探讨签名算法的原理，只是以此来应用。下面使用RSA来讲解如何进行签名来完成通信。

RSA：常见的非对称加密算法，使用一对密钥（一个是公钥，一个是私钥）来进行通信，其中公钥是公开的，任何人都可以得到，私钥由私人保管，不得公开或者遗失。

消息摘要：消息摘要是将消息通过Hash函数生成固定长度的唯一的字符串。有两个特点：

• 值唯一：不同的消息进行Hash得到摘要是不同的，而且能够确保唯一（不考虑Hash碰撞）；
• 过程不可逆：不能通过摘要反推得到消息明文。（不过MD5和SHA1都被攻破，SHA-2还没有）；

数字签名过程

我们通过一系列场景来展示下数字签名是如何生成的：

1. 用户A拥有两把密钥，一把公钥，一把私钥

2. 用户A将自己的公钥发给需要通信的人，私钥自己保存

3. 用户B想要跟用户A通信，写完信之后使用A的公钥进行加密，就可以达到保密效果

4. 用户A收到信之后，使用自己保存的私钥解密，就能看到信件内容。由于私钥只保存在用户A手中，只要不外泄，这封信就是安全的，即使这封信被别人截获，也无法解密

5. 用户A给用户B回信，决定使用 数字签名。 写完信之后使用Hash函数，形成信件的摘要（digest）

6. 然后，用户A使用私钥，对摘要进行加密，生成数字签名

7. 用户A将这个签名附在信件下面，一起发给用户B

8.用户B收到信件之后，取下数字签名，使用用户A的公钥解密，得到摘要。由此证明，这封信确实是用户A发出来的。也就是达到了 不可抵赖的效果

9. 用户B对信件本身使用Hash函数，将得到的结果，与上一步得到的摘要进行对比，如果两者一致，就证明这封信 未被修改过。

10. 用户C想获取用户A和B的信件，那么他可以使用自己的公钥体会用户A的公钥。此时，用户B实际拥有的是用户C的公钥，但是他以为这是用户A的公钥。因此用户C就可以冒充用户A，使用自己的私钥做成数字签名，写信给用户B，让用户B使用假的用户A公钥进行解密。

11. 如何解决这个问题？需要对用户A的公钥进行公证即可。用户A去找证书中心（certificate authority，简称CA）。证书中心使用自己的私钥，对用户A的公钥和用户A的基本信息进行加密，生成数字证书。

12. 用户A拿到数字证书，以后再给用户B写信，只要在签名的同时，附上数字证书即可。

实际应用

现在很多业务需要数字签名，但是很多都是在手机上进行办公，就要求在更换设备的时候可以也能方便的进行数字签名。

方案一

流程说明

生成证书阶段：

1. 服务端提供SDK工具包给用户用于生产公私钥对；

2. 用户私钥自己保存，向服务端提供用户信息、公钥等请求证书；

3. 服务端对用户进行校验，符合条件的向公有CA申请证书；

4. 公有CA返回用户证书

5. 服务端存储证书，然后返回证书给用户

生成签名阶段：

1. 用户使用自己保存的私钥对数字摘要进行加密生成签名，完全在本地进行；

2. 如果用户更换设备，由于无法获取私钥，只能重新生成新的公私钥对和证书；

方案分析

优点：用户自己存储私钥，安全性强。

缺点：用户在更换设备时，由于无法私钥分发，只能重新获取公私钥对，但是新的公钥需要公证，就需要生成新的证书，所以重新生成证书会增加成本。

方案二

公有CA可能会提供类似方案

流程说明

生成证书阶段

1. 用户提供基本信息请求证书；

2. 服务端校验用户，然后向公有CA请求生成证书；

3. 公有CA为用户生成公私钥对，同时对用户私钥分隔，将一半私钥存储在CA的云端，另一半私钥联通用户信息和用户公钥加密生成用户证书返回给服务端；

4. 服务端存储用户证书，同时返回证书给用户；

生成签名阶段

1. 用户通向公有CA请求另一半私钥；

2. 公有CA将另一半私钥发送给用户；

3. 用户使用私钥对数字摘要进行加密得到数字签名；

4. 如果更换设备，用户向公有CA重新获取CA；

5. 公有CA对用户进行权限校验之后返回带有一半私钥的证书；

6. 需要生成签名的时候重复步骤1-3；

方案分析

优点：

1. 用户在更换设备时候可以通过重新获取证书的方式进行数字签名，而不需要重新生成证书；

2. 证书虽然有私钥，但是保存的是非完整私钥；

3. 用户获取另一半私钥，网络传输的也是非完整私钥；

缺点：

1. 公有CA虽然将私钥分隔进行组装和传输，但是在公有CA云端存储了私钥，只是将私钥分成两部分进行存储而已；

2. 用户每次进行数字签名的时候都要向公有CA请求另一半私钥，如果大量用户同时进行签名的时候，并发会很高；

3. 加密私钥的key放到客户端和服务端都不安全；

4. 最重要的是，用户私钥存储在公有CA那边，企业无法控制；

行业可能方案

云端签名方案

流程说明

生成证书阶段

1. 用户提供信息请求数字证书；

2. 服务端进行用户校验，然后生成公私钥对，并对私钥进行加密存储；

3. 服务端使用用户信息、用户公钥等向公有CA申请证书；

4. 公有CA返回证书给服务端；

5. 服务端存储证书，并返回给用户证书；

生成签名阶段

1. 用户请求数字签名，APP端将待签名的数据生成数字摘要，将用户证书进行Hash，同时要求用户输入口令；

2. 服务端对校验口令对用户进行校验，同时比对数字证书，通过之后使用用户私钥对数字摘要生成签名返回给用户；

方案分析

优点：数字签名是在服务端进行，不涉及到用户私钥分发，服务端做好安全防护即可。

缺点：用户私钥是存储在服务端，并不下发到用户端。不知道是否符合法规。

客户端签名方案

流程说明

生成证书阶段

1. 用户提供信息请求数字证书；

2. 服务端进行用户校验，然后生成公私钥对，并对私钥进行加密存储；

3. 服务端使用用户信息、用户公钥等向公有CA申请证书；

4. 公有CA返回证书给服务端；

5. 服务端存储证书，并返回给用户证书；

生成签名阶段

1. 用户向服务的请求私钥；

2. 服务端进行权限校验，通过后返回加密私钥；

3. 用户通过SDK解密私钥；

4. 用户使用私钥加密数字摘要得到数字签名；

5. 如果更换设备，用户需要重新获取加密私钥；然后重复1-4过程；

方案分析

优点：用户在签名的时候不需要每次都要请求私钥；

缺点：

1. 用户私钥存储在服务端；

2. 加密私钥的key存储在客户端不安全，只能定期更换，这无形中会造成用户使用不方便；

总结：

1. 云端签名可以做到方便生成用户签名，而且在更换设备时基本无影响；服务端可以集中做好安全防护，但是需要用户信任服务端；如果互联网法规规定用户私钥需要保存在用户端，那么此方案不可用；

2. 客户端签名安全性比较差，只能通过定期更换密钥，加强客户端防护等手段加强，而且交互起来非常复杂。

转载于:https://juejin.im/post/5c35aa19e51d4551ea7f1644