https://cert.360.cn

1报告事件:cert@360.
cn密钥重载攻击:强制WPA2重用Nonce安全报告:密钥重载攻击:强制WPA2重用Nonce报告编号:B6-2017-101707报告来源:360CERT报告译者:360CERT原文作者:MathyVanhoef,FrankPiessens原文链接:https://papers.
mathyvanhoef.
com/ccs2017.
pdf保密级别:公开更新日期:2017年10月17日https://cert.
360.
cn2报告事件:cert@360.
cn目录摘要.
31介绍32背景52.
1802.
11i修正协议.
52.
2身份验证和连接.
52.
3四次握手.
62.
4机密性和完整性协议.
72.
5组密钥握手.
83攻击四次握手.
93.
1请求状态机.
93.
2密钥重载攻击.
93.
3明文重传Message3113.
4加密重传Message3133.
5攻击PeerKey握手164攻破组密钥握手.
164.
1组密钥握手的细节.
174.
2攻击快速装载密钥的AP184.
3攻击延迟装载密钥的AP195针对802.
11RFT握手的攻击.
215.
1FastBSSTransition(FT)握手.
215.
2针对AP的密钥重载攻击225.
3滥用BSS传输请求.
226评估和讨论.
236.
1802.
11协议中重用nonce造成的影响.
236.
2攻击场景.
246.
3全零加密密钥漏洞.
256.
4安全证明的限制.
256.
5对策266.
6讨论267相关工作.
277.
1密钥重载攻击.
277.
2Wi-Fi和网络协议安全278.
总结28致谢.
29参考链接.
29https://cert.
360.
cn3报告事件:cert@360.
cn摘要本文我们将介绍密钥重载攻击,这种攻击滥用了加密协议的设计和实现来重装一个已经在使用的key.
重置和key相关的参数,例如传输的nonces和重传计数器.
一些加密的Wi-Fi握手包也会受到该攻击影响.
所有受保护的Wi-Fi网络使用四次握手来产生一个新的sessionkey.
目前为止,握手协议已经使用了14年,一度被认为很安全,可以免受攻击.
但是,本文证明了在密钥重载攻击面前四次握手协议是脆弱的.
攻击者通过操作和应答握手信息来欺骗受害者重新安装一个已经在使用的key.
当密钥重载时,相关的参数例如传输包的增长序列(nonce)和重传计数器被重置为初始值.
密钥重载攻击也能破坏PeerKey,组密钥和FastBSSTransition(FT)握手协议.
该影响取决于握手协议是否被攻击以及使用的数据加密协议.
简单来说,针对AES-CCMP的攻击者可以应答和解密(不是伪造)握手包.
这使得劫持TCP流并注入恶意数据变得有可能.
而对于WPA-TKIP和GCMP允许应答、解密和伪造包影响是灾难性的.
因为GCMP在传输的双方使用相同的key,影响尤为严重.
最后,我们在实践中验证了我们的观点,并发现每个Wi-Fi设备都有可能受到一些变种攻击的影响.
值得注意的是,Android6.
0强制客户端使用初始值全为零的加密key,使得我们的攻击对其影响是巨大的.
关键词:安全协议;网络安全;攻击;密钥重载;WAP2;nonce重用;握手包;包序列;初始向量1介绍所有使用WPA/2协议的Wi-Fi网络并认为是安全的.
更有甚者,由于Hotspot2.
0,现在公共的热点也能用这种加密认证[7].
所有这些技术都依赖于四次握手协议,该协议被定义在802.
11中的802.
11i修正案.
本文我们将展示四次握手的设计流程和相关的握手包,因为我们认为这些握手包以及WPA和WPA2-认证产品都会受我们攻击的影响.
四次握手提供了相互认证和会话密钥协商协议,连同(AES)-CCMP,数据保密和完整性协议,构成了802.
11i修正案的基础.
作为802.
11i的核心部分,自从2003年第一次被命名为WPA被引入,它就免受了攻击.
实际上,802.
11i目前已知的弱点是在(WPA-)TKIP[57,66].
其数据保密协议被设计作为破旧的WEP协议的一个短期解决方案.
换句话说,TKIP从来没有打算作为一个长期的安全解决方案.
此外,虽然过去几年有几次针对Wi-Fi网络的攻击被发现,但都不是利用802.
11i协议.
而是利用WPS[73],有缺陷的驱动程序[13,20],有缺陷的随机数字生成器[72],可预测的预共享密钥[45],不安全的企业认证[21]等等.
在CCMP和四次握手里没有发现重大的弱点.
这并不奇怪,毕竟,两者都被正式证明是安全的[39,42].
考虑以上几点,人们可以合理地假设四次握手确实是安全的.
尽管历史证明它是安全的,但我们可以证明四次握手面对密钥重载攻击是脆弱的.
此外,我们发现了其他Wi-Fi握手协议中有相似的缺陷.
这意味着,我们也能攻击PeerKey握手,组密钥握手和FastBSSTransition(FT)握手.
我们攻击背后的原理在事后看来其实很简单.
概括如下:当客户端加入一个网络时,它会执行四次握手来协商得到一个新的会话.
在接收到握手https://cert.
360.
cn4报告事件:cert@360.
cn的Message3后,它会安装该key.
一旦key被安装,它将被用于数据保密协议来加密正常的数据帧.
但是因为消息可能丢失,如果没有收到合适的响应作为应答,接入点(AP)将重发Message3.
所以,客户端可能收到多次的Message3.
每次接收到该消息,客户端就会重新安装相同的会话密钥,从而重置不断增长的传输包的序列号(nonce)以及数据保密协议使用的重传计数器.
我们证明了攻击者可以通过收集和重发Message3来强制重置nonce.
通过临时重置nonce,可以攻击数据保密协议.
例如,数据包可以被重放,解密,或伪造,这样的技术也可以用来攻击组密钥,PeerKey,fastBSSTransition.
当四次握手或fastBSS握手被攻击时,影响的大小取决于使用的数据保密协议.
如果是使用CCMP,任意数据包都可以被解密,反之,这可以用来加密TCPSYN包来挟持TCP连接.
例如,攻击者可以注入恶意内容到未加密的HTTP连接中.
如果是使用TKIP或GCMP,攻击者可以解密并注入任意包.
尽管GCMP是一个相对较新的Wi-Fi协议,预计在今后几年中会有很高的采用率.
最后,当组密钥握手被攻击时,攻击者可以重放组寻址帧,即广播和多播帧.
我们的攻击对于wpa_supplicant(Linux系统常用的Wi-Fi客户端)2.
4版本和2.
5版本影响巨大,该客户端将安装一个全零的加密key而不是重装一个真实的key.
该漏洞由802.
11标准中的一句话引发:如果会话密钥已经被安装,建议从内存中清除部分的会话密钥[1,§12.
7.
6.
6].
因为Android使用了改进的wpa_supplicant,所以Android6.
0和AndroidWear2.
0也包含此漏洞.
因此,目前31.
2%的Android设备很容易受到这种攻击变种的破坏.
[33]有趣的是,我们的攻击并不违反四次握手和组密钥握手被证明的安全属性.
特别值得一提的是,这些证明表明协商的会话密钥仍然是私有的,并且客户端和接入点(AP)的身份是被确认的.
我们的攻击不会泄露会话密钥.
(另外,虽然使用TKIP或GCMP可以导致正常的数据帧被伪造,但是攻击者不能伪造EAPOL消息,因此不能在握手期间伪装成客户端或AP,所以不能模拟key的安装.
不同的是,当一个协商key应该被安装时,他们的模型不能阐述.
)实际中,这意味着相同的key可以被安装多次,从而重置nonces和数据保密协议使用的重传计数器.
总之,本文的主要阐述如下:(1)我们介绍了密钥重载攻击,攻击者强制重载一个已经使用过的key,从而重置任何相关的nonces或重传计数器.
(2)我们认为四次握手,PeerKey握手,组密钥握手和fastBSStransition握手容易受到密钥重载攻击.
(3)我们在实践中实施了我们的攻击,这表明所有的实现都易受某些变种的攻击.
(4)我们评估了所有802.
11的数据保密协议重用nonce的影响.
本文的其余部分如下:第二节将介绍802.
11标准的相关方面.
第三节主要阐述针对四次握手和PeerKey握手的密钥重载攻击.
第四节则是针对组密钥的描述.
第五节描述针对fastBSStransition握手的攻击.
在第六节,我们将描述攻击的影响,提出对策,解释安全性失败的原因,并讨论吸取的教训.
最后我们会在第七节介绍本文的相关工作,并在第八节进行总结.
https://cert.
360.
cn5报告事件:cert@360.
cn2背景这个章节主要介绍802.
11i修正协议,在连入WiFi网络时的各种消息和协议和802.
11中使用的各种数据机密性完整性协议.
2.
1802.
11i修正协议在WEP安全性从根本上打破之后,IEEE提供了一个更加健壮的解决方式,使用802.
11i作为802.
11的修正协议.
修正协议定义了四次握手和两个数据机密性、完整性协议WPA-TKIP和AES-CCMP.
尽管802.
11i修正案还在开发中,WiFi联盟开始根据802.
11iD3.
0版本的草案来验证设备.
验证程序叫做WiFiProtectedAccess(WPA).
一旦802.
11i的D9.
0最终版本被批准,WPA2的认证就建立在这个正式批准的版本上.
因为WPA和WPA2都是基于802.
11,所以在技术水平上两者几乎相同的.
最主要的区别是WPA2要求支持更安全的CCMP,可选使用TKIP,而WPA是相反的.
因为功能需求,WPA和WPA2都采用四次握手保护WiFi网络.
企业版网络也是依赖于四次握手.
因此所有使用四次握手的WiFi网络都被这次攻击影响.
四次握手,组密钥握手和CCMP协议都正式被分析和证明是安全的2.
2身份验证和连接当客户端要连接WiFi网络,自动开始(互相)身份验证和连接.
图2描述了连接阶段的握手.
但是当第一次连接到网络时,是没有实际的身份验证.
相反,使用了开放系统身份验证,对客户端进行身份验证.
实际身份验证在四次握手中使用.
但真正的身份认证仅在两个采用fastBSStransition握手协议的相同网络AP之间漫游时使用.
在开放式身份验证之后,客户端连接到网络中.
通过客户端向AP发送一个连接请求完成.
这条消息包含客户端希望使用的成对的密码组.
AP回复一个连接响应,通知客户端连接是否被成功建立.
图1https://cert.
360.
cn6报告事件:cert@360.
cn图22.
3四次握手四次握手提供相互身份验证,基于共享密钥技术,这种技术称为成对的主密钥PairwiseMasterKey(PMK),并协商一个新的会话秘钥PairWiseTransientKey(PTK).
在这次握手中,客户端称为supplicant,而AP称为authenticator,PMK由个人网络中的预共享密码生成,在企业网络中使用802.
1x身份验证来进行协商.
PTK由PMK,AuthenticatorNonce(ANonce),SupplicantNonce(SNonce)和supplicant和authenticator使用的MAC地址派生而来.
一旦生成,PTK被分割成确认key(KCK),加密Key(KEK),和临时Key(TK),确认Key和加密Key使用来保护握手消息,TK和数据机密性协议是用来保护正常数据帧,如果使用了WPA2,四次握手协议也传输现在的GroupTemporalKey组临时密钥(GTK)到supplicant.
https://cert.
360.
cn7报告事件:cert@360.
cn四次握手中的每一条消息都是使用EAPOL帧格式.
(如图1)对字段进行介绍首先,消息的头部定义了所代表的消息类型,我们将使用messagen和MsgN来代表四次握手中第n段消息.
Replaycount(重放计数器)字段用于检测重放的数据帧:authenticator在发送一个帧之后会自增长,当supplicant对authenticator发送的EAPOL帧做出应答时,它使用相同的replaycount.
Nonce字段是一个随机的nones值,这个随机值是supplicant和authenticator在生成新的会话秘钥这一步骤产生的.
接下来,如果EAPOL帧传输一个组密钥,RSC(接受序列)包含了key起始包号.
组密钥是存储在KeyData字段,使用加密Key(KEK)加密.
最后,使用消息确认Key(KCK)来进行完整性校验.
MIC(MessageIntegrityCheck)图2表示了四次握手时消息的传输格式.
我们使用一下的符号标记MsgN(r,Nonce;GTK)表示:四次握手中的第N条消息,重放计数器replaycount为r,给定的nonce,在';'之后的参数都存储在数据域中,也就是说会使用KEK加密.
1.
Authenticator通过发送message1来初始化四次握手.
包含ANonce,是唯一一个没有MIC(完整性校验)EAPOL格式消息.
2.
当收到消息时,suplicant生成一个SNonce而且导出PTK,suplicant发送message2给authenticator,message2包含了(SNonce).
3.
authenticator收到SNonce,也会导出PTK.
并且发送组密钥GTK给supplicant.
4.
supplicant在安装PTK和GTK之后回复message4,authenticator收到message4之后也会安装PTK,其中GTK在AP启动时就已经安装.
1,2条消息使用来传输nonces,最后两条消息是用来传输组密钥而且使用抵御降级攻击注意:在已经存在的连接中,PTK可以被刷新通过初始化新的四次握手.
在密钥重载的过程中,所有的四次握手消息都是使用PTK完成数据机密性加密的.
2.
4机密性和完整性协议802.
11i修正协议定义了两个数据级机密性协议,第一个是TKIP(TemporalKeyIntegrityProtocol)暂时完整性协议.
现在因为安全考虑TKIP被弃用.
第二个是(AES-)CCMP,CCMP是目前最广泛使用来保证数据机密性的协议,在2012年,802.
11修正协议中增加了新的数据机密性协议Galios/CountModeProtocol(GCMP).
这个修正协议也增加了在60GHz带宽的short-range信息交互,这需要一个能够快速计算的密码(fastcipher),比如GCM.
现在802.
11ad修正协议在WirelessGigabit(WiGig)中推广,而且预期在接下来几年被更快速广泛的采用.
最后,802.
11ac修正协议通过加入256位的key更佳的拓展了GCMP当TKIP使用的时候,PTK的一部分:TK(暂时密钥)被分隔称为一个128位加密密钥,两个64位的MIC消息完整性检测key.
第一个MIC使用在无线网热点对终端方向的消息发送,第二个则相反.
这个加密使用了RC4,每个包密钥都是独特的,通过128位加密秘钥,发送者的MAC地址,和增长的48位nonce.
Nonce每发送一个帧都会自动增长,用做重放计数器,当安装TK时会重置为1.
通过Michael算法来确认消息的权威性,但是Michaelhttps://cert.
360.
cn8报告事件:cert@360.
cn算法是可逆的,给一个明文和MIC值,就可以有效的恢复MIC密钥.
CCMP协议是基于AES在CCM模式下的加密方式(CBC-MAC的计数器模式).
这是一种身份验证加密,使用了AssociatedData(AEAD)算法,只要特定的Key中没有重复的初始化向量就是安全的.
在CCMP中,这个初始化向量是发送者MAC地址,48位nonce和一些传输帧中额外flags的组合.
这个nonce也会被用作接受者的重传计数器,每次发送后都会增加1,再TK重新安装则会被初始化为0.
这样可以保证初始化向量不会重复.
另外的,这个构造允许TK可以被直接做为信道两个方向交互的key.
GCMP协议是基于AES-GCM,意味着使用了同样的加密计数器模式,得到的密文使用GHASH功能进行验证.
和CCMP相同,是一个AEAD加密,只要在特定的key中初始化向量没有重复就可以保证安全,在GCMP中nonce作用也一样,在安装TK之后会被置为0.
通常保证初始化向量只使用一次,TK可以作为交互双方的密钥,两个消息传递方向使用TK作为key.
一旦nonce被重复了,就有可能重构GHASH功能使用的验证密钥.
为了表示数据帧是通过数据机密性协议加密而且验证的,使用下面的符号标记n表示nonce(也就是重放计数器).
参数k表示key,表示单播流量中的PTK.
为了向组地址发送流量:比如广播和组播帧,使用GTK(组密钥).
最后使用两个标记符Data(payload)表示向单一地址发送GroupData(payload)向多个地址(组地址发送)2.
5组密钥握手Authenticator周期性刷新组密钥,而且向所有的客户端发送组密钥,使用这些组密钥来进行握手.
这些握手环节被证明是安全的,在图2的最后阶段.
Authenticator初始化所有的握手通过发送组消息message1给所有的客户端.
Supplicant通过回复组message2来确认收了了新的组密钥.
取决于实现,Authenticator安装GTK可以在发送groupMessage1之后也可以在收到所有客户端的连接请求之后.
最后groupmessage1也包含了现有组密钥的收到重放计数器,这个字段是图1的RSC字段所有的组密钥握手消息都是使用EAPOL格式帧,使用Group1和Group2在图2中代表.
注意组消息1存储了新的组密钥在数据字段中(使用KEK确认密钥加密)、所以只要PTK被安装之后,完整的EAPOL格式帧都被被数据机密性协议保护最后,当客户端发送一个广播或者多播帧,她首先需要发送单播给AP,AP对这个数据帧使用组密钥加密,然后广播给所有的客户端.
这保证了所有的在AP范围内的客户端都能收到消息.
https://cert.
360.
cn9报告事件:cert@360.
cn3攻击四次握手3.
1请求状态机802.
11i的修订没有一个正式的描述Supplicant如何实现四次握手.
相反,它只提供了如何实现的伪代码,并没有说明握手包将在何时被处理.
幸运的是,802.
11r略微扩展了四次握手,并详细描述了请求状态机该如何实现.
图2包括了这个状态机的简单描述.
当第一次连接一个网络并且开始四次握手的时候,状态机会进入PTK_INIT状态.
在这里,它将初始化PMK.
当Supplicant接收到信息1的时候,会进入PTK-START阶段.
这个经常在第一次连入一个网络的时候,或者是在前一个四次握手完成之后,会话密钥需要更新的时候.
当进入PTK-START阶段,Supplicant会随机生成一个SNonce,计算一个临时PTK(TPTK),并且在信息2中将SNonce发送给Authenticator.
Authenticator随后会回复Message3,其将在MIC和重传计数器有效的时候被Supplicant所接受.
如果成功,将进入PTK-NEGOTIATING状态,在这里若是TPTK和PTK相同时,Supplicant会发送Message4给Authenticator.
紧接着,就会进入PTK-DONE阶段,在这里PTK和GTK都会被装载,并且被用在数据保密协议以及密钥管理请求的完整性.
最终,它会打开802.
1x的端口,让Supplicant能够正常接收和发送数据包.
注意,这个状态机会在Authenticator没接收到信息2和4的时候,分别重复发送信息1和3.
我们确认802.
11r的状态机符合在802.
11i的修订中通过文字描述的状态机.
最重要的是,我们能够进行重装密钥攻击的两个要素.
第一,802.
11i的状态机中,AP会在没有接受到回复的时候重传消息1和3.
因此,客户端必须接受这重传的信息1和3,来和802.
11r的状态机相匹配.
更多的,802.
11i状态机要求客户端在接受并且回复Message3之后要装载PTK.
这点也和802.
11r中提供的状态机相匹配.
3.
2密钥重载攻击我们的密钥重载攻击现在很容易理解:因为Supplicant即使在PTK-Done阶段,依旧持续接受重传的Message3,我们就可以强制重载PTK.
更确切地说,我们第一步在Supplicant和Authenticator中建立一个中间人(MitM)的身份.
我们是用这个中间人的身份来进行Message3的重放,并阻止Authenticator接受Message4.
这就导致了,当重放Message3的时候,Supplicant就会重载一个已经被使用过的PTK.
反过来说,这个会重置被用在数据保密协议中的Nonce.
取决于不同协议的使用,这有可能造成数据包的重放、解密以及伪造.
在6.
1节中,我们会详细描述Nonce的重用会在不同协议中有什么实际的影响.
在攻击实践中,可能会遇到一些问题.
首先,不是所有Wi-Fi设备都正确实现了状态机.
特别是Windows和iOS,它们不接受Message3的重传.
这和802.
11标准是相违背的.
总的来说,这些错误的实现并不会被我们的针对四次握手的密钥重载攻击所影响.
不幸的是,从防御者的角度来说,iOS和Windows设备依旧会被我们针对组密钥的攻击所影响.
另外,因为他们都支持802.
11r,因此他们依旧有可能被针对AP的密钥重载攻击所影响.
第二个主要障碍是我们需要在AP和Client中获得一个中间人(MitM)的身份.
这可能不能通过使用一个不同MAC地址的恶意AP在真实AP和Client间转发数据包来实现.
在2.
3节中提到,会话密钥(sessionkey)是基于Client和AP的MAC地址来生成的,这意味着不https://cert.
360.
cn10报告事件:cert@360.
cn同的MAC会生成不同的密钥.
这会导致握手过程以及攻击过程的失败.
为了解决这个问题,我们可以部署基于频段的中间人攻击,在不同频段部署和目标AP相同MAC的恶意AP来实现.
这个保证了Client和AP能产生一样的会话密钥.
第三个障碍是某些实现在PTK已经被加载的时候,只接受被数据保密协议所保护的数据包.
这对我们的攻击是一个问题,因为Authenticator会在不加密的情况下重传Message3.
这意味着这些重传信息会被Supplicant所忽略.
即使这看起来会阻碍我们的攻击,但是我们发现了一个技术手段来绕过这个问题(3.
4节)在接下来的两节中,我们会描述如何使用我们的密钥重载攻击在不同情况下来攻击四次握手实现的细节.
更确切地说,我们会先描述在Client(受害者)接受明文重传Message3的情况.
然后我们会演示对只接受加密重传Message3的客户端的攻击.
表1第6列里总结了哪些设备会在针对四次握手的不同的密钥重载攻击中受影响.
不同设备的表现取决于操作系统以及被使用的无线网络设备.
例如,即使Linux接受明文的重传Message3,但是在某些Android设备里使用的网卡会拒绝它们.
因此,使用不同无线芯片的Android设备事实上可能会接受明文的重传Message3.
表1https://cert.
360.
cn11报告事件:cert@360.
cn3.
3明文重传Message3如果受害者在加载完会话密钥之后,依旧接受明文重传Message3的话,我们的密钥重载攻击就很简单了.
首先,攻击者会使用基于频段的中间人攻击,因此她可以控制握手包.
然后她能够阻止Authenticator接受Message4.
这就是图4里的第一阶段.
在发送Message4之后很快,受害者就会装载PTK以及GTK密钥.
在这种情况下,受害者依然会打开802.
11x端口,并且开始传输正常数据.
注意一点,在数据保密协议中的第一个数据包使用的Nonce是1.
然后,在攻击的第三阶段,Authenticator会因为没有收到Message4而重传Message3.
攻击者可以转发重传Message3给受害者,导致它重新装载PTK和GTK.
总的来说,这样会重置数据保密协议使用的Nonce和防重传计数器.
注意一点,攻击者不能够重放旧的Message3,因为EAPOL的重传计数器没有被刷新.
我们现在暂时忽略攻击的阶段4.
最后,当受害者传输它下一个数据帧时,数据保密协议就会使用旧的Nonce.
这意味着攻击者可以在转发重传Message3给受害者前等待任意的时间.
因此,我们可以控制一定数量的会被重用的Nonce.
更多的,攻击者可以一直对Client进行掉线攻击(deauthenticating),直至它重新连入网络并执行新的四次握手的过程.
https://cert.
360.
cn12报告事件:cert@360.
cn图4图4同样展示了我们的密钥重载攻击会在Message4由于背景噪声而丢失的时候自发地出现.
不同的是,接受明文重传Message3的Client,可能会在没有攻击者的情况下重用Nonce.
在这种情况下,一个攻击者可以选择性地阻塞Message4,来区分攻击和随机背景噪声的干扰.
我们现在回到攻击的阶段4.
这个阶段的目标是完成Authenticator部分的握手阶段.
这不是很重要,因为受害者已经加载了PTK,这意味着它的下一个Message4是被加密的.
在Authenticator还未加载PTK时,它通常会拒绝已加密的Message4.
因此,802.
11标准里揭示了Authenticator需要接受具有任意重传计数器的四次握手包,而不仅仅是最后一个.
接受Message4的时候,Authenticator验证KeyReplayCounter字段值在当前四次握手过程中使用的.
在实践中,我们发现一些AP确实接受具有旧的重传计数器的数据包.
更确切的说,一些AP接受在被发送给Client数据包中使用,并且还未被Client发送回来的重传计数器.
这些AP会接受旧的未加密的Message4,就是图4里的重传计数器r+1.
总的来说,这些APhttps://cert.
360.
cn13报告事件:cert@360.
cn会装载PTK,并且开始发送加密的单播数据帧给Client.
虽然图4只说明了Client发送的Nonce重用情况,我们的攻击同样允许我们重放数据帧.
首先,在Client在阶段3中重载GTK之后,AP之后通过广播和多播的重传Message3是可以被重放的.
这是因为在重载密钥的时候,重传计数器也被重置了.
第二,如果我们能够让AP装载PTK,我们同样能重放从AP单播给Client的数据帧.
我们确认,在图4中的攻击在MediaTek的Wi-Fi设备和特定版本的wpa_supplicant下是有效的.
我们将在下一节解释我们攻击的另外一种实现.
3.
4加密重传Message3我们现在来解释我们是如何攻击那些一旦装载了PTK就只接受加密重传Message3的Client的.
为了完成这个,我们利用一个使用了数据保密协议的实体在执行四次握手的时候的一个内在的竞争条件.
图5https://cert.
360.
cn14报告事件:cert@360.
cn就像先前说的,我们先来攻击Android上所实现的Supplicant.
在这里,我们发现当明文重传Message3被紧接着原始Message3发送的时候,Android会接收这个重传信息.
图5表明了为什么会发生这个情况,并且我们该如何利用它.
注意一下就是,图5里并没有AP,因为AP的反应在上文中已经描述的很清楚了.
在我们的攻击中,首先让Client和AP交换信息1,2.
然后我们不将第一个Message3转发给Client,而是等着AP重传第二个Message3,在攻击的第二阶段,我们接连发送两个Message3给Client.
这时候,实现了数据保密协议的无线网卡还没有装载PTK,于是就将收到的两个包按顺序转发给CPU.
这个实现了四次握手的CPU接受了第一个Message3,并且让无线网卡装载PTK.
在攻击的阶段4里,Client的CPU从接受序列里得到了第二个Message3.
及时它注意到了这个数据包并没有加密,但是Android和Linux例外允许未加密的EAPOL包,因此CPU会执行这个重传Message3.
因为网卡刚刚装载了PTK,因此这个回复会是在Nonce为1的情况下加密的.
在这之后,CPU再次让无线网卡装载PTK.
同时,无线网卡也会重置与PTK相关的Nonce和重传计数器,这意味着下一个数据帧会重用Nonce1.
我们现在展示如何攻击OpenBSD,OSX和macOS.
这些设备只接受加密的重传Message3.
就像攻击Android设备一样,我们在无线网卡和CPU间进行一个条件竞争.
然而,我们现在的目标是四次握手重载密钥的过程.
就像2.
3解说的,所有的信息在重载密钥的时候都会经过数据保密协议的加密.
https://cert.
360.
cn15报告事件:cert@360.
cn图6图6描述了这种攻击的细节.
注意同样的AP并没有被展示在图里,因为从上文我们很清楚AP的反应会是怎么样.
一样的,攻击者使用一个基于频段的中间人(MitM)身份.
她让受害者和她自己进行一个初始的四次握手,并且在握手成功之后,初始化执行PTK的重载.
及时她只能看到加密的数据帧,但是四次握手的信息能通过它们独特的长度和地址来探查.
在这时候,攻击就像在Android那里一样,在攻击的第二阶段,攻击者没有立刻转发第一个Message3,而是等待AP重传Message3,然后将这两个Message3按顺序一起发送给受害者.
网卡会使用当前的PTK来解密这两个信息,然后将它们转发到CPU的接收序列.
在第三阶段,CPU会执行第一个Message3,让网卡装载新的PTK.
在第四阶段,CPU会从接收序列取出第二个Message3.
当PTK被装载的时候,OpenBSD,OSX和macOS(在这里被称为CPU)会要求这个这个信息是加密的.
然而,它们不会检查这个信息是使用哪个PTK密钥来加密的.
因此,即使这个信息是通过旧的PTK来加密的,但是CPU依然会执行它.
现在Message4就会通过新的PTK和Nonce1来加密并发送.
在这之后,CPU会让网卡重载PTK,并且重置Nonce和重传计数器.
最终,受害者发送的下一个数据帧就会使用新的PTK和Nonce1来加密.
我们确认这个攻击能在OpenBSD6.
1,OSX10.
9.
5和macOSSierra10.
12里实现.
https://cert.
360.
cn16报告事件:cert@360.
cnOpenBSD仅在无线网卡卸载加密的时候受影响.
比如,iwn驱动和相关的设备支持硬件加密,因此他们就会收到攻击的影响.
然而,rum驱动在四次握手中使用的是软件加密,那么就不会被影响.
这种攻击技术需要我们等待会话密钥被重载的那一刻.
一些AP会在每个小时都重载一次会话密钥.
在实践中,Client也会通过发送一个设置了Request和Pairwise位的EAPOL包给AP来请求重载会话密钥.
很巧的是,Broadcom的路由器并不会验证这些数据帧的真伪(MIC),这就意味着攻击者可以强制Broadcom的AP开始重载密钥的握手.
讲这些结合到一起,我们可以让重载密钥发生,这就意味着攻击者可以实施重载密钥攻击了.
3.
5攻击PeerKey握手PeerKey握手和四次握手相关,被使用在当两个Client需要一个安全的方式来直接通信的时候.
这由两个阶段组成.
第一个阶段一个STSL和SMK的握手会被执行.
它会在两个Client中协商密钥.
而第二个阶段,一个新的会话密钥会通过主密钥产生,并且通过STK握手来传输.
虽然这个协议没有被广泛的支持,但是它很好的展示了我们的密钥重载攻击良好适应性.
不出所料,SMK握手并不会被我们的攻击所影响.
在这之后,主密钥的协商握手并没有被数据保密协议所保护,这就意味着它们没有Nonce和重传计数器来重置.
然而,STK握手是基于四次握手的,它装载了用于数据保密协议的密钥.
因此,他可以像四次握手那样被攻击.
这种攻击在wpa_supplicant上通过了测试.
为了实现这个测试,我们修改了一个wpa_supplicant实例,让它发送第二个(重传)Message3.
这个证实了未修改的wpa_supplicant会在STK握手中接收到重传Message3时重载STK密钥.
然而,我们没有发现其他支持PeerKey的设备.
因此,我们针对PeerKey握手的攻击的影响范围很小.
4攻破组密钥握手在这一节,我们会在组密钥握手中,实现我们的重载密钥攻击.
我们展示所有的Wi-Fi设备都会被这攻击所影响,让攻击者可以重放广播和组播的数据帧.
https://cert.
360.
cn17报告事件:cert@360.
cn表24.
1组密钥握手的细节网络会定期更新组密钥来保证只有近期认证的Client拥有这个密钥.
在多数防御情况下,组密钥会在Client离开网络的时候进行更新.
新的组密钥会通过组密钥握手进行分发,而这个握手过程已经被正式地证明是安全的.
就像图2中展示的那样,握手过程由AP发送信息1给所有的Client开始.
AP也会在没有收到回复的时候重传这个信息1.
注意一下,EAPOL的重传计数器在这些重传信息中总是增加1.
在我们的攻击中,我们的目标是收集一个重传的组信息1,阻止它到达Client,然后在一段时间后再转发给Client.
这会让Client装载组密钥并重置重传计数器.
我们攻击的第一个条件是Client会在装载一个已经用过的组密钥的时候重置重传计数器.
因为Client同样使用MLME-SETKEYS请求安装组密钥,这种情况就会发生.
我们确定在实际中所有的Wi-Fi设备都会在装载一个用过的组密钥的时候重置重传计数器(表1列7).
因此,所有的Wi-Fi设备都会被我们随后的攻击所影响.
第二个攻击条件是我们必须能够收集一个仍然能被Client所接受的组信息1,然后这个信息中包含了已经被AP使用过的组密钥.
如何去得到这个信息取决于AP何时开始使用新的组密钥.
特别的事,AP将会在发送第一个组信息1之后立即使用新的组密钥,或者会延迟装载知道所有的Client都回复了组信息2表明收到了组信息1.
表2第3列总结了一些APhttps://cert.
360.
cn18报告事件:cert@360.
cn的行为.
注意根据标准,新的组密钥需要在收到所有Client的组信息2之后才能被装载.
例如GTK会被延迟装载.
当一个AP会立即装载新的组密钥的时候,我们的密钥重载攻击就很简单了.
然而,如果AP延迟装载组密钥,我们的攻击就会更复杂.
我们将会在4.
2和4.
3节中更详细地讨论这两种情况.
就像2.
3节中所说,AP会广播和组播通过组密钥加密的数据帧.
因为我们的密钥重载攻击目标是Client,这就意味着我们不能在加密的时候强制Client重用Nonce.
然而,Client会在重载组密钥之后重置重传计数器,我们就可以重放这些数据帧给Client.
大多数AP每小时都会更新一次组密钥.
一些网络会在每次有设备离开网络的时候更新组密钥.
而且,Client可以通过发送一个设置了Request和Group位的EAPOL包来触发组密钥的握手.
同样,Broadcom路由器并不会验证这些信息是否正确,这就意味着攻击者可以伪造它们来触发组密钥的更新.
将这些结合起来,我们就可以假设大多数网络会进行组密钥的更新,然后我们就可以实行接下来所说的攻击.
4.
2攻击快速装载密钥的AP图7图7展示了当一个AP会在发送完给所有的Client的组信息1之后立即装载组密钥的情https://cert.
360.
cn19报告事件:cert@360.
cn况下,我们的密钥重载攻击将会如何实现.
注意组密钥的握手信息是通过当前PTK进行数据保密协议来加密的.
作为组信息1的回复,Client会安装新的PTK然后返回组信息2.
攻击者可以阻止AP接收这个组信息2,然后AP就会在攻击的第二阶段重传一个新的组信息1.
我们现在等待一个广播数据帧的发送,然后将其转发给受害者.
在这之后,我们转发阶段二中的重传组信息1.
这样就会导致受害者会重载GTK,从而会重置相关的重传计数器.
这就允许我们来重放广播的数据帧(阶段5).
Client会接收这个数据帧,因为它的重传计数器被重置了.
我们必须在一个广播数据帧之后再发送重传组信息1.
这是因为组信息1包括了当前使用的组密钥的值以及重传计数器.
因此,如果在广播帧之后发送,它就会包含一个更新过的重传计数器,那么我们就不能使受害者的重传计数器重置.
我们确定这种针对快速装载组密钥的AP在实践中是有效的.
基于我们的实验,所有的Wi-Fi设备在连接这类AP之后,都会受到影响.
4.
3攻击延迟装载密钥的AP通过组密钥握手来攻击延迟装载密钥的AP是比较复杂的.
注意上一个攻击方式会因为图7中的第三阶段里那个广播数据包是由旧的组密钥加密而失败.
因为在这种情况下,AP没有接收到从所有Client返回的组信息2,就不会装载新的组密钥,也就不能使旧的组密钥的重传计数器重置.
https://cert.
360.
cn20报告事件:cert@360.
cn图8图8展示了一个能够解决这个问题的方法.
这种攻击的前两个阶段和上一个攻击类似.
就是AP产生新的组密钥,然后将其传输给受害者,然后攻击者阻止AP接收Client发送的组信息2.
这会导致AP重传组信息1,并且EAPOL的重传计数器为r+1.
在攻击的阶段三,我们转发旧的组信息2(重置计数器值为r)给AP.
有趣的是,AP应该接受这个信息,及时它没有使用最新的重置计数器的值(r+1):在接收组信息2的时候,AP需要验证重传计数器的值为曾经在组密钥握手过程中使用过的值.
这个标准不需要重传计数器的值和AP最新的值相匹配,而是需要和在组密钥握手过程用过的值中的一个相匹配即可,也就是任意的组信息1使用的重传计数器的值.
在实践中我们发现,一些实现确实接受了这个旧的还未收到回复的重传计数器的值(表2列2).
因此,这个AP就会装载新的组密钥.
在这种情况下,攻击就会想之前那个一样进行.
直到第一个广播数据包被传输,我们就可以在攻击阶段5里进行重载组密钥的操作,然后在第6阶段中重放广播数据帧.
同样的,我们必须在一个广播数据帧之后再发送重传组信息1.
不然我们的组信息1会包含一个更新过的重传计数器.
我们在一些延迟装载GTK的AP上进行了攻击测试,然后他们接受了先前在和Client发https://cert.
360.
cn21报告事件:cert@360.
cn包时的还未收到回复的重传计数器(表2列2).
我们已经知道所有的Wi-Fi客户端会在重载GTK的时候重置重传计数器,因此他们都会被这种攻击所影响.
最后,一个OpenBSD的AP并不会被影响,因为它是延迟装载GTK的,并且只接受最新的重传计数器而不是旧的.
5针对802.
11RFT握手的攻击在这一节中,我们将介绍FastBSSTransition(FT)握手并证明它的实现也受我们密钥重载攻击的影响.
5.
1FastBSSTransition(FT)握手802.
11r修正案增加了FastBasicServiceSet(BSS)Transition(FT)握手到802.
11[5].
目的是减少客户端从一个AP到另一个相同网络的漫游时间.
(例如相同的基本服务集)此外还需要一个握手,包括新的802.
1x和四次握手(请看图2).
然而,因为FT握手依赖于网络之前连接中派生的主密钥,所以并不需要一个新的802.
1x握手.
此外它将四次握手的阶段嵌在了认证和重组框架里.
一个标准的FT握手如图9的阶段1所示.
图9针对FastBSSTransiton(FT)的密钥重载攻击,注意到它并不需要中间人,仅仅是能窃听和重放帧https://cert.
360.
cn22报告事件:cert@360.
cn图中可以观察到FT握手不像四次握手,它由请求者初始化.
前面两个消息是认证请求(AuthReq)和认证响应(AuthResp).
它们的功能相当于四次握手的Message1和2,产生随机数来作为nonces(新的会话密钥).
在这之后,客户端发送一个重新连接请求(ReassoReq),AP回复一个重新连接响应(ReassoResp).
它们和四次握手的Message3和4相似,用于完成FT握手和传送GTK给客户端.
只有两个重新连接的消息是使用MIC(见图9)验证的,另外,FT握手中没有包含重传计数器的消息.
相反地,在不同握手调用之间,FT握手依靠随机的SNonce和ANonce来提供重放保护[1,§13.
5.
2].
根据标准,在认证响应被发送或接收后必须安装PTK[1,§13.
9].
这在图9的第1阶段的灰色方框里已经标注了.
另外,802.
1x的逻辑端口只有在发送或接收重连请求后才会被打开,这保证了即使握手阶段PTK已经被安装了,AP和客户端也只有在握手完成后才能传输和接收数据帧.
结合起来,表明了802.
11r修正案里定义的FT握手并不容易受到密钥重载攻击.
然而,通过实验和代码检查,我们发现大多数协议实现都是在发送或接收完重连响应后安装PTK和GTK.
这种行为已经在图9的阶段1的黑色方框里阐述了.
结果,在实际中,FT握手的实现容易受到密钥重载的攻击.
5.
2针对AP的密钥重载攻击由于AP是在响应一个重连请求后才安装PTK,所以我们的目标是重放该帧.
我们注意到,在实际中,AP必须接受重连请求的重传.
这是因为AP的重连响应可能由于背景噪声而丢失,所以需要客户端重新发送一个请求.
图9显示针对FT握手的密钥重载攻击.
我们并不需要中间人,只需能够窃听和注入帧就行.
在攻击的第一阶段,我们让客户机和AP执行一个正常的AP握手,然后等待AP传输一个或多个加密数据帧,之后我们重放对AP的重连请求包,因为FT握手不包含重传计数器和有效的MIC,所以AP将会接受并处理该重放帧.
最后,AP将会在攻击的阶段3重装PTK,随之重置相关的nonce和重传计数器.
因此,AP发送的下一个数据帧将会用已经用过的nonce进行加密.
和之前的密钥重载攻击类似,它可以让攻击者重放之前客户端发给AP的数据包.
我们认为该攻击对FT握手的危害尤其大是因为FT的消息不包含重传计数器,这使得攻击者可以不停地重放重连请求,不停地重置AP使用的nonce和重传计数器.
我们测试了三个支持802.
11r的AP.
第一个是用开源的hostapd,第二个联发科设计用于家用路由器,运行在LinksysRE7000上的.
第三个是一个专业的AerohiveAP.
以上三个都受密钥重载攻击的影响.
由于背景噪声,重连响应包如果丢失,客户端将会自动重发重连请求包,这会导致AP密钥重载.
也就是说,就算没有受到攻击,AP也已经重用nonces了.
FT握手没有使用数据保密协议进行额外的保护.
特别是管理帧保护(MFP),它不保护认证和重连帧[1,§12.
6.
19].
因此,FT握手是否启用MFP对密钥重载攻击的防御是微不足道的.
5.
3滥用BSS传输请求FT握手只有从一个站点AP漫游到另一个站点AP时才会被实现.
所以攻击发生的场景https://cert.
360.
cn23报告事件:cert@360.
cn是有限制的.
然而我们可以强制受害者进行FT握手,具体方法如下:首先假设一个客户端连接到了一个支持802.
11r的网络,其次在客户端的网络里没有其他的AP,我们就可以利用虫洞攻击[41]克隆一个真实的AP网络放在客户端附近.
这使得客户端认为目标网络的另一个AP就在附近.
最后我们向客户端发送一个BSSTransitonManagement请求.
该请求帧用于负载均衡[1,11.
24.
7],并命令客户端漫游到另一个AP.
BSS是一个未经验证的管理框架,所以可以被攻击者伪造.
最后客户端接受该请求帧,并使用FT握手漫游到伪造的AP.
我们测试了支持802.
11r的客户端,证明wpa_supplicant,iOS[8],Windows10[52]都会接受伪造的传输请求,并用FT握手漫游到另一个AP.
6评估和讨论在这一节中我们评估nonce重用对于802.
11数据机密性协议的影响,展示攻击场景,和明确漏洞实现,解释为什么安全证明错过了我们的攻击,并提出了对策.
6.
1802.
11协议中重用nonce造成的影响Nonce重用造成的影响取决于使用的数据机密性协议.
对于TKIP,CCMP,GCMP.
三个协议使用了流密钥来加密帧.
因此,对nonce的重用总是意味着重用keystream.
这可以用于解密数据包.
在我们的攻击中受害者的重放计数器会被重置,因此,这三种协议都容易受到重放攻击的攻击.
当使用TKIP时,我们也可以像下面一样恢复MIC.
1.
我们滥用nonce重用来解密一个完整的TKIP包,包括它的MIC字段.
2.
攻击Michael算法,使用给出的明文帧和MIC密文,来恢复MIC明文.
因为TKIP使用了不同的MICkey在每个不同的消息传输方向,我们可以再特定的方向上伪造数据帧.
方向的源头是被重装密钥攻击的设备.
表3在提到TKIP时总结了这一点当使用CCMP时,实际的攻击被限制为对包的重放和解密.
尽管有一些消息伪造攻击讨论,但这些攻击是理论上的,不能用于伪造消息.
当使用GCMP时,其影响是灾难性的.
1.
可以对包进行重放和解密.
2.
有可能恢复身份验证密钥,它在GCMP中用于交互双方两个方向上的通信,因此,与TKIP不同的是,攻击者可以在两个方向上伪造数据包,鉴于GCMP预计将在未来几年在以WiGig的名字广泛采用,这是一个令人担忧的情况.
一般来说,对手总是可以在特定的通信方向上重放、解密或伪造数据包.
具体的方向取决于握手的方式.
例如,通过四次握手攻击客户端,它可以用于1.
重放单播和广播/多播帧给客户端2.
将客户端发送给AP的帧的解密3.
伪造客户端发送给AP的帧https://cert.
360.
cn24报告事件:cert@360.
cn表3:密钥重载攻击对使用了四次握手,FT,组密钥握手数据机密性的协议影响.
每一个小格都展示了在这个方向上的数据帧可以被替换、解密或者伪造然而,攻击FT握手行为中攻击了AP而不是客户端,意味着,攻击者可以在相反的方向重放,解密或者伪造数据包.
表3在附录总结中,考虑了握手被攻击最后,在不同的情况下,我们可以从客户机向AP发送消息(参见表3),有趣的是,AP通常不是数据帧的最终目的地,而是将数据帧转发.
这意味着我们可以伪造数据包发视频发送到任何连接到网络的设备上.
根据AP的不同,甚至可以发送一个数据帧反射回到客户机.
6.
2攻击场景在其他方面,密钥重载攻击可以让攻击者解密TCP数据包,知道传输序号,挟持TCP数据流注入任意数据.
对wifi网络最常见的攻击之一是:在未加密的HTTP连接中注入恶意数据.
https://cert.
360.
cn25报告事件:cert@360.
cn重放广播和多播帧的能力.
比如:组帧,也是一个明显的安全违规.
为了说明这将如何影响实际系统,请考虑在广播模式下运行的网络时间协议(NTP).
在这种模式下,客户端首先通过一个初始化过程,然后通过监听身份验证的广播NTP数据包来同步它的时钟.
Malhotra和Goldberg已经表明,如果这些广播包被重放,受害者将永久被困在一个特定的时刻.
使用我们的组密钥攻击可以重放这些帧,即使它们是通过一个受保护的无线网络发送的.
注:以这种方式操作时间会破坏安全性,例如TLS证书,DNSSEC、Kerberos身份验证和比特币.
另外一个例子是xAP和xPL家庭验证协议.
这些使用UDP广播包给设备发送命令.
我们推测,密钥重载攻击允许我们重放这些命令.
所有这些例子都说明,重播广播或多播帧的影响不应被低估.
6.
3全零加密密钥漏洞密钥重载攻击对于四次握手的攻击发现了wpa_supplicant的特殊行为1.
2.
3版本和更低的版本在很容易受到攻击,没有任何意外的副作用.
2.
我们发现当接收到重新传输的message3时,2.
4和2.
5版本安装了一个全零加密密钥(TK).
这个漏洞似乎是由802.
11标准中的一句话引起的,该标准间接建议在安装了TK之后,从内存清除它.
3.
版本2.
6修复了这个bug,只在第一次接收Message3时安装了TK.
然而,在修补这个bug时,只考虑了一个良性的场景:message3被重新传输是因为message4由于背景噪音丢失.
他们没有考虑到一个活跃的攻击者可以滥用这个漏洞来强制安装一个全为零的密钥.
因此,补丁并没有被视为严重的安全问题,也没有被移植到较老的版本中.
独立于这个bug,所有版本的wpa_supplicant在接收时重传的message3时重新安装组密钥,也容易受到第四章所说的组密钥攻击.
因为Android内部使用的是一个稍微修改过wpa_supplicant的版本,它也会受到这些攻击的影响.
特别地,我们检查了Androidwpa_supplicant关键源代码,并发现所有的Android6.
0版本都包含了全零加密密钥的漏洞.
androidwear2.
0也很容易受到这次攻击.
尽管第三方厂商可能会在他们的Android版本中使用不同的wpa_supplicant版本,但这说明大多数Android6.
0版本都容易受到攻击.
换句话说,31.
2%的Android智能手机很容易受到全零加密密钥漏洞的影响.
最后,我们还从经验上证实,Chromium很容易受到全零加密密钥漏洞的影响.
6.
4安全证明的限制有趣的是,我们的攻击并没有违反对四次握手和组密钥握手的安全属性.
1.
他人证明了四次握手提供了密钥保密和会话认证.
密钥保密表明只有authenticator和supplicant将会拥有PTK.
因为我们没有恢复PTK,所以这个仍然正确.
会话身份验证使用了匹配会话的标准概念.
直观地说,协议时安全的除非攻击者能依赖消息参与到完成这个协议中.
我们的攻击,包括我们使用的基于信道的中间人攻击,并不违反此属性:我们只能通过转发(转发)消息使端点完成握手.
2.
他人证实了组密钥握手中key的有序性和key保密性.
密钥有序性确保supplicant不安https://cert.
360.
cn26报告事件:cert@360.
cn装旧的GTK.
这在我们的攻击中仍然是正确的,因为我们重新安装了新的的组密钥.
另外,我们不知道组密钥,因此我们的攻击也不违反密钥保密.
然而,这些证明并没有对密钥安装进行建模.
不同的是,它们不会声明密钥重载使用了数据机密性协议.
在实践中,这意味着相同的密钥可以多次安装,重置为了保证数据机密性中使用的nonce和重放计数器6.
5对策密钥重载攻击可以在两层上减轻.
1.
实现数据保密协议的实体应该检查是否已经安装了已经使用的密钥.
如果是这样,它不应该重置相关的nonces和重放计数器.
这可以防止我们的攻击,至少攻击者不能临时欺骗去实现在重新安装当前的key之前安装一个不同的(旧的)密钥.
特别是,当使用这个对策时,接收组密钥的握手重放计数器只会增加.
否则,攻击者可以使用旧的Groupmessage1来临时安装一个旧的(不同的)密钥,然后使用现有的groupmessage1重新安装新的组密钥.
2.
第二种解决方案是确保在握手过程中,在实现数据保密协议的实体中只安装一个特定的密钥.
例如,在四次握手过程中生成的会话密钥应该只安装一次.
当客户端接收到一个重新传输的message3时,它应该回复,但不能重新安装会话密钥.
这可以通过在图3的状态机中添加一个布尔变量来实现.
它被初始化为false,当在PKT-START时生成一个新的PTK时,它将被设置为true.
如果在输入PTK-DONE且布尔值为true,则会安装PTK并将布尔值设置为false.
如果在输入PTK-DONE时布尔值为false,则跳过PTK的安装.
注:这正是2.
6版本的wpa_supplicant实施的.
证明上述对策的正确性:我们NuSMV中对改进状态机进行了建模,并使用该模型证明了两个安装key总是被新的PTK分离.
这意味着相同的密钥从未安装过两次.
注:key保密性和会话身份验证已经在其他工作中得到了验证.
我们目前正在通知供应商关于我们发现的漏洞,这样他们就可以实施这些措施.
我们所熟知的各种攻击的变种将会被提供给一个供应商名单.
6.
6讨论从我们的结果中可以学到一些重要的教训.
首先,协议的规范应该是足够精确和明确的.
例如,当我们在第3.
3节中攻击四次握手时,我们注意到802.
11标准对于应该被接收的重放计数器的值是不明确的.
更精确或更正式的规范将避免这种潜在的不正确的解释.
其次,这并不是因为协议已经被正式证明是安全的,它的实现也是安全的.
在我们的例子中,在正式证明中使用的四次握手模式并没有完全反映现实.
这是因为它没有定义何时应该安装协商的会话密钥.
因此,不能保证只安装一次会话密钥.
只有当我们读代码才发现正式模型并没有和显示情况相匹配,这些key可以重新安装.
在这方面,正式的证明实际上可能会适得其反:一旦一个协议被正式验证,社区可能会对审核实际的实现变得不那么感兴趣.
有趣的是,一个模型可能是错误的,因此并不能准确地反映现实,也同样适用于我们自己的对策的证明.
换句话说,不是因为我们在NuSMV中建模了对策,所有的实现现在都突然变得安全了.
在现实中,我们的正式状态机可能无法准确地反映某些实现,供应商实现可能有缺陷,或者供应商可能受到未知的攻击的影响.
因此,保持审计和测试实际实现是非常https://cert.
360.
cn27报告事件:cert@360.
cn重要的.
另一个教训是,数据保密协议应该为nonce重用提供一些保护.
例如,对于GCMP,可以在nonce重新使用时恢复身份验证密钥,而对于CCMP来说则不是这样.
更广泛地说,应该使用一种nonce抵制重用加密模式,比如aes-siv、gcm-siv或hs1-siv.
这些减少了nonce重用的影响,也降低了key重新安装攻击的影响7相关工作本章节我们将探索密钥重载攻击的历史,并对其它Wi-Fi和协议安全工作进行一个概述.
7.
1密钥重载攻击我们并不清楚密钥重载攻击之前的一些研究,这很可能因为之前Wi-Fi握手包密码仍然易受到攻击.
我们也是现在才发现长达14年的四次握手会受到密钥重载攻击的影响.
此外,该缺陷不仅存在实现中,而是在协议规范(标准)本身.
电源故障也会导致nonce被重用.
电源故障后,key从boot的非易失性存储器里被恢复,但是nonce会被重置为初始值.
对于这个问题,Zenner在参考文献[76]提出了解决方案.
然而,和密钥重载攻击不同的是,触发电源故障不能通过网络进行远程实施.
这需要对被攻击的设备进行物理访问.
另外,电源故障不影响我们所研究的协议的安全性,因为这些握手协议是用来避免维护新旧连接的状态.
在参考文献[16],Bock等人发现一些TLS服务器正在使用静态的nonces,这是由TLSrecordlayer协议的错误实现引起的.
就是说,它不是由重装一个已经使用过的key引起的.
此外,有些服务器使用随机产生的nonces,这意味着在实践中很可能因为生日悖论攻击导致nonce重用.
相反,密钥重载攻击允许攻击者通过重放握手信息强制重用nonce,这是由于握手协议的规范(或实现)而导致的缺陷.
McGrew写了一篇关于产生IVs和nonces的最好实现的调查报告,并总结了它们是如何在协议中被生成和使用的[51].
然而在讨论安全风险时,没有提到密钥重载攻击.
另一个相关的工作是Beurdouche等人[14]和deRuiter,Poll[27]所进行的.
他们发现了几个TLS实现存在缺陷的机器.
错误的实现导致握手信息可以被重放.
然而他们不能提供针对重放信息的攻击样例.
我们猜想攻击者可以重放特定的信息欺骗站点重装一个TLS会话密钥,即密钥重载攻击存在可能性.
我们认为能否实施实际的攻击在未来的工作里是很有趣的一点.
重用IVs在千疮百孔的WEP协议[17,18]里也存在问题.
特别值得一提的是,Borisov等人发现某个无线网卡每次初始化时都将WEPIV初始为零.
因此,较小的IVs值产生的密钥流可能被重用[18].
然而,和密钥重载攻击不同的是,重置IV值不能被远程触发.
7.
2Wi-Fi和网络协议安全在对四次握手的一次正式分析中,何和Mitchell发现了一个拒绝服务漏洞[38,55].
这促使四次握手规范的改善[1].
2005年,何等人提出了一个关于四次握手和组密钥握手的正确https://cert.
360.
cn28报告事件:cert@360.
cn性证明[39].
但是他们没有对密码选择和降级进行准确地建模.
这使得Vanhoef和Piessens提出了针对四次握手的降级攻击[72].
在他们的攻击里,在传输Message3时,AP被欺骗使用RC4来加密组密钥.
这种攻击只有在支持WPA-TKIP的网络里有效,因为WPA-TKIP显然是一个不安全的加密协议[66,69].
此外,在参考文献[39]中使用的模型没有定义何时安装协商的会话密钥或者传输的组密钥.
然而我们认为这一时机十分重要,有可能会导致密钥重载攻击.
FT握手是基于四次握手的[5],但是业界没有对它进行正式的安全性分析.
现有的工作重点都是放在握手的性能上.
例如参考文献[11,46].
部分工作是研究协商主密钥(PMKs)的认证机制[19,21,59,75].
其中一些机制依赖于初始时创建一个安全的TLS会话[9].
因此,近期对TLS的攻击也会影响这些机制.
例如[10,14,15,27,62].
本文中我们对协商主密钥进行研究,而把主要精力放在如何从协商主密钥或预共享主密钥中获取新的会话密钥.
Beck和Tews在WPA-TKIP上实现了第一次关于数据保密协议的实际攻击[66].
他们展示了如何解密一个小TKIP数据包,恢复MICkey,之后对数据包进行了伪造.
他们的攻击进一步改善当前的一些工作[36,67,69,70].
研究人员还利用RC4的缺陷对由弱key构建的TKIP包进行攻击[6,57,71].
如今TKIP因为其安全问题已经被Wi-Fi协会所摒弃.
尽管CCMP收到一些批评[60],但它已经被证明可以提供类似OCB模式的安全保障.
在参考文献[31]中,Fouque等人讨论了在CCMP中nonces被重用时消息伪造攻击的原理.
众所周知,GCM密码在使用短验证标签和重用nonces时是脆弱的.
Bck等人实际研究了当GCM在TLS被使用时nonce重用问题,发现一些服务器确实存在nonces重用问题.
我们的攻击在802.
11上的GCMP和之前不同是因为当一个端点重用nonce时我们可以对其进行控制.
并且GCMP在连接双方使用相同的认证key.
所以涉及到GCM的加密协议就会显得脆弱[35,56].
最后,在Wi-Fi实现或者相关技术上的安全问题的一些工作值得被注意.
例如在Wi-Fi保护设置(WPS)上发现了设计缺陷[73],在驱动程序[13,20]发现了漏洞,路由器被发现可以使用预共享key,等等.
8.
总结尽管四次握手和组密钥交换握手都被证明为安全的,但我们展示出它们都存在被密钥重载攻击的可能.
这些攻击方式和已经被证实的安全标准并不冲突,但是强调了它们所使用的模型的限制.
特别的,模型没有指定何时应该装载一个用于数据保密协议的密钥.
更多的,我们展示了PeerKey和fastBSSTransition握手同样会被密钥重载攻击所影响.
所有我们测试的Wi-Fi设备都会被针对组密钥握手的攻击所影响.
这就允许攻击者重放广播和组播的数据帧.
当四次握手或者fastBSSTransition握手被攻击的时候,这种影响范围取决于它们使用的哪一种数据保密协议.
在所有情况下,都有可能解密数据帧,因此可以劫持TCP链接.
这就允许攻击者向未加密的HTTP连接中注入数据.
更多的,针对Android6.
0,我们的攻击使其装载了一个全为零的密钥,这让所有的安全保障都失效了.
更令人担心的是,如果我们的握手信息由于背景噪音而丢失,密钥重载攻击可能会自动地进行.
这意味着,在一定的条件下,即使没有攻击者,nonces也可能被重用.
将来一个有趣的研究方向是其他协议的实现是否也会受到密钥重载攻击的影响.
考虑到https://cert.
360.
cn29报告事件:cert@360.
cn消息可能丢失的协议可能会显得特别脆弱,毕竟这些协议用设计用来重传帧时,就有可能密钥重载.
致谢这篇研究是由KULeuven基金和theimecHighImpactInitiativeDistributedTrust赞助.
参考链接https://papers.
mathyvanhoef.
com/ccs2017.
pdfhttps://www.
krackattacks.
com/