iOS 常用的加密演算法和網路安全問題的瞭解
iOS中的加密演算法
對稱加密演算法AES演算法
AES加密演算法涉及4種操作：位元組替代（SubBytes）、行移位（ShiftRows）、列混淆（MixColumns）和輪金鑰加（AddRoundKey）。下圖給出了AES加解密的流程，從圖中可以看出：
1）解密演算法的每一步分別對應加密演算法的逆操作
2）加解密所有操作的順序正好是相反的
正是由於這幾點（再加上加密演算法與解密演算法每步的操作互逆）保證了演算法的正確性。加解密中每輪的金鑰分別由種子金鑰經過金鑰擴充套件演算法得到。演算法中16位元組的明文、密文和輪子金鑰都以一個4x4的矩陣表示。
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演算法的使用
簽名和加密
我們說加密，是指對某個內容加密，加密後的內容還可以通過解密進行還原。 比如我們把一封郵件進行加密，加密後的內容在網路上進行傳輸，接收者在收到後，通過解密可以還原郵件的真實內容。
簽名就是在資訊的後面再加上一段內容，可以證明資訊沒有被修改過，怎麼樣可以達到這個效果呢？
一般是對資訊做一個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位雜湊值
複製程式碼演算法用途
1、防止被篡改
比如傳送一個電子文件，傳送前，我先得到MD5的輸出結果a。然後在對方收到電子文件後，對方也得到一個MD5的輸出結果b。如果a與b一樣就代表中途未被篡改。
比如我提供檔案下載，為了防止不法分子在安裝程式中新增木馬，我可以在網站上公佈由安裝檔案得到的MD5輸出結果。
SVN在檢測檔案是否在CheckOut後被修改過，也是用到了MD5。
2、防止直接看到明文
現在很多網站在資料庫儲存使用者的密碼的時候都是儲存使用者密碼的MD5值。這樣就算不法分子得到資料庫的使用者密碼的MD5值，也無法知道使用者的密碼(其實這樣是不安全的，後面我會提到)。
經加密後儲存在檔案系統中。當用戶登入的時候，系統把使用者輸入的密碼計算成MD5值，然後再去和儲存在檔案系統中的MD5值進行比較，進而確定輸入的密碼是否正確。通過這樣的步驟，系統在並不知道使用者密碼的明碼的情況下就可以確定使用者登入系統的合法性。這不但可以避免使用者的密碼被具有系統管理員許可權的使用者知道，而且還在一定程度上增加了密碼被破解的難度。）
3、數字簽名
這需要一個第三方認證機構。例如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-9、+、/" 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加密
複製程式碼