公鑰加密數字簽名

『壹』 公鑰加密與數字簽名的聯系與區別

一、密鑰加密：密鑰加密也稱不對稱加密，其常用演算法是RSA、ElGamal。 不對稱加密演算法不對稱加密演算法使用兩把完全不同但又是完全匹配的一對鑰匙—公鑰和私鑰。在使用不對稱加密演算法加密文件時，只有使用匹配的一對公鑰和私鑰，才能完成對明文的加密和解密過程。加密明文時採用公鑰加密，解密密文時使用私鑰才能完成，而且發信方（加密者）知道收信方的公鑰，只有收信方（解密者）才是唯一知道自己私鑰的人。不對稱加密演算法的基本原理是，如果發信方想發送只有收信方才能解讀的加密信息，發信方必須首先知道收信方的公鑰，然後利用收信方的公鑰來加密原文；收信方收到加密密文後，使用自己的私鑰才能解密密文。顯然，採用不對稱加密演算法，收發信雙方在通信之前，收信方必須將自己早已隨機生成的公鑰送給發信方，而自己保留私鑰。由於不對稱演算法擁有兩個密鑰，因而特別適用於分布式系統中的數據加密。廣泛應用的不對稱加密演算法有RSA演算法和美國國家標准局提出的DSA。以不對稱加密演算法為基礎的加密技術應用非常廣泛。
二、數字簽名： 數字簽名技術是不對稱加密演算法的典型應用。數字簽名的應用過程是，數據源發送方使用自己的私鑰對數據校驗和或其他與數據內容有關的變數進行加密處理，完成對數據的合法「簽名」，數據接收方則利用對方的公鑰來解讀收到的「數字簽名」，並將解讀結果用於對數據完整性的檢驗，以確認簽名的合法性。數字簽名技術是在網路系統虛擬環境中確認身份的重要技術，完全可以代替現實過程中的「親筆簽字」，在技術和法律上有保證。在公鑰與私鑰管理方面，數字簽名應用與加密郵件PGP技術正好相反。在數字簽名應用中，發送者的公鑰可以很方便地得到，但他的私鑰則需要嚴格保密。通俗地說，就是A用自己的私鑰機密，B用A的公鑰解密來確定是否是A發送的。

可是實際的情況是，用雙鑰密碼體制加密消息非常慢，單鑰加密比雙鑰加密要快1000倍，所以實際應用中，不是直接加密消息，而是先通過散列函數處理消息，得到消息摘要，然後用雙鑰密碼體制中的私鑰來加密這個消息摘要，就得到了數字簽名。
三、兩者的區別：密鑰加密是用來數據加密與解密的一種手段，增強了密文的安全性。而數字簽名是一種類似寫在紙上的普通的物理簽名，但是使用了公鑰加密領域的技術實現，用於鑒別數字信息的方法。一套數字簽名通常定義兩種互補的運算，一個用於簽名，另一個用於驗證。
四、從兩者的定義及兩者的區別中，我們也可以看出兩者之間的聯系其實也是很緊密的。在公鑰加密的基礎上附加數字簽名，不僅保證了密文的安全性，同時也可以驗證密文是否由真實的發送方發送的，從而做到不輕易被解密。數字簽名僅僅只能保證消息的來源，卻不能加密消息本身，而公鑰加密恰恰彌補了這一缺陷。兩者的關系，簡單地說，這就類似一封寫好的信和一個簽上了名字的信封一樣。

『貳』 電子合同數字簽名中的公鑰加密是什麼意思

每個人都有一對「鑰匙」（數字身份），其中一個只有她/他本人知道（密鑰），另一個公開的（公鑰）。
簽名的時候用密鑰，驗證簽名的時候用公鑰。
又因為任何人都可以落款聲稱她/他就是你，因此公鑰必須向接受者信任的人（身份認證機構）來注冊。注冊後身份認證機構給你發一數字證書。
對文件簽名後，你把此數字證書連同文件及簽名一起發給接受者，接受者向身份認證機構求證是否真地是用你的密鑰簽發的文件。

『叄』 「數字簽名技術採用的是公鑰體制,它是用私鑰進行加密」的對不

對。
公鑰體制是數字簽名的基礎，數字簽名就是使用數字證書的私鑰對數據的摘要加密，以保證數據的完整性、真實性和不可抵賴。

『肆』 什麼是數字簽名 數字簽名的介紹

1、數字簽名（又稱公鑰數字簽名）是只有信息的發送者才能產生的別人無法偽造的一段數字串，這段數字串同時也是對信息的發送者發送信息真實性的一個有效證明。

2、它是一種類似寫在紙上的普通的物理簽名，但是使用了公鑰加密領域的技術來實現的，用於鑒別數字信息的方法。一套數字簽名通常定義兩種互補的運算，一個用於簽名，另一個用於驗證。數字簽名是非對稱密鑰加密技術與數字摘要技術的應用。

『伍』 公鑰加解密、數字簽名、CA證書簡介

本文對信息安全領域中的公鑰加密、數字簽名、CA證書技術進行初步介紹。

如圖：

Source:

issuePublicKey.dia

由圖可知，A與B各自持有自己的私鑰，並對外發布自己的公鑰；導致雙方擁有對方的公鑰。

關鍵在於：發送者是否真的將內容發送給了正確的接收者。

如圖：

Source:

rsa_encrypt_decrypt.dia

由圖可知：

問題：發送者A需要為整個信件加密，過程緩慢。

關鍵在於：接收者接受的是否真的是發送者是本人發送的信息。

為確保B從正確的來源收到數據A。

如圖：

Source:

ca.dia

問題：發送者A的公鑰，可能是偽造的。

前面只介紹了公鑰加密與數字簽名兩個基本的技術。而CA才能確保這些技術更為實用，這里將用具體例子的方式，來逐步對它們進行講述。

發送者a：發送信件給b。

接受者b:

發送者a：

接收者b：

註：信件經過公鑰加密得到密文，密文只能通過與公鑰配對兒的私鑰才能解密還原為信件。

發送者a：

接收者b：

註：信件通過hash生成摘要，摘要用私鑰加密生成簽名；簽名只能通過與私鑰配對兒的公鑰才能解密回摘要，再次計算信件摘要與之匹配才算成功。

發送者a：

接收者b：

註：權威機構用權威私鑰將發送者公鑰及其它信息加密生成證書；用眾所周知的權威機構公鑰解密證書得到發送方公鑰進而可靠地驗證簽名。

『陸』 大多數使用公鑰密碼進行加密和數字簽名的產品及標准使用的都是

RSA演算法。RSA系統是公鑰系統的最具有典型意義的方法，大多數使用公鑰密碼進行加密和數字簽名的產品和標准使用的都是RSA演算法。公鑰：相當於錢包的地址，可理解成銀行賬戶。擁有私鑰，可以算出公鑰，擁有公鑰卻不能算出私鑰。

『柒』 公鑰密碼體系的數字簽名的原理是什麼

原理？首先公鑰體系你明白吧？用私鑰加密的內容只有公鑰能解密。
那麼數字簽名就是將需要簽名的內容進行散列（一般是SHA演算法）後用私鑰加密，得到數字簽名。
驗證簽名就是將內容進行散列後與附帶的數字簽名用公鑰解密的結果做比較，如果一致，則說明內容未被篡改過。

『捌』 四、公鑰和私鑰，加密和數字簽名

本文涉及到支付寶SDK的內容，均摘自支付寶開放平台。

因為支付寶SDK使用RSA來加密和生成數字簽名，所以本文中涉及到的概念也都是針對於RSA的。

一對兒密鑰生成後，會有公鑰和私鑰之分，我們需要把私鑰保存下來，而把公鑰發布出去。一對兒公鑰和私鑰，不能由其中一個導出另一個。

比如使用支付寶SDK的時候，我們商戶端會生成一對兒密鑰A和B，A是私鑰，B是公鑰，支付寶也會生成一對兒密鑰C和D，C是私鑰，D是公鑰。我們商戶端需要把商戶端私鑰A保存下來，而把商戶端公鑰B發布出去給支付寶，支付寶需要把支付寶私鑰C保存下來，而把支付寶公鑰D發布出去給我們商戶端。

加密是指我們使用一對兒密鑰中的一個來對數據加密，而使用另一個來對數據解密的技術，需要注意的是公鑰和私鑰都可以用來加密，也都可以用來解密 ，並不是規定死了只能用公鑰加密私鑰解密，但是加解密必須是一對兒密鑰之間的互相加解密，否則不能成功。

加密的目的是為了保證數據的不可讀性，防止數據在傳輸過程中被截獲。

知道了加密這個概念，我們先看一下支付寶的加密過程，再引出數字簽名這個概念。接著第1小節的例子，當我們商戶端和支付寶互相發布了公鑰之後，我們商戶端手裡就有 商戶端私鑰 和 支付寶公鑰 兩個密鑰，支付寶手裡也有 商戶端公鑰 和 支付寶私鑰 兩個密鑰。現在假設我們商戶端要給支付寶傳輸訂單信息，那麼為了保證傳輸訂單信息時數據的安全性，結合我們商戶端手裡所擁有的密鑰，可以有兩套加密方案

貌似這兩套加密方案都能達到對訂單信息加密的效果，而且如果採用方案二，我們商戶端甚至只需要存儲支付寶公鑰這一個密鑰，都不用去申請一對兒商戶端的公私鑰來維護，支付寶也不用保存我們一堆商戶那麼多的商戶端公鑰了，這不是更簡單嗎，那為什麼支付寶開放平台讓我們採用的是方案一而不是方案二呢？下面來回答一下。

支付寶開放平台說明：當我們採用RSA（1024位密鑰）來加密的時候，支付寶分配給所有商戶的支付寶公鑰都是一樣的，即支付寶針對那麼多的商戶只負責維護一對兒支付寶公私鑰，這就意味著支付寶公鑰隨便什麼人拿到後都是一樣的；而當我們採用RSA2（2048位密鑰）來加密的時候，支付寶會分配給每個商戶單獨的一個支付寶公鑰，即支付寶為每一個的商戶單獨的維護一對獨立的支付寶公私鑰，當然一個商戶下的多個App的支付寶公鑰是一樣的。RSA是早就支持的，RSA2是最近才支持的。

知道了上面這段話，現在假設我們採用的是方案二，並且採用RSA加密（很多老業務並沒有使用RSA2加密），業務邏輯將會是下面這樣。

這就出問題了， RSA加密下，支付寶公鑰是公開發布的，而且所有的商戶用的都是同一個支付寶公鑰（上面聲明了RSA2加密下，支付寶才針對每個商戶維護了一對兒公私鑰），攻擊者很容易就能獲取到，而 notify_url 也很容易被截獲，那攻擊者拿到這兩個東西就可以做和商戶一樣的操作來發起支付請求，這樣就會一直給小明充錢了。

所以 支付寶就需要確認支付請求確實是商戶發給他們的，而不是攻擊者發給他們的。 這就用到了 數字簽名 ，我們會通過方案一的實現流程來引出數字簽名的具體概念。如果我們採用的是方案一，我們商戶端保存的就是商戶端私鑰和支付寶公鑰，而支付寶保存的就是需要存著商戶端公鑰和支付寶私鑰的，業務邏輯將會是下面這樣。

這樣就可以保證交易的安全性了，我們也可以看出使用支付寶SDK保證交易的安全性注重的其實不是訂單信息是否加密，而是如何確保商戶端和支付寶能夠互相確認身份，訂單信息是明文的，但是後面拼接了數字簽名。

數字簽名其實就是明文數據加密之後得到的一個密文，只不過它是用私鑰加密生成的而已，我們一般會把數字簽名拼接在明文數據後面一起傳遞給接收方，接收方收到後用公鑰解密數字簽名，從而驗證發送方的身份、以及明文數據是否被篡改。數字簽名的生成過程其實就是一個加密過程，數字簽名的驗簽過程就是一個解密過程。

數字簽名的目的有兩個：一、發送方和接收方互相驗證身份；二、驗證數據是否被篡改。

從上面第一部分我們知道為了確保商戶和支付寶交易的安全性，約定採用的是給訂單信息加數字簽名傳輸的方式。支付寶也為我們提供了 一鍵生成RSA密鑰的工具 ，可以幫助我們很快的生成一對商戶端公私鑰。以下會對支付寶SDK的支付流程做個大概的解釋，並點出實際開發中我們使用支付寶SDK時應該注意的地方。

由我們商戶端自己生成的RSA私鑰（必須與商戶端公鑰是一對），生成後要保存在服務端，絕對不能保存在客戶端，也絕對不能從服務端傳輸給客戶端。

用來對訂單信息加簽，加簽過程一定要在服務端完成，絕對不能在客戶端做加，客戶端只負責用加簽後的訂單信息調起支付寶來支付。

由我們商戶端自己生成的RSA公鑰（必須與商戶端私鑰是一對），生成後需要填寫在支付寶開放平台。

用來給支付寶服務端驗簽經過我們加簽後的訂單信息，以確保訂單信息確實是我們商戶端發給支付寶的，並且確保訂單信息在傳輸過程中未被篡改。

這個和我們就沒關系了，支付寶私鑰是他們自己生成的，也是他們自己保存的。

用來對支付結果進行加簽。

支付寶公鑰和支付寶私鑰是一對，也是支付寶生成的，當我們把商戶端公鑰填寫在支付寶開放平台後，平台就會給我們生成一個支付寶公鑰，我們可以復制下來保存在服務端，同樣不要保存在客戶端，並且不要傳輸給客戶端。

用來讓服務端對支付寶服務端返給我們的同步或非同步支付結果進行驗簽，以確保支付結果確實是由支付寶服務端返給我們服務端的，而且沒有被篡改，對支付結果的驗簽工作也一定要在服務端完成。

上面已經說過了： 訂單信息的加簽和支付結果的驗簽是一定要在服務端做的，絕對不能在客戶端做。

下面是在客戶端對訂單信息加簽的過程，僅僅是為了模擬服務端來表明訂單信息是如何通過加簽最終轉變為orderString的， 千萬不要覺得訂單信息的加簽過程也可以放在客戶端完成 。

假設我們服務端收到了來自支付寶服務端的支付結果，即： 支付結果+數字簽名 。

那麼我們服務端就會對支付結果進行驗簽，怎麼個驗法呢？