对IKE协议中弱密钥的研究*

2014-02-10秦培斌李希源

通信技术 2014年10期

关键词：明文攻击者密钥

杨洋,花欣,秦培斌,李希源

(1.西南交通大学信息科学与技术学院,四川成都610031;2.迈普通信技术股份有限公司,四川成都610041)

对IKE协议中弱密钥的研究*

杨洋1,花欣2,秦培斌1,李希源1

(1.西南交通大学信息科学与技术学院,四川成都610031;2.迈普通信技术股份有限公司,四川成都610041)

文中介绍了IKE中密钥的产生过程,明确该过程可能产生对系统安全不利的弱密钥。对于IKE部署中是否需要进行弱密钥过滤的问题,IKE相关的多个标准文档中并未给出一致的结论,亦未给出充分的依据。在此背景下,对IKE标准文档中要求必须使用的密码算法、部分建议使用的密码算法的弱密钥进行了研究。结合IKE的实际使用情况,包括密钥生存周期、IKE/IPsec报文格式等,分析了弱密钥对IKE系统的影响,明确给出了目前涉及的密码算法都不需要进行弱密钥过滤的结论。

IKE 弱密钥过滤

0 引言

IETF(因特网工程任务组)于1998年发布了安全协议标准IPsec,该协议随后成为互联网安全的基石之一。IPsec的基础是安全关联SA(Security Association),SA即通信双方协商的、IPsec所需的相关信息:如加密算法、验证算法、工作密钥等[1]。SA可通过手工配置、使用密钥交换协议两种方式生成,实际中主要采用第二种。IPsec默认的密钥交换协议是IKE(Internet Key Exchange)[2]。IKEv1协议由《RFC2409》定义,并于2005年被《RFC4306:Internet Key Exchange(IKEv2)Protocol》定义的IKEv2所替代。但由于IKEv1与IKEv2事实上的共存,本文将两个协议同时纳入研究,若无特别注明,统称为IKE。

现代密码学重要的原则是“一切秘密寓于密钥之中”,即算法的安全性基于密钥的安全性,而不是算法的保密[3];又由于IPsec被广泛的应用于政府、军队、银行等敏感组织的网络系统,因此IKE产生的密钥的安全性非常重要。

在密码学中,弱密钥是指这样一类密钥:使用它们进行加密,会降低密文的安全强度。因此研究IKE中的弱密钥,并提出明确的处理方法是非常有必要的。

1 IKE密钥产生过程

IKE协议要求通信双方协商prf(pseudo random function),即伪随机数产生器。将通信双方协商的参数如Diffie-Hellman共享秘密等作为prf的输入, prf的输出则作为密钥种子。密钥种子经过一定的变换和截取,作为最终的工作密钥。

以IKEv2的密钥产生具体过程为例:

SKEYSEED=prf(Ni|Nr,g^ir)

{SK_d|SK_ai|SK_ar|SK_ei|SK_er|SK_ pi|SK_pr}=prf+

(SKEYSEED,Ni|Nr|SPIi|SPIr)

SKEYSEED为密钥种子,Ni、Nr分别为发送端和响应端的Nonce字段,g^ir为Diffie-Hellman共享秘密。SPIi、SPIr分别为发送端和响应端的SPI。SK _ai、SK_ar、SK_ei、SK_er、SK_pi、SK_pr为IKE的工作密钥。prf+表示用以下方式对prf的输出结果进行扩展:

prf+(K,S)=T1|T2|T3|T4|...

T1=prf(K,S|0x01)

T2=prf(K,T1|S|0x02)

T3=prf(K,T2|S|0x03)

T4=prf(K,T3|S|0x04)

得到SK_d后,用以下方式生成KEYMAT,IPsec的工作密钥在KEYMAT中截取。

KEYMAT=prf+(SK_d,Ni|Nr)KEYMAT= prf+(SK_d,g^ir(new)|Ni|Nr)

可见不管经过多么复杂的中间变换,工作密钥实际上就是伪随机数产生器产生的一串随机数。既然是随机数,就可能取到密钥样本空间中的任一样本,包括弱密钥(若该密钥样本空间存在弱密钥)。

2 IKE中密码算法的弱密钥的分析

要研究IKE的弱密钥,首先要确定IKE使用的密码算法的种类。为了保证互用性,IKE标准文档规定了部署时必须支持的密码算法;同时对另外一些密码算法作出了明确的描述,可理解为建议部署。

IKEv1必须支持的密码算法为:CBC模式的DES、MD5、SHA。

IKEv2必须支持的密码算法:3DES、PRF_HMAC _SHA1、AUTH_HMAC_SHA1_96[4]。

IKEv1相关标准明确描述的密码算法:DES、3DES、RC5、IDEA、CAST、BLOWFISH、3IDEA、RC4[5]。

IKEv2相关标准明确描述的密码算法:DES、3DES、RC5、IDEA、CAST、BLOWFISH、3IDEA、AES[6]。

同时考虑到思科以及国内一些网络设备厂商对IKE密码算法的使用情况,本文将研究聚焦于以下算法:DES、3DES、RC5、CAST、BLOWFISH、AES、HMAC_SHA1。

2.1 DES

数据加密标准(Data Encryption Standard,DES)是在二十世纪七十年代由美国国家标准局发布实施,并得到ISO认可的一种密码算法。虽然随着计算机能力的提高,DES已不再足够安全,但其加解密速度快,仍被广泛使用。

DES的密钥共64位,不考虑每个字节第8位的奇偶校检位,则为56位,在DES的每一轮加密中,从56位密钥生出不同的48位子密钥。生成方法为:56位密钥被分成两部分,每部分28位[7]。然后根据轮数,这两部分分别循环左移1位或2位。若密钥的两部分的所有位都是0或1,那么每一轮使用的子密钥都是相同的。这些就是DES的弱密钥。

该弱密钥降低了密文的“混淆”程度(扩散和混淆是密码算法设计的基本方法),也就降低了密码算法的安全强度。另外DES还存在60个半弱密钥,类似于弱密钥——存在着重复的子密钥,但子密钥不全相同。

2.2 3DES

3DES是DES的变形,3DES共有4种不同模式,RFC标准中使用的是DES-EDE3模式[8]。该模式对一个明文块使用3个互不相同的密钥,依次使用加密-解密-加密算法。加解密过程如图1所示。

图1 DES-EDE3Fig.1 DES-EDE3

《RFC2451》中阐述:DES-EDE3没有必要针对弱密钥或补密钥作特殊处理。但当K1=K2,或者K2=K3时,DES-EDE3退化为DES。

当退化为DES,DES-EDE3实际上存在着和DES相同的弱密钥和半弱密钥。

2.3 BLOWFISH

BLOWFISH是1993年由Bruce Schneider设计的一种分组密码算法,能够保证很好的加密速度,得到较为广泛的应用[9]。

BLOWFISH的弱密钥有两种。

第一种是S-盒中有两个及以上的相同元素。对已知S-盒、加密轮数为r的BLOWFISH算法使用差分攻击,需要28r+1个选择明文来得到密钥;但对于弱密钥产生的S-盒,所需选择明文降低为24r+1。如果S-盒未知,差分攻击能探测出是否使用了弱密钥,但不能求出S-盒和密钥。而且此攻击仅对轮数小于16轮的BLOWFISH有效。

第二种叫做“反射型弱密钥”,BLOWFISH有大约2k+32-16r个反射型弱密钥。其中k为密钥长度,r为轮数。通过234个选择明文可确定未知密钥是否为反射型弱密钥。若已知密钥为反射型弱密钥,则最快可通过r·2k-11次密文运算推算出密钥[10]。

2.4 RC5

RC5是1994年由Ronald L.Rivest设计的一种参数可变的分组密码算法,3个可变参数是:分组大小、密钥大小、加密轮数。

即使在多轮加密的RC5算法中,依然存在着一类会在线性攻击下暴露出来的弱密钥[11]。

记RC5弱密钥为WKm,其中m代表该类弱密钥能够压缩的加密轮数。如加密轮数为12的RC5的弱密钥WK5,表示该弱密钥使该RC5的强度和加密轮数为7的RC5相同。给定WKm,则破解该RC5所需的已知明文块数目Np确定。

设密钥随机产生,则产生WKm的几率为:

此时破解所需的已知明文块数目为:

其中1＜m＜r-1,ω表示明文块的一半的比特数。

2.5 CAST、AES、HMAC_SHA1

CAST、AES、HMAC_SHA1暂不存在弱密钥[12-13]。

3 IKE是否需要进行弱密钥过滤

经上节分析,由于弱密钥或半弱密钥降低了密码算法的安全强度,理论上使用密码算法之前应该检查密钥是否为弱密钥或半弱密钥,并抛弃弱密钥或半弱密钥。《RFC2409》正是这样规定:在使用DES时,应该过滤掉弱密钥和半弱密钥。《RFC2451》亦阐述:应该进行弱密钥检查。如果找到这样的密钥,应该将其丢弃并重新建立SA。

但在《RFC3602》中有如下阐述:当使用动态密钥管理协议,如IKE时,不应部署弱密钥检测,因为这会增加系统复杂度而且会弱化系统的安全度。而在IKEv2的标准文档《RFC4306》中未提弱密钥检测或过滤的问题。

相关RFC在给出上述结论时,未同时给出充分的依据。下文将结合实际情况对各个算法进行分析,给出所涉及的加密算法不需要进行过滤的明确结论。在分析之前需明确一个前提:弱密钥的过滤将增加IKE系统的复杂度。因此本文中判断是否应进行弱密钥过滤的依据不是弱密钥过滤是否带来安全性的收益,而是这种收益是否显著到值得付出额外的系统复杂度。

3.1 IKE工作密钥的使用期限

在IKEv1的标准文档《RFC2409》、IKEv2的标准文档《RFC4306》中未规定SA的使用期限。但在《RFC4308》中规定“建议使用的IKEv1配置套件”(包括SA)的使用期限为24小时(第一阶段)、8小时(第二阶段)。对于IKEv2,以思科某新型路由器为例,ISAKMP SA的默认使用期限为24小时,ipsecSA的默认使用期限为460 800 kb流量或1小时。

由于SA包括工作密钥,因此SA的使用期限即工作密钥的使用期限。

由于流量不便于估算,下文将使用时间期限最短的ipsec SA作为参照,即设工作密钥的使用期限为1小时。

3.2 DES

产生弱密钥及半弱密钥的概率为弱密钥及半弱密钥的总数除以密钥总数,即64/254=1/248。出现一个使用弱密钥或者半弱密钥的SA的期望时间为:

显然,即使攻击者能够快速破解使用弱密钥或半弱密钥的DES,去等待使用弱密钥或者半弱密钥的SA的出现是毫无意义的。因此在IKE中不需进行DES弱密钥或半弱密钥的过滤。

3.3 3DES

当K1=K2,或者K2=K3时,DES-EDE3退化为DES。考虑到DES密钥的有效长度为56比特,则随机产生DES-EDE3的密钥,K1=K2或者K2=K3的概率为:

在此基础上,产生弱密钥或半弱密钥的概率为:

根据3.2节的结论,此概率小到可忽略。因此,在IKE中不需要进行3DES弱密钥或半弱密钥的过滤。

3.4 BLOWFISH

IKE所使用的BLOWFISH默认加密轮数为16轮,默认密钥长度为128比特。

如2.3节所述,加密轮数为16的BLOWFISH可抵御针对于S-盒中有两个及以上相同元素的弱密钥的攻击。

对于反射攻击,BLOWFISH有大约2k+32-16r个反射型弱密钥,当k=128,加密轮数r=16:

即IKE所使用的BLOWFISH算法约含有0个反射型弱密钥。

因此IKE中不需要进行BLOWFISH弱密钥过滤。

3.5 RC5

IKE中所使用的RC5默认轮数为16轮,默认密钥长度为128比特,明文块长度为64比特。即r= 16,ω=25。则:

可知,弱密钥能够压缩的加密轮数和该类弱密钥产生的几率成反比。取破解所需明文块最少的极端情况:

然后估算攻击者可得到多少个已知明文。在IKE主模式中最后两个报文被加密。其中ISAKMP头部格式如下,每个字段的明文均可被攻击者获取,一共224≈28比特。

图2 ISAKMP头部Fig.2 ISAKMP header

攻击者无法获取IKE加密报文的其余部分对应的明文。

在IPsec的ESP报文中,在隧道模式下,攻击者可获得IP报头中的版本字段的明文,仅22比特。在传输模式下,攻击者无法获得任何明文。

可见攻击者所能获得的明文比特数远小于理想情况下所需的最小明文比特数。

因此RC5不需要进行弱密钥过滤。

3.6 CAST、AES、HMAC_SHA1

因暂无弱密钥,因此不需要进行弱密钥过滤。

4 结语

本文对IKE及IKEv2协议所使用的密码算法的弱密钥进行了逐个分析,结合它们的实际应用,得出了在上述协议中都不需要进行弱密钥过滤的结论。根据此结论,在网络设备中实现IKE或IKEv2协议时,无需实现弱密钥过滤的功能,而不会降低系统的安全性。但需要注意的是,随着研究的深入,已有密码算法可能暴露出新的弱密钥。另外,IKE协议本身处于演进过程之中,未来可能使用新的密码算法。这些新老密码算法可能出现的新的弱密钥会具有怎样的性质、需不需要进行弱密钥过滤有待后续的研究。

[1] KENT S.,ATKINSON R..RFC2401,Security Architecture for the Internet Protocol[S].American:IETF:10-11 [2014].http://www.rfc-editor.org/rfc/rfc2401.txt.

[2] HARKINS D.,CARREL D..RFC2409,The Internet Key Exchange(IKE)[S].American:IETF:5-8[2014].http://www.rfc-editor.org/rfc/rfc2409.txt.

[3] 张仕斌,万武南,张金全,孙宣东.应用密码学[M].第一版.西安:西安电子科技大学出版社,2009:15.

ZHANG Shi-bin,WAN Wu-nan,ZHANG Jin-quan, SUN Xuan-dong.Applied Cryptography[M].1sted.. Xian:Xidian University Press,2009:15.

[4] SCHILLER J..RFC4307,Cryptographic Alogrithms for Use in the Internet Key Exchange Version 2(IKEv2) [S].American:IETF:2-3[2014].http://www.rfc-editor.org/rfc/rfc4307.txt.

[5] PIPER D..RFC2407,The Internet IP Security Domain of Interpretation for ISAKMP[S].UK:IETF:9[2014].http://www.rfc-editor.org/rfc/rfc2407.txt.

[6] KAUFMAN C..RFC4306,Internet Key Exchange(IKEv2) Protocol[S].American:IETF:49-50[2014].http://www. rfc-editor.org/rfc/rfc4306.txt.

[7] 王善跃,何小海,罗代升,宁国强.通信信息加/解密研究进展[J].通信技术,2010,43(04):101-103.

WANG Shan-yue,HE Xiao-hai,LUO Dai-sheng,NING Guo-qiang.Study Progress for Encryption/Decryption of Communication Information[J].Communications Technology,2010,43(04):101-103.

[8] PEREIRA R..RFC2451,The ESP CBC-Mode Cipher Algorithms[S].American:IETF:4[2014].http://www.rfc -editor.org/rfc/rfc2451.txt.

[9] SCHNEIER Bruce.Applied Cryptography,Protocols,Algorithms,and Source Code in C[M].2nd ed.Beijing: China Machine Press,2001:237-240.

[10] KARA Orhun,MANAP Cevat.A New Class of Weak Keys for Blowfish[C]//Fast Software Encryption.Luxembourg:Springer,2007:167-180.

[11] HEYS H.M..Linearly Weak Keys of RC5[J].IEE E-lectronics Letters.1997(33):836-838.

[12] FRANKEL S..RFC3602,The AES-CBC Cipher Algorithm and Its Use with IPsec[S].American:IETF:3 [2014].http://www.rfc-editor.org/rfc/rfc3602.txt.

[13] MADSON C..RFC2404,The Use of HMAC-SHA-1-96 within ESP and AH[S].American:IETF:2[2014].http://www.rfc-editor.org/rfc/rfc2404.txt.

YANG Yang(1988-),male,graduate student,majoring in computer network security.

花欣(1956—),男,硕士,教授,主要研究方向为计算机网络;

HUA Xin(1956-),male,M.Sci.,professor,mainly working at computer network.

秦培斌(1989—),男,硕士研究生,主要研究方向为嵌入式软件开发;

QIN Pei-bin(1989-),male,graduate student,majoring in embedded software engineering.

李希源(1988—),男,硕士研究生,主要研究方向为嵌入式软件开发。

LI Xi-yuan(1988-),male,graduate student,majoring in embedded software engineering.

Weak Keys in IKE Procotol

YANG Yang1,HUA Xin2,QIN Pei-bin1,LI Xi-yuan1
(1.School of Information Science and Technology,Southwest Jiaotong University,Chengdu Sichuan 610031,China; 2.Maipu Communication Technology Co.,Ltd,Chengdu Sichuan 610041,China)

This paper describes key generating process of IKE,explains that this process may generates weak keys and this could reduce the security of the system.Related RFCs of IKE give no coincident conclusions on whether the weak keys in IKE deployment should be filtered,and no convincible arguments.In this context, this paper discusses the weak keys of ciphering algorithms labeled as MUST and some other ciphering algorithms labeled as SHOULD or MAY in related RFCS.Then the effect of weak keys based on practical use is analyzed,including life time of keys,message format of IKE/IPsec,etc.Finally,this paper explictly draws the conclusion that there is no need to filter weak keys of the currently-involved ciphering algorithms.

IKE;weak key;filter

TN918

1002-0802(2014)10-1198-05

10.3969/j.issn.1002-0802.2014.10.018