數字加密簽名模塊

⑴ 數字簽名的加密方式是怎樣的原理

數字簽名（又稱公鑰數字簽名、電子簽章）是一種類似寫在紙上的普通的物理簽名，但是使用了公鑰加密領域的技術實現，用於鑒別數字信息的方法。一套數字簽名通常定義兩種互補的運算，一個用於簽名，另一個用於驗證。

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

公鑰加密系統允許任何人在發送信息時使用公鑰進行加密，數字簽名能夠讓信息接收者確認發送者的身份。當然，接收者不可能百分之百確信發送者的真實身份，而只能在密碼系統未被破譯的情況下才有理由確信。

• 鑒權的重要性在財務數據上表現得尤為突出。舉個例子，假設一家銀行將指令由它的分行傳輸到它的中央管理系統，指令的格式是(a,b)，其中a是賬戶的賬號，而b是賬戶的現有金額。這時一位遠程客戶可以先存入100元，觀察傳輸的結果，然後接二連三的發送格式為(a,b)的指令。這種方法被稱作重放攻擊。

• 完整性。傳輸數據的雙方都總希望確認消息未在傳輸的過程中被修改。加密使得第三方想要讀取數據十分困難，然而第三方仍然能採取可行的方法在傳輸的過程中修改數據。一個通俗的例子就是同形攻擊：回想一下，還是上面的那家銀行從它的分行向它的中央管理系統發送格式為(a,b)的指令，其中a是賬號，而b是賬戶中的金額。一個遠程客戶可以先存100元，然後攔截傳輸結果，再傳輸(a,b3)，這樣他就立刻變成百萬富翁了。

• 不可抵賴。在密文背景下，抵賴這個詞指的是不承認與消息有關的舉動（即聲稱消息來自第三方）。消息的接收方可以通過數字簽名來防止所有後續的抵賴行為，因為接收方可以出示簽名給別人看來證明信息的來源。

⑵ 什麼是郵件加密，什麼是數字簽名，提供了哪些方面的安全功能

郵件加密就是把郵件從明文轉換為密文的過程。數字簽名是一個加密的信息摘要，附加在消息後面，模擬文件中的親筆簽名或印章以保證文件的真實性。數字簽名是認證技術之一，認證主要包括三個方面：消息認證、數字簽名、身份認證。而加密和認證時是現代信息安全領域中常見的信息保護手段。

⑶ 數字簽名機制和簡單加密的區別是什麼

數字簽名機制和簡單加密的區別分別是：

數字簽名機制是：所謂數字簽名就是附加在數據單元上的一些數據，或是對數據單元所作的密碼變換。

這種數據或變換允許數據單元的接收者用以確認數據單元的來源和數據單元的完整性並保護數據，防止被人(例如接收者)進行偽造。

簡單加密是：簡單加密的基本過程，就是對原來為明文的文件或數據按某種演算法進行處理，使其成為不可讀的一段代碼，通常稱為「密文」。通過這樣的途徑，來達到保護數據不被非法人竊取、閱讀的目的。

簡單加密方式的種類有：

1、凱撒加密：凱撒密碼（Caesar）加密時會將明文中的每個字母都按照其在字母表中的順序向後（或向前）移動固定數目（循環移動）作為密文。

2、單表代換：隨機選取字母代替原來的字母順序表，故一共有26！-1種可能。

3、一次一密：一次一密亂碼本是一個大的不重復的真隨機密鑰字母集，這個密鑰字母集被寫在幾張紙上，並被粘成一個亂碼本。

4、柵欄加密法：柵欄加密法將明文分為若干欄（行），每個欄的字母數量相同與key相同，如meet me after party,首先罵我們去掉空格。

明文就變為meetmeafterparty。一共16個字母，key為4，則我們可以將其分為16/key=4欄，從上到下排列，每欄個字母個數為4。

⑷ 四、公鑰和私鑰，加密和數字簽名

本文涉及到支付寶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的， 千萬不要覺得訂單信息的加簽過程也可以放在客戶端完成 。

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

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

⑸ 數字證書、加密與數字簽名有什麼關系 急用…………

加密的方式分為：對稱加密（很常見，比如RSA）和非對稱加密（即公鑰和私鑰加密）。
非對稱加密的主要用途就是：密鑰交換（交換對稱加密的密鑰）和數字簽名。

數字簽名的作用主要是：確保發送的報文沒有被篡改。
數字簽名：
1、發送方A對發送的報文M生成一個摘要X1。（大多使用hash）
2、發送方A用自己的私鑰加密這個摘要X1。
3、接收方B對使用A的公鑰解開這個加密摘要，得到X1。
4、B對比一下接收到的報文M重新生成摘要X2.
如果一樣，說明報文M在傳遞過程沒有被修改，的確是A發送的。

而數字證書：就是包含發送方（比如一個網站）公鑰、發送方信息的一個文件，該文件被CA所認證過（CA對此進行了數字簽名），從而保證發送方是可信的。

⑹ 如何使用加密和數字簽名

用非常基本的詞彙說，加密是一種以密碼方式發送信息的方法。只有擁有正確密鑰的人才能解開這個信息的密碼。對於其他人來說，這個信息看起來就像是一系列隨機的字母、數字和符號。如果你要發送不應該讓其他人看的敏感信息時，加密是特別重要的。由於電子郵件是在互聯網上發送的，可能被攻擊者攔截，對敏感的信息增加一個額外的保護層是很重要的。 同數字簽名一樣，公共密鑰加密使用PGP等軟體，使用數學演算法轉換信息並且依靠公共和專用密鑰。但是，加密和數字簽名是有區別的，加密的目的是通過把信息翻譯成密碼秘密地隱藏內容。數字簽名的目的是完整性和身份識別性，驗證一個信息的發送者和指出內容沒有被修改。雖然加密和數字簽名能夠單獨使用，但是，你還可以對加密的信息採用數字簽名。 當你簽署一個信息時，你使用你的專用密鑰，任何有你的公共密鑰的人都能夠驗證這個簽名是合法的。當你加密一個信息的時候，你為接收你的信息的人使用這個公共密鑰，並且使用他或者她的專用密鑰解碼這個信息。用於人們要保持自己的專用密鑰的機密，並且使用口令保護這些密鑰，這個信息的接收者應該是惟一的能夠觀看這個信息的人。 1.獲得你要他能夠閱讀這個信息的人的公共密鑰。如果你從一個公共密鑰環得到這個密鑰，你可以直接與那個人取得聯系，使用密鑰驗證一系列有關的字母和數字是正確的指紋。 2.使用他們的公共密鑰加密這個電子郵件。大多數電子郵件客戶端軟體都有輕松進行這項工作的功能。 3.當這個人收到這個信息的時候，他或者她將能夠對這個信息解密。