WiFi加密之WPA3-SAE浅谈
时间:03月12日 人气:...

话不多说,直接开始。

一. 联网流程

wpa3也是在rsn ie中体现其加密类型的,下面用张图说明wpa/wpa2-psk和wpa3-sae的区别:

可以看到,AKMP中00-FC-AC-02表示是wpa-psk,00-FC-AC-08表示是wpa3-sae。

当联网使用wpa3-sae时,整个联网流程如下图:

可以看到auth过程变得和wep shared类似,这是因为sae会在联网最开始用auth帧协商出pmk:sta 发送auth alg 3 seq 1,ap回复auth seq2,sta继续发送auth seq 3,ap回复auth seq 4,如无失败,则pmk协商成功,就可以进行下一步关联。

本文不会提及去看看哪本协议,我相信跑来网上找资料的朋友基本上是不会去看协议原文的,所以对此过程auth交互代码实现感兴趣的朋友,可以去看看wpa_supplicant中的sae.c文件,开始入口函数为sme_external_auth_trigger,收到auth帧处理入口函数为sme_external_auth_mgmt_rx。

关联时asso req帧的rsn ie中只会填sae:

关联成功之后,就会进入四次握手的密钥协商流程,此过程不再介绍,sta代码可参考wpa_supplicant中的wpa.c文件,三个入口函数为wpa_supplicant_process_1_of_4、wpa_supplicant_process_3_of_4和wpa_supplicant_process_1_of_2,softap的代码可读性较差不建议阅读。

二. PMK caching

我们可以发现,正常的sae连接过程共需要4个auth帧,而且这个阶段需要进椭圆曲线计算,也比较耗时,那么有没有什么机制加速一下这个过程呢?

当然是有的。

AP可以保存PMK,当sta下次连接AP时就可以和wpa-psk一样,直接发送alg=0的auth帧,AP也回复一次auth帧即可,

然后sta发送的关联帧(或重关联帧)的rsn ie中只要携带pmkid,

那么关联之后同样也就进入了四次握手协商密钥的阶段,这样就能节省sae协商pmk的环节。

至于AP保存的PMK具有多久的时效我目前没有研究明白,我也没有从协议中看到明确说明,如果有人了解这个不妨告诉我。根据我的测试,在某些AP下,sta发送disasso帧,AP不会清除PMK;sta发送deauth帧,ap会清除PMK;也有AP始终不清除,直到自己掉电……

如果关联时携带了pmkid,而AP回复的asso resp帧的status为53,则直接表示pmkid无效,当然也会有例外,有些AP会用status为40表示pmkid无效或自己不支持此功能。

为了兼容性,根据我的观察,当sta使用pmkid联网被AP拒绝后,应该不携带pmkid再次尝试联网一次或许就可以了。

对于PMK caching,wpa_supplicant也是做了实现的,其代码可参考pmksa_cache.c。

三. 管理帧保护

有些资料称之为pmf,也有地方称之为mfp,本文用mfp表示。

在wpa2年代,mfp仅仅是可选,但是在使用wpa3时则mfp是强制要用,此要求可在rsn ie体现:

MFPC为1则说明ap支持mfp功能,为0则说明ap不支持mfp;MFPR为1则说明mfp需要要用,为0则说明可用可不用。

mfp用来加密关键管理帧,关键管理帧包括deauth、disassoc和部分action帧。这里我列出当前协议规定的需要加密的action帧,category如下表:

category
0
1
2
3
5
6
8
9
10
12
13
14
21
126
128

mfp要求sta和ap都对关键管理帧进行加密,如果某一方收到对方非加密的关键管理帧,则需要发送一个加密的sa query帧(action帧的一种)鉴定对方是否有效,对方需要在一定的时间内回复一个加密的sa query resp帧,所以对于假冒者发送的管理帧会因为sa query交互失败而被忽略,从而保证了安全。


这里需要强调,单播的管理帧也是使用ptk进行加解密的。但是广播管理帧有点不同:

在组密钥协商时除了得到一个gtk,还会得到一个igtk。ap发送广播管理帧时并不会使用gtk加密此报文,而是使用igtk将管理帧内容用aes-128-cmac算法进行计算得出一个64 bit的mic,然后将此mic值添加到管理帧的一个叫做管理帧mic的ie中(ie号为76),最后将此广播管理帧明文发出。当sta收到广播管理帧后,需要自己使用igtk对报文内容计算出mic,和报文mgmt ie中携带的mic进行比较是否一致,如果一致则说明是ap发送的管理帧,否则就是假冒的。

加密的广播管理帧如下图所示:

我理解使用igtk是因为同一个ap下的sta的gtk都是相同的,所以为了防止同一个ap下的某些sta故意模仿ap恶意广播管理帧做得保护。


写到这里本文基本上就写完了想要介绍的东西,最后我谈一点有意思的事情。

似乎使用了mfp就非常安全,之前那种模拟ap不停发送deauth帧做的断网神器就不太可能了。然而我举个例子,比如sta已经连上了ap,并且使用了mfp,这时此sta直接掉电重启,然后发个明文deauth,然后从auth开始联网,这时就可以很顺利重新连上网了。所以mfp机制确实是安全的,但是在实际的ap实现中,ap厂商可能也为了兼容性,他们在实现上并没有严格的遵守协议的某些要求,甚至有的路由器连action sa query机制都没,所以就会出现这种漏子。

热门评论