一种改进的适用于空间网络的密钥交互协议

张亚航 庞波 程博文

（北京空间飞行器总体设计部，北京 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）