大話數字簽名

zhangdp發表於2019-01-10

序言

最近業界出臺了一系列規定,要求部分業務需要進行數字簽名,以便達到行業的合規要求。藉此機會建設下公司的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. 客戶端簽名安全性比較差,只能通過定期更換金鑰,加強客戶端防護等手段加強,而且互動起來非常複雜。


相關文章