一、資料加密和解密概述
資料加密和解密是一門曆史悠久的技術，從古代就已經出現了，一直發展到當代。其中，資料加密的目的有很多，可以是為了保證本地資料存取的安全性，可以是為了保證資料流在網絡傳輸過程中的保密性，也可以是為了驗證資料的完整性，還可以通過資料加密來實作密鑰的交換等。
資料加密依賴于某種加密算法和加密密鑰，而資料解密則依賴于某種解密算法和解密密鑰。而在當代加密解密技術中，加密密鑰既可以與解密密鑰相同，也可以和解密密鑰不同，這取決于使用什麼方法進行加解密。
二、安全的目标
就資訊傳輸過程來說，安全目标有以下三個要點：
(1)保密性：確定通信雙方之間的通信資料不會被無關的第三方所竊取，這是最基本的要求。
(2)完整性：確定通信時資料不會丢失或被第三方篡改、破壞，一旦資料丢失或被篡改時，通信的一方能夠立即發現。
(3)可用性：確定授權使用者能夠按需合法通路資源。
三、安全攻擊類型
對應于以上的安全目标，分别有以下三種攻擊類型：
(1)威脅保密性的攻擊：竊聽/竊取、通信量分析；
(2)威脅完整性的攻擊：篡改、僞裝、重放、否認；
(3)威脅可用性的攻擊：拒絕服務(Dos)、分布式拒絕服務(DDos)；
四、安全防範的解決方案
為了防範安全攻擊，可以分别從技術層面上和服務層面上防範：
(1)技術層面：提供加密和解密技術。這個層面解決了本地資料存儲加密和通信過程中資料加密的一系列問題，可分為傳統加密算法和現代加密算法：
①傳統加密算法：替換加密算法、置換加密算法；
②現代加密算法：現代塊加密方法
(2)技術層面：提供用于抵禦攻擊以及為了達到上述安全目标而特地設計的服務。在這一層面上主要有認證機制和通路控制機制：
①認證機制：确定通路資源的使用者是誰、通信對方的身份是否為期望的另一方等；
②通路控制機制：确定某個使用者是否有權限通路資源；如果有權限通路資源，再進一步确定使用者所能夠通路的資源以及對資源能夠執行的操作（檢視、使用、修改、建立等）；
在以上技術和服務這兩個層面中會用到的密鑰算法和協定有對稱加密、公鑰加密（非對稱加密）、單向加密以及認證協定。接下來介紹在實作安全通信過程中所用到的加密算法以及它們的實作。
五、加密算法和實作
1、對稱加密
(1)特點：加密和解密使用同一個密鑰；通信時，雙方要想實作基于對稱加密算法來實作通信需要預先共享密鑰。
(2)用途：用于實作資料保密性。
(3)常見算法：
①DES：Data EncryptionStandard(資料加密标準)。DES算法是以64bits(8Bytes)為塊，在加密端把資料分成多塊，對每塊資料(64bits)進行加密，生成64bits密文；在解密端則把64bits密文轉換為64bits明文。各個塊之間建立一定的聯系，DES使用16個疊代塊來完成疊代。其中，加密和解密使用56bits密鑰。
②3DES：Triple DES(三輪DES加密機制)。3DES加密次數是DES的三個數量級(10^3)。
③AES：Advanced Encryption Standard(進階加密标準)。AES支援多種變長密鑰，如128bits,192bits, 256bits, 384bits等。
④其它對稱加密算法有：Blowfish, Twofish, IDEA, RC6, CAST5等。
Note：DES算法存在缺陷，而且隻使用56bits的密鑰太短；為了提供更高的安全性，可使用DES的派生算法3DES來進行加密，但3DES算法和DES算法一樣存在可被攻擊的缺陷。後來DES被AES所替代。
(4)缺陷：
①密鑰過多：如果通信是基于C/S模式，則伺服器端與每一個用戶端之間的通信都必須使用不同的密鑰，造成伺服器端密鑰過多的問題。
②密鑰分發困難：對稱加密可實作通信時資料加密功能，但問題是雙方通信之前必須互動密鑰，而密鑰在交換過程中也同樣保證保密性，這時會造成密鑰分發困難的問題，必 須依賴于一種安全的方法來實作密鑰的交換。
2、非對稱加密
(1)特點：也稱為公鑰加密。加密和解密資料使用不同的密鑰，例如用公鑰加密的資料隻能使用與之配對的私鑰進行解密，而用私鑰加密則隻能使用與之配對的公鑰進行解密。相比于對稱加密，公鑰加密可把公鑰直接公開，即使公鑰在通信時被竊取，因為沒有與之配對的私鑰，是以仍然無法解密資料。
①公鑰：public key，從私鑰中提取産生，可公開給所有人。
②私鑰：secret key，通過工具建立生成，由使用者自己留存，必須保證其私密性。
(2)用途：
①數字簽名：主要用于讓接受方确認發送方的身份。
②密鑰交換：通過對方的公鑰加密一個對稱密鑰，并發送給對方，對方通過其私鑰解密之後就可以擷取對稱密鑰了。這解決了上述對稱加密算法中密鑰分發困難這一問題。
③資料加密：這種直接使用公鑰加密算法來實作通信時資料的保密性的方式并不常用，因為這種方式要比使用對稱加密慢上3個數量級，不推薦。
(3)常見算法：
①RSA：名稱由RSA三個提出者(Ron Rivest, AdiShamir, Leonard Adleman)的姓氏首字母組合而成，這種算法的可靠性由對極大整數做因數分解的難度決定；RSA既能實作數字 簽名，又能實作加解密。
②DSA：Digital Signature Algorithm，即數字簽名算法，又稱DSS(Digital Signature Standard, 數字簽名标準)；DSA僅能實作數字簽名，不能用于加解密。
③其他公鑰加密算法有ELGamal等。
(4)缺陷：通信效率低。
3、單向加密
(1)特點：提取資料特征碼，隻能加密，不能解密，它是基于兩個特性。
①定長輸出：提取出來的資料量是定長的，與進行加密的資料的量無關。
②雪崩效應：初識條件的微小改變會引起加密結果的巨大變化。
(2)用途：用于實作資料完整性的驗證。
(3)常見算法：
①md5：Message Digest 5，即資訊摘要，'5'是版本号；取出的特征碼定長為128bits。
②sha1：Secure Hash Algorithm 1，即安全雜湊演算法，'1'是版本号；取出的特征碼定長為160bits。
③其他的單向加密算法還有：sha224、sha256、sha384、sha512 ...分别表示定長輸出224bits、256bits、384bits、512bits...
Note：CentOS 5使用者密碼加密使用的是md5，CentOS 6/7使用者密碼加密使用的是sha512.
4、密鑰交換(IKE, Internet Key Exchange)
兩種實作方式：
①公鑰加密：常見的算法有RSA等。
②DH算法：Deffie-Hellman(迪菲-赫爾曼)算法。
③其他用于實作密鑰交換的算法有：ECDH(橢圓曲線DH)、ECDHE(臨時橢圓曲線DH)等。
以下為DH算法的工作原理圖：
一般的過程：
1.Alice生成随機自然數a、随機大質數p和原根g；
2.Alice計算，計算結果為A，并把p,g,A發送給Bob；
3.Bob生成随機自然數b，根據Alice發過來的p,g，計算，計算結果為B；
4.Bob把B發送給Alice，并計算，計算結果為K；而Alice計算，計算結果也為K；
5.Alice和Bob以K值作為密鑰進行通信。
Note：在整個密鑰協商過程中，p、g、A、B和的值是可以公開給攻擊者的，而a,b,K值是不公開的。問題關鍵在于：通過傳遞的A= g^a%p和B=g^b%p，其實也就是傳遞的是A B g p的值按照數學的算法反推能求出a b的值，但是現在計算機還不能滿足這樣的要求，是以a b分别為Alice和Bob所私有，對方都不知道，何況攻擊者了，這樣雙方計算出K值(最終Alice和Bob協商好的密鑰)了，這個問題就是著名的離散對數問題。
六、一次加密通信的過程
以發送方Alice和接收方Bob為例，Alice向Bob發送封包，怎麼才能保證Alice的封包安全、可靠地被Bob接收到，并且保證封包資料的完整性？接下來圍繞着這個問題來說明一下。。
網絡傳輸中主要問題
| 資料傳輸 | 解決方案 | 實作步驟 |
| 1、發送資料未被修改 | 利用單向加密提取資料特征碼（相當于資料指紋） | 在資料準備發送的時候提取資料的特征碼，在收受到資料後提取其特征碼與之前的特征碼對比，保證資料的完整性。 |
| 2、確定通信過程的保密性 | 利用對稱加密的方法 | 發送方Alice生成一個臨時的對稱密鑰，并使用這個對稱密鑰加密整段資料。 |
| 3、驗證資料的發送方和接收方是否本人 | 利用公鑰加密的機制：公鑰加密，私鑰解密；私鑰加密，公鑰解密。 | 在Alice發送時資料時用Bob公開的公鑰加密資料包。在Alice接受到資料包以後用自己的私鑰是否能打開，進而驗證了身份。 |
加密和發送過程：
1、當發送方Alice有資料要發送給Bob時，為了確定資料能夠完整地發送至Bob，首先需要使用單向加密算法去計算出這段要發送的資料的特征碼；
2、為了便于Bob收到資料之後可驗證身份，發送方Alice使用本地私鑰加密這段特征碼，并将加密後的特征碼附加在資料後面；
3、為了確定通信過程是保密的，發送方Alice生成一個臨時的對稱密鑰，并使用這個對稱密鑰加密整段資料；
4、發送方Alice擷取Bob的公鑰，再使用Bob的公鑰加密來加密剛才生成的臨時的對稱密鑰，并把加密後的對稱密鑰附加在整段加密資料後面，而後發送給Bob。
接收和解密過程：
接收和解密的過程和解密發送的過程剛好相反。
1、接收方Bob收到資料之後，先使用自己的私鑰去解密這段加密過的對稱密鑰(由Alice生成)；
2、接收方Bob用解密得到的對稱密鑰去解密整段（發送方用對稱密鑰）加密的内容；此時接收方Bob得到Alice發送給自己的資料和加密後的特征碼；
3、接收方Bob用對方Alice的公鑰去解密這段特征碼，如果能解密出來，則發送方的身份得到驗證（沒錯，就是Alice發送的）；
4、接收方Bob再用同樣的單向加密算法去計算這段資料的特征碼，與解密得到的特征碼進行比較，如果相同，則資料完整性得到驗證，否則說明資料有可能被篡改或被破壞。
圖解加密通信過程：
相關問題：
(1)什麼是數字簽名？
數字簽名就是對資料的特征碼進行加密。
(2)如何保證公鑰不被篡改？
解決方法：将公鑰放在證書中。隻要證書是可信的，那麼公鑰就是可信的。
(3)公鑰加密計算量太大，如何減少耗用的時間？
解決方法：每一次對話（session），雙方都生成一個臨時的“會話密鑰”（session key），用來加密資訊。由于“會話密鑰”是對稱加密，是以運算速度快，比公鑰加密快3個數量級，而公鑰加密本身隻用于加密“會話密鑰”本身，這樣就減少了耗用的時間。
七、數字證書授權機構--CA
前面的加密通信過程中能夠保證通信過程的保密性、通信資料的完整性，但這是以雙方(Alice和Bob)能夠在此之前可靠地擷取對方的公鑰為前提的。如果不能保證能夠可靠擷取對方公鑰，那麼就有可能出現中間人攻擊（Man-in-the-middleattack，縮寫：MITM）。假設這個中間人是Eve，Eve就可以分别與Alice和Bob建立聯系，而這時Alice擷取的是“假的”Bob公鑰，而Bob擷取的是“假的”Alice公鑰；這時候Alice和Bob在毫不知情的情況下進行通信，但其實他們之間資料包的轉發是經由Eve的，如圖：
上述的通信過程中缺失的一環在于通信雙方不能保證可靠地擷取對方的公鑰，是以，為了保證可靠地擷取通信對方的公鑰，于是就有了數字證書認證機構(CertificateAuthority，縮寫：CA)。CA就是為了能夠保證通信雙方能夠可靠擷取對方的公鑰，而特地設定的一個雙方公信的第三方可信機構。
為了避免出現上述一環的缺失，Alice和Bob可向公信的CA申請有效的證書，并由CA分别頒發給Alice和Bob，其中這個證書中的資訊包括了證書擁有者的名稱、公鑰、證書的有效期等資訊，而CA還會提驗證書中資訊的特征碼，并用CA自己的私鑰進行加密，再把加密後的特征碼附加在證書中最後面。此後，當雙方通信時，Alice和Bob雙方都把自己的證書發給對方，并都分别使用CA的公鑰去解密證書中的特征碼，如果能解密，則說明證書的确由他們所信任的CA機構所頒發；接着使用同樣的單向加密算法去提驗證書中資訊的特征碼，與解密出來的特征碼進行比較，如果兩者相同，說明證書内容完整，沒有被篡改或破壞，而對方的證書中就有對方的公鑰。
但這又引入了一個問題，Alice和Bob如何可靠地擷取CA的呢?顯然，不能基于網絡通信的方式擷取CA的公鑰（一切基于網絡的傳輸都是不可靠的），而應該當面交易。全球有多個CA機構，這些CA的數量是有限、基本固定的；它們彼此之間存在互信鍊，也就是說CA的信任關系是可以傳遞的。為了管理友善，全球有一個根CA，它與其他CA是從屬關系。
為了解決通信主機能夠可靠擷取CA的公鑰，CA需要自簽一份證書，就是CA自簽名證書，在證書資訊中包括了CA的名稱、CA的公鑰等，通信主機（這裡是Alice和Bob）需要擷取CA憑證，這樣才能擷取CA公鑰以及其他的CA資訊，并能通過CA憑證來驗證其他通信主機的證書是否可靠。CA憑證的擷取需要通過當面交易來實作，而微軟公司直接在windows作業系統上內建了在全球具有公信力的CA憑證，但在Linux中一般不内置CA憑證，需要自己通過可靠手段擷取。
雖然通過上述手段可以極大地保證通信過程的安全性，但仍然存在問題，例如在這整個通信過程中使用的某種算法出現漏洞依然不夠安全。
八、公鑰基礎設施--PKI
以上述為例子，如果Alice的私鑰丢失或者被竊取，則需要立即向CA機構申請吊銷證書，聲明證書廢棄，将損失将至最低；為了能夠第一時間讓其他人知道證書已經吊銷，可以通過各種媒體來傳播，例如新聞、報紙等。由此可見，CA不單要頒發證書，還需要提供證書吊銷清單，公開聲明有哪些證書已經吊銷及不能再信任。是以，為了可以更好地管理CA，發展出了一套以CA為核心的體系--公鑰基礎設施（Public Key Infrastructure，縮寫為：PKI）。
PKI架構主要包括以下四部分：
①簽證機構：Certificate Authority，縮寫為CA；負責簽署證書；
②注冊機構：Registration Authority，縮寫為RA；負責接收簽署證書的申請；
③證書吊銷清單：Certificate Revocation List，縮寫為CRL；負責公開所有已經吊銷的證書；
④證書存取庫：Certificate Repository，縮寫為CR；負責将公開所有已申請的證書的相關資訊；
為了統一數字證書的格式，國際電信聯盟（ITU-T）制定了數字證書标準--X.509，即數字證書的格式遵循X.509标準。在X.509v3版本中，定了數字證書的結構以及認證協定标準。而由X.509v3定義的數字證書應該包括以下幾個部分：
1.版本号
2.序列号（辨別第幾個證書）
3.簽名算法
4.發行者名稱（CA名稱）
5.有效期限
6.主體名稱
7.主體公鑰
8.發行者的唯一辨別
9.主體的唯一辨別
10.擴充資訊
11.發行者的簽名（即CA對整個證書的簽名；CA把以上内容進行單向加密，得到特征碼；再使用CA自己的私鑰對特征碼進行加密，并附在證書後面，用來生成發行者數字簽名）
另外需要注意的是，數字證書中的序列号、簽名算法、發行者的唯一辨別等資訊是內建于電子晶片中的。
九、CA如何在A和B通信之間發揮作用？
基本過程：
1、首先，在A和B通信之前需要互相發送證書；
2、A和B之間協商通信過程中要使用的加密算法（對稱加密、公鑰加密、單向加密、密鑰交換）；
3、開始驗證證書：
1)用CA的公鑰去解密CA的簽名，如果能解密，則說明證書來源可靠；
2)用同樣的單向加密算法計算出證書中資訊的特征碼，與解密得到的特征碼進行比較；如果兩者相同，則說明證書完整性可靠；
3)檢查證書的有效日期是否在目前時間的合理範圍内；如果證書過期了則不會被認可；
4)檢查證書的主體名稱與期望通信的對方是否一緻；如果不一緻則不會被認可；
5)檢查證書是否被吊銷過；如果沒有吊銷則可使用該證書，否則證書不會被認可。
Note：在每次通信過程中，以上步驟一步也不能少；另外，A和B需要事先擷取CA自簽名證書，因為持有CA自簽名證書是用來驗證CA頒發給其他人或主機的證書的前提。
十、SSL概述
1、為什麼需要SSL？
我們知道，服務程式一般都會存在bug，黑客隻要找到服務程式的bug就可以基于網絡進行攻擊。對于這種情況，我們的服務程式邏輯要盡可能做得足夠安全，但程式總會有bug，是以需要做好安全防範，解決思路是使用一個監控程式對所有的資源通路做監控，如果攻擊者想做一些未經授權的資源通路，則這個監控程式自動報警。通俗地來講，就是“一旦它把手伸到不該伸的地方就報警”，這是一種輔助機制。但這種輔助機制隻能確定本地服務程式不會被違規機制所通路到，不能確定資源在網絡傳輸過程是安全的。
在早期計算機未普及時，使用計算機網絡進行通信的主機很少，網絡安全不是很受到重視。而在早期設計的一些協定本身就不具備加解密功能，例如http,ftp,smtp,pop3等協定。即便後來随着網際網路的發展，網絡安全得到越來越多的關注，這些協定也很難在其中添加加解密功能，因為早期的很多協定已經成為了網絡通信的公共功能和基礎設施，一旦在這些基礎協定（例如http）添加上加解密功能，則會牽一發而動全身，各個依賴于這些基礎服務程式開發出來的程式勢必會受到影響。
是以，網景公司為http協定研發設計了一種可被調用的功能子產品，這個功能子產品所處的位置在應用層和傳輸層之間的半層，作為公共功能庫，也稱為半層庫。任何程式在研發時可調用這個半層庫以實作加解密和密鑰分發的功能，不調用則不使用。這個半層庫就是SSL庫。
2、SSL是什麼？
SSL（Secure Sockets Layer，安全套接字層）是一種安全的加解密協定，它的實作也是需要程式（算法）來實作。ssl是一種公共功能，但ssl本身隻是一種規範和協定，需要程式員開發出一種遵循SSL協定規範的程式來實作。對于其他協定和程式也一樣，
例如：httpd、nginx是http協定的服務端程式實作，而各種浏覽器如IE、chrome及firefox等則是http協定的用戶端程式實作；在Windows界面上的遠端終端程式Xshell、在Linux上的ssh程式也是ssh協定的用戶端程式實作。而ssl在Linux上的開源實作有Openssl和GPG，其中Openssl是ssl協定和ssl庫的實作，而GPG是pgp協定的實作，Openssl和GPG也是密鑰算法和協定的實作。
任何一個加密解密庫（例如ssl庫）要求必須滿足以下兩個功能：
①實作加解密的基本功能；
②能夠基于網絡通信方式實作密鑰分發。
3、SSL的應用
以https通信過程為例描述SSL的實作過程：
HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全為目标的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL。
以https為例，進一步說明如何依靠CA來可靠的獲得通信對方的公鑰，如圖：
https的主要實作過程說明：
（1）在通信之前，伺服器端通過加密算法生成一對密鑰，并把其公鑰發給CA申請數字證書，CA稽核後，結合服務端發來的相關資訊生成數字證書，并把該數字證書發回給伺服器端。
（2）用戶端和伺服器端經tcp三次握手，建立初步連接配接。
（3）用戶端發送http封包請求并協商使用哪種加密算法。
（4）服務端響應封包并把自身的數字簽名發給服務端。
（5）客服端下載下傳CA的公鑰，驗證其數字證書的擁有者是否是伺服器端（這個過程可以得到伺服器端的公鑰）。（一般是用戶端驗證服務端的身份，服務端不用驗證用戶端的身份。）
（6）如果驗證通過，用戶端生成一個随機對稱密鑰，用該密鑰加密要發送的URL連結申請，再用伺服器端的公鑰加密該密鑰，把加密的密鑰和加密的URL連結一起發送到伺服器。
（7）伺服器端使用自身的私鑰解密，獲得一個對稱密鑰，再用該對稱密鑰解密經加密的URL連結，獲得URL連結申請。
（8）伺服器端根據獲得的URL連結取得該連結的網頁，并用用戶端發來的對稱密鑰把該網頁加密後發給用戶端。
（9）用戶端收到加密的網頁，用自身的對稱密鑰解密，就能獲得網頁的内容了。
（10）TCP四次揮手，通信結束。