一種改進的適用于空間網絡的密鑰交互協議

張亞航 龐波 程博文

（北京空間飛行器總體設計部，北京 100094）

1 引言

在保密通信系統中，為保證系統的安全性，加密密鑰在使用過程中應經常更換。密鑰交換是密鑰管理中最棘手的環節，核心問題是如何保證密鑰在交換中的安全。

因特網密鑰交互協議（Internet Key Exchange，IKE）作為請求評論（Request for Comments，RFC）文檔推薦的互聯網密鑰交互協議，已經成為世界上最著名、最廣泛使用的密鑰交互協議之一。雖然協議本身過于龐雜和有一些安全漏洞，引來大量批評和攻擊。但是該協議的安全性和效率經受了時間的考驗，從這個意義上來說，IKE 協議是個成功的協議。

因特網交互安全小組（IETF）在IKEv1[1-2]的基礎上，對原先的漏洞和缺點進行改進，發展出了IKEv2，并在2005年12月推出詳細文檔[3]。之后，因特網安全小組再次對IKEv2 進行了改進，并在2010年9月推出改進版本文檔[4]。相對于IKEv1，IKEv2系統性更完整，效率更高，安全性更好。在IKEv2 的基礎上發展出適用于空間信息鏈路的安全協議是一個比較可行的方法，理由如下：

（1）空間通信安全協議由于應用范圍較小，因此無法像地面網絡應用協議一樣接受大量的分析和考驗，協議容易在構建甚至實現之后仍然存在難以發覺的漏洞[5]，而IKE協議經歷了世界上大量安全專家的分析和攻擊，其安全性和包容性經受了考驗[6-9]；

（2）相對于IKEv1，IKEv2系統性更完整，效率更好，安全性更好[7-8]；

（3）IKEv2協議繼承了IKEv1協議由ISAKMP、Oakley 和SKEME三種協議組成的模式，條例清晰，便于修改[3-4]。

本文通過對IKEv2的分析和改進，可以產生一種報文負載更加簡潔，報文頭更加少，更加適用于空間網絡鏈路的密鑰交互協議，稱之為IKESal協議。

2 IKEv2

IKEv2協議中，協商分為兩個階段，第一階段稱為初始交換（Initial Exchange），第二階段稱為產生子安全關聯交換（CREATE＿CHILD＿SAExchange），這兩個階段的交換分別協商安全關聯（IKE SA）和子安全關聯（CHILD SA），CHILD SA則主要是用于IP報文安全協議（IPSec）[10-11]或空間鏈路數據包安全協議（SCPS-SP）協議[12-13]。另外還有信息交換（INFORMATIONAL Exchange），用來向對方通知一些出錯、配置、刪除等消息。IKEv2中定義了自己的各種載荷，是在IKE 協議中載荷的基礎上做了刪減和增加。大部分載荷的作用和IKE協議中的相同，某些載荷的形式有所變化。

2.1 IKEv2協議頭格式分析

IKEv2協議頭的消息格式同IKEv1 消息格式基本類似，其主要格式如圖1所示。

圖1 IKEv2協議頭消息格式Fig.1 IKEv2 Message header

對IKEv2各個字段的分析如下：

（1）發起者安全參數索引（SPI），8byte，表示發送者用于標記IKE的唯一安全關聯，值不為零。在空間信息網絡中，通信雙方密鑰交互頻率相對地面較低，安全關聯的存儲量可以消減且不會影響安全性，因此建議簡化其SPI長度。

（2）響應者安全參數索引，8byte，在IKE 初始化的第一條消息中，包含消息重發的值均為零，除此之外的值均為非零。建議簡化。

（3）下一載荷（Next Payload），1byte，表示連著IKE 頭的下一載荷類型。對下一載荷的分析如表1所示。

（4）主版本號，4bit，IKEv2協議設置為2，IKEv1協議設置為1，建議保留。

（5）副版本號，4bit，IKE 協議的副版本，一般設置為0，忽略，建議刪除。

（6）交互類型，1byte，表示當前交互類型，包含消息中的載荷和一次交互中的消息次序，對交互類型的分析如表2所示。

（7）旗標，1byte，代表一些特殊的操作，旗標由1byte碼來表示的，其中，每個位對應一個具體的選項。比較有用的是發起方第4bit位的值設置為1，接收方第5bit位的值設置為1。為了降低空間網絡協議復雜性，建議刪除。

（8）消息標志，4byte，用于控制消息丟失后重發，并用于防止重放攻擊，建議保留。

（9）消息長度，4byte，空間數據包的長相對較短，建議簡化。

表1 下一載荷類型值分析表Table1 Next Payload value analysis

表2 交互類型值分析表Table2 Exchange type value analysis

2.2 IKEv2通用頭字段分析

IKEv2協議規定的通用頭結構如圖2所示。

圖2 IKEv2通用頭消息格式Fig.2 IKEv2generic payload header

（1）下一載荷，1byte，如果當前為最后載荷，則其值為0。因此，如果是一個加密的載荷，那么它必是最后一個載荷。

（2）關鍵字，1bit，主要用于接收方無法理解當前載荷的情況。如果值為0，則接收方忽略當前載荷，如果值為1，則接收方拒收當前的整個消息，保留。

（3）保留域，7bit，建議刪除。

（4）載荷長度，2byte，建議簡化。

3 IKESal協議

根據第二節中對IKEv2的分析，在本文中，對IKEv2進行簡化，主要是包括內容和載荷的縮小、刪減。對于IKESal協議的主要構架（包括初始化階段和子安全關聯生成階段）不進行改變。

因為當前階段，直接進行加密信道的安全關聯交互的安全協議負載過重，采用兩層階段交互的方式，可以將大量的認證加密計算放在少量使用的第一階段，而多次使用的第二階段依賴第一階段的密鑰材料，交互和計算負載可以縮小很多。

3.1 IKESal協議消息格式

空間環境相對地面互聯網仍然較為簡單，IKE中的部分字段主要是考慮了地面網絡的復雜性，在空間網絡中不能起到應用的作用，反而容易增加協議的冗余度和復雜度。為了減少協議交互信息數據量，同時保證協議安全性且能夠在空間環境適用，IKESal協議頭做了簡化。IKESal協議頭的消息格式如圖3所示。

每個字段的作用、長度和取值含義解釋如下：

（1）發起者安全參數索引，2byte，同IKEv2協議類似，值不為零。

（2）響應者安全參數索引，具體含義和用法同IKEv2協議。

（3）下一載荷，0.5byte，相對IKEv2協議，其可能的取值進行了簡化，如表3所示。

圖3 IKESal協議頭消息格式Fig.3 IKESal message header

表3 IKESal下一載荷類型值Table3 IKESal next payload type values

（4）交互類型值，0.5byte，相對于IKEv2協議，其可能的取值進行了簡化，如表4所示。

表4 IKESal交互類型值表Table4 IKESal exchange type values

（5）消息標志，4byte，相對于IKEv2協議，長度不變。

（6）消息長度，1.5byte，考慮簡化后的消息長度一般保護超過1k，設置消息長度為1.5byte，數據包總長度應小于4Kbyte。

（7）版本號，4bit，IKESal協議測試版為0，第一次應用版可以為1。

（8）保留段，1byte，考慮將來航天器應用環境擴展的保留字節。

IKESal協議頭數據結構如下所示。

IKESal協議通用頭結構圖如圖4所示。圖4IKESal協議通用頭消息格式

Fig.4 IKESal generic payload message header

（1）下一載荷，0.5byte。

（2）保留域，0.5byte，全置為零，交換中忽略。

（3）載荷長度，2byte，包括通用頭在內的當前載荷長度。

IKESal協議通用頭數據結構如下所示。

IKESal協議響應消息格式數據結構如下所示。

IKESal協議刪除消息數據結構如下所示。

3.2 IKESal協議第一階段

為了降低IKEv2 第一階段相對較大的數據交互量并考慮安全性，IKESal協議對IKEv2 第一階段交互進行了簡化，其具體消息交互流程如圖5所示。

圖5 IKESal協議第一階段交互流程Fig.5 Exchanges of initial exchanges in IKESal

其中各條消息符號代表的意義和計算方式如下所示。

（1）SK｛…｝：加密載荷，表示｛｝內所有載荷用SK＿e和SK＿a分別提供機密性和完整性保護；

（2）Prf（…）：散列算法，表示對括號里面的輸入數據進行散列運算；

（3）SA代表發起者支持的密碼算法；

（4）KE 載荷發送發起者的D-H值，通過KE，并在N 中發送nonce來完成D-H 交換。

通過IKE SA＿INIT 交換，雙方生成一個密鑰材料（SKEYSEED）計算方法如下

后續消息使用的所有密鑰材料都源于SKEYSEED。其中SK 一為CHILD SA衍生新密鑰；SK＿ai和SK＿ar用于IKE＿AUTH 消息交換的完整性保護；SK＿ei和SK＿e；用于IKE＿AUTH 的機密性保護，SK＿pi和SK＿pr用于生成AUTH 載荷，它們的計算方法如下

式中：SK＿d，SK＿ai，SK＿ar，SK＿ei，SK＿er，SK＿pi和SK＿pr的值順序地截取偽隨機函數prf的生成比特。

IKE＿AUTH 消息的作用是驗證IKE＿SA＿INIT 以及交換身份標識和證書，并建立第一個CHILD SA。發起者在IDi載荷中聲明其身份，證明其擁有和IDi相對應的秘密，并用AUTH 對前面消息的內容進行完整性保護。可以在CERT 載荷中發送其證書，并在CERTREQ 中發送證書驗證路徑。如果發送證書，則在提供的第一個證書中，必須包含用于驗證AUTH 域的公鑰。可選的IDr載荷用來明確地表明想和對方的哪個身份通信，這適應對方在同一IP地址擁有多個身份的情況。在IKE＿AUTH 消息中的AUTH 載荷中采用以下三種認證方法：

（1）RSA數字簽名；

（2）共享密鑰消息認證；

（3）DSS數字簽名。

以預共享密鑰驗證方式為例，AUTH 載荷的計算方式如下：

3.3 IKESal協議第二階段

與IKEv2類似，CREAT＿CHILD＿SA消息交換，可以在初始交換建立的IKE SA基礎上生成多個CHILD＿SA，為了降低IKEv2第二階段相對較大的數據交互量并考慮安全性，IKESal協議對IKEv2第二階段交互的消息內容同樣進行了簡化。其具體流程如圖6所示。

第二階段密鑰材料計算式，CHILD SA交換的加密密鑰生成方法如下：

圖6 IKESal協議第二階段交互流程Fig.6 Exchanges of CREATE＿CHILD＿SAexchange in IKESal

考慮前向完美保密性，使用新的g＾ir則如下：

SA的重協商有時并不需要建立一個新的IKE＿SA，而是從一個現存的IKE＿SA基礎上協商一個新SA，新IKE＿SA的SKEYSEED 計算公式如下：

4 IKESal協議交互效率分析

如圖5所示，對于消息頭部分，經過裁剪之后的IKESal協議消息頭長度，由原先的28byte降低到12byte。

1）第一階段交互量分析

對于第一階段載荷部分，為了降低交互數據量，采取了以下方案：

（1）只保留了部分核心負載類型，去除了與空間鏈路特點關系不大的載荷，如traffic selector載荷，降低了消息交換量；

（2）暫時沒有采用證書認證方式頒發證書的密鑰管理中心不適合在空間信息系統中使用，以后可以考慮組合公鑰（Combination of Public Key，CPK）模式；

（3）去除了擴展認證交互和信息交互等模式。

參考航天器當前使用密鑰材料長度，設密鑰長度（KE）字段為128byte，證書材料（Auth）字段為128byte，IKESal協議中一條消息長度將在256byte以內，因此第一階段實際交互量在4×256＝1 024byte以內。

2）第二階段交互量分析

設密鑰長度為128byte，證書材料為128byte，考慮前向完美保密性，一條消息長度不超過256byte，實際交互量在2×256＝512byte以內。

5 應用場景

本文提出的密鑰交換協議可以作為實際星地、星間密鑰交換措施，如圖7所示。

圖7 IKESal協議在空間網絡的應用Fig.7 Application of IKESal in space network

如圖8所示，以星地通信為例，設計本密鑰協商方法的具體實施方案：在衛星和地面各自配置密鑰協商模塊，可在衛星發射前預置共享的初始密鑰或證書，衛星在軌的密鑰協商通過上行遙控鏈路和下行遙測鏈路（假定上下行信道已經過認證保護）來完成。

6 結束語

IKE 得到大量分析和使用，并通過了實際驗證的安全協議。IKEv2在IKEv1的基礎上進行了改進，其安全性、系統性和簡潔性得到提高。

本文設計的IKESal協議在以下方面對IKEv2進行簡化：

（1）通過對IKEv2報文頭分析，結合航天任務與地面環境的不同，刪除或縮短部分報文段，降低了報文頭的長度和復雜度；

（2）通過對IKEv2 交互階段載荷內容進行分析，結合航天任務特點，對交互內容進行了精簡。

通過對IKEv2 的裁剪和部分修改，使IKESal協議變得更加簡潔有效，并保證了該協議的安全性，使其適用于實際空間數據系統和空間信息網絡。今后對IKESal的工作主要包含兩個方面：通過形式化語言等其他手段，對IKESal協議安全性進行更加嚴格的邏輯分析和效率分析；在實際工程實現上逐步驗證IKESal協議，使之真正能夠應用于空間信息系統，以提高我國空間網絡的安全。

（References）

[1]Harkins D，Carrel D.The internet key exchange（IKE）[S].IETF，RFC2409，November 1998

[2]Maughhan D，Schertler M，Schneider M，et al.Internet security association and key management protocol（ISAKMP）[S].IETF，RFC 2408，1998

[3]Kaufman C E.Internet key exchange（IKEv2）Protocol[S].IETF，RFC4306，2005

[4]Kaufman C，Hoffman P，Nir Y，et al.Internet key exchange protocol version 2 （IKEv2）[S].IETF，RFC5996，2010

[5]Srivastava A.Is internet security a major issue with respect to the slow acceptance rate of digital signatures[R].Computer Law and Security Report，2005

[6]Lari I A，Jorma Y ，Pekka L.Aproposal to improve IKEv2negotiation[C]//International Conference on Emerging Security Information，2007

[7]Brunstrom A，Lindskog S，Faigl Z.Analyzing IKEv2 performance when protecting mobile IPv6signaling[J].Wireless Communication Systems，2007

[8]劉海靜.IKEv2的實現及形式語言邏輯分析[D].西安：西安電子科技大學，2004

Liu Haijing.Realize and logical analysis of IKEv2protocols[D].Xi’an：Xidian University，2004 （in Chinese）

[9]Zhang Yahang，Cheng Bowen，Wen Weiing，et al.MLIKE：a multi-layer IKE protocol for TCP performance enhancement in wireless networks[C]//The International Society for Optical Engineering，2010，7651：17

[10]Knt S，Atkinson P.IP authentication header[S].IETF，RFC 2402，1998

[11]Kent S，Atkinson P.IP encapsulating security payload（ESP）[S].IETF，RFC2406，1998

[12]CCSDS.Recommendation for space data systems standards[S].Washington，D.C.：CCSDS 713.5-B-1.Blue Book.Issue 2，1999

[13]趙和平，李寧寧，CCSDS標準在軍用航天任務中的應用[J].北京：航天器工程，2007，16（4）

Zhao Heping，Li Ningning.Implementation of CCSDS standard in military space mission[J].Spacecraft Engineering，2007，16（4）（in Chinese）