窄帶無線通信網(wǎng)絡(luò)中協(xié)議控制的安全加固技術(shù)研究*

雷文虎，戶江民，王均春，譚淇文，蔣元兵，康宗緒

（1.重慶金美通信有限責(zé)任公司，重慶400030；2.中國人民解放軍31006 部隊，北京 100036）

0 引 言

在窄帶無線通信網(wǎng)絡(luò)中，通信節(jié)點之間主要使用微波、衛(wèi)星、電臺等窄帶寬無線鏈路進(jìn)行節(jié)點間互聯(lián)；節(jié)點之間利用OSPF 協(xié)議、EIGRP 協(xié)議等交互路由；網(wǎng)管系統(tǒng)采用SNMPv2 協(xié)議對通信節(jié)點進(jìn)行管理控制；上層業(yè)務(wù)系統(tǒng)基于通信網(wǎng)絡(luò)提供的IP通道完成端到端的業(yè)務(wù)傳輸。

由于無線信道的開放性，雖然通信網(wǎng)絡(luò)采用了各種無線信道加密手段，仍然存在信息泄密和被竊取的風(fēng)險。因此，業(yè)務(wù)系統(tǒng)的報文在端到端傳輸前后一般都會在信源和信宿的應(yīng)用層進(jìn)行壓縮和加密等處理，以保障報文的傳輸效率及安全性。

對于通信網(wǎng)絡(luò)本身，當(dāng)網(wǎng)絡(luò)規(guī)模較大或者路由表數(shù)量較多時，網(wǎng)絡(luò)內(nèi)部會產(chǎn)生大量的協(xié)議控制報文。對于EIGRP 協(xié)議來說，標(biāo)準(zhǔn)的EIGRP 協(xié)議報文的內(nèi)容部分一般采用TLV 格式封裝，特別是其UPDATE 報文和QUERY 報文，這導(dǎo)致報文內(nèi)容的重復(fù)度較高。對于OSPF 協(xié)議來說，標(biāo)準(zhǔn)的OSPF協(xié)議報文的內(nèi)容部分主要也采用TLV 格式封裝，特別是其DD 報文和LSU 報文，同樣導(dǎo)致報文內(nèi)容的重復(fù)度較高。此外，EIGRP 協(xié)議和OSPF 協(xié)議一般都采用明文方式傳輸，即便啟用了MD5 驗證功能，也只能增加信息交換的安全性，無法實現(xiàn)信息保密，同時會增加報文長度。利用網(wǎng)管系統(tǒng)對通信節(jié)點進(jìn)行管理時，也會產(chǎn)生大量的SNMP 報文，在搜索網(wǎng)絡(luò)拓?fù)浜筒樵兺ㄐ殴?jié)點的路由表信息等操作時尤為明顯；SNMP 報文的數(shù)據(jù)部分采用BER 編碼規(guī)則進(jìn)行封裝，同樣導(dǎo)致其內(nèi)容重復(fù)度較高；某些查詢設(shè)備基礎(chǔ)信息的SNMP 報文甚至因為長度過長從而導(dǎo)致在超短波電臺信道上傳輸失敗。

針對上述問題，對窄帶無線通信網(wǎng)絡(luò)的協(xié)議控制報文的數(shù)據(jù)部分采用壓縮和加密等技術(shù)處理，縮減報文長度，降低報文對無線信道的帶寬占用，實現(xiàn)協(xié)議控制報文的安全加固，提升網(wǎng)絡(luò)安全保密能力，具有較強(qiáng)的實用意義。

1 數(shù)據(jù)壓縮技術(shù)

數(shù)據(jù)壓縮技術(shù)[1]就是減少用于存儲和傳輸信息的位的數(shù)目。數(shù)據(jù)壓縮技術(shù)按照壓縮前后信息量劃分為無損數(shù)據(jù)壓縮和有損數(shù)據(jù)壓縮。無損壓縮沒有信息丟失，可根據(jù)壓縮后的數(shù)據(jù)完全的恢復(fù)原來數(shù)據(jù)，它是一個可逆過程；有損數(shù)據(jù)壓縮是在保真情形下移除數(shù)據(jù)的壓縮編碼技術(shù)，壓縮后的數(shù)據(jù)不能完全的恢復(fù)為原來數(shù)據(jù)，它是一個不可逆過程。網(wǎng)絡(luò)中傳輸?shù)膮f(xié)議報文經(jīng)過壓縮和解壓縮之后必須完全重現(xiàn)，需要采用無損壓縮技術(shù)。常用的無損壓縮方法有：時間編碼（如游程編碼）、哈夫曼編碼、算術(shù)編碼、基于字典編碼（以LZ 碼為代表）、Rice 算法等。本文選取基于字典編碼的LZW 算法和LZJH 算法進(jìn)行數(shù)據(jù)壓縮處理。

1.1 LZW 壓縮算法

LZW（Lempel-Ziv-Welch）壓縮算法[2]由Terry Welch 在1984 年開發(fā)，是一種非常著名、基于字典的串表式無損壓縮算法，支持流式解壓縮，可以根據(jù)內(nèi)存大小選擇合適的最大字典串長。LZW 在壓縮和解壓縮階段字典都是自動生成的，它不需要對數(shù)據(jù)源進(jìn)行分析或者傳輸額外信息給解壓方，因此壓縮和解壓縮不會產(chǎn)生大量的計算代價。

LZW 壓縮算法的基本思想是建立一個串表，將輸入字符串映射成定長的碼字輸出，通常碼長設(shè)置為12 bit，也可設(shè)置為其它相應(yīng)的長度。串表具有“前綴性”：假設(shè)任何一個字符串Str 和某一個字符C組成一個字符串StrC，若StrC 在串表中，則C 為Str 的擴(kuò)展，Str 為C 的前綴。字符串表是動態(tài)生成的，編碼前先將其初始化（通常初始化為ASCII 碼的常用字符），使其包含所有可能的單個字符值。在壓縮過程中，串表中不斷產(chǎn)生壓縮信息的新字符串，存儲新字符串時也保存新字符串StrC 的前綴Str 相對應(yīng)的碼字。在解壓縮過程中，程序可根據(jù)碼字恢復(fù)出同樣的字符串表，解出編碼數(shù)據(jù)流。

1.2 LZJH 壓縮算法

LZJH（Lempel-Ziv-Jeff-Heath）壓縮算法[3]是一種基于代碼庫的、自適應(yīng)的數(shù)據(jù)壓縮算法，最初是為衛(wèi)星工業(yè)中的IP 數(shù)據(jù)包壓縮而開發(fā)的，ITU-T選擇它作為建議V.44 的基礎(chǔ)。LZJH 算法的壓縮和解壓縮數(shù)據(jù)的執(zhí)行速度很好，在兩個IP 數(shù)據(jù)報之間重設(shè)字典所花的時間也是微不足道的。

LZJH 壓縮算法的基本思想是使用1024 個碼字和一個1024 個輸入的代碼庫，它足夠壓縮一個1500字節(jié)的幀，有1024 唯一的碼字，一個對應(yīng)一個代碼庫輸入，在編碼過程中這可以表示一個字節(jié)或多個字節(jié)串?dāng)U展。如果前256 個碼字保留給一個8 比特字節(jié)所有可能的值，并且另外兩個碼字保留給控制字使用，那么串?dāng)U展得到的第一個碼字是值258。

LZJH 在任何情況下不重復(fù)使用代碼庫輸入。于是，相應(yīng)于沒有指定代碼輸入的碼字可用作解碼器的信號表示N 個字節(jié)串的擴(kuò)展。這種擴(kuò)展機(jī)理允許LZJH 把多個字節(jié)匹配字符串在數(shù)據(jù)中第二次出現(xiàn)時使用兩個碼字編碼，第三次及以后再出現(xiàn)時使用一個碼字編碼相同的字符串。根據(jù)這種字符串?dāng)U展機(jī)理，在把字符串?dāng)U展到其最大有用長度過程中，LZJH實質(zhì)上使用很少的代碼庫輸入及其相應(yīng)的碼字。

2 數(shù)據(jù)傳輸加密技術(shù)

數(shù)據(jù)加密技術(shù)[4]是為提高信息系統(tǒng)和數(shù)據(jù)的安全性和保密性，防止秘密數(shù)據(jù)被外部破譯而采用的主要技術(shù)手段之一，按照作用的不同可分為數(shù)據(jù)傳輸加密技術(shù)、數(shù)據(jù)存儲加密技術(shù)、數(shù)據(jù)完整性的鑒別技術(shù)和密鑰管理技術(shù)。

數(shù)據(jù)傳輸加密技術(shù)的目的是對傳輸中的數(shù)據(jù)流加密，防止被非法竊取、閱讀和篡改，通常有線路加密與端-端加密兩種。線路加密側(cè)重在線路上而不考慮信源與信宿，是對保密信息通過各線路采用不同的加密密鑰提供安全保護(hù)。端-端加密指信息由發(fā)送端自動加密，并且由TCP/IP進(jìn)行數(shù)據(jù)包封裝，然后作為不可閱讀和不可識別的數(shù)據(jù)穿越網(wǎng)絡(luò)，當(dāng)這些信息到達(dá)目的地，將被自動重組、解密，而成為可讀的數(shù)據(jù)。前文所述的無線信道加密手段即屬于線路加密，業(yè)務(wù)系統(tǒng)報文加密處理即屬于端-端加密。

數(shù)據(jù)傳輸加密技術(shù)歷經(jīng)單表代替、多表代替、置換、序列、分組密碼、Merkle-Hellman 背包、LOKI91、Skipjack、RC4、RC5、MD5、Blowfish、Idea、RSA、AES、DES 等加密算法。當(dāng)前比較流行的傳輸加密技術(shù)主要采用RSA 和DES 等算法。大部分加密算法加密后的內(nèi)容會比原始內(nèi)容更長，這是因為在加密過程中新增了額外的信息。

通過對壓縮算法處理后的報文內(nèi)容分析發(fā)現(xiàn)，壓縮后的數(shù)據(jù)在很大程度上已經(jīng)失去了數(shù)據(jù)的規(guī)律性，在不知道具體壓縮算法的情況下，已經(jīng)很難將數(shù)據(jù)進(jìn)行還原。因此，為提高數(shù)據(jù)的安全性，在不增加報文長度以及盡量減少加解密耗時的前提下，本文選取置換加密（Permutation）算法對報文作進(jìn)一步的加密處理。即把壓縮后的字符編碼重新排列，字符本身不變，但其位置改變了，同時將位置變換規(guī)則與數(shù)據(jù)部分長度相結(jié)合，以增加破解的難度。

3 安全加固技術(shù)實現(xiàn)

3.1 壓縮算法的實現(xiàn)

對于LZW 壓縮算法，參照Mark R. Nelson 于1989 年利用C 語言編寫的LZW 文件壓縮算法進(jìn)行改進(jìn)，使其適合于處理IP 報文數(shù)據(jù)內(nèi)容，形成獨(dú)立的LZW 算法功能模塊，對外提供lzwCompressBuf和lzwExpandBuf 兩個功能函數(shù)。lzwCompressBuf （unsigned char *inputBuf, int bufLen, unsigned char *outputBuf）函數(shù)通過inputBuf 指針接收原始數(shù)據(jù)，通過bufLen 獲知數(shù)據(jù)長度，處理結(jié)束后將壓縮數(shù)據(jù)放入outputBuf 指針?biāo)傅膬?nèi)存區(qū)，同時返回壓縮后的數(shù)據(jù)長度；如果壓縮后長度超過原始長度，則放棄壓縮并返回0，外部調(diào)用據(jù)此作特殊 處 理。 lzwExpandBuf （unsigned char *srcBufPtr, int srcBufLen, unsigned char *dstBufPtr） 函 數(shù) 通 過srcBufPtr 指針接收壓縮數(shù)據(jù)，通過srcBufLen 獲知數(shù)據(jù)長度，處理結(jié)束后將還原數(shù)據(jù)放入dstBufPtr 指針?biāo)傅膬?nèi)存區(qū)，同時返回還原后的數(shù)據(jù)長度；如果因數(shù)據(jù)錯誤等原因?qū)е陆鈮嚎s失敗，返回值為0表示異常。其中，BITS_LZW 宏定義的值原為12，經(jīng)多次實驗測試發(fā)現(xiàn)，當(dāng)值為10 時可以取得更好的壓縮效果。

對于LZJH 壓縮算法，參照ITU_T_V.44[5]的數(shù)據(jù)壓縮程序建議的壓縮算法說明，采用C 語言進(jìn)行編碼實現(xiàn)，形成獨(dú)立的LZJH 算法功能模塊，對外提供lzjhCompressBuf 和lzjhExpandBuf 兩個功能函數(shù)。lzjhCompressBuf（unsigned char *inBuf, int inBufLen）函數(shù)通過inBuf 指針接收原始數(shù)據(jù)，通過inBufLen 獲知數(shù)據(jù)長度，處理結(jié)束后將壓縮數(shù)據(jù)放入inBuf 指針?biāo)傅膬?nèi)存區(qū)，同時返回壓縮后的數(shù)據(jù)長度；如果壓縮后長度超過原始長度，則放棄壓縮并返回0，外部調(diào)用據(jù)此作特殊處理。lzjhExpandBuf（unsigned char *inBuf, int inBufLen, int maxLen）函數(shù)通過inBuf 指針接收壓縮數(shù)據(jù)，通過inBufLen 獲知數(shù)據(jù)長度，通過maxLen 獲知解壓后的最大允許長度（即inBuf 開辟的內(nèi)存區(qū)長度）以防止內(nèi)存溢出，處理結(jié)束后將還原數(shù)據(jù)放入inBuf指針?biāo)傅膬?nèi)存區(qū)，同時返回還原后的數(shù)據(jù)長度；如果因數(shù)據(jù)錯誤或長度超長等原因?qū)е陆鈮嚎s失敗，返回值為0 表示異常。其中，單字符占用最大比特數(shù)取值為8，首個可用碼字取值為4，最大字符串長度取值為255，碼字最大比特數(shù)取值為11，最大字典項數(shù)量取值為1525。

3.2 置換加密算法的實現(xiàn)

采用C語言進(jìn)行編碼實現(xiàn)，形成獨(dú)立的Permutation Encrypt 算法功能模塊，對外提供PermuteBuf 功能 函 數(shù)。PermuteBuf（unsigned char * inputBuf, int bufLen）函數(shù)通過inputBuf 指針接收原始數(shù)據(jù)，通過bufLen 獲知數(shù)據(jù)長度，結(jié)合數(shù)據(jù)長度設(shè)定不同的數(shù)據(jù)置換規(guī)則。規(guī)則示例見表1。

同時，數(shù)據(jù)置換規(guī)則支持以格式化的配置文件方式進(jìn)行加載，必要時可更換規(guī)則配置文件。

3.3 協(xié)議控制報文安全加固實現(xiàn)

測試環(huán)境下的窄帶無線通信網(wǎng)絡(luò)中的路由交換設(shè)備采用Vxworks 操作系統(tǒng)，因此本文選用Tornado IDE 作為技術(shù)研究驗證的集成開發(fā)環(huán)境，并基于Vxworks 網(wǎng)絡(luò)協(xié)議棧進(jìn)行開發(fā)實現(xiàn)。

表1 數(shù)據(jù)置換規(guī)則

路由交換設(shè)備的TCP/IP 協(xié)議棧內(nèi)部相關(guān)協(xié)議模塊之間的關(guān)系如圖1 所示。對于EIGRP 協(xié)議和OSPF 協(xié)議來說，生成的協(xié)議報文都會送到IP 協(xié)議棧的ipProto.c 文件中的ipOutput 函數(shù)進(jìn)行處理后再通過交換網(wǎng)絡(luò)從對于接口發(fā)送出去；從各接口收到的協(xié)議報文也都會通過交換網(wǎng)絡(luò)送到IP 協(xié)議棧的ip_input.c 文件中的ipintr 函數(shù)進(jìn)行處理后再被分派給相應(yīng)的協(xié)議入口處理函數(shù)。對于SNMP 協(xié)議來說，設(shè)備生成的SNMP 報文經(jīng)由UDP 模塊處理后也會送給IP 協(xié)議棧的ipOutput 函數(shù)進(jìn)行處理后再通過交換網(wǎng)絡(luò)從相應(yīng)的接口發(fā)送出去。

圖1 路由交換設(shè)備內(nèi)部相關(guān)協(xié)議模塊關(guān)系

由此可見，可在路由交換設(shè)備TCP/IP 協(xié)議棧的IP 模塊對協(xié)議控制報文進(jìn)行安全加固處理，具體實施方法如圖2 所示。路由交換設(shè)備可以通過配置選擇壓縮算法，也可結(jié)合壓縮報文特征動態(tài)選擇壓縮算法，源端設(shè)備進(jìn)行壓縮加密并在報文中攜帶上壓縮算法標(biāo)識；目的端設(shè)備收到報文后根據(jù)攜帶的壓縮算法標(biāo)識進(jìn)行解密解壓縮處理，實現(xiàn)壓縮算法的差異化。

圖2 路由交換設(shè)備協(xié)議控制報文安全加固處理

對路由交換設(shè)備的協(xié)議報文進(jìn)行特征分析發(fā)現(xiàn)，EIGRP 協(xié)議報文的特征包括：iphead.proto=88，iphead.id=0，iphead.tos=0；OSPF 協(xié)議報文的特征包 括：iphead.proto=89，iphead.id=0，iphead.tos=0； SNMP 協(xié)議報文的特征包括：iphead.proto=17， iphead.tos=0，udphead.dport=161/162。根據(jù)以上特征在ipOutput 函數(shù)中增加發(fā)送報文識別功能，并對協(xié)議報文首先進(jìn)行壓縮處理再進(jìn)行加密處理。在處理過程中，需要對報文首部的長度、ID、TOS、校驗和等字段同步進(jìn)行調(diào)整，壓縮調(diào)整對比如圖3 所示。同樣地，結(jié)合被調(diào)整字段特征在ipintr 函數(shù)中增加接收報文識別功能，并對協(xié)議報文首先進(jìn)行解密處理再進(jìn)行解壓縮處理。

對于EIGRP 協(xié)議報文和OSPF 協(xié)議報文，處理流程基本相同，將協(xié)議報文首部和內(nèi)容部分作為整體進(jìn)行壓縮。發(fā)報文時，采用壓縮算法對協(xié)議報文進(jìn)行壓縮；利用IP 首部的TOS 字段來標(biāo)識該報文是否被壓縮及其壓縮算法；利用IP 首部的ID 字段來保存報文的原始長度；采用置換加密算法對壓縮內(nèi)容進(jìn)行加密；重新計算IP 首部的校驗和。接收報文時，利用IP 首部的TOS 字段來判斷該報文是否被壓縮及其壓縮算法；采用置換加密算法對壓縮內(nèi)容進(jìn)行解密；采用壓縮算法對協(xié)議報文進(jìn)行解壓縮；利用解壓縮的協(xié)議報文內(nèi)容長度與IP 首部的ID 字段比對，判斷協(xié)議報文的正確性；恢復(fù)協(xié)議報文的IP 首部的長度、ID、TOS、校驗和等字段。

對于SNMP 協(xié)議報文，保留其UDP 首部，僅對其內(nèi)容部分進(jìn)行壓縮。發(fā)報文時，采用壓縮算法對內(nèi)容部分進(jìn)行壓縮；調(diào)整SNMP 報文的IP 首部的長度字段，但是不調(diào)整UDP 首部的長度字段；利用IP 首部的TOS 字段來標(biāo)識該報文是否被壓縮及其壓縮方法；采用置換加密算法對壓縮內(nèi)容進(jìn)行加密；重新計算IP 首部的校驗和。當(dāng)SNMP 協(xié)議報文到達(dá)網(wǎng)絡(luò)管理系統(tǒng)所接入的路由交換設(shè)備時對壓縮內(nèi)容進(jìn)行恢復(fù)，利用IP 首部的TOS 字段來判斷該報文是否被壓縮及其壓縮算法；采用置換加密算法對壓縮內(nèi)容進(jìn)行解密；采用壓縮算法對內(nèi)容部分進(jìn)行解壓縮；利用解壓縮的SNMP 報文內(nèi)容長度與UDP 首部的長度字段比對，判斷SNMP 報文的正確性；調(diào)整SNMP 報文的IP 首部的長度字段。

圖3 協(xié)議報文壓縮調(diào)整對比

如果報文在傳輸途中被篡改或者發(fā)生了錯誤，在數(shù)據(jù)的解壓縮過程將會失敗報錯，該報文將被直接丟棄，同時該事件可被識別出來并記錄下來。如此，即可在上層協(xié)議控制模塊無感的情況下，完成協(xié)議控制報文的安全加固處理。

4 測試結(jié)果與分析

在試驗環(huán)境下采用7 臺路由交換設(shè)備搭建了如圖4 所示的網(wǎng)絡(luò)拓?fù)湟阅M窄帶無線通信網(wǎng)絡(luò)， R1～R6 之間的直接連接采用ETH 接口互連，R6 與R7 之間采用超短波電臺鏈路互連，網(wǎng)絡(luò)管理系統(tǒng)采用ETH 接口與R1 互連。由于是對上層的協(xié)議報文壓縮加密效果進(jìn)行測試驗證，采用ETH 鏈路代替無線鏈路并不會對最終結(jié)果引起偏差。

在路由交換設(shè)備中對報文的壓縮加密耗時及解密解壓縮耗時分別進(jìn)行了長時間的打印統(tǒng)計，發(fā)現(xiàn)各種協(xié)議控制報文的處理耗時均不到1tick，路由交互及網(wǎng)絡(luò)管理與之前效果一樣，說明壓縮加密功能對設(shè)備的CPU 處理性能幾乎沒有影響。

圖4 試驗環(huán)境網(wǎng)絡(luò)拓?fù)?/p>

表2 協(xié)議控制報文數(shù)據(jù)壓縮效果統(tǒng)計

對協(xié)議報文的數(shù)據(jù)壓縮效果進(jìn)行了大量統(tǒng)計分析，得到平均結(jié)果如表2 所示?？梢姡瑢τ陂L度較短的報文，壓縮效果并不明顯；報文長度越長壓縮效果越好，對于EIGRP 協(xié)議的UPDATE、QUERY報文和OPSF 協(xié)議的DD、LSU 報文的壓縮效果尤為明顯；LZJH 算法的壓縮效果普遍優(yōu)于LZW 算法。

采用加密算法動態(tài)變化和置換規(guī)則動態(tài)變化相結(jié)合的手段，能進(jìn)一步增強(qiáng)數(shù)據(jù)保密能力。采用Wireshark、Ethereal 等工具軟件對路由交換設(shè)備之間的協(xié)議控制報文進(jìn)行抓包統(tǒng)計分析，報文數(shù)據(jù)部分雜亂無規(guī)律可循。

啟用協(xié)議控制報文壓縮加密功能后，所有的SNMP管控報文均能在超短波電臺信道上成功傳輸，極大地減少了電臺接口的傳輸分片處理次數(shù)。

5 結(jié) 語

利用數(shù)據(jù)壓縮和加密相結(jié)合的手段對窄帶無線通信網(wǎng)絡(luò)的協(xié)議控制報文的數(shù)據(jù)部分進(jìn)行安全加固技術(shù)處理，可在不影響網(wǎng)絡(luò)和設(shè)備原有性能的情況下大幅度縮減協(xié)議控制報文的傳輸長度，有效降低協(xié)議控制報文對無線信道的帶寬占用，提升通信網(wǎng)絡(luò)協(xié)議控制報文的傳輸效率和安全保密能力，增強(qiáng)網(wǎng)絡(luò)的內(nèi)生安全。后續(xù)可以繼續(xù)開展對OLSR、AODV 等路由協(xié)議的安全加固研究與試驗。