大話數字簽名

序言

最近業界出臺了一系列規定，要求部分業務須要進行數字簽名，以便達到行業的合規要求。藉此機會建設下公司的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. 客戶端簽名安全性比較差，只能經過按期更換密鑰，增強客戶端防禦等手段增強，並且交互起來很是複雜。