例說圖解TCP/IP協議族--PKI與證書(1)密碼學基礎

1. 安全的四大要素

    講安全,一般都會提及到安全的四大要素:

    機密性,發送方利用祕鑰對數據進行加密,然後在網絡中傳輸的數據由明文變成密文,接受方利用祕鑰解密數據.

    完整性,雖然網絡中傳輸的數據是密文,但如果密文被第三方修改,那麼數據也就失去了意義,所以發送方用完整性算法來對數據做摘要,然後把摘要跟隨密文一起發給接收方,接受方對收到的密文做摘要,與發送方發來的摘要比對,如果相同,則接受該數據,如果不同則丟棄,要求發送方重發.

    身份認證, 數據再怎麼安全,再怎麼完整,也得保證通信雙方的身份是真實的,而不是僞造的,所以在通信前需要對雙方的身份進行認證.

    不可否認性, 前面產生的數據是的的確確發生的,如果通信一方否認該數據,這也不行,所以還需要對已經交換的數據,通信雙方無法否認.

 

2. 機密性

2.1 對稱加密算法    

    對於在網絡種傳輸的數據,爲了防止第三方查看到,通常採用加密來保護數據,即使第三方得到密文數據,由於沒有加密的密鑰,所以無法解密,也就無法查看到原始數據.

    而這密鑰就是密碼學中的對稱密鑰,所使用的加密方法,被稱之爲對稱加密算法,一般常用的加密算法有DES, 3DES, AES.其中DES所使用的密鑰長度爲56bit, 3DES則是168bit, AES有三種: 128bit, 192bit, 256bit.密鑰長度越長,安全性則越高.

    對通信雙方而言,對稱加密使用的加密算法是需要相同的,而兩者事先也不知道各自使用的對稱加密算法,所以在加密之前雙方還得協商各自使用的加密算法,而對稱加密算法的協商可以是明文,可以是密文,對於明文傳輸的加密算法,即使第三方知道也沒關係,只要沒有對稱加密的密鑰也無法獲取數據內容.

    上面提到的對稱加密的密鑰,雙方都是需要知道的,一個用之加密,一個用之解密.那通信雙方是如何知道或者產生這密鑰呢?答案有多種,在實際中也有各自的使用場景.一個是提前在通信雙方設備上配置相同的密鑰,即PSK(預共享密鑰),PSK不要在網絡中傳輸,還有一種是在雙方通信時臨時產生一個密鑰,通信結束時密鑰丟棄,即session key(SK),需要在網絡中傳輸.

    對於PSK而言,如果有N個人需要兩兩通信,則需要N*(N-1)個密鑰,而且如果有一方的密鑰改變了,另一方也得改變,這需要重新修改配置,維護困難,另外如果密鑰一直不動,如果密鑰被第三方通過其他途徑知道,數據還是不安全.

2.2 非對稱加密算法

    上文提到SK, 由於密鑰是通信雙方臨時產生的,所以免去了維護困難的問題,而且第三方即使知道本次會話的密鑰,也只能破解本次會話的數據.當然除了以上的好處之外,還引入了另一個問題,通信雙方是如何產生並安全傳輸SK的呢?

    要安全傳輸SK,很顯然也不能在網絡中明文傳輸SK. 那要怎麼才能安全傳輸SK?答案是採用非對稱密鑰加密SK,假設通信雙方爲A和B, A要把SK傳給B,A可以用B的公鑰加密SK,然後發給B,由於只有B纔有B自己的私鑰,所以SK可以被B解密獲取,而第三方沒有B的私鑰,無法解密SK.

    當然可能有人會想既然公/私鑰也可以加解密,爲何不用公/私鑰加解密真正的數據,而是加解密SK呢?這主要是由於公/私鑰對設備的性能消耗巨大,而過用來加解密真實的數據,那消耗的資源可不是一點半點,由於SK長度相對於真實數據很短,所以一般公/私鑰用來加解密SK,而不是真實數據.

2.3 密鑰交換算法

    上文只是解決了SK傳輸過程中的安全問題,關於產生和傳輸SK的問題還沒解決.其實在網絡中並沒有傳輸真正的SK,而只是傳輸產生SK的密鑰種子而已.而真正的SK是根據這些密鑰種子和其他參數還有算法生成的. 而要傳輸SK的密鑰種子,就用到密鑰交換算法(KE, Key Exchange),常用的KE算法有RSA, DH, ECDHE等, 而這幾種KE算法所需要的參數和祕鑰種子是不同的.

    上面提及到的RSA算法,其實既可以做公私算法,也可以用於密鑰交換.

2.4 僞隨機數生成器

    上文提到了在網絡中採用KE算法交換密鑰種子,但是光有密鑰種子還不夠, 還需要相應的方法來生成最後的密鑰,而這就用到僞隨機數生成器(RPF). 而雙方所採用的RPF可以提前通過明文協商.RPF所使用的輸入參數,即密鑰種子以及提前通過KE算法得到,所以雙方可以生成SK來加解密真正的數據.

 

3. 完整性

    完整性的作用是保證數據在網絡傳輸中不被篡改,如果被篡改,接收方能夠識別,並要求發送方重發.所以完整性的主要工作就是要讓數據接收方能夠判斷髮送方通過網絡發來的數據是否被篡改.

     我們一般通過哈希算法,或者叫摘要算法,來檢測數據是否被改變.原理是發送方首先採用指定的哈希算法對要發送的數據做哈希計算,得到一個哈希值,然後發送方把此哈希值附加在要發送數據的尾部,一起通過網絡給接收方.

    接收方收到數據後,用同樣的哈希算法對發送方發來的實際數據做哈希,也得到一個哈希值,然後與附加在發送方數據數據尾部的哈希值作比較.如果相同,說明數據沒被篡改;如果不同,說明數據被篡改,丟棄數據,要求重複.無論是發送方發來的實際數據被篡改,還是附加在數據後的哈希值被篡改,都會導致哈希值比較時的不匹配.

    哈希算法的幾個特點,(1)單向性,只能從數據到哈希值,從哈希值反推不出數據;(2)哈希值的大小,一般是固定的,具體多少取決於所採用的哈希算法;(3)雪崩性,哪怕數據的一個比特改變,哈希值的結果會大不相同.

    常用的哈希算法有: MD5, SHA1, SHA2_256, SHA2_384, SHA2_512.  

    

4. 身份驗證

     上文提到對網絡中傳輸的數據的加密以及完整性保護,但是忽略另一個問題,即通信有一方是Hacker,就算你數據再怎麼加密,再怎麼完整性保護,另一方是仿冒的,你的數據還是被他所竊取.所以在通信之前,我們需得保證與你通信的對方,是真正的你想要通信的對方.

     而這就涉及到要對通信雙方身份的驗證,好判斷對方是否真實.爲什麼是對通信雙方進行認證呢,很簡單,你要確保別人的身份是真實的,別人同理也要知道你的身份是真實的. 對身份的認證一般的方法有(注意: 以下方法只是說明一般使用方式,具體的協議會略有不同)

    (1)提前知道對方的ip或者標識符,對方發來的數據會攜帶對方的ip或者標識符,跟本地配置的比較.

    (2)雙方提前配置好PSK/Password,被認證方採用認證方的公鑰加密此PSK/Password,然後發給認證方,認證方用私鑰解密,得出PSK/Password的明文,跟存放在本地的比較;

        還有一種方式,發送方在本地生成一段隨機數,然後利用PSK/Password加密此隨機數,併發送密文隨機數給接收方,接收方利用自身提前配置的PSK/Password解密此隨機數,然後發送明文隨機數給發送方,發送方拿該明文隨機數與本地生成的隨機數比對.

    (3)被認證方的公鑰提前存放在認證方的指定路徑下,當通信時被認證方發送自己的公鑰給認證方,認證方會拿來跟本地存放的公鑰比較.

    (4)採用PKI體系,被認證方利用證書來證明自己的身份, 認證方提前在本地存放了被認證方CA的證書, 當被認證方發送自己的證書給認證方時, 認證方提取證書中CA的摘要值,與本地存放CA證書摘要值做比較,看是否一致.

    (5)利用username和password來做身份認證,被認證方向認證方提供username和password,認證方拿到username和password去查找數據庫,看是否匹配數據庫保存的username和password,

        該數據庫可以是認證方本地的,也可以放在第三方服務器,這可以用AAA來實現, 而且該方式一般是用於對用戶的認證,而上面的幾種方法主要是用來對用戶所使用的設備作認證.

    (6)採用EAP來做認證,瞭解過EAP或者802.1X的同學應該知道,EAP是一個認證框架,具體的認證方式可以多種多樣,比如EAP-TLS, EAP-TTLS, EAP-FAST, EAP-PEAP(包括PEAP-GTC, PEAP-MSCHAPv2),還有已經淘汰的EAP-MD5, EAP-LEAP等.具體的情況,本篇文檔不做展開,以後有時間,專門爲此另寫一篇文檔.

 

5. 不可否認性

    個人發現對於不可否認性,常用的網絡傳輸協議IPSec, SSL, SSH好像都沒有去實現,這一塊沒有仔細去研究,這裏暫且不討論,以後若有發現,再重新補上.

 

6. 總結

    以後對於網絡中常用的安全協議,比如IPSec, SSL, SSH協議的報文交互,我們可以從身份認證方式,非對稱加密算法,對稱加密算法,密鑰交換算法等方面去分析,就很容易理解,後面的文章會以此爲基礎去各個擊破這些安全協議,當然每個協議具體的細節還是有所不同.

    上文說了重點說了密碼學四大要素中的三個:機密性, 完整性, 身份認證.下面以一個表格來總結下.

常用安全算法
對稱加密算法 密鑰交換算法 非對稱加密算法 哈希算法 身份認證方式
DES RSA RSA MD5 IP/Idenfication
3DES

DH

DSA SHA1 PSK/Password
AES_128bit ECDHE ECDSA SHA2_224bit Public Key
AES_192bit   ECC SHA2_256bit PKI & Certificate
AES_256bit     SHA2_384bit username/password & AAA
        EAP

 

 

 

 

 

 

 

 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章