加解密，加簽、驗簽也就這肥事（加簽驗簽加密解密）

前言：

ps:上圖有一處錯誤，右下角有一條線是N，指向的是不讀取內容

上圖省略了CA認證過程，直接提取到了密鑰對，Base64的過程已省略(關于Base64的底層原理，可參考標題3)。全文1.6w字，如果想全部了解，可能需要花一點時間，相信大家看完一定會有所收獲。

@TOC

1.非對稱加密

1.1簡介

非對稱加密技術，需要兩個秘鑰，公鑰和私鑰。公鑰和私鑰成對出現。

優點：安全性更高，公鑰是公開的，秘鑰是自己保存的，不需要將私鑰給別人。

缺點：加密和解密花費時間長、速度慢，只適合對少量數據進行加密。

常見算法有：RSA、ECC（移動設備用）、Diffie-Hellman、El Gamal、DSA（數字簽名用）等。

1.2.為何只能用公鑰進行加密、解簽，私鑰解密、加簽

加簽的目的：驗證信息的發送方是否正確，信息是否被其他人篡改。

之所以用發送方的私鑰加簽，是因為，即便信息被黑客攔截，黑客修改了信息，但是加簽需要用發送方的私鑰，黑客沒有發送方的私鑰，所以也無法生成正確的簽名，接收方驗簽就不用通過。

反之如果用接收方的公鑰加簽，如果信息被黑客攔截，黑客修改了信息，因為接收方的公鑰是公開的，黑客就可以重新生成新的簽名，替換原有的簽名，發送出去，接收方接收到信息，拿自己的公鑰校驗是通過的，所以接收方無法辨別信息是真正的發送方還是黑客發送過來的，這樣的加簽不能辨別信息是否被篡改過

加密的目的：保證信息的隱私，不被別人看到，只能讓接收方看到正確的信息。

之所以用接收方的公鑰加密，是因為，如果信息被黑客攔截，需要用接收方的私鑰來解密，黑客無法獲取接收方的私鑰，即便攔截了信息（情報），黑客也無法看到明文，只能看天書?了。

反之，如果用發送方的私鑰加密，如果信息被黑客攔截，因為發送方的公鑰是公開的，黑客就可以用發送方的公鑰解密密文獲得明文，這樣的加密所有的人都可以看到明文，不能保證信息的隱私。

1.3.公鑰與私鑰原理

2)鮑勃把公鑰送給他的朋友們----帕蒂、道格、蘇珊----每人一把。

3)蘇珊要給鮑勃寫一封保密的信。她寫完后用鮑勃的公鑰加密，就可以達到保密的效果。

4)鮑勃收信后，用私鑰解密，就看到了信件內容。這里要強調的是，只要鮑勃的私鑰不泄露，這封信就是安全的，即使落在別人手里，也無法解密。

5)鮑勃給蘇珊回信，決定采用"數字簽名"。他寫完后先用Hash函數，生成信件的摘要（digest）。

6)然后，鮑勃使用私鑰，對這個摘要加密，生成"數字簽名"（signature）。

7)鮑勃將這個簽名，附在信件下面，一起發給蘇珊。

8)蘇珊收信后，取下數字簽名，用鮑勃的公鑰解密，得到信件的摘要。由此證明，這封信確實是鮑勃發出的。

9)蘇珊再對信件本身使用Hash函數，將得到的結果，與上一步得到的摘要進行對比。如果兩者一致，就證明這封信未被修改過。

10)復雜的情況出現了。道格想欺騙蘇珊，他偷偷使用了蘇珊的電腦，用自己的公鑰換走了鮑勃的公鑰。此時，蘇珊實際擁有的是道格的公鑰，但是還以為這是鮑勃的公鑰。因此，道格就可以冒充鮑勃，用自己的私鑰做成"數字簽名"，寫信給蘇珊，讓蘇珊用假的鮑勃公鑰進行解密。

11)后來，蘇珊感覺不對勁，發現自己無法確定公鑰是否真的屬于鮑勃。她想到了一個辦法，要求鮑勃去找"證書中心"（certificate authority，簡稱CA），為公鑰做認證。證書中心用自己的私鑰，對鮑勃的公鑰和一些相關信息一起加密，生成"數字證書"（Digital Certificate）。

12)鮑勃拿到數字證書以后，就可以放心了。以后再給蘇珊寫信，只要在簽名的同時，再附上數字證書就行了。

13)蘇珊收信后，用CA的公鑰解開數字證書，就可以拿到鮑勃真實的公鑰了，然后就能證明"數字簽名"是否真的是鮑勃簽的。

1.4 CA證書

CA中心，又稱為數字證書認證中心，作為電子商務交易中受信任的第三方，專門解決公鑰體系中公鑰的合法性問題。CA中心為每個使用公開密鑰的用戶發放一個數字證書，數字證書的作用是證明證書中列出的用戶名稱與證書中列出的公開密鑰相對應。CA中心的數字簽名使得攻擊者不能偽造和篡改數字證書。

Ukey廠商，Ukey又稱USBKey，是數字證書的硬件載體。目前國內的UKey廠商有大明五洲、海泰、恒寶、中鈔、華大等。

業務系統需要在CA登記注冊獲取根證書，然后對根證書簽發給客戶的數字證書做校驗和解密。

1、證書DN，X.509證書使用DN（Distinct Name）來標識一個實體，其功能類似于我們平常使用的ID，可以在制證過程中和證書屬性中查看，如下圖所示

2、證書SN（Serial Number），證書序列號是證書的唯一標識。和DN的區別是，當發生換證、補發情況時，DN是相同的，而SN是不同的。

3、參考號和授權碼，這兩個字段用在證書下載過程中。

4、證書狀態有：未下載、激活、凍結和注銷。

5、頒發者，是證書的簽發證書DN，在證書驗證過程中需要驗證該屬性

如上圖所示，它分為兩個過程，第一個過程是簽發證書，它可以對數據進行簽名（不僅是傳輸的數據、公鑰及其包含的一些相關信息也可以看作是一段數據），第二個過程是驗證證書如下。

簽發證書的過程

撰寫證書元數據：包括 簽發人(Issuer)、地址、簽發時間、有效期 等，還包括證書持有者(Owner)基本信息，比如 DN(DNS Name，即證書生效的域名)、 Owner 公鑰 等信息

使用通用的 Hash 算法（如SHA-256）對證書元數據計算生成 數字摘要

使用 Issuer 的私鑰對該數字摘要進行加密，生成一個加密的數字摘要，也就是Issuer的 數字簽名

將數字簽名附加到數字證書上，變成一個 簽過名的數字證書

將簽過名的數字證書與 Issuer 的公鑰，一同發給證書使用者（注意，將公鑰主動發給使用者是一個形象的說法，只是為了表達使用者最終獲取到了 Issuer 的公鑰）

驗證證書的過程

證書使用者獲通過某種途徑（如瀏覽器訪問）獲取到該數字證書，解壓后分別獲得 證書元數據 和 數字簽名

使用同樣的Hash算法計算證書元數據的 數字摘要

使用 Issuer 的公鑰 對數字簽名進行解密，得到 解密后的數字摘要

對比 2 和 3 兩個步驟得到的數字摘要值，如果相同，則說明這個數字證書確實是被 Issuer 驗證過合法證書，證書中的信息（最主要的是 Owner 的公鑰）是可信的。

全世界的頂級 CA（Root CA） 就那么幾個，每天都有很多人要向它申請證書，它也忙不過來啊，怎么辦呢？它可以選擇繼續往下授權，向下一級授權，這樣我們就只要找一級/二級/三級 CA 申請證書即可。

比如一級 CA 讓 Root CA 來簽名認證，二級 CA 讓一級 CA 來簽名認證,Root CA 沒有人給他簽名認證，只能自己證明自己了，這個證書就叫「自簽名證書」或者「根證書」，我們必須信任它，不然證書信任鏈是走不下去的。

如下舉例來看我們的根、一級、二級等CA，如下是Chrome瀏覽器，打開的是百度的網址，前面有一個小鎖，我們點擊然后再點擊connection is secure,如下：

然后再點擊certificate is valid

點擊后可以看到如下內容：

該證書的層次關系為：

GlobalSign Root CA -> GlobalSign Organization Validation CA -> baidu.com

對其解釋：

end-user：即 baidu.com，該證書包含百度的公鑰，訪問者就是使用該公鑰將數據加密后再傳輸給百度，即在 HTTPS 中使用的證書

intermediates：即上文提到的頂級CA向下授權的中間CA，用來認證公鑰持有者身份的證書，負責確認 HTTPS 使用的 end-user 證書確實是來源于百度。這類 intermediates 證書可以有很多級。

root：可以理解為 頂級的CA，負責認證 intermediates 身份的合法性。

該證書鏈的認證過程可以簡要總結為如下：

為了獲取 end-user 的公鑰，需要獲取 end-user 的證書，因為公鑰就保存在該證書中

為了證明獲取到的 end-user 證書是可信的，就要看該證書是否被 intermediate 權威機構認證，等價于是否有權威機構的數字簽名

有了權威機構的數字簽名，而權威機構就是可信的嗎？需要繼續往上驗證，即查看是否存在上一級權威認證機構的數字簽名

信任鏈條的最終是Root CA，他采用自簽名，對他的簽名只能無條件的信任

2.對稱加密

2.1.簡介

圖片來自百度百科

采用單鑰密碼系統的加密方法，同一個密鑰可以同時用作信息的加密和解密，這種加密方法稱為對稱加密，也稱為單密鑰加密。

優點：

對稱加密算法的優點是算法公開、計算量小、加密速度快、加密效率高。

缺點：

對稱加密算法的缺點是在數據傳送前，發送方和接收方必須商定好秘鑰，然后使雙方都能保存好秘鑰。其次如果一方的秘鑰被泄露，那么加密信息也就不安全了。另外，每對用戶每次使用對稱加密算法時，都需要使用其他人不知道的獨一秘鑰，這會使得收、發雙方所擁有的鑰匙數量巨大，密鑰管理成為雙方的負擔。

常見的算法有：DES、3DES、Blowfish、IDEA、RC4、RC5、RC6和AES等。

它的缺點是非常明顯的，那么對稱加密有其用武之地嗎，答案肯定是有的，在傳輸大量數據的時候，它與非對稱加密配合著使用（即對稱+非對稱）

2.2.對稱+非對稱加密進行傳輸大量數據

我們可以先用對稱加密方式對需要傳輸的數據（優點：加密速度快、加密效率高）進行加密得到加密數據；

之后再把對稱加密方式中用到的密鑰（也就是步驟1中用到的密鑰）用非對稱加密方式進行加密（優點：安全性更高）得到加密后的密鑰;

組裝好步驟1得到的加密數據和步驟2得到的加密后的密鑰，然后發送給對方。

這樣二者想結合，就具備了加密速度快、加密效率高，安全性更高的特點，具體流程如下：

ps:上圖有一處錯誤，右下角有一條線是N，指向的是不讀取內容

3.Base64編碼底層原理

在開發中，我們經常會遇到使用Base64的場景，這里本人詳細闡述一下Base64的底層原理。

3.1.作用

按照RFC2045的定義，Base64被定義為：Base64內容傳送編碼被設計用來把任意序列的8位字節描述為一種不易被人直接識別的形式。（The Base64 Content-Transfer-Encoding is designed to represent arbitrary sequences of octets in a form that need not be humanly readable.） 傳輸8Bit字節代碼的編碼方式之一。

Base64是一種任意二進制到文本字符串的編碼方法，常用于在URL、Cookie、網頁中傳輸少量二進制數據。不是加密算法，只是無法直接看到明文?？梢酝ㄟ^打亂Base64編碼來達到類似加密的效果。

Base64就是一種基于64個可打印字符來表示二進制數據的方法，把一些不可打印的字符轉換成全部都是可打印的字符。

ps：關于ASCII編碼(含擴展ASCII)中，打印字符和不可打印字符：https://blog.csdn.net/MrYushiwen/article/details/107998062

3.2.Base64編碼轉換表（64個可打印字符）

總共64個可打印字符，從0開始到63結束。

3.3.Base64舉例說明全過程

關于這個編碼的規則：

把3個字節變成4個字節,6位為一組，高位補兩個0，組成一個字節，這樣十進制中正好從0到63

每76個字符加一個換行符。

最后的結束符也要處理。

Base64要求把每三個8Bit的字節轉換為四個6Bit的字節（3*8 = 4*6 = 24），然后把6Bit再添兩位高位0，組成四個8Bit的字節，也就是說，轉換后的字符串理論上將要比原來的長1/3。

ps：為什么每76個字符要加一個換行符，如下： RFC2045中有規定： The encoded output stream must be represented in lines of no more than 76 characters each. Base64一行不能超過76字符，超過則添加回車換行符。 “回車換行符（\r\n）”是在Windows才有，而Linux只有換行（\n），Mac只有回車（\r）。

把UTF-8編碼的abc進行base64編碼其具體過程如下：

UTF-8編碼的abc其底層用二進制表示為01100001 01100010 01100011

拆分，每六位一組：011000 010110 001001 100011

高位補兩個0：00011000，00010110，00001001 ， 00100011

查找base64編碼轉換表，00011000，00010110，00001001 ， 00100011十進制為：24，22，9，33，對于的字符為：YWJj

在1中的規則，第一條對于這個有稍微的變化，因為這個末尾差分6個為一組時，最后只有4個，怎么辦呢，先低位補0，補成6位，然后在高位補兩個0，組成一個字節，這樣十進制中正好從0到63

把UTF-8編碼的ab進行base64編碼其具體過程如下：

UTF-8編碼的ab其底層用二進制表示為01100001 01100010

拆分，每六位一組，末尾只有4位，先低位補0，補成6位：011000 010110 001000

高位補兩個0：00011000，00010110，00001000

查找base64編碼轉換表，00011000，00010110，00001000 十進制為：24，22，8對于的字符為：YWI

在舉例1中字節數量應該是3的倍數，如果這個條件不能滿足的話，具體的解決辦法是這樣的：剩余的字節根據編碼規則繼續單獨轉過程如上述所述，最后再用=號補滿4個字節。這就是為什么有些Base64編碼會以一個或兩個等號結束的原因，但等號最多只有兩個。因為一個原字節至少會變成兩個目標字節，所以余數任何情況下都只可能是0，1，2這三個數中的一個。如果余數是0的話，就表示原文字節數正好是3的倍數（最理想的情況）。如果是1的話，轉成2個Base64編碼字符，為了讓Base64編碼是4的倍數，就要補2個等號；同理，如果是2的話，就要補1個等號。

補一個=號，最后結果為：YWI=

3.4.關于URL的改進Base64編碼

標準的Base64并不適合直接放在URL里傳輸，因為URL編碼器會把標準Base64中的“/”和“+”字符變為形如“%XX”的形式，而這些“%”號在存入數據庫時還需要再進行轉換，因為ANSI SQL中已將“%”號用作通配符。

為解決此問題，可采用一種用于URL的改進Base64編碼，它在末尾填充’='號，并將標準Base64中的“+”和“/”分別改成了“-”和“_”，即把 二.base64編碼轉換表（64個可打印字符）中的62和63對應的字符改成了-和_ ;這樣就免去了在URL編解碼和數據庫存儲時所要作的轉換，避免了編碼信息長度在此過程中的增加，并統一了數據庫、表單等處對象標識符的格式。

4.關于OpenSSL、Keytool生成密鑰對

4.1簡介：

OpenSSL：

OpenSSL是一個開放源代碼的軟件庫包，應用程序可以使用這個包來進行安全通信，避免竊聽，同時確認另一端連接者的身份。

即OpenSSL是一個功能豐富且自包含的開源安全工具箱。它提供的主要功能有：SSL協議實現(包括SSLv2、SSLv3和TLSv1)、大量軟算法(對稱/非對稱/摘要)、大數運算、非對稱算法密鑰生成、ASN.1編解碼庫、證書請求(PKCS10)編解碼、數字證書編解碼、CRL編解碼、OCSP協議、數字證書驗證、PKCS7標準實現和PKCS12個人數字證書格式實現等功能。

keytool ：

JDK自帶的Keytool，它是個密鑰和證書管理工具。它使用戶能夠管理自己的公鑰/私鑰對及相關證書，用于（通過數字簽名）自我認證（用戶向別的用戶/服務認證自己）或數據完整性以及認證服務。在JDK 1.4以后的版本中都包含了這一工具，它的位置為“%JAVA_HOME%\bin\keytool.exe”。

為節省時間本人只講解了如何使用了keytool去生成密鑰對，即4.3章節的內容；關于使用OpenSSL軟件庫包生成密鑰對參考了網上的該篇博客：

即

4.2章節中以下內容來自該篇博文：https://www.cnblogs.com/linjiqin/p/11133435.html

4.2OpenSSL生成密私鑰、公鑰(非CA認證的公鑰)過程(PKCS#8編碼)：

下面將介紹在Linux系統下生成公私鑰，當然也可以使用其他開源平臺提供的已編輯好的工具。

我們主要了解其過程，幫助我們知道公私鑰是怎么來的。

ps：4.2章節中以下內容來自該篇博文：https://www.cnblogs.com/linjiqin/p/11133435.html

當前使用的是Linux系統，已經安裝OpenSSL軟件包。

如下演示用OpenSSL軟件包生成RSA算法的密鑰對。

1、執行命令openssl version -a 驗證機器上已經安裝openssl

$ openssl version -a

2、生成私鑰

這條命令讓openssl隨機生成一份私鑰，加密長度是1024位。加密長度是指理論上最大允許”被加密的信息“長度的限制，也就是明文的長度限制。隨著這個參數的增大（比方說2048），允許的明文長度也會增加，但同時也會造成計算復雜度的極速增長。一般推薦的長度就是2048位。

$ openssl genrsa -out rsa_private_key.pem 2048

運行結果：

生成私鑰文件：C:\Users\PC\rsa_private_key.pem，內容都是標準的ASCII字符，開頭一行和結尾一行有明顯的標記，真正的私鑰數據是中間的不規則字符。

-----BEGIN RSA PRIVATE KEY----- MIIEpAIBAAKCAQEAyF3lqF456UvWSyvj5iP5oS4hIprE1fUqR0hHXMHN48f/4ycj tAml3MSHHeE0j3cnutI5xh5WlZAKI1GLZwcZeg0WNDFiRP6pAdz32w== -----END RSA PRIVATE KEY-----

3、根據私鑰生成公鑰：C:\Users\PC\rsa_public_key.pem

$ openssl rsa -in rsa_private_key.pem -pubout -out rsa_public_key.pem

運行結果：

公鑰內容：

-----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyF3lqF456UvWSyvj5iP5 grP5WGPmTggfh6vo2NLdvAngk62UgAALdvokmM4xFs/qj8bDBQ8R2Wqvl3JsX/rd -----END PUBLIC KEY----

注意：此時的私鑰還不能直接被使用，需要進行PKCS#8編碼：

4、PKCS#8編碼：指明輸入私鑰文件為rsa_private_key.pem，輸出私鑰文件為pkcs8_rsa_private_key.pem，不采用任何二次加密（-nocrypt）

$ openssl pkcs8 -topk8 -in rsa_private_key.pem -out pkcs8_rsa_private_key.pem -nocrypt

C:\Users\PC\可以看到pkcs8_rsa_private_key.pem文件。

至此：可用的密鑰對已經生成好了，私鑰使用pkcs8_rsa_private_key.pem，公鑰采用rsa_public_key.pem

4.3JDK自帶的Keytool生成數字證書/.cer/.p12文件(PKCS#12)

秘鑰庫是存儲一個或多個密鑰條目的文件，每個密鑰條目應該以一個別名標識，它包含密鑰和證書相關信息。

如果使用"keytool -genkeypair"命令生成密鑰條目，則會生成一個密鑰對（公鑰和相關私鑰）并將公鑰包裝到X.509 v3自簽名證書中，該證書存儲為單個元素證書鏈，此證書鏈和私鑰存儲在以別名標識的密鑰庫條目中，條目類型為PrivateKeyEntry。

如果使用"keytool -genseckey"命令生成密鑰條目，則會生成一個密鑰并將其存儲在以別名標識的密鑰庫條目中，條目類型為SecretKeyEntry。

下面講解使用RSA算法，PKCS#12編碼生成數字證書，使用"keytool -genkeypair"命令生成密鑰條目：

cd進入JDK的bin目錄下：

輸入如下命令：

keytool -genkeypair -alias serverkey -keyalg RSA -keysize 2048 -validity 3650 -keystore D:\demo\p12test.keystore

參數解釋：

genkeypair：生成一對非對稱密鑰并將公鑰包裝到X.509 v3自簽名證書中；

alias 實體別名(包括證書私鑰)

dname 證書個人信息 keyalg 采用公鑰算法，默認是DSA，這里采用RSA keysize 密鑰長度(DSA算法對應的默認算法是sha1withDSA，不支持2048長度，此時需指定RSA)

validity 有效期

keystore 指定keystore文件儲存位置

執行后會要求我們輸入一些信息，如下：

注意點：

密鑰庫的密碼至少必須6個字符，可以是純數字或者字母或者數字和字母的組合等

名字與姓氏應該是輸入域名，而不是我們的個人姓名，其他的可以不填

如果創建默認類型(JKS)的密鑰庫，則可附加"-keypass"參數指定條目的密鑰口令，如果沒有指定則會在最后一步提示"輸入該條目的密鑰口令，如果與密鑰庫口令相同按回車"，一般設為與密鑰庫口令相同。如果創建PKCS12類型的密鑰庫，則會忽略條目的密鑰口令相關參數，因為PKCS12不支持設置密鑰庫條目密碼，默認它與密鑰庫密碼一致。

執行完上述命令后，在操作系統的指定目錄下生成了一個"p12test.keystore"的文件。

輸入如下命令：

keytool -list -v -keystore D:\demo\p12test.keystore

最后一行提示信息，我們可以執行一下，輸入完成后經過轉過的key就會生成，原來的key自動會有一個old的后綴，當然不轉換直接使用老的key也可以。

將密鑰庫p12test.keystore中別名為serverkey條目的相關信息以及公鑰導出到一個數字證書文件p12test.cer中，cmd命令如下：

keytool -exportcert -keystore D:\demo\p12test.keystore -file D:\demo\p12test.cer -alias serverkey

參數解釋：

export 表示證書導出操作

keystore 指定秘鑰庫文件

file 指定導出文件路徑

alias 密鑰庫中條目的別名

執行完成后生成如下文文件：

ps：該p12test.cer證書文件不包含私鑰。

Keytool -printcert -file D:\demo\p12test.cer

打印內容如下：

可以看到該數字證書中便只有對應的某個條目的相關信息了（對比4.3.2下的截圖）。

keytool -importkeystore -srckeystore D:\demo\p12test.keystore -destkeystore D:\demo\p12test.p12 -srcalias serverkey -destalias serverkey -srcstoretype jks -deststoretype pkcs12 -noprompt -destkeypass ysw123

生成如下文件：

當然p12證書也可以轉回cer格式的證書，這里不在繼續深入說明，我們只需要弄清楚它們之間的關系就行，想深入了解的同學可以自行查詢資料。

p12證書提取密鑰流程如下：

4.4關于ANS.1編碼規則

openssl的數據編碼規則是基于ans.1。

百度百科是這樣解釋的：ASN.1抽象語法標記（Abstract Syntax Notation One） ASN.1是一種 ISO/ITU-T 標準，描述了一種對數據進行表示、編碼、傳輸和解碼的數據格式。它提供了一整套正規的格式用于描述對象的結構，而不管語言上如何執行及這些數據的具體指代，也不用去管到底是什么樣的應用程序。它有兩部分：

數據描述語言標準：語言標準允許用戶自定義的基本數據類型，并可以通過簡單的數據類型組成更復雜的數據類型。

對于普通數據類型，我們將數據直接轉化成數據流進行傳輸即可；對于復雜數據格式，需要引入一個數字對象的概念，通過將復雜數據結構轉化成數據對象。

數據編碼規則：這些編碼方法規定了將數字對象轉換成應用程序能夠處理、保存、傳輸的二進制形式的一組規則。

也就是編碼解碼規則，有如下：

基本編碼規則（BER） -X.209 、規范編碼規則（CER）、識別名編碼規則（DER）、壓縮編碼規則（PER）和 XML編碼規則（XER）。

所以，ASN.1標準就是規定了把數據轉化成數據對象，又規定數據對象編碼為二進制流的方法。

openssl使用的是asn.1的DER編碼規則（識別名編碼規則），保證每個asn.1對象使用DER編碼獲得的二進制編碼是唯一的。

openssl使用pem作為基本的文件編碼格式，pem和der的關系如下圖所示，其中幾種加密環節是可選的：

可以看出openssl的pem編碼實際上就是在DER編碼規則（識別名編碼規則）的基礎上進行了Base64編碼，然后追加了頭部信息。

我們也可以使用openssl的相關指令進行DER與pem之間進行轉換。

在任何需要以數字方式發送信息的地方，ASN.1 都可以發送各種形式的信息（聲頻、視頻、數據等等）。ASN.1 和特定的 ASN.1 編碼規則推進了結構化數據的傳輸，尤其是網絡中應用程序之間的結構化數據傳輸，它以一種獨立于計算機架構和語言的方式來描述數據結構。

OSI 協議套中的應用層協議使用了 ASN.1 來描述它們所傳輸的 PDU，這些協議包括：用于傳輸電子郵件的 X.400、用于目錄服務的 X.500、用于 VoIP 的 H.323 和 SNMP。它的應用還可以擴展到通用移動通信系統（UMTS）中的接入和非接入層。

ASN.1的第一部分—數據描述語言標準，這個標準定義了一些基本的數據類型，如果我們使用到復雜的數據結構，asn.1還允許通過簡單數據類型組成復雜的數據類型(x.509)。

Java官方關于x.509的實現如下，大家感興趣可以自己點進源碼看一下，這里不深入討論。

4.5證書相關知識

PEM

PEM (Privacy Enhancement Message)，定義見 RFC1421。是一種基于 base64 的編碼格式，常見于 linux/unix 下的證書編碼

結構組成 == {header} body {tail}

示例

-----BEGIN PUBLIC KEY-----

MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDMYfnvWtC8Id5bPKae5yXSxQTt

+Zpul6AnnZWfI2TtIarvjHBFUtXRo96y7hoL4VWOPKGCsRqMFDkrbeUjRrx8iL91

4/srnyf6sh9c8Zk04xEOpK1ypvBz+Ks4uZObtjnnitf0NBGdjMKxveTq+VE7BWUI

yQjtQ8mbDOsiLLvh7wIDAQAB

-----END PUBLIC KEY-----

DER

DER (Distinguished Encoding Rules) , 定義見維基百科-ASN.1.DER，是來自ASN.1 體系的一種二進制編碼格式，常用于 windows/mac 的證書編碼

編碼方式 == DER uses a pattern of type-length-value triplets

PEM與DER的關聯

DER就是密鑰的二進制表述格式。

PEM格式就是對DER編碼轉碼為base64字符格式。通過base64解碼可以還原DER格式。

PEM 是明文格式，可以包含證書或者是密鑰；其內容通常是以類似 “—–BEGIN …—–” 開頭 “—–END …—–” 為結尾的這樣的格式進行描述的。因為DER是純二進制格式，對人不友好，所以一般都用PEM進行存儲。

1．X.209（1988）

ASN.1是描述在網絡上傳輸信息格式的標準方法。它有兩部分：第一部份（ISO 8824/ITU X.208）描述信息內的數據、數據類型及序列格式，也就是數據的語法；第二部分（ISO 8825/ITU X.209）描述如何將各部分數據組成消息，也就是數據的基本編碼規則。

ASN.1原來是作為X.409的一部分而開發的，后來才獨立地成為一個標準。這兩個協議除了在PKI體系中被應用外，還被廣泛應用于通信和計算機的其他領域。

2．X.500（1993）

X.500是一套已經被國際標準化組織（ISO）接受的目錄服務系統標準，它定義了一個機構如何在全局范圍內共享其名字和與之相關的對象。X.500是層次性的，其中的管理域（機構、分支、部門和工作組）可以提供這些域內的用戶和資源信息。在PKI體系中，X.500被用來惟一標識一個實體，該實體可以是機構、組織、個人或一臺服務器。X.500被認為是實現目錄服務的最佳途徑，但X.500的實現需要較大的投資，并且比其他方式速度慢;而其優勢具有信息模型、多功能和開放性。

3．X.509（1993）

X.509是由國際電信聯盟（ITU-T）制定的數字證書標準。在X.500確保用戶名稱惟一性的基礎上，X.509為X.500用戶名稱提供了通信實體的鑒別機制，并規定了實體鑒別過程中廣泛適用的證書語法和數據接口。

X.509的最初版本公布于1988年。X.509證書由用戶公共密鑰和用戶標識符組成。此外還包括版本號、證書序列號、CA標識符、簽名算法標識、簽發者名稱、證書有效期等信息。這一標準的最新版本是X.509 v3，它定義了包含擴展信息的數字證書。該版數字證書提供了一個擴展信息字段，用來提供更多的靈活性及特殊應用環境下所需的信息傳送。

以下是PKCS標準匯總，截圖來自百度百科，這里簡單了解一下即可。

常見的有三種X.509證書，PKCS#12證書和PKCS#7證書。

X.509證書：

它僅包含了公鑰信息而沒有私鑰信息。

X.509 DER 編碼(ASCII)的后綴是： .DER .CER .CRT

X.509 PAM 編碼(Base64)的后綴是： .PEM .CER .CRT

PKCS#7

簽名或加密。可以往里面塞x509，同時沒有簽名或加密內容。

PKCS#7可以封裝一個或者多個X.509證書或者PKCS#6證書，并且可以包含CRL信息。PKCS#7證書中也不包含私鑰信息。openssl提供了crl2pkcs7和pkcs7兩個指令來生成和處理PKCS#7文件，可以使用他們在X.509證書和PKCS#7證書之間進行轉換和處理

PKCS#7證書的后綴名是.p7b或.p7r 。

PKCS#8

PKCS#8標準是一個非常簡單的標準，它主要用于封裝私鑰和其他相關的屬性信息。一般來說，PKCS#8格式的私鑰都是被加密的，支持PKCS#5和PKCS#12標準定義的算法，當然，私鑰也可以不加密。PKCS#8標準一方面可以增強私鑰的安全性，另一方面也為用戶提供了一種簡單的確立信任關系的方式，這主要是基于私鑰特別名稱和最高層可信者的權威公鑰等屬性信息。

PKCS#12證書：

含有私鑰，同時可以有公鑰，有口令保護。

PKCS12證書可以包含一個或者多個證書，并且還可以包含證書對應的私鑰。openssl的pkcs12指令可以將X.509格式的證書和私鑰封裝成PKCS#12格式的證書，也可以將PKCS#12證書轉換成X.509證書。

PKCS#12證書的后綴名通常是p12或者pfx。

X509是基本規范

P7和P12是兩個實現規范，P7是數字信封，P12是帶有私鑰的證書規范。

它們之間可以進行相互轉換。

5.常見算法

5.1對稱加密算法

主要有DES算法，3DES算法，TDEA算法，Blowfish算法，RC5算法，IDEA算法。

這里進行簡單介紹一下基于“對稱密鑰”的加密算法。

基于“對稱密鑰”的加密算法主要有DES、TripleDES、RC2、RC4、RC5和Blowfish等。

對稱密鑰：DES TripleDES算法

DES算法把64位的明文輸入塊變為數據長度為64位的密文輸出塊，其中8位為奇偶校驗位，另外56位作為密碼的長度。首先，DES把輸入的64位數據塊按位重新組合，并把輸出分為L0、R0兩部分，每部分各長32位，并進行前后置換，最終由L0輸出左32位，R0輸出右32位，根據這個法則經過16次迭代運算后，得到L16、R16，將此作為輸入，進行與初始置換相反的逆置換，即得到密文輸出。

DES算法具有極高的安全性，到目前為止，除了用窮舉搜索法對DES算法進行攻擊外，還沒有發現更有效的辦法，而56位長密鑰的窮舉空間為2^56，這意味著如果一臺計算機的速度是每秒種檢測100萬個密鑰，那么它搜索完全部密鑰就需要將近2285年的時間，因此DES算法是一種很可靠的加密方法。

對稱密鑰：RC算法

RC4算法的原理是“攪亂”，它包括初始化算法和偽隨機子密碼生成算法兩大部分，在初始化的過程中，密鑰的主要功能是將一個256字節的初始數簇進行隨機攪亂，不同的數簇在經過偽隨機子密碼生成算法的處理后可以得到不同的子密鑰序列，將得到的子密鑰序列和明文進行異或運算（XOR）后，得到密文。

由于RC4算法加密采用的是異或方式，所以，一旦子密鑰序列出現了重復，密文就有可能被破解，但是目前還沒有發現密鑰長度達到128位的RC4有重復的可能性，所以，RC4也是目前最安全的加密算法之一。

對稱密鑰：BlowFish算法 [1]

BlowFish算法是一個64位分組及可變密鑰長度的分組密碼算法，該算法是非專利的。

BlowFish算法使用兩個“盒”：pbox[18]和sbox[4256]，BlowFish算法有一個核心加密函數。該函數輸入64位信息，運算后以64位密文的形式輸出。用BlowFish算法加密信息，需要密鑰預處理和信息加密兩個過程。BlowFish算法的原密鑰pbox和sbox是固定的，要加密一個信息，需要選擇一個key，用這個key對pbox和sbox進行變換，得到下一步信息加密所用到的key_pbox和key_sbox。

BlowFish算法解密，同樣也需要密鑰預處理和信息解密兩個過程。密鑰預處理的過程和加密時完全相同。信息解密的過程就是把信息加密過程的key_pbox逆序使用即可。

以上內容來源自百度百科

5.2非對稱加密算法

算法有RSA、ECC（移動設備用）、Diffie-Hellman、El Gamal、DSA（數字簽名用）等。這里說下常見的算法：

RSA

RSA 加密算法是目前最有影響力的公鑰加密算法，并且被普遍認為是目前 最優秀的公鑰方案 之一。RSA是第一個能同時用于 加密和數字簽名 的算法，它能夠抵抗到目前為止已知的 所有密碼攻擊，已被 ISO 推薦為公鑰數據加密標準。

RSA 加密算法 基于一個十分簡單的數論事實：將兩個大 素數 相乘十分容易，但想要對其乘積進行 因式分解 卻極其困難，因此可以將乘積 公開作為 加密密鑰。

ECC

ECC 也是一種 非對稱加密算法，主要優勢是在某些情況下，它比其他的方法使用 更小的密鑰，比如 RSA 加密算法，提供 相當的或更高等級 的安全級別。不過一個缺點是 加密和解密操作 的實現比其他機制 時間長 (相比 RSA 算法，該算法對 CPU 消耗嚴重)。

5.3散列算法

MD5

MD5（信息-摘要算法5）：MD5將任意長度的“字節串”映射為一個128bit的大整數。MD5以512位分組來處理輸入的信息，且每一分組又被劃分為16個32位子分組，經過了一系列的處理后，算法的輸出由四個32位分組組成，將這四個32位分組級聯后將生成一個128位散列值。也就是說無論是多長的輸入，MD5 都會輸出長度為128bits 的一個串 (通常用 16 進制 表示為 32 個字符)。

SHA1

SHA（安全哈希算法）：Secure Hash Algorithm該算法的思想是接收一段明文，然后以一種不可逆的方式將它轉換成一段（通常更?。┟芪模部梢院唵蔚睦斫鉃槿∫淮斎氪a（稱為預映射或信息），并把它們轉化為長度較短、位數固定的輸出序列即散列值（也稱為信息摘要或信息認證代碼）的過程。可以對任意長度的數據運算生成一個160位的數值。SHA將輸入流按照每塊512位（64個字節）進行分塊，并產生20個字節的被稱為信息認證代碼或信息摘要的輸出。SHA-1是不可逆的、防沖突，并具有良好的雪崩效應。

SHA1 是和 MD5 一樣流行的消息摘要算法，然而 SHA1 比 MD5 的 安全性更強。對于長度小于 2 ^ 64 位的消息，SHA1 會產生一個 160 位的消息摘要?；?MD5、SHA1 的信息摘要特性以及 不可逆 (一般而言)，可以被應用在檢查 文件完整性以及數字簽名等場景。但是在速度上，在相同的硬件上，SHA-1的運行速度比MD5慢。

SSL證書管理 數據加密服務

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。