鏈路加密

鏈路加密

使用鏈路加密裝置能為某鏈路上的所有報文提供傳輸服務。即經過一台節點機的所有網路信息傳輸均需加、解密,每一個經過的節點都必須有密碼裝置,以便解密、加密報文。如果報文僅在一部分鏈路上加密而在另一部分鏈路上不加密,則相當於未加密,仍然是不安全的。與鏈路加密類似的節點加密方法,是在節點處採用一個與節點機相連的密碼裝置(被保護的外圍設備),密文在該裝置中被解密並被重新加密,明文不通過節點機,避免了鏈路加密關節點處易受攻擊的缺點。

簡介

鏈路加密鏈路加密
鏈路加密是傳輸數據僅在物理層前的數據鏈路層進行加密。接收方是傳送路徑上的各台節點機,信息在每台節點機內都要被解密和再加密,依次進行,直至到達目的地
使用鏈路加密裝置能為某鏈路上的所有報文提供傳輸服務。即經過一台節點機的所有網路信息傳輸均需加、解密,每一個經過的節點都必須有密碼裝置,以便解密、加密報文。如果報文僅在一部分鏈路上加密而在另一部分鏈路上不加密,則相當於未加密,仍然是不安全的。與鏈路加密類似的節點加密方法,是在節點處採用一個與節點機相連的密碼裝置(被保護的外圍設備),密文在該裝置中被解密並被重新加密,明文不通過節點機,避免了鏈路加密關節點處易受攻擊的缺點。

特點

對於在兩個網路節點間的某一次通信鏈路,鏈路加密能為網上傳輸的數據提供安全保證。對於鏈路加密(又稱線上加密),所有訊息在被傳輸之前進行加密,在每一個節點對接收到的訊息進行解密,然後先使用下一個鏈路的密鑰對訊息進行加密,再進行傳輸。在到達目的地之前,一條訊息可能要經過許多通信鏈路的傳輸。
由於在每一個中間傳輸節點訊息均被解密後重新進行加密,因此,包括路由信息在內的鏈路上的所有數據均以密文形式出現。這樣,鏈路加密就掩蓋了被傳輸訊息的源點與終點。由於填充技術的使用以及填充字元在不需要傳輸數據的情況下就可以進行加密,這使得訊息的頻率和長度特性得以掩蓋,從而可以防止對通信業務進行分析。
儘管鏈路加密在計算機網路環境中使用得相當普遍,但它並非沒有問題。鏈路加密通常用在點對點的同步或異步線路上,它要求先對在鏈路兩端的加密設備進行同步,然後使用一種鏈模式對鏈路上傳輸的數據進行加密。這就給網路的性能和可管理性帶來了副作用。
線上路/信號經常不通的海外或衛星網路中,鏈路上的加密設備需要頻繁地進行同步,帶來的後果是數據丟失或重傳。另一方面,即使僅一小部分數據需要進行加密,也會使得所有傳輸數據被加密。
在一個網路節點,鏈路加密僅在通信鏈路上提供安全性,訊息以明文形式存在,因此所有節點在物理上必須是安全的,否則就會泄漏明文內容。然而保證每一個節點的安全性需要較高的費用,為每一個節點提供加密硬體設備和一個安全的物理環境所需要的費用由以下幾部分組成:保護節點物理安全的雇員開銷,為確保全全策略和程式的正確執行而進行審計時的費用,以及為防止安全性被破壞時帶來損失而參加保險的費用。
在傳統的加密算法中,用於解密訊息的密鑰與用於加密的密鑰是相同的,該密鑰必須被秘密保存,並按一定規則進行變化。這樣,密鑰分配在鏈路加密系統中就成了一個問題,因為每一個節點必須存儲與其相連線的所有鏈路的加密密鑰,這就需要對密鑰進行物理傳送或者建立專用網路設施。而網路節點地理分布的廣闊性使得這一過程變得複雜,同時增加了密鑰連續分配時的費用。

還有一種方式:端--端加密

端--端加密是為數據從一端傳送到另一端提供的加密方式。數據在傳送端被加密,在最終目的地(接收端)解密,中間節點處不以明文的形式出現。
採用端--端加密是在套用層完成,即傳輸前的高層中完成。除報頭外的的報文均以密文的形式貫穿於全部傳輸過程。只是在傳送端和最終端才有加、解密設備,而在中間任何節點報文均不解密,因此,不需要有密碼設備。同鏈路加密相比,可減少密碼設備的數量。另一方面,信息是由報頭和報文組成的,報文為要傳送的信息,報頭為路由選擇信息。由於網路傳輸中要涉及到路由選擇,在鏈路加密時,報文和報頭兩者均須加密。而在端--端加密時,由於通道上的每一個中間節點雖不對報文解密,但為將報文傳送到目的地,必須檢查路由選擇信息,因此,只能加密報文,而不能對報頭加密。這樣就容易被某些通信分析發覺,而從中獲取某些敏感信息。

加密傳輸方式的比較

數據保密變換使數據通信更安全,但不能保證在傳輸過程中絕對不會泄密。因為在傳輸過程中,還有泄密的隱患。
採用鏈路加密方式,從起點到終點,要經過許多中間節點,在每個節點地均要暴露明文(節點加密方法除外),如果鏈路上的某一節點安全防護比較薄弱,那么按照木桶原理(木桶水量是由最低一塊木板決定),雖然採取了加密措施,但整個鏈路的安全只相當於最薄弱的節點處的安全狀況。
採用端--端加密方式,只是傳送方加密報文,接收方解密報文,中間節點不必加、解密,也就不需要密碼裝置。此外,加密可採用軟體實現,使用起來很方便。在端--端加密方式下,每對用戶之間都存在一條虛擬的保密信道,每對用戶應共享密鑰(傳統密碼保密體制,非公鑰體制下),所需的密鑰總數等於用戶對的數目。對於幾個用戶,若兩兩通信,共需密鑰n*(n-1)/2種,每個用戶需(n-1)種。這個數目將隨網上通信用戶的增加而增加。為安全起見,每隔一段時間還要更換密鑰,有時甚至只能使用一次密鑰,密鑰的用量很大。
鏈路加密,每條物理鏈路上,不管用戶多少,可使用一種密鑰。在極限情況下,每個節點都與另外一個單獨的節點相連,密鑰的數目也只是n*(n-1)/2 種。這裡n是節點數而非用戶數,一個節點一般有多個用戶。
從身份認證的角度看,鏈路加密只能認證節點,而不是用戶。使用節點A密鑰的報文僅保證它來自節點A。報文可能來自A的任何用戶,也可能來自另一個路過節點A的用戶。因此鏈路加密不能提供用戶鑑別。端--端加密對用戶是可見的,可以看到加密後的結果,起點、終點很明確,可以進行用戶認證。
總之,鏈路加密對用戶來說比較容易,使用的密鑰較少,而端--端加密比較靈活,用戶可見。對鏈路加密中各節點安全狀況不放心的用戶也可使用端--端加密方式。
絡設施。而網路節點地理分布的廣闊性使得這一過程變得複雜,同時增加了密鑰連續分配時的費用。

設計思路

數據鏈路層是OSI系統結構中的第二層,如果採用鏈路加密,則網路中每條通信鏈路上的加密是獨立實現的。對每條鏈路可以使用不同的密鑰,這樣,當某條鏈路受到破壞時也不會導致其他鏈路上傳遞的加密信息被解出。
NDIS微連線埠驅動位於網路鏈路層,是網路驅動中與網卡結合最緊密的驅動程式。因此可以對微連線埠驅動程式進行改造,在驅動程式中實現對數據幀的截取,並調用加解密模組對數據進行加解密。

數據的傳送和截取

數據的傳送由上層協定驅動發起,傳送的數據信息用一個NDIS_PACKET包來描述。NDIS庫提供了一些函式來提取包中的信息,並對其進行處理。
傳送過程可分為兩種情況:
1)當協定驅動程式有數據要傳送時,啟動傳輸操作,通過NIDS庫調用微連線埠驅動程式的MYNE2000Send函式。該函式調用的參數是一個指向NDIS_PACKET包(描述將要傳送的信息)的指針。驅動調用NdisQueryPacket函式得到包的長度和存放待傳送包緩衝區的邏輯地址。然後設定NIC上的暫存器將包傳送出去,並返回一個傳送成功的狀態。
2)如果驅動程式不能立即傳送包,則將它送到“待傳輸”佇列中,然後由中斷處理函式MYNE2000HandleInterrupt來完成傳送。完成傳送以後,調用NdisMSendComplete函式通知上層傳送已經完成。
由於從上層傳下來的數據包到微連線埠層被放在預先分配的緩衝區中。用NDIS提供的相應函式,可以得到該緩衝區的首地址和數據長度。因此,可在驅動程式中加入Send_Intercept子程式,利用NDIS提供的函式得到存放數據緩衝區的相應參數。然後調用加密模組接口函式DES_ENCRYPT對數據包進行加密。最後調用CardWrite子程式將加密後的密文傳送到網路上。
這裡需要注意的是當微連線埠驅動程式準備傳送數據包時,總是認為上層的協定驅動程式不會傳送一個太大的數據包到微連線埠層。因為根據NDIS,協定驅動程式會在初始化時查詢微連線埠並決定包的最大長度,協定驅動只能傳送大小在微連線埠層所支持範圍內的數據包。在本方案中,數據包的最大長度不會超過1514位元組

數據的接收和截取

數據接收是將網路上的數據幀接收到網卡緩衝區中,然後由驅動程式將緩衝區中的數據讀入記憶體中。
網卡接收數據時會產生一個中斷,因此驅動程式接收數據首先要在中斷處理過程MYNE2000HandleInterrup中進行。對於乙太網卡,程式調用NdisMEthReceiveIndicate函式將一個稱為lookahead的數據傳遞給上層協定驅動,由協定驅動檢查收到的數據是否符合協定要求。lookahead是指網卡中準備接收的數據的一部分。因為協定驅動判斷微連線埠接收的數據是否符合協定要求時,不需要對所有數據都進行判斷,只需對一部分數據(lookahead)進行判斷即可。
如果協定驅動判斷數據符合要求,就會調用微連線埠的MYNE2000TransferData函式,將除lookahead之外剩餘的數據傳送到記憶體中,再交給上層驅動處理。當傳送完畢時,調用NdisMEthReiveIndicatecomplete函式通知上層驅動數據已經接收完畢。如果協定驅動檢查數據不符合要求,就會終止接收過程。而已經傳送到記憶體中的lookahead也會被下次接收到的數據覆蓋掉。
在接收過程中截取數據需要注意一個問題。按照NDIS的規定:在接收數據時,先要調用NdisMEthReceiveIndicate函式將網卡緩衝區中接收的數據的一部分(lookahead)送到上層驅動程式,餘下的數據仍在網卡緩衝區中。但是這樣會把密文數據分割開,從而無法完成對數據的解密。
因此,必須另外開闢出一塊緩衝區Prebuffer,在接收截取子程式Receive_Intercept中先調用CardRead子程式,將網卡緩衝區中所有密文數據送入記憶體緩衝區Prebuffer,同時得到數據長度。然後調用解密模組函式DES_DECRYPT對密文進行解密,解密後的數據存放在Prebuffer中。接下來按照原先的接收順序,先送一部分數據到lookahead,交協定驅動確認後,再將剩餘數據送往上層,最後調用Indicatecomplete函式表示接收過程已經結束。

加解密的實現

加解密實現的主要思想是將加解密算法集成到驅動程式中,本方案採用傳統的DES加解密算法作為示例。
數據在被送入加密模組之前已經成幀,前14個位元組存放的是源地址、目的地址和數據長度。傳送截取函式Send_Intercept得到將要加密的數據長度和起始地址後,調用加密模組的接口函式DES_ENCRYPT,從數據的第15個位元組開始進行加密,這樣就將除地址和數據長度之外的所有數據都進行了加密。數據進行加密之後,驅動程式調用CardWrite函式將數據傳送到網路中。
由於採用的是分組加密算法,密文長度和明文長度一致。這樣就保證了傳送的密文長度不會超過乙太網協定所規定的幀最大長度,也就不存在因數據過長而需要對數據進行分割的問題。
數據幀被接收到網卡緩衝區後,讀入到記憶體當中的前14個位元組數據為源地址、目的地址和數據長度。這14個位元組的信息是以明文形式存在的。解密時,接收截取子程式Receive_Intercept調用解密模組接口函式DES_DECRYPT,從密文數據的第15個位元組開始進行解密運算。解密之後將數據存入預先分配的緩衝區Prebuffer中。此後,驅動程式無論調用NdisMEthReceiveIndicate函式,還是MYNE2000TransferData函式,都是從緩衝區Prebuffer中讀取數據,而不是從網卡緩衝區中讀取,直至解密過程結束。
作者利用driverstudio提供的工具TrueCoverage對驅動程式進行了編譯,生成MYNE2000.SYS檔案。經安裝測試,數據可以在兩台安裝有該檔案的主機上進行正常傳輸。而在同一區域網路內的其它主機無法得到正常的數據。實驗證明本加密方案的設計思路是可行的。
用軟體實現對數據的加解密有著一定的局限性,特別是處理速度較慢。本方案經過適當修改可以採用硬體實現。在實際使用當中,將部分功能用硬體實現,可以得到更快的執行速度,從而提高整個系統的性能

相關詞條

相關搜尋

熱門詞條

聯絡我們