IKE协议中基于数字签名验证的主模式研究.docx
- 文档编号:24349491
- 上传时间:2023-05-26
- 格式:DOCX
- 页数:18
- 大小:26.20KB
IKE协议中基于数字签名验证的主模式研究.docx
《IKE协议中基于数字签名验证的主模式研究.docx》由会员分享,可在线阅读,更多相关《IKE协议中基于数字签名验证的主模式研究.docx(18页珍藏版)》请在冰豆网上搜索。
IKE协议中基于数字签名验证的主模式研究
!
第"#卷!
第$期南京邮电大学学报(自然科学版)%&’("#!
)&($
!
!
"**#年"月+&,-./’&0)/.12.34.256-7289&0:
&787/.;<6’6=&>>,.2=/82&.7()/8,-/’?
=26.=6)@6A("**#
!
!
文章编号:
$B#CDEFCG("**#)*$D**BGD*B!
"#
协议中基于数字签名验证的主模式研究张!
琳$,王汝传$,"
$H南京邮电大学计算机学院,江苏南京!
"$***C
"H南京大学计算机软件新技术国家重点实验室,江苏南京()!
"$**GC摘
!
要:
I.86-.68(因特网)密钥交换协议(IJK)由于其灵活性和复杂性,不可避免的存在某些安全隐患。
简要介绍其工作机制之后,分析了两种中间人攻击的方式,为有效抵御第二种中间人攻击,对基于
数字签名的主模式交换过程进行了改进,并提出了密钥签名载荷的概念。
最后,给出了改进前后的
定量的性能分析,结合0-66?
LMN)源代码,修改和增加了相应的函数,将改进思想融入其中。
关键词:
IJK;数字签名;主模式;中间人攻击
中图分类号:
<:
CGC(*O!
!
!
文献标识码:
P$%&%’()*+,-’./-+0%1.2*3.4/’25(%652*%/2.)’2.+/./!
"#7(+2+)+89:
6;<=./$,
>6;<$5?
)*5’/$,"
$(Q&’’636&0Q&>R,86-,)/.12.34.256-7289&0:
&787/.;<6’6=&>>,.2=/82&.7,)/.12.3"$***CQS2./
"(?
8/86J69T/A&-/8&-90&-)&56’?
&08U/-6<6=S.&’&39,)/.12.34.256-7289,())/.12.3"$**GCQS2./6@&2(’)2
:
I8272.6528/A’68S/88S6-6/-67&>676=,-289’2>28/82&.72.IJKR-&8&=&’,A6=/,76&02870’6V2A2’289/.;
=&>R’6V289(N086-8S6>6=S/.27>&0IJK272.8-&;,=6;,8S68U&W2.;7&0>/.D2.D>2;;’6/88/=W/-6/./’9X6;(I.&-D
;6-8&;606.;8S676=&.;&.6,7&>62>R-&56>6.87/-6R-676.86;2.8S6>/2.>&;6U28S723./8,-6/,8S6.82=/82&.(
Y&-6&56-8S6=&.=6R82&.&0W69D723./8,-6R/9’&/;27R-&52;6;(@2./’’9,8S6R/R6->/W67/Z,/.828/8256=/R/A2’289/D
./’9727&.8S6US&’6(P9=&>A2.2.3U28S8S6&R6.=&;6&00-66?
LMN),28>&;20267/.;/;;77&>6/RR-&R-2/860,.=D
82&.78&2.863-/868S62;6/&02>R-&56>6.82.8&IJK(
"%A1+(0&:
IJK;[2328/’723./8,-6;Y/2.>&;6;Y/.D2.D>2;;’6/88/=W!
!
收稿日期:
"**BD*CD"*
基金项目:
国家自然科学基金(B*E#C$F$、#*"#$*E*)、江苏省自
然科学基金(PJ"**E$FB)、江苏省高技术研究计划
(P\"**F**F、P\"**E*C#、P\"**E*CO、P\"**B**$)、
国家高技术研究发展计划(OBC计划)
("**BNN*$]FCG)、南京市高科技项目("**B软资
$*E)、现代通信国家重点实验室基金
(G$F*Q$$*$*$*B*C)、江苏省计算机信息处理技术重
点实验室基金(W17*E***$、W17*B*B)资助项目BC
引C言网络安全一直是一个倍受关注的领域,如果缺
乏一定的安全保障,无论是公共网络还是企业专用
网络都难以抵挡网络攻击和非法入侵。
目前,
I.86-D
.68(因特网)上存在着大量特制的协议专门用来保
障网络各个层次的安全。
安全功能可以在
^?
I(开
放式系统互联)七层网络模型中的任何一层中实
现,包括网络层、传输层、应用层或数据链路层。
而
在网络层实施安全措施与低层协议无关,对高层协
议和应用进程透明,即安全服务的提供不需要应用
程序、其他通信层次和网络部件做任何改动。
网格
计算等多种需要安全保障的应用程序均可共享由网
络层提供的密钥管理结构,这样,密钥协商的开销就
可被大大削减。
因此,网络层是一个实施安全措施
的有力场所,尤其在密钥管理方面。
IJK( "#$%协议族中的一个关键部分为另外 两个协议———&’和(#"提供着安全服务,它是! ") #$%默认的自动密钥管理协议,最终为通信双方安 全秘密的协商所采用的算法并生成经过验证的密 钥,是目前因特网上最具应用前景的密钥交换协议。 ! *(并非仅由! "#$%专用,只要其它协议需要,便可 用它协商具体的安全服务,因此,网格计算中的安全 机制完全可用! *(协议来实现密钥管理。 近十几年来,世界各国学者对! *(进行了较为 广泛和深入的研究,尤其是美国和欧洲的一些国家 在这一关键领域投入了大量的研究经费和力量,一 些研究机构和公司已对其进行了试验性的实现,而 国内对它们的研究仍处于初期阶段。 ! "#$% 工作原理! *([+]作为一种混合协议,主要通过两个阶段 的交换来完成#&(#$%,-./0&112%.3/.24)的协商。 阶 段一交换主要是协商相关算法以及交换5.66.$)’$77) 834共享值,最终生成一个已通过身份验证和安全 保护的通道(! *(#&)用来保护阶段二交换(! "#$% #&)。 ! *(#&的生命周期远远大于! "#$%#&的生 命周期,如一个! *(#&的生命周期可为几小时甚 至几天,而一个 ! "#$%#&的生命周期可能只有+至 9分钟。 所以在一个! *(#&的生命周期内可以有 很多个! "#$%#&,保证了会话密钥的频繁更新。 ! *(共定义了: 种交换。 阶段一有两种模式的 交换: 对身份进行保护的主模式交换(;3.4;2<$) 以及积极模式交换(&==-$11.>$;2<$)。 阶段二交换 使用快速模式交换( ? .%@;2<$)。 另外,! *(自己 还定义了两种交换: 一个是为通信各方协商一个新 的5.66.$)’$77834组类型的新组模式交换,另一个是 在! *(通信双方传送错误及状态消息的! #&*;"[ 9]信息交换。 本文主要讨论阶段一的主模式交换,它要经过 A个步骤,共交换B条消息。 头两个消息协商策略; 接着的两个消息交换5.66.$)’$77834的公开值和必 要的辅助数据(例如: 424%$);最后的两个消息验证 5.66.$)’$77834交换。 对! *(交换影响最深的是身份验证方法。 在 阶段一交换的过程中,给出了C种方法,分别是数字 签名验证、公钥加密验证、修改过的公钥加密验证以 及预共享密钥验证。 不同的验证算法提供的安全强 度不同,使得交换消息的内容也各不相同,但达到的 目的是完全一致的,最终都是生成安全通道#&。 不管对于哪一种验证方式,双方都要分别计算 #*(D! 5值,它是所有会话密钥的生成基础,为衍生 下一级双方共享的密钥材料做准备。 以数字签名 为例: #*(D! 5EF-6(G.HIJG-HI,=KL0)(+) 为了验证和保护! *(消息,参与通信的双方都 要生成另外A种秘密#*(D! 5H<、#*(D! 5H3和 #*(D! 5H$,它们都是建立在#*(D! 5的基础之上。 另外,为了验证交换中的双方,协议的发起者和响应 者要分别产生 ’’H! 和’’HM。 ’’H! EF-6(#*(D! 5,=KL.J=KL-JN*DH! JN*DHMJ #&.HIJ! 5..HI)(9) ’’HMEF-6(#*(D! 5,=KL-J=KL.JN*DHMJN*DH! J #&.HIJ! 5.-HI)(A) 至于其他验证方式的#*(D! 5的计算方法, #*(D! 5H<、#*(D! 5H3、#*(D! 5H$的表达式及各标 识符所代表的含义均可参见文献[+]。 以基于数字签名的主模式为例,其消息交换过 程见图 +。 图 &"主模式下数字签名验证的消息交换过程其中,#! OH! 是发起者对’’H! 进行私钥签名的结 果;同理, #! OHM是响应者对’’HM进行私钥签 名的结果。 ’" 安全性分析及改进方案自! *(协议成为MPN标准以来,由于其认证的 灵活性,使得交换的过程增加了几分复杂性,进而给 攻击者以可乘之机。 由于! *(协议是基于5.66.$) ’$77834密钥交换的(消息A、C中交换5’公开 值),所以它容易遭受中间人攻击,解决的思想是增 加认证环节。 过早的进行5’交换又带来了另外一些不足。 QR南京邮电大学学报(自然科学版) SSSSSSSSSS9QQR年S由于经过消息! 、"交换后,双方需要分别计算#$ 交换的共享值%&’(和"个共享秘密。 不管是公开 值、共享值还是共享秘密都属于高次幂模运算,需要 占用 )*+大量的计算资源。 一旦后两条消息验证 失败,那么,已经进行的各种计算工作都要作废,浪 费了相当大的计算机资源,这样很容易就能诱导损 耗计算机资源的 #,-(#./012,3-.4506.)攻击。 针对 #,-攻击的具体的改进方案可参见文献[! —"],本 文主要从抵御两种中间人攻击方面谈协议的改进。 ! "#$ 第一种中间人攻击已经发现789协议的阶段一存在安全缺陷,包 括主模式和积极模式,以及每种模式的"种验证方 法。 其中,部分隐患是由散列载荷$: -$;7和 $: -$;<的错误定义引起的。 具体的针对789的 第一次消息往返过程中存在的中间人攻击,以主模 式下数字签名验证方式为例,见图=。 图 %$遭受中间人攻击的主模式下数字签名方式消息交换攻击者可以截取消息>,把-: 0载荷的内容改 为-: 1发送给响应者,达到冒充发起者的目的。 另 外,攻击者还可以截取消息=,把响应者的回答载荷 -: 4修改为-: ? 以回送给发起者,从而达到了冒充 响应者的目的。 针对这种攻击,文献[@]分别对$: -$;7和 $: -$;<都作了修改,如下: $: -$;7ABC43(-89D7#,%&’0E%&’4E)8DF7E)8DF 0;? E-: 4;? E7#00;? )(") $: -$; )8DF7E-: 4;? E7#04;? )(@) 这样,不管攻击者冒充发起者修改了-: 0还是 冒充响应者修改了-: 4,最终都不能通过验证。 这 种攻击方式已被研究的比较深入,下面给出另一种 中间人攻击的方式。 ! "%$ 第二种中间人攻击由于789协议是基于#0330.F$.22G1/交换的,因 此,在消息的第二次往返过程中还存在另一种形式 的中间人攻击方式,即针对#$交换的中间人攻击。 在这种情况下,攻击者作为第三方在响应者面 前冒充发起者,而在发起者面前又可以冒充响应者, 从而使得双方都不知道到底在和谁进行#$公开值 交换。 现把遭受攻击的消息! 、"单独进行分析(以 主模式下数字签名验证方式为例),见图! 。 图 ! $针对&’交换的中间人攻击第三方攻击者H截获由发起者I发往响应者D 的第! 条消息,由于该消息是以明文的形式传送89 载荷和/,/6.载荷,因此很容易被攻击者篡改。 攻 击者H可将89载荷中的I的#$公开值%&’改为 它自己的公开值%&J,然后冒充发起者伪造第! 条消 息以消息! A的方式将含有%&J的载荷发给响应者D。 由于消息传送前未作任何的认证工作,因此,响应者 觉察不到消息的篡改过程。 同样的道理,攻击者H可截获第"条消息,将响 应者D的#$公开值%&(也修改为它自己的公开值 %&J,然后冒充响应者以消息"A的方式将含有%&J的 载荷回送给发起者I。 这样,双方在第二次消息往返后分别拥有了对 方的 #$公开值,再根据收到的其他的信息就可以 生成"个秘密材料。 如果存在图! 所示攻击的话, 发起者I拥有的其实是和攻击者H共享的秘密,如 #$共享值%&’J、-89D7#>、-89D7#;K>、-89D7#;1> 和-89D7#;.>。 而响应者D拥有的也是和攻击者H 共享的秘密,如#$共享值%&(J、-89D7#=、-89D7#; K=、-89D7#;1=和-89D7#;.=。 这样,攻击者就能够模拟通信双方分别在消息 ! 、"中与两方进行#0330.F$.22G1/交换。 当攻击者 截获消息@时,就可以利用它和发起者共享的秘密 来解密该消息,从而获得了发起者的身份信息。 由 于在数字签名的验证方式下攻击者没有发起者的私 钥,因此也就无法伪造消息@的签名操作。 但这种 攻击不可避免的会浪费计算资源,容易进一步诱导 为#,-攻击,因此,有必要对协议作新的改进以弥 >LM 第>期MMMMMMMMMM张M琳等: 789协议中基于数字签名验证的主模式研究绲慕? ’交换又带来了另外一些不足。 QR南京邮电大学学报(自然科学版) S补上述的缺陷。 ! "! #主模式下数字签名方式的改进数字签名方式建立在公钥基础设施之上,利用 本地的私钥签名来保证数据的完整性和数据源的真 实性并对抗抵赖性也有一定功效。 如果遭受到上述 两种中间人攻击,那么,在消息! 中就无法保护发起 者的身份信息,另外,还可能引发"#$攻击。 下面 给出了一个新的改进方案,见图%。 图 $#改进后的主模式下数字签名方式消息交换与图&相比较,改进后的图%有’处发生了重 大改变: ( &)可选的证书负载[()*+]分别从消息! 、, 中上移到了消息’、%中进行传送,并紧随-)载荷 之后。 (.)在消息’、%的可选证书载荷[()*+]之后 分别增加了两个对-)载荷内容的签名载荷——— $/01-)1/和$/01-)1*,暂时将二者取名为密钥签 名载荷。 其中,$/01-)1/是发起者先对自身要传送 的-)载荷内容(发起者的"2公开值)用消息&、. 协商好的验证算法进行2345计算,然后再用自己的 私钥对该2345结果进行签名得到的;同样,$/01-) 1*是响应者先对它的-)载荷进行2345计算,然 后用自己的私钥对其进行签名得到。 注意,-)载 荷、[()*+]载荷和$/01-)1/(或$/01-)1*)载荷 的顺序不能改变。 (’)借鉴上文中对抵抗第一种中间人攻击的改 进成果(表达式%和! ),将它引入到本改进方案中, 具体的是在消息! 、,中分别用26$21/7和26$21 *7两种散列载荷代替原来的$/01/和$/01*两种签 名载荷。 如果发起者或者响应者拥有多个证书,那么他 们可以使用消息’、%提供的可选的证书载荷来向对 方表明自己到底选用哪个证书。 证书里面包含了个 体的身份和公开密钥等信息,并且二者是绑定的,任 何一个攻击者由于没有(6认证机构的私有密钥, 因此无法伪造证书信息。 之所以将证书载荷提前传送,是因为消息’、% 中新增加的密钥签名载荷要用到私钥加密操作,等 对方收到消息后要根据证书载荷的提示选择相应的 公钥进行解密验证。 改进前攻击者很容易通过第二 种中间人攻击的方式模拟双方进行通信,针对这个 问题本文才提出了密钥签名载荷的思想。 对于发起者,通过在传送-)载荷的同时附加 他的密钥签名载荷$/01-)1/,就可以防止攻击者在 截获他的消息’后伪造之。 因为,即便攻击者可以 篡改-)载荷内容,但是,由于他不可能知道发起者 的私有密钥而无法伪造$/01-)1/载荷。 同理,攻 击者也无法伪造消息%中响应者的$/01-)1*载 荷。 这样就可以彻底的抵御本文所说的第二种中间 人攻击。 消除了消息’、%中可被中间人攻击的疑虑,消 息! 、,的机密性就会表现的更好。 因为攻击者再也 不可能冒充双方生成伪造的"2共享值以及%个秘 密材料了,他不管是截获消息! 还是截获消息,,都 绝对不可能解密消息内容,当然也就无法获得通信 双方的身份信息了。 这样,原来消息中的 $/01/和 $/01*载荷就显得多此一举了,取而代之的是 26$2散列载荷26$21/7和26$21*7,结果是不仅 减少了签名操作中的加解密的计算量,还有效的阻 止了第一种中间人攻击的发生。 总的来说,对于主模式下数字签名方式的这种 改进没有增加额外的 8-/的负担,在消息’、%中提 供了对"2共享值的有效保护,在消息! 、,中提供 了验证功能和对双方身份的保护。 其改进的优势简 单总结如下: (&)利用26$21/7和26$21*7抵御了第一种 中间人攻击。 (.)引入密钥签名载荷$/01-)1/和$/01-)1 *有效防止了第二种中间人攻击的发生。 (’)通信双方身份信息的机密性增强。 (%)整个消息交换过程的签名操作的次数没有 增加,依然是发起者和响应者各签名一次、解密 一次。 (! )整体的计算量要大幅减少。 改进前的$/0 1/和$/01*是分别对26$2载荷26$21/和26$2 1*进行的签名,而2345运算包含的内容较多,有 $-)9/"、各"2公开值和$6载荷等,其中单一个 $6就很复杂,因此,仅对-)载荷(即"2公开值) 进行签名的$/01-)1/和$/01-)1*要比$/01/和 .: 南京邮电大学学报(自然科学版) ;;;;;;;;;;.<<: 年;! "#$%的计算量少的多。 (&)签名验证载荷的提前传送使得双方能较早 的发现攻击,减少了彼此对无效协商进行的计算,进 而有利于抵御 ’(! 攻击。 ! " 性能分析及实现方案对于’(! 攻击通常是由耗费系统计算资源的 大规模的乘幂运算和公钥体制下的加解密操作引起 的,我们可以借鉴文献[&—)]中提到的“计算代价” 来评估一个协议抵御’(! 攻击的性能。 以%! *算 法为例,假设! 是%! *密钥长度,那么每一次(加) 解密运算的计算代价为+,-).! ,通常假定! / 0+12。 下面给出改进前后的定量的性能分析。 ! #$" 对抵御第一种中间人攻击的性能分析不管是改进前还是改进后,如果存在第一种中 间人攻击篡改了消息0、1中的! *载荷的内容,那 么修改前后的两种交换方式都是在响应者收到消息 .后经过重新计算3*! 3$"4而检测出来。 截止到发 现攻击时,双方已付出的计算代价如表0和表1 所示。 表 $"改进前双方付出的计算代价发起者的计算代价响应者的计算代价 一次56交换(’3公开值的计算)一次56交换(’3公开值的计算) 2个秘密密钥的计算2个秘密密钥的计算 一次! "#$"的加密(+,-).! /-72)一次对消息.的对称解密 一次对消息.的对称加密一次! "#$"的解密(+,-).! /-72)表 %"改进后双方付出的计算代价发起者的计算代价响应者的计算代价 一次56交换(’3公开值的计算)一次! "#$56$"解密(+,-).! /-72) 一次! "#$56$"加密(+,-).! /-72)一次56交换(’3公开值的计算) 一次! "#$56$%解密(+,-).! /-72)一次! "#$56$%加密(+,-).! /-72) 2个秘密密钥的计算2个秘密密钥的计算 一次对消息.的对称加密一次对消息.的对称解密88 针对这一种攻击,双方在发现攻击时改进后的 计算代价要比改进前的计算代价多了一次公钥加 (解)密操作。 ! #%" 对抵御第二种中间人攻击的性能分析在对协议进行修改之前,响应者也是在收到消 息 .后才能检测到攻击。 双方及攻击者所付出的计 算代价如表-所示。 表 &"改进前双方及攻击者付出的计算代价发起者的计算代价攻击者的计算代价响应者的计算代价 一次’3公开值的计算一次’3公开值的计算 2个秘密密钥的计算一次’3公开值的计算2个秘密密钥的计算 ! "#$"加密(+,-).! /-72)7个秘密密钥的计算对消息.的对称解密 对消息.的对称加密对消息.的对称解密! "#$"解密(+,-).! /-72)88 改进后,由于在消息-、2中增加了身份签名载 荷! "#$56$"和! "#$56$%的保护,因此,根本就不 存在第二种中间人攻击,即为抵御这种攻击双方需 要付出的计算代价等于+,这就是本文提出这种改 进思想的关键所在。 ! #&" 实现方案"56作为守护进程工作于应用程序空间,采用 消息队列的方式通过9: $56;套接字接口与操作系 统内核进行通信,以便更新内核的! 9’<和! *’<。 基于=>? @A的: BCC! DE*F是目前国外最安全 的一种"9! CG的实现方案。 在升级=>? @A内核和借 助HBCC! DE*F配置好"9! CG后,在实现"56协议的 IJ@K(模块的开源目录代码下,我们修改和增加了相 应的函数来模拟通信双方之间的"56消息交换过 程。 针对上文的改进方案需要提供以下两个新增 函数: %! *$L>M? $NC(8): 构造! "#$56$"载荷,并将 该载荷的下一个载荷头设为FOFP6载荷。 %! *$GQCGN$L>M? RK@BC$NC(8): 验证对方的密钥 签名载荷。 ’" 结束语安全是一个相对的概念,没有绝对安全的协议。 为了更好的保证数据的通信安全,"56协议还有待 于进一步的完善。 另外,"56主要用于通信的双方 进行协商安全联盟来保护以后的信息交换,那么如 何把它顺利的用于多播环境下是值得考虑的问题; 再者,为了解决"9地址短缺的问题,许多企业采用 了F*S地址转换的方法,它与使用了"56进行密钥 交换的*3和6! 9等其他安全协议中的完整性认证 是矛盾的。 因此,如何解决类似这些问题的兼容性 是我们下一步要开展工作。 参考文献: [ 0]3*%5"F! ’,P*%%6=’,SQC"? KCB? CKNCTCAGQR? MC("56)[! ],-)8第0期8888888888张8琳等: "56协议中基于数字签名验证的主模式研究! "#$%&’,(’’)*((+ [$],-./00-,1,2#03! 453! +6789: 79829;<: =8>-? ? @;=A8=@7 A7BC9>,A7AD9E978F: @8@;@G(62-C,F)[2]+! "#$%&),(’’)* ((+ [H]杨欣,王世军+抵抗1@2攻击的6C3协议改进方案[I]+计算机 应用,$&&H(J): H&J*H&)+ [%]王焕宝+6C3协议及其抵御1@2攻击研究[1]+合肥: 合肥工业 大学,$&&$: K&*KH+ [L]宋育芳,张宏科+6789: 798密钥交换协议的安全性分析[I]+计 算机工程与应用,$&&%()): (HJ*(H’+ [J]M0-N/O+1=D=8AG? =D7;: >P8=@7@: Q@R8@A;Q=9S9;@? 8[#]TT-BU SA7;9? =7#: >P8@G@D>,#: >P8@V’K,5N#2($’%,- (JL *()’+ [K],-42..! -C,6,-60+,@B=W=9B-DD: 9? ? =S9,@B9@W6789: 798 C9>3X;QA7D9! 9? =? 8A78ADA=7? 8197=AGU@WU29: S=;9-88A;Y? [I]+63U 6#34: A7? @76N"Z2O24,$&&&,)HU1(L): ’K$*’K’+作者简介: [[张[琳((’)&*),女,江苏丰 县人。 南京邮电大学计算机学院 博士研究生。 $&&L年在中国矿业 大学计算机应用技术专业获工学
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- IKE 协议 基于 数字签名 验证 模式 研究