一、數據加密和解密概述
數據加密和解密是一門歷史悠久的技術,從古代就已經出現了,一直發展到當代。其中,數據加密的目的有很多,可以是爲了保證本地數據存取的安全性,可以是爲了保證數據流在網絡傳輸過程中的保密性,也可以是爲了驗證數據的完整性,還可以通過數據加密來實現密鑰的交換等。
數據加密依賴於某種加密算法和加密密鑰,而數據解密則依賴於某種解密算法和解密密鑰。而在當代加密解密技術中,加密密鑰既可以與解密密鑰相同,也可以和解密密鑰不同,這取決於使用什麼方法進行加解密。
二、安全的目標
就信息傳輸過程來說,安全目標有以下三個要點:
(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四次揮手,通信結束。