序言

最近業界出臺了一系列規定，要求部分業務需要進行數字簽名，以便達到行業的合規要求。借此機會建設下公司的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

總結

以上是生活随笔為你收集整理的大话数字签名的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。