序言

最近業(yè)界出臺了一系列規(guī)定，要求部分業(yè)務(wù)需要進行數(shù)字簽名，以便達到行業(yè)的合規(guī)要求。借此機會建設(shè)下公司的PKI（Public Key Infrastructure）, 其核心是通過CA進行數(shù)字簽名。通過此篇文章梳理下數(shù)字簽名內(nèi)容。

簽名有兩個作用：

• 不可偽造：別人不能冒充我簽署某個文件；
• 不可抵賴：我不能抵賴我簽署過這個文件；

生活中見到的很多都是手寫簽名，由于每個人的手寫簽名都是獨一無二的，所以應用比較廣泛，比如合同，借條等。

數(shù)字簽名如果也要達到上述目的，也必須滿足不可偽造和不可抵賴兩個特性。用到的技術(shù)就是數(shù)字簽名算法和消息摘要。

數(shù)字簽名算法主要有三種：

• RSA：基于大整數(shù)分解問題；
• DSA：基于離散對數(shù)問題；
• ECDSA：基于橢圓曲線上的離散對數(shù)問題，DSA的一個變種；

此文不會探討簽名算法的原理，只是以此來應用。下面使用RSA來講解如何進行簽名來完成通信。

RSA：常見的非對稱加密算法，使用一對密鑰（一個是公鑰，一個是私鑰）來進行通信，其中公鑰是公開的，任何人都可以得到，私鑰由私人保管，不得公開或者遺失。

消息摘要：消息摘要是將消息通過Hash函數(shù)生成固定長度的唯一的字符串。有兩個特點：

• 值唯一：不同的消息進行Hash得到摘要是不同的，而且能夠確保唯一（不考慮Hash碰撞）；
• 過程不可逆：不能通過摘要反推得到消息明文。（不過MD5和SHA1都被攻破，SHA-2還沒有）；

數(shù)字簽名過程

我們通過一系列場景來展示下數(shù)字簽名是如何生成的：

1. 用戶A擁有兩把密鑰，一把公鑰，一把私鑰

2. 用戶A將自己的公鑰發(fā)給需要通信的人，私鑰自己保存

3. 用戶B想要跟用戶A通信，寫完信之后使用A的公鑰進行加密，就可以達到保密效果

4. 用戶A收到信之后，使用自己保存的私鑰解密，就能看到信件內(nèi)容。由于私鑰只保存在用戶A手中，只要不外泄，這封信就是安全的，即使這封信被別人截獲，也無法解密

5. 用戶A給用戶B回信，決定使用 數(shù)字簽名。 寫完信之后使用Hash函數(shù)，形成信件的摘要（digest）6. 然后，用戶A使用私鑰，對摘要進行加密，生成數(shù)字簽名7. 用戶A將這個簽名附在信件下面，一起發(fā)給用戶B

8.用戶B收到信件之后，取下數(shù)字簽名，使用用戶A的公鑰解密，得到摘要。由此證明，這封信確實是用戶A發(fā)出來的。也就是達到了不可抵賴的效果9. 用戶B對信件本身使用Hash函數(shù)，將得到的結(jié)果，與上一步得到的摘要進行對比，如果兩者一致，就證明這封信未被修改過。

10. 用戶C想獲取用戶A和B的信件，那么他可以使用自己的公鑰體會用戶A的公鑰。此時，用戶B實際擁有的是用戶C的公鑰，但是他以為這是用戶A的公鑰。因此用戶C就可以冒充用戶A，使用自己的私鑰做成數(shù)字簽名，寫信給用戶B，讓用戶B使用假的用戶A公鑰進行解密。

11. 如何解決這個問題？需要對用戶A的公鑰進行公證即可。用戶A去找證書中心（certificate authority，簡稱CA）。證書中心使用自己的私鑰，對用戶A的公鑰和用戶A的基本信息進行加密，生成數(shù)字證書。

12. 用戶A拿到數(shù)字證書，以后再給用戶B寫信，只要在簽名的同時，附上數(shù)字證書即可。

實際應用

現(xiàn)在很多業(yè)務(wù)需要數(shù)字簽名，但是很多都是在手機上進行辦公，就要求在更換設(shè)備的時候可以也能方便的進行數(shù)字簽名。

方案一

流程說明

生成證書階段：

1. 服務(wù)端提供SDK工具包給用戶用于生產(chǎn)公私鑰對；

2. 用戶私鑰自己保存，向服務(wù)端提供用戶信息、公鑰等請求證書；

3. 服務(wù)端對用戶進行校驗，符合條件的向公有CA申請證書；

4. 公有CA返回用戶證書

5. 服務(wù)端存儲證書，然后返回證書給用戶

生成簽名階段：

1. 用戶使用自己保存的私鑰對數(shù)字摘要進行加密生成簽名，完全在本地進行；

2. 如果用戶更換設(shè)備，由于無法獲取私鑰，只能重新生成新的公私鑰對和證書；

方案分析

優(yōu)點：用戶自己存儲私鑰，安全性強。

缺點：用戶在更換設(shè)備時，由于無法私鑰分發(fā)，只能重新獲取公私鑰對，但是新的公鑰需要公證，就需要生成新的證書，所以重新生成證書會增加成本。

方案二

公有CA可能會提供類似方案

流程說明

生成證書階段

1. 用戶提供基本信息請求證書；

2. 服務(wù)端校驗用戶，然后向公有CA請求生成證書；

3. 公有CA為用戶生成公私鑰對，同時對用戶私鑰分隔，將一半私鑰存儲在CA的云端，另一半私鑰聯(lián)通用戶信息和用戶公鑰加密生成用戶證書返回給服務(wù)端；

4. 服務(wù)端存儲用戶證書，同時返回證書給用戶；

生成簽名階段

1. 用戶通向公有CA請求另一半私鑰；

2. 公有CA將另一半私鑰發(fā)送給用戶；

3. 用戶使用私鑰對數(shù)字摘要進行加密得到數(shù)字簽名；

4. 如果更換設(shè)備，用戶向公有CA重新獲取CA；

5. 公有CA對用戶進行權(quán)限校驗之后返回帶有一半私鑰的證書；

6. 需要生成簽名的時候重復步驟1-3；

方案分析

優(yōu)點：

1. 用戶在更換設(shè)備時候可以通過重新獲取證書的方式進行數(shù)字簽名，而不需要重新生成證書；

2. 證書雖然有私鑰，但是保存的是非完整私鑰；

3. 用戶獲取另一半私鑰，網(wǎng)絡(luò)傳輸?shù)囊彩欠峭暾借€；

缺點：

1. 公有CA雖然將私鑰分隔進行組裝和傳輸，但是在公有CA云端存儲了私鑰，只是將私鑰分成兩部分進行存儲而已；

2. 用戶每次進行數(shù)字簽名的時候都要向公有CA請求另一半私鑰，如果大量用戶同時進行簽名的時候，并發(fā)會很高；

3. 加密私鑰的key放到客戶端和服務(wù)端都不安全；

4. 最重要的是，用戶私鑰存儲在公有CA那邊，企業(yè)無法控制；

行業(yè)可能方案

云端簽名方案

流程說明

生成證書階段

1. 用戶提供信息請求數(shù)字證書；

2. 服務(wù)端進行用戶校驗，然后生成公私鑰對，并對私鑰進行加密存儲；

3. 服務(wù)端使用用戶信息、用戶公鑰等向公有CA申請證書；

4. 公有CA返回證書給服務(wù)端；

5. 服務(wù)端存儲證書，并返回給用戶證書；

生成簽名階段

1. 用戶請求數(shù)字簽名，APP端將待簽名的數(shù)據(jù)生成數(shù)字摘要，將用戶證書進行Hash，同時要求用戶輸入口令；

2. 服務(wù)端對校驗口令對用戶進行校驗，同時比對數(shù)字證書，通過之后使用用戶私鑰對數(shù)字摘要生成簽名返回給用戶；

方案分析

優(yōu)點：數(shù)字簽名是在服務(wù)端進行，不涉及到用戶私鑰分發(fā)，服務(wù)端做好安全防護即可。

缺點：用戶私鑰是存儲在服務(wù)端，并不下發(fā)到用戶端。不知道是否符合法規(guī)。

客戶端簽名方案

流程說明

生成證書階段

1. 用戶提供信息請求數(shù)字證書；

2. 服務(wù)端進行用戶校驗，然后生成公私鑰對，并對私鑰進行加密存儲；

3. 服務(wù)端使用用戶信息、用戶公鑰等向公有CA申請證書；

4. 公有CA返回證書給服務(wù)端；

5. 服務(wù)端存儲證書，并返回給用戶證書；

生成簽名階段

1. 用戶向服務(wù)的請求私鑰；

2. 服務(wù)端進行權(quán)限校驗，通過后返回加密私鑰；

3. 用戶通過SDK解密私鑰；

4. 用戶使用私鑰加密數(shù)字摘要得到數(shù)字簽名；

5. 如果更換設(shè)備，用戶需要重新獲取加密私鑰；然后重復1-4過程；

方案分析

優(yōu)點：用戶在簽名的時候不需要每次都要請求私鑰；

缺點：

1. 用戶私鑰存儲在服務(wù)端；

2. 加密私鑰的key存儲在客戶端不安全，只能定期更換，這無形中會造成用戶使用不方便；

總結(jié)：

1. 云端簽名可以做到方便生成用戶簽名，而且在更換設(shè)備時基本無影響；服務(wù)端可以集中做好安全防護，但是需要用戶信任服務(wù)端；如果互聯(lián)網(wǎng)法規(guī)規(guī)定用戶私鑰需要保存在用戶端，那么此方案不可用；

2. 客戶端簽名安全性比較差，只能通過定期更換密鑰，加強客戶端防護等手段加強，而且交互起來非常復雜。

轉(zhuǎn)載于:https://juejin.im/post/5c35aa19e51d4551ea7f1644

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。