大话数字签名

序言

最近业界出台了一系列规定，要求部分业务须要进行数字签名，以便达到行业的合规要求。借此机会建设下公司的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. 客户端签名安全性比较差，只能经过按期更换密钥，增强客户端防御等手段增强，并且交互起来很是复杂。