iOS 經常使用的加密算法和網絡安全問題的瞭解

時間 2019-11-07

原文原文鏈接

iOS中的加密算法

對稱加密算法AES算法

AES加密算法涉及4種操做：字節替代（SubBytes）、行移位（ShiftRows）、列混淆（MixColumns）和輪密鑰加（AddRoundKey）。下圖給出了AES加解密的流程，從圖中能夠看出：html

1）解密算法的每一步分別對應加密算法的逆操做算法

2）加解密全部操做的順序正好是相反的數據庫

正是因爲這幾點（再加上加密算法與解密算法每步的操做互逆）保證了算法的正確性。加解密中每輪的密鑰分別由種子密鑰通過密鑰擴展算法獲得。算法中16字節的明文、密文和輪子密鑰都以一個4x4的矩陣表示。安全

www.cnblogs.com/luop/p/4334…bash

RSA算法（非對稱加密算法）

RSA密碼體制是一種公鑰密碼體制，公鑰公開，私鑰保密，它的加密解密算法是公開的。由公鑰加密的內容能夠而且只能由私鑰進行解密，而且由私鑰加密的內容能夠而且只能由公鑰進行解密。也就是說，RSA的這一對公鑰、私鑰均可以用來加密和解密，而且一方加密的內容能夠由而且只能由對方進行解密。服務器

對稱加密算法：

1）甲方選擇某一種加密規則，對信息進行加密；
2）乙方使用同一種規則，對信息進行解密。

問題出如今哪？ 保存和傳遞密鑰，就成了最頭疼的問題。

非對稱加密算法

1）乙方生成兩把密鑰（公鑰和私鑰）。公鑰是公開的，任何人均可以得到，私鑰則是保密的。
2）甲方獲取乙方的公鑰，而後用它對信息加密。
3）乙方獲得加密後的信息，用私鑰解密。
4）甲方一樣能夠經過公鑰去解密私鑰加密過的數據。
複製代碼

RSA算法原理

簡單說一下經常使用的非對稱加密算法 RSA 的數學原理，理解簡單的數學原理，就能夠理解非對稱加密是怎麼作到的，爲何會是安全的：

1. 選兩個質數 p 和 q，相乘得出一個大整數n，例如 p = 61，q = 53，n = p*q = 3233
2. 選 1-n 間的隨便一個質數e，例如 e = 17
3. 通過一系列數學公式，算出一個數字 d，知足：
a.經過 n 和 e 這兩個數據一組數據進行數學運算後，能夠經過 n 和 d 去反解運算，反過來也能夠。
b.若是隻知道 n 和 e，要推導出 d，須要知道 p 和 q，也就是要須要把 n 因數分解。

上述的 (n,e) 這兩個數據在一塊兒就是公鑰，(n,d) 這兩個數據就是私鑰，知足用私鑰加密，公鑰解密，或反過來公鑰加密，私鑰解密，也知足在只暴露公鑰 (只知道 n 和 e)的狀況下，要推導出私鑰 (n,d)，須要把大整數 n 因數分解。目前因數分解只能靠暴力窮舉，而 n 數字越大，越難以用窮舉計算出因數 p 和 q，也就越安全，當 n 大到二進制 1024 位或 2048 位時，以目前技術要破解幾乎不可能，因此很是安全。
複製代碼

具體計算能夠詳讀這兩篇文章：RSA 算法原理一、二網絡

RSA算法的使用

簽名和加密

咱們說加密，是指對某個內容加密，加密後的內容還能夠經過解密進行還原。 好比咱們把一封郵件進行加密，加密後的內容在網絡上進行傳輸，接收者在收到後，經過解密能夠還原郵件的真實內容。

簽名就是在信息的後面再加上一段內容，能夠證實信息沒有被修改過，怎麼樣能夠達到這個效果呢？

通常是對信息作一個hash計算獲得一個hash值，注意，這個過程是不可逆的，也就是說沒法經過hash值得出原來的信息內容。在把信息發送出去時，把這個hash值加密後作爲一個簽名和信息一塊兒發出去。 接收方在收到信息後，會從新計算信息的hash值，並和信息所附帶的hash值(解密後)進行對比，若是一致，就說明信息的內容沒有被修改過，由於這裏hash計算能夠保證不一樣的內容必定會獲得不一樣的hash值，因此只要內容一被修改，根據信息內容計算的hash值就會變化。固然，不懷好意的人也能夠修改信息內容的同時也修改hash。
複製代碼

iOS中的使用

https最爲直觀。 咱們再AFNetworking中能夠看到RSA的應用


SecKeyEncrypt：使用公鑰對數據進行加密
SecKeyDecrypt：使用私鑰對數據進行解密
SecKeyRawVerify：使用公鑰對數字簽名和數據進行驗證，以確認該數據的來源合法性。
SecKeyRawSign：使用私鑰對數據進行摘要並生成數字簽名

複製代碼

MD5算法

MD5消息摘要算法，屬Hash算法一類。MD5算法對輸入任意長度的消息進行運行，產生一個128位的消息摘要。MD5已經普遍使用在爲文件傳輸提供必定的可靠性方面。例如，服務器預先提供一個MD5校驗和，用戶下載完文件之後，用MD5算法計算下載文件的MD5校驗和，而後經過檢查這兩個校驗和是否一致，就能判斷下載的文件是否出錯。測試

算法原理

MD5以512位分組來處理輸入的信息，且每一分組又被劃分爲16個32位子分組，通過了一系列的處理後，算法的輸出由四個32位分組組成，將這四個32位分組級聯後將生成一個128位散列值
複製代碼

算法用途

一、防止被篡改

好比發送一個電子文檔，發送前，我先獲得MD5的輸出結果a。而後在對方收到電子文檔後，對方也獲得一個MD5的輸出結果b。若是a與b同樣就表明中途未被篡改。

好比我提供文件下載，爲了防止不法分子在安裝程序中添加木馬，我能夠在網站上公佈由安裝文件獲得的MD5輸出結果。

SVN在檢測文件是否在CheckOut後被修改過，也是用到了MD5。

二、防止直接看到明文

如今不少網站在數據庫存儲用戶的密碼的時候都是存儲用戶密碼的MD5值。這樣就算不法分子獲得數據庫的用戶密碼的MD5值，也沒法知道用戶的密碼(其實這樣是不安全的，後面我會提到)。

經加密後存儲在文件系統中。當用戶登陸的時候，系統把用戶輸入的密碼計算成MD5值，而後再去和保存在文件系統中的MD5值進行比較，進而肯定輸入的密碼是否正確。經過這樣的步驟，系統在並不知道用戶密碼的明碼的狀況下就能夠肯定用戶登陸系統的合法性。這不但能夠避免用戶的密碼被具備系統管理員權限的用戶知道，並且還在必定程度上增長了密碼被破解的難度。）

三、數字簽名

這須要一個第三方認證機構。例如A寫了一個文件，認證機構對此文件用MD5算法產生摘要信息並作好記錄。若之後A說這文件不是他寫的，權威機構只需對此文件從新產生摘要信息，而後跟記錄在冊的摘要信息進行比對，相同的話，就證實是A寫的了。這就是所謂的「數字簽名」。

複製代碼

在iOS中的使用

字符串加密：

NSString *message = @"測試加鹽MD5加密";
const char *cStr = [message UTF8String];
unsigned char result[CC_MD5_DIGEST_LENGTH];
CC_MD5(cStr, strlen(cStr), result);

NSString *md5 = [NSString stringWithFormat:@"%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X",result[0],result[1],result[2],result[3],result[4],result[5],result[6],result[7],result[8],result[9],result[10],result[11],result[12],result[13],result[14],result[15]];

NSLog(md5);

文件MD5之類的 百度一下就有了
複製代碼

Base64算法

Base64編碼原理

以下Base64的索引表，字符選用了"A-Z、a-z、0-九、+、/" 64個可打印字符。數值表明字符的索引，這個是標準Base64協議規定的，不能更改。64個字符用6個bit位就能夠所有表示，一個字節有8個bit 位，剩下兩個bit就浪費掉了，這樣就不得不犧牲一部分空間了。這裏須要弄明白的就是一個Base64字符是8個bit，可是有效部分只有右邊的6個 bit，左邊兩個永遠是0。字體

那麼怎麼用6個有效bit來表示傳統字符的8個bit呢？8和6的最小公倍數是24，也就是說3個傳統字節能夠由4個Base64字符來表示，保證有效位數是同樣的，這樣就多了1/3的字節數來彌補Base64只有6個有效bit 的不足。你也能夠說用兩個Base64字符也能表示一個傳統字符，可是採用最小公倍數的方案實際上是最減小浪費的。結合下邊的圖比較容易理解。Man是三個字符，一共24個有效bit，只好用4個Base64字符來湊齊24個有效位。紅框表示的是對應的Base64，6個有效位轉化成相應的索引值再對應 Base64字符表，查出"Man"對應的Base64字符是"TWFU"。說到這裏有個原則不知道你發現了沒有，要轉換成Base64的最小單位就是三個字節，對一個字符串來講每次都是三個字節三個字節的轉換，對應的是Base64的四個字節。這個搞清楚了其實就差很少了。網站

可是轉換到最後你發現不夠三個字節了怎麼辦呢？願望終於實現了，咱們能夠用兩個Base64來表示一個字符或用三個Base64表示兩個字符，像下圖的A對應的第二個Base64的二進制位只有兩個，把後邊的四個補0就是了。因此 A對應的Base64字符就是QQ。上邊已經說過了，原則是Base64字符的最小單位是四個字符一組，那這才兩個字符，後邊補兩個"="吧。其實不用"="也不耽誤解碼，之因此用"="，多是考慮到多段編碼後的Base64字符串拼起來也不會引發混淆。因而可知 Base64字符串只可能最後出現一個或兩個"="，中間是不可能出現"="的。下圖中字符"BC"的編碼過程也是同樣的。

提及Base64編碼可能有些奇怪，由於大多數的編碼都是由字符轉化成二進制的過程，而從二進制轉成字符的過程稱爲解碼。而Base64的概念就剛好反了，由二進制轉到字符稱爲編碼，由字符到二進制稱爲解碼。

Base64編碼主要用在傳輸、存儲、表示二進制等領域，還能夠用來加密，可是這種加密比較簡單，只是一眼看上去不知道什麼內容罷了，固然也能夠對Base64的字符序列進行定製來進行加密。

Base64編碼是從二進制到字符的過程，像一些中文字符用不一樣的編碼轉爲二進制時，產生的二進制是不同的，因此最終產生的Base64字符也不同。例如"上網"對應utf-8格式的Base64編碼是"5LiK572R"，對應GB2312格式的Base64編碼是"yc/N+A=="。

開發中的安全通訊流程

模擬客戶服務器安全通訊過程的演變

第一回合：

客戶和服務器之間通訊

客戶 -> 服務器：你好

服務器 -> 客戶：你好，我是服務器

客戶 -> 服務器：？？？

//由於消息是在網絡上傳輸的，有人能夠冒充本身是「服務器」來向客戶發送信息。例如上面的消息能夠被「黑客」截獲以下：

客戶 -> 服務器：你好

服務器 -> 客戶：你好，我是服務器

// 「黑客」 在 「客戶」 和 「服務器」之間的某個路由器上截獲 「客戶」 發給服務器的信息，而後本身冒充 「服務器」

客戶 -> 黑客 ：你好       

黑客 -> 客戶：你好，我是服務器

第一回合 「客戶」 在接到消息後，並不能確定這個消息就是由 「服務器」 發出的，某些 「黑客」 也能夠冒充「服務器」發出這個消息。如何肯定信息是由「服務器」發過來的呢？
複製代碼

解決方法: 由於只有服務器有私鑰，因此若是隻要可以確認對方有私鑰，那麼對方就是「服務器」。所以通訊過程能夠改進爲以下：

第二回合：

客戶 -> 服務器：你好

服務器 -> 客戶 ：你好，我是服務器

客戶 -> 服務器 ：向我證實你就是服務器

服務器 -> 客戶 ：你好，我是服務器 {你好，我是服務器}[私鑰|RSA]

//{} 表示加密後的內容，[ | ]表示用什麼密鑰和算法進行加密，這裏表示 RSA 私鑰加密

爲了向「客戶」證實本身是「服務器」， 「服務器」把一個字符串用本身的私鑰加密，把明文和加密後的密文一塊兒發給「客戶」。對於這裏的例子來講，就是把字符串 「你好，我是服務器」和這個字符串用私鑰加密後的內容 {你好，我是服務器}[私鑰|RSA] 一塊兒發給客戶。

「客戶」收到信息後，她用本身持有的公鑰解密密文，和明文進行對比，若是一致，說明信息的確是由服務器發過來的。也就是說「客戶」把 {你好，我是服務器}[私鑰|RSA] 這個內容用公鑰進行解密，而後和 「你好，我是服務器」 對比。由於用「服務器」用私鑰加密後的內容，由而且只能由公鑰進行解密，私鑰只有「服務器」 持有，因此若是解密出來的內容是可以對得上的，那說明信息必定是從 「服務器」 發過來的。

假設「黑客」想冒充「服務器」：

黑客 -> 客戶：你好，我是服務器

客戶 -> 黑客：向我證實你就是服務器

黑客 -> 客戶：你好，我是服務器 {你好，我是服務器}[？？？|RSA]    //這裏黑客沒法冒充，由於他不知道私鑰，沒法用私鑰加密某個字符串後發送給客戶去驗證。

客戶 -> 黑客：？？？？

因爲「黑客」沒有「服務器」的私鑰，所以它發送過去的內容，「客戶」是沒法經過服務器的公鑰解密的，所以能夠認定對方是個冒牌貨！中斷通訊。

到第二回合結束，「客戶」 就能夠確認 「服務器」 的身份了，能夠放心和「服務器」進行通訊，同理，若是客戶端須要驗證也是同樣的道理。
複製代碼

可是這裏有一個問題，通訊的內容在網絡上仍是沒法保密。爲何沒法保密呢？通訊過程不是能夠用公鑰、私鑰加密嗎？其實用RSA的私鑰和公鑰是不行的，咱們來具體分析下過程，看下面的演示：

第三回合：

客戶 -> 服務器：你好

服務器 -> 客戶：你好，我是服務器

客戶 -> 服務器：向我證實你就是服務器

服務器 -> 客戶：你好，我是服務器 {你好，我是服務器}[私鑰|RSA]

//開始通訊
客戶 -> 服務器 ：{個人賬號是aaa，密碼是123，把個人餘額的信息發給我看看}[公鑰|RSA]

服務器 -> 客戶：{你的餘額是100元}[私鑰|RSA]

注意上面的的信息 {你的餘額是100元}[私鑰]，這個是 「服務器」 用私鑰加密後的內容，可是咱們以前說了，公鑰是發佈出去的，所以全部的人都知道公鑰，因此除了 「客戶」，其它的人也能夠用公鑰對 {你的餘額是100元}[私鑰]進行解密。因此若是 「服務器」 用私鑰加密發給「客戶」，這個信息是沒法保密的，由於只要有公鑰就能夠解密這內容。然而「服務器」也不能用公鑰對發送的內容進行加密，由於「客戶」沒有私鑰，「客戶」也解密不了。
複製代碼

這樣問題就又來了，那又如何解決呢？在實際的應用過程，通常是經過引入對稱加密來解決這個問題，看下面的演示：

第四回合：

客戶 -> 服務器：你好

服務器 -> 客戶：你好，我是服務器

客戶 -> 服務器：向我證實你就是服務器

服務器 -> 客戶 ：你好，我是服務器 {你好，我是服務器}[私鑰|RSA]

客戶 -> 服務器：{咱們後面的通訊過程，用對稱加密來進行，這裏是對稱加密算法和密鑰}[公鑰|RSA]    //藍色字體的部分是對稱加密的算法和密鑰的具體內容，客戶把它們發送給服務器。

服務器 -> 客戶：{OK，收到！}[密鑰|對稱加密算法]

客戶 -> 服務器：{個人賬號是aaa，密碼是123，把個人餘額的信息發給我看看}[密鑰|對稱加密算法]

服務器 -> 客戶：{你的餘額是100元}[密鑰|對稱加密算法]


在上面的通訊過程當中，「客戶」在確認了「服務器」的身份後，「客戶」本身選擇一個對稱加密算法和一個密鑰，把這個對稱加密算法和密鑰一塊兒用公鑰加密後發送給「服務器」。

注意：因爲對稱加密算法和密鑰是用公鑰加密的，就算這個加密後的內容被「黑客」截獲了，因爲沒有私鑰，「黑客」也無從知道對稱加密算法和密鑰的內容。

因爲是用公鑰加密的，只有私鑰可以解密，這樣就能夠保證只有服務器能夠知道對稱加密算法和密鑰，而其它人不可能知道(這個對稱加密算法和密鑰是「客戶」本身選擇的，因此「客戶」本身固然知道如何解密加密)。這樣「服務器」和「客戶」就能夠用對稱加密算法和密鑰來加密通訊的內容了。

複製代碼

中場休息

咱們總結一下，RSA加密算法在這個通訊過程當中所起到的做用主要有兩個：

加密

由於私鑰只有「服務器」擁有，所以「客戶」能夠經過判斷對方是否有私鑰來判斷對方是不是「服務器「

簽名

客戶端經過RSA的掩護，安全的和服務器商量好一個對稱加密算法和密鑰來保證後面通訊過程內容的安全  
複製代碼

到這裏，「客戶」就能夠確認「服務器」的身份，而且雙方的通訊內容能夠進行加密，其餘人就算截獲了通訊內容，也沒法解密。的確，好像通訊的過程是比較安全了。

可是這裏還留有一個問題，在最開始咱們就說過，「服務器」要對外發布公鑰，那「服務器」如何把公鑰發送給「客戶」呢？

咱們第一反應可能會想到如下的兩個方法：

a)把公鑰放到互聯網的某個地方的一個下載地址，事先給「客戶」去下載。

b)每次和「客戶」開始通訊時，「服務器」把公鑰發給「客戶」。
複製代碼

可是這個兩個方法都有必定的問題，

對於a)方法，「客戶」沒法肯定這個下載地址是否是「服務器」發佈的，你憑什麼就相信這個地址下載的東西就是「服務器」發佈的而不是別人僞造的呢，萬一下載到一個假的怎麼辦？另外要全部的「客戶」都在通訊前事先去下載公鑰也很不現實。

對於b)方法，也有問題，由於任何人均可以本身生成一對公鑰和私鑰，他只要向「客戶」發送他本身的私鑰就能夠冒充「服務器」了。示意以下：

「客戶」->「黑客」：你好                           //黑客截獲「客戶」發給「服務器」的消息

「黑客」->「客戶」：你好，我是服務器，這個是個人公鑰    //黑客本身生成一對公鑰和私鑰，把公鑰發給「客戶」，本身保留私鑰

「客戶」->「黑客」：向我證實你就是服務器

「黑客」->「客戶」：你好，我是服務器 {你好，我是服務器}[黑客本身的私鑰|RSA]      //客戶收到「黑客」用私鑰加密的信息後，是能夠用「黑客」發給本身的公鑰解密的，從而會誤認爲「黑客」是「服務器」
複製代碼

所以「黑客」只須要本身生成一對公鑰和私鑰，而後把公鑰發送給「客戶」，本身保留私鑰，這樣因爲「客戶」能夠用黑客的公鑰解密黑客的私鑰加密的內容，「客戶」就會相信「黑客」是「服務器」，從而致使了安全問題。

這裏問題的根源就在於，你們均可以生成公鑰、私鑰對，沒法確認公鑰對究竟是誰的。

若是可以肯定公鑰究竟是誰的，就不會有這個問題了。例如，若是收到「黑客」冒充「服務器」發過來的公鑰，通過某種檢查，若是可以發現這個公鑰不是「服務器」的就行了。

數字證書

爲了解決這個問題，數字證書出現了，它能夠解決咱們上面的問題。先大概看下什麼是數字證書，一個證書包含下面的具體內容：

版本號、序列號（證書的惟一標識）
證書的發行機構（issuer）
證書的有效期（valid from， valid to）
公鑰（public key）
證書全部者名稱（subject）
簽名所使用的算法
指紋以及指紋算法

數字證書能夠保證數字證書裏的公鑰確實是這個證書的全部者的，或者證書能夠用來確認對方的身份。也就是說，咱們拿到一個數字證書，咱們能夠判斷出這個數字證書究竟是誰的。如今把前面的通訊過程使用數字證書修改成以下：

第五回合：

客戶 -> 服務器：你好

服務器 -> 客戶：你好，我是服務器，這裏是個人數字證書        //這裏用證書代替了公鑰

客戶 -> 服務器：向我證實你就是服務器

服務器 -> 客戶：你好，我是服務器 {你好，我是服務器}[私鑰|RSA]
複製代碼

注意，上面第二次通訊，「服務器」把本身的證書發給了「客戶」，而不是發送公鑰。「客戶」能夠根據證書校驗這個證書究竟是不是「服務器」的，也就是能校驗這個證書的全部者是否是「服務器」，從而確認這個證書中的公鑰的確是「服務器」的。後面的過程和之前是同樣，「客戶」讓「服務器」證實本身的身份，「服務器」用私鑰加密一段內容連同明文一塊兒發給「客戶」，「客戶」把加密內容用數字證書中的公鑰解密後和明文對比，若是一致，那麼對方就確實是「服務器」，而後雙方協商一個對稱加密來保證通訊過程的安全。到這裏，整個過程就完整了，咱們回顧一下：

完整過程

step1： 「客戶」向服務端發送一個通訊請求

客戶 -> 服務器：你好

step2： 「服務器」向客戶發送本身的數字證書。證書中有一個公鑰用來加密信息，私鑰由「服務器」持有

服務器 -> 客戶：你好，我是服務器，這裏是個人數字證書 

step3： 「客戶」收到「服務器」的證書後，它會去驗證這個數字證書究竟是不是「服務器」的，數字證書有沒有什麼問題，數字證書若是檢查沒有問題，就說明數字證書中的公鑰確實是「服務器」的。檢查數字證書後，「客戶」會發送一個隨機的字符串給「服務器」用私鑰去加密，服務器把加密的結果返回給「客戶」，「客戶」用公鑰解密這個返回結果，若是解密結果與以前生成的隨機字符串一致，那說明對方確實是私鑰的持有者，或者說對方確實是「服務器」。

「客戶」->「服務器」：向我證實你就是服務器，這是一個隨機字符串     //前面的例子中爲了方便解釋，用的是「你好」等內容，實際狀況下通常是隨機生成的一個字符串。

「服務器」->「客戶」：{一個隨機字符串}[私鑰|RSA]

step4： 驗證「服務器」的身份後，「客戶」生成一個對稱加密算法和密鑰，用於後面的通訊的加密和解密。這個對稱加密算法和密鑰，「客戶」會用公鑰加密後發送給「服務器」，別人截獲了也沒用，由於只有「服務器」手中有能夠解密的私鑰。這樣，後面「服務器」和「客戶」就均可以用對稱加密算法來加密和解密通訊內容了。

「服務器」->「客戶」：{OK，已經收到你發來的對稱加密算法和密鑰！有什麼能夠幫到你的？}[密鑰|對稱加密算法]

「客戶」->「服務器」：{個人賬號是aaa，密碼是123，把個人餘額的信息發給我看看}[密鑰|對稱加密算法]

「服務器」->「客戶」：{你好，你的餘額是100元}[密鑰|對稱加密算法]

…… //繼續其它的通訊

複製代碼

數字證書其餘知識

數字證書的內容解釋

◆Issuer (證書的發佈機構)

指出是什麼機構發佈的這個證書，也就是指明這個證書是哪一個公司建立的(只是建立證書，不是指證書的使用者)。對於上面的這個證書來講，好比"SecureTrust CA"這個機構。

◆Valid from , Valid to (證書的有效期)

也就是證書的有效時間，或者說證書的使用期限。 過了有效期限，證書就會做廢，不能使用了。

◆Public key (公鑰)

這個咱們在前面介紹公鑰密碼體制時介紹過，公鑰是用來對消息進行加密的，第2章的例子中常常用到的。這個數字證書的公鑰是2048位的，它的值能夠在圖的中間的那個對話框中看獲得，是很長的一串數字。

◆Subject (主題，證書全部者)

這個證書是發佈給誰的，或者說證書的全部者，通常是某我的或者某個公司名稱、機構的名稱、公司網站的網址等。

◆Signature algorithm (簽名所使用的算法)

就是指的這個數字證書的數字簽名所使用的加密算法，這樣就可使用證書發佈機構的證書裏面的公鑰，根據這個算法對指紋進行解密。指紋的加密結果就是數字簽名。

◆Thumbprint, Thumbprint algorithm (指紋以及指紋算法)

這個是用來保證證書的完整性的，也就是說確保證書沒有被修改過

其原理就是在發佈證書時，發佈者根據指紋算法(一個hash算法)計算整個證書的hash值(指紋)並和證書放在一塊兒，使用者在打開證書時，本身也根據指紋算法計算一下證書的hash值(指紋)，若是和剛開始的值對得上，就說明證書沒有被修改過，由於證書的內容被修改後，根據證書的內容計算的出的hash值(指紋)是會變化的。 注意，這個指紋會使用"SecureTrust CA"這個證書機構的私鑰用簽名算法(Signature algorithm)加密後和證書放在一塊兒。
複製代碼

證書的申請到使用

咱們"ABC Company"申請到這個證書後，咱們把證書投入使用，咱們在通訊過程開始時會把證書發給對方，對方如何檢查這個證書的確是合法的而且是咱們"ABC Company"公司的證書呢？

首先應用程序(對方通訊用的程序，例如IE、OUTLook等)讀取證書中的Issuer(發佈機構)爲"SecureTrust CA" ，而後會在操做系統中受信任的發佈機構的證書中去找"SecureTrust CA"的證書，若是找不到，那說明證書的發佈機構是個水貨發佈機構，證書可能有問題，程序會給出一個錯誤信息。 

若是在系統中找到了"SecureTrust CA"的證書，那麼應用程序就會從證書中取出"SecureTrust CA"的公鑰，而後對咱們"ABC Company"公司的證書裏面的指紋和指紋算法用這個公鑰進行解密，而後使用這個指紋算法計算"ABC Company"證書的指紋，將這個計算的指紋與放在證書中的指紋對比，若是一致，說明"ABC Company"的證書確定沒有被修改過而且證書是"SecureTrust CA" 發佈的，證書中的公鑰確定是"ABC Company"的。對方而後就能夠放心的使用這個公鑰和咱們"ABC Company"進行通訊了。
複製代碼

是否能夠本身生成證書

若是數字證書只是要在公司內部使用，公司能夠本身給本身生成一個證書，在公司的全部機器上把這個證書設置爲操做系統信任的證書發佈機構的證書(這句話仔細看清楚，有點繞口)，這樣之後公司發佈的證書在公司內部的全部機器上就能夠經過驗證了(在發佈證書時，把這些證書的Issuer(發佈機構)設置爲咱們本身的證書發佈機構的證書的Subject(主題)就能夠了)。

可是這隻限於內部應用，由於只有咱們公司本身的機器上設置了信任咱們本身這個所謂的證書發佈機構，而其它機器上並無事先信任咱們這個證書發佈機構，因此在其它機器上，咱們發佈的證書就沒法經過安全驗證。

好比 Https 的自簽發，但通常都是內部使用
複製代碼

其它問題

【問題1】

上面的通訊過程當中說到，在檢查完證書後，「客戶」發送一個隨機的字符串給「服務器」去用私鑰加密，以便判斷對方是否真的持有私鑰。

可是有一個問題，「黑客」也能夠發送一個字符串給「服務器」去加密而且獲得加密後的內容，這樣對於「服務器」來講是不安全的，由於黑客能夠發送一些簡單的有規律的字符串給「服務器」加密，從而尋找加密的規律，有可能威脅到私鑰的安全。

因此說，「服務器」隨隨便便用私鑰去加密一個來路不明的字符串並把結果發送給對方是不安全的。
複製代碼

〖解決方法〗

每次收到「客戶」發來的要加密的的字符串時，「服務器」並非真正的加密這個字符串自己，而是把這個字符串進行一個hash計算，加密這個字符串的hash值(不加密原來的字符串)後發送給「客戶」，「客戶」收到後解密這個hash值並本身計算字符串的hash值而後進行對比是否一致。

也就是說，「服務器」不直接加密收到的字符串，而是加密這個字符串的一個hash值，這樣就避免了加密那些有規律的字符串，從而下降被破解的機率。

「客戶」本身發送的字符串，所以它本身能夠計算字符串的hash值，而後再把「服務器」發送過來的加密的hash值和本身計算的進行對比，一樣也能肯定對方是不是「服務器」。

MD5加密
複製代碼

【問題2】

在雙方的通訊過程當中，「黑客」能夠截獲發送的加密了的內容，雖然他沒法解密這個內容，可是他能夠搗亂，例如把信息原封不動的發送屢次，擾亂通訊過程。
複製代碼

〖解決方法〗

能夠給通訊的內容加上一個序號或者一個隨機的值，若是「客戶」或者「服務器」接收到的信息中有以前出現過的序號或者隨機值，那麼說明有人在通訊過程當中重發信息內容進行搗亂，雙方會馬上中止通訊。

有人可能會問，若是有人一直這麼搗亂怎麼辦？那不是沒法通訊了？ 答案是的確是這樣的，例若有人控制了你鏈接互聯網的路由器，他的確能夠針對你。可是一些重要的應用，例如軍隊或者政府的內部網絡，它們都不使用咱們平時使用的公網，所以通常人不會破壞到他們的通訊。 
複製代碼

【問題3】

在雙方的通訊過程當中，「黑客」除了簡單的重複發送截獲的消息以外，還能夠修改截獲後的密文修改後再發送，由於修改的是密文，雖然不能徹底控制消息解密後的內容，可是仍然會破壞解密後的密文。所以發送過程若是黑客對密文進行了修改，「客戶」和「服務器」是沒法判斷密文是否被修改的。雖然不必定能達到目的，可是「黑客」能夠一直這樣碰碰運氣。
複製代碼

〖解決方法〗

在每次發送信息時，先對信息的內容進行一個hash計算得出一個hash值，將信息的內容和這個hash值一塊兒加密後發送。接收方在收到後進行解密獲得明文的內容和hash值，而後接收方再本身對收到信息內容作一次hash計算，與收到的hash值進行對比看是否匹配，若是匹配就說明信息在傳輸過程當中沒有被修改過。若是不匹配說明中途有人故意對加密數據進行了修改，馬上中斷通話過程後作其它處理。

MD5加密
複製代碼